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) — curator, librarian, command-interpreter. Off the critical path; removing PM degrades to manual mode without breaking the workflow.
• Developer (agent-dev) — the worker. Claims issues, runs phase prompts (simple, investigate, propose, apply), opens PRs, maintains its ledger.
• QA (agent-qa) — 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.

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 — 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.