# Workflow Roles

This reference defines responsibility without turning collaboration into admission ceremony.

## Authorizing User

The Authorizing User is the person empowered to approve the requested work, whether a developer,
maintainer, operator, or product lead. The Authorizing User approves the final Post objective and any material change to intent, acceptance,
public contracts, security/privacy/data/migration/release behavior, repository or runtime-dependency
boundaries, or risk tier. That approval is the sole Build authority.

The Authorizing User may explicitly request peer review. Silence means no review; do not routinely ask.

## Primary Agent

The primary agent owns investigation, the five-section Post packet, adaptive implementation, QA
selection, diff and ownership review, material-drift judgment, and the Ship handoff. It may delegate
bounded implementation or factual work without surrendering those decisions.

The primary agent independently verifies, adopts, or rejects reviewer findings; never seeks mere
re-endorsement; and surfaces unresolved disagreement to the Authorizing User.

## Optional Peer Reviewer

A peer reviewer supplies advisory evidence when the Authorizing User requested review. Review can find
material correctness, safety, maintainability, or acceptance problems. Its process status is not a
gate: no reviewer metadata, availability proof, receipt, quoted attestation, digest, or verdict is
required to Build or Ship.

The primary agent independently evaluates findings. A valid issue blocks because it makes the
objective unsafe or incorrect, not because the reviewer used a blocking label.

## QA Process

When delegated QA is useful, use one visible command-capable process for the objective. It owns raw
command output and returns compact receipts from `quality-assurance.md`. It does not approve the
plan, implementation, commit message, or launch.

Delegation is optional. Command capability required by the objective must exist somewhere, but a
specific QA agent, model, provider, or route is never admission authority.

## Ship

Ship verifies Authorizing User or direct-user authority, final-tree ownership, required QA, material
drift, temporary-link and migration boundaries, and narrative commit coherence. Ship may create
coherent commits but does not reopen the plan through mandatory downstream review.

## Bounded Collaboration

Optional implementation assistance and factual checks receive a concrete scope, repository path,
ownership boundaries, validation limits, and an instruction not to publish, deploy, mutate registry
state, or cross user-owned migration/link boundaries. Their output is context for the primary agent,
not an approval receipt.