butschster/kickside-hr — HR

Hire employees from the harnsy catalog (https://hr.harnsy.dev) as KickSide agents. A user browses the catalog, reads an employee's CV and hires them from the KickSide web UI; the hire becomes an ordinary user agent they can edit, chat with or delete in KickSide.

The module owns only the catalog domain and reuses the platform for the rest:

• The agent — kickside/agents (kickside.agents:agents create), a user agent component owned by the hirer.
• The agent's skills — kickside/skills: each bundle skill becomes a KickSide skill and the agent gets the Skills capability pinned to them.
• Access control — the host router and the component service; every write runs under the caller's own actor and scope.

What it ships

• GET /hr/catalog?q=&department= — public catalog cards, departments with counts, the feed's seq and expiry.
• GET /hr/cv?id=&version= — downloads and verifies one pack and returns its CV with the pack sha256 the hire must match.
• POST /hr/hire {id, version, expect_sha256, name, model?, skills?} — creates the skills, then the agent, then the hire row; a failure undoes what was made.
• GET /hr/hires — the caller's hires with origin, sha256, licence and attribution.
• GET /hr/avatar?id=&version= — an employee's avatar PNG. A card's image is fetched once from https://hr.harnsy.dev/packs/ and then served from the module's database; a CV read or a hire stores the pack's own avatar.png, checked against the pack manifest.
• The HR page — a web component (butschster-kickside-hr) at /hr in the app nav.
• The HR assistant — a system agent (butschster.kickside_hr.agents:assistant, class:balanced) in the chat agent picker as soon as the module is installed. Its tools search the catalog, read a CV and hire through the same code as the page, under the chatting user; a hire needs the user's explicit confirmation (confirmed: true) and the CV's sha256. Being a system agent, it is not listed on the Agents page, which lists users' own agents.

Trust in version 1

Packs are checked over HTTPS against the feed's sha256 and size, then every file against the pack manifest's hashes. The catalog's Ed25519 signature is not checked yet; the UI says so. Skill scripts are never run: they are left out of the hired skills and listed on the CV and the hire. The HTTP client may reach https://hr.harnsy.dev/* only.

Requirements

• butschster.kickside_hr:api_router — the authenticated API router (app:api).
• butschster.kickside_hr:ui_server — the HTTP server for the web component (app:gateway).
• butschster.kickside_hr.store:target_db — the SQL database for the hires table (app:db).
• butschster.kickside_hr.security:user_security_scope — the user group allowed to reach the endpoints, read the HR nav item, and resolve the HR assistant and call its four tools. Nothing else in the module is opened to it.

Install

wippy add butschster/kickside-hr
wippy install

The defaults bind the requirements to a standard KickSide app (app:api, app:gateway, app:db, app:user). The migrations create the kickside_hr_hires and kickside_hr_avatars tables; the HR page appears in the nav and the HR assistant in the chat agent picker after a restart.

Development

cd test
wippy update      # after dependency changes
wippy test        # feed, pack, CV, hire plan, hire end to end, wiring
wippy lint --ns 'butschster.kickside_hr.*'
npm --prefix ui ci && npm --prefix ui run build   # web component → static/

Tests on PostgreSQL: make postgres-up, make test-pg, make postgres-down.

Publishing

The version is chosen at publish time and is not pinned in wippy.yaml:

make release-check VERSION=0.1.0   # verify + dry-run pack
make publish VERSION=0.1.0         # private by default; VIS=public to publish openly

Not in version 1: signature checks, updates of a hired employee, revoked versions, a feed cache.