# Agents

FJX defines a small set of named roles. Each is a separate Forgejo account, with its own phase prompts, its own work ledger on every issue it touches, and its own narrow set of authorities.

- [**Project Manager (`agent-pm`)**](./pm.md) — curator, librarian, command-interpreter. Off the critical path; removing PM degrades to manual mode without breaking the workflow.
- [**Developer (`agent-dev`)**](./dev.md) — the worker. Claims issues, runs phase prompts (`simple`, `investigate`, `propose`, `apply`), opens PRs, maintains its ledger.
- [**QA (`agent-qa`)**](./qa.md) — the deliberately-misaligned second pair of eyes. Reads the Actions output, finds the gaps the harness can't catch, returns pass / concerns / fail.
- **Builder (`agent-build`)** — *planned.* Release manager. See below.

The **human** (`$FJX_OWNER`) is not an agent but carries authority that no agent has: the trust map for `/<command>` directives, `/spec-approved` for design-gate decisions, and the final merge.

For the broader framing — how these roles map onto the five leadership "chairs" — see [Roles & Chairs](https://git.tfks.net/tfks/fjx/src/branch/main/wiki/roles-chairs.md).

## Builder (`agent-build`) — planned

`agent-build` is the **release manager** role. It does not exist yet. This section sketches the intent so the design is visible before code lands.

### The job

Owning the release path: tagging, building artifacts, publishing to registries, drafting release notes, gating prod deploys. Today these steps are handled by Actions on `main` plus human attention; `agent-build` would consolidate them under a named owner with its own work ledger and its own narrow set of authorities.

### The chair it picks up

Build maps onto the **operator chair** from [Roles & Chairs](https://git.tfks.net/tfks/fjx/src/branch/main/wiki/roles-chairs.md) — documented triggers rather than nervous-system vigilance. The four canonical trigger categories all land on build's surface:

- **Cost** — dollar threshold per release (CI minutes, registry storage, deploy compute).
- **Irreversibility** — deletions, external sends (release announcements, customer emails), prod deploys, migrations. Always escalate.
- **Confidence** — build's self-rated confidence on a tagged version. Below threshold, escalate.
- **Drift** — release notes vs the actual change set. Did the release ship more than the changelog claims?

### Why it isn't shipped yet

The platform-lead chair (blast-radius permissioning) is thinner than the operator chair, and `agent-build` is the role where that gap hurts most. Prod deploys, tag pushes, migrations, and release-note sends are exactly the high-blast-radius actions that flat boundaries don't cover well. Shipping `agent-build` before action-tiered permissions exist is the loud-failure-mode shape ROLES.md warns about.

The current plan: design the permission tiering first (read / staging-write / prod-write / delete / external-send), then build the agent against it.