Workflow states and agent attribution

This is the FLOW-09B contract for the released opt-in workflow. A task's four-value status is a broad index. The current workflow.phase and ordered workflow_get.history are the authority for execution progress. Every phase transition updates the workflow row, appends a sequenced event with a server timestamp and updates the task's broad status in one PostgreSQL transaction. The Bridge execution event is also stored with its sequence and lease fencing.

User-facing meaning	Persisted workflow phase	Broad task status	Who causes the transition	Next observable action
Task defined, waiting for issue	No workflow	todo	Task author	Select worker, verifier, criteria, Git base and Bridge policy. No agent is assigned yet.
Ready for issue	ready event	todo	Server during authorized dispatch	Freeze the selected worker/verifier versions and create the first offer. This phase is normally transient within dispatch.
Issued to Bridge	queued	in_progress	Server creates an offered execution	Authorized Bridge can poll and claim it.
Bridge accepted the offer	claimed	in_progress	Bridge claim, validated by server	Lease exists; native provider is not yet ready.
Preparing agent session	preparing	in_progress	Bridge ordered event	Materialize the selected profile and workspace.
Worker doing the task	running	in_progress	Bridge running event with native provider session ID	Worker produces a clean Git candidate and evidence reference.
Candidate ready for tests	awaiting_verification	in_progress	Server after valid worker completion	Server creates a separate verifier offer. This is not acceptance.
Verifier picked up work	claimed, then preparing	in_progress	Verifier offer claimed; Bridge prepares a fresh session	active_purpose=verify distinguishes these phases from worker claim/preparation.
Independent tests under way	verifying	in_progress	Bridge running event for verifier session	Verifier submits a verdict for every frozen criterion.
Changes required	changes_requested event	in_progress	Server after a valid failed verdict	If budget remains, a fresh worker attempt is offered and current phase becomes queued in the same transaction; the event remains in history. UI labels the new queue as a correction.
Correction in progress	queued → claimed → preparing → running	in_progress	Server and Bridge, with incremented work count	New native worker session receives verifier feedback and candidate base.
Accepted and closed	done	done	Server after a valid all-pass independent verdict	Exactly one acceptance receipt and completed handoff are written atomically. Git publication is a separate action.
Cannot continue safely	blocked	blocked	Server on failed/interrupted/missing evidence, exhausted corrections or expired lease	Read the reason; a new authorized workflow revision is required. No ambiguous automatic replay.
Operator cancelled	cancelled	blocked	Authorized operator through workflow control	The attempt is cancelled; no acceptance receipt is invented.

ready and changes_requested remain durable events even when their current phase immediately advances in the same transaction. The task list can therefore show queued while history shows the failed verdict and correction request. A plain task.status=in_progress never proves which agent is active.

The assignment is explicit at dispatch: workflow_dispatch_catalog selects worker and verifier agent_id and version, provider account, pinned instruction sources, Bridge enrollment identity, Git base and acceptance criteria. The server freezes both profiles; Bridge does not choose or substitute an agent. Before dispatch an ordinary todo task has no assignee field. The operator or client is responsible for selecting both roles when issuing it.

For attribution, task_list/task_get include worker and verifier profile versions and the current attempt purpose/ID. workflow_get includes the frozen contract, current attempt, ordered events and a bounded list of every execution attempt: purpose (work or verify), selected profile/version/model, Bridge enrollment ID, execution ID, process state and native provider session ID. The event's execution_id joins to that list. actor_subject=server on a server transition identifies the writer of the durable event, not the human or native agent who performed the work. Each terminal attempt also has a work receipt; final acceptance has its own server receipt.

The server verifies sequence, lease, attempt ownership, candidate commit, contract digest, independent verifier session and complete criterion results. It validates references and attribution; it does not independently run the tests described in a verifier's evidence. Work Center is a refreshed view of these records. A stale lease is displayed as expired even before reconciliation changes the phase to blocked.