# Task state (authoritative text)

The project's human-readable plan is the only task-state record. Diagrams explain; they never authorize a transition, create state, or grant authority.

## States and active owners

| State | Active owner | Meaning |
| --- | --- | --- |
| `PROPOSED` | Parent controller | Task exists but is not execution-ready |
| `READY` | Parent controller | Dependencies, scope, authority, and route are satisfied |
| `WAITING_ON` | Parent controller | Named prerequisite, checkout-lease conflict, or independent-assurance dispatch unavailable |
| `IN_PROGRESS` | Assigned worker or parent controller | Assigned action is being performed |
| `EVIDENCE_READY` | Parent controller | Candidate and evidence ready for next missing assurance |
| `VALIDATING` | Assurance Test Engineer | Evidence sufficiency under validation |
| `REVIEWING` | Reviewer when required | Independent defect review active |
| `ACCEPTANCE` | Integration Engineer execution, Owner Authority, or parent controller when `required_assurance` is `none` | User-facing acceptance or parent-controller completion confirmation is active |
| `CORRECTION_REQUIRED` | Orchestrator or nearest parent controller | Agent-owned in-authority correction required |
| `OWNER_DECISION_REQUIRED` | Owner Authority | Authority, scope, security, or replacement-path judgment required |
| `COMPLETE` | Parent controller after assurance | Outcome and required assurance satisfied |
| `CANCELLED` | Owner Authority or authorized parent | Task will not proceed |

## Legal transitions

- `PROPOSED` → `READY` when dependencies, scope, authority, assigned role, and assurance are declared and satisfied; else `WAITING_ON`.
- `WAITING_ON` → `READY` when the prerequisite is repaired or replaced; → `EVIDENCE_READY` when fresh assurance becomes available; → `CANCELLED` on owner scope reduction.
- `READY` → `IN_PROGRESS` when the assigned role starts; → `OWNER_DECISION_REQUIRED` on authority or integrity guard.
- `IN_PROGRESS` → `EVIDENCE_READY` with candidate and handoff; → `CORRECTION_REQUIRED` on correctable failure; → `OWNER_DECISION_REQUIRED` on security, authority, or integrity guard.
- `CORRECTION_REQUIRED` → `READY` with a new hypothesis and evidence inside the recorded authority and any owner-supplied allowance; → `OWNER_DECISION_REQUIRED` when that allowance is exhausted or an out-of-contract amendment is needed.
- `EVIDENCE_READY` → `VALIDATING` | `REVIEWING` | `ACCEPTANCE` for the next missing required role; → `WAITING_ON` if assurance dispatch is unavailable.
- During the single assurance round, an accepted Assurance Test Engineer or Reviewer handoff returns to `EVIDENCE_READY` to select the next missing assurance role in declared order.
- `VALIDATING` → `CORRECTION_REQUIRED` when more evidence or repair is needed; otherwise back through `EVIDENCE_READY` for remaining assurance.
- `REVIEWING` → `CORRECTION_REQUIRED` | `EVIDENCE_READY` | `OWNER_DECISION_REQUIRED` by verdict.
- `ACCEPTANCE` → `COMPLETE` when every required assurance accepted the same candidate; when `required_assurance` is `none`, parent-controller confirmation satisfies the assurance requirement; → `CORRECTION_REQUIRED` on acceptance gap.
- `OWNER_DECISION_REQUIRED` → `READY` or `CANCELLED` by owner choice.

## Ownership rules

- One parent controller writes each task block and its transitions. The parent controller is the Orchestrator on a direct packet and the Coordinator on a coordinator wave.
- Orchestrator alone writes cross-wave dependencies and Lifecycle-wide sequencing. Direct packets never dispatch Coordinator. `roles.coordinator.enabled` means the route is available, not that every packet gets a Coordinator. A wave that needs Coordinator while the route is omitted or disabled is a typed capability gap, not silent Orchestrator substitution.
- Workers and assurance roles return handoffs; they do not race plan edits.
- Candidate authors never provide their own Assurance Test Engineer, Reviewer, or Integration Engineer execution verdict. Implementer must not self-certify.
- Waiting on a prerequisite consumes no correction attempt. Record corrections as evidence, not a fixed attempt cap. Preserve any owner-supplied allowance; identical retries without new evidence are invalid.
- Each declared phase or wave receives at most one assurance round and one review-directed repair. Replacement candidates do not reset the count within that declared unit; the next distinct declared phase or wave carries its own 1/1 budget. The parent controller records `assurance_rounds`, preauthorizes bounded same-session repair in the review packet, and records deterministic closure from the repaired candidate’s evidence without dispatching assurance again.
- `COMPLETE` is terminal for Bearing assurance. An already authorized deployment keeps operational verification and rollback readiness but does not reopen review; candidate-changing deployment work requires separate scope.

## Landing a closed unit

Landing moves a closed unit toward the repository's default branch. It is
delivery, not assurance: it never opens or reopens a review.

- **When:** a declared wave or phase, or a direct packet, is closed once its
  deterministic checks pass and any owner-requested review round has closed
  through its deterministic gate. The parent controller (Coordinator on a
  coordinator wave, Orchestrator on a direct packet) lands it before reporting
  the unit `READY` or `COMPLETE`. A unit is not landed while its requested
  review is pending.
- **Commit:** revalidate the wave receipt at `commit`, then commit the closed
  candidate on the leased Lifecycle branch. Never commit on the default
  branch. Run the unit's exit commands after that last commit, and keep raw
  logs out of commits.
- **Push and pull request:** push the Lifecycle branch, then open or update one
  pull request to the default branch. Name the unit, candidate revision,
  deterministic and review receipts, and the issues it addresses. Planning
  proposes `commit`, `push`, and `open_pull_request` in the authority
  envelope's `allowed.actions`, and the integrated approval grants them.
  Without them, or with them in `prohibited.actions`, return
  `OWNER_DECISION_REQUIRED` (owner-stops class F). A missing remote or a
  refused push is `WAITING_ON`, never a landed unit.
- **Merge:** merge only when `allowed.actions` includes `merge` for that unit
  and the repository's required checks pass on the pull request head. A
  passing check, a review verdict, or a profile setting never grants merge.
  Otherwise merge stays with the owner: report the pull request, mark the unit
  as awaiting the owner's merge, and continue dependency-ready work on the
  same branch. Never rewrite published history to land.
- **Record:** each push, pull request, and observed merge is a landing. The
  configured recorder transcribes it before handoff or closeout.
  `hooks/reconcile.cjs` observes merges through `merge` events. It never
  performs them.

## Checkout lease

The Orchestrator inventories visible nonterminal Lifecycles and holds one
generation-bound checkout lease before any planning write or dispatch.

- Same checkout plus a live other Lifecycle → `WAITING_ON` with sanitized
  competing Lifecycle and controller. Distinct explicitly approved compatible
  worktrees may proceed.
- Resume keeps the same generation and must not duplicate dispatch.
- `COMPLETE` or `CANCELLED` releases the lease exactly once.
- Stale recovery is explicit, recorded, increments generation, and cannot
  steal a live lease. Forged or stale-generation records fail closed.
- Branch or HEAD drift from the leased identity stops the transition before
  mutation. Authorized same-Lifecycle candidate progress whose parent is the
  current leased revision refreshes `candidate_revision` on the same
  generation. Foreign controller, branch/worktree, or unrelated HEAD still
  fail closed as `WAITING_ON`.

## Planning stage order

Planning runs Intake → combined Architectural Alignment and Scope (in the
Orchestrator controller session; the legacy Scope Definition name forwards to it
and never starts another stage) → the enabled specialists the task needs, in
data-dependency order: Requirements Engineer → Systems Modeler → Integration
Engineer planning → Planning Test Engineer → the Planning Orchestrator's own
final Planning and Design and assembly → requested planning review → owner
confirmation → `handoff.md`. Independent ready work runs in parallel; inactive
roles are skipped. The Requirements Engineer completes its own quality pass from
confirmed Alignment/Scope context; a selected Systems Modeler then returns a
placement receipt that final Planning and Design allocates against (see
`../../planning-and-design/references/allocation-inputs.md`); a selected or
required but unavailable Systems Modeler is a typed capability gap, never silent
allocation. The Test Engineer binds SEIT cases to existing requirement IDs, and
final assembly blocks until every pending binding is complete.


## Bound assurance launch accounting

For executable bound assurance, the parent uses the root plan's
`assurance_dispatch` binding and the same visible JSON task record described
in [assurance-policy.md](assurance-policy.md#mandatory-bound-dispatch-209--210).
The human-readable plan remains the authority for task transitions; the JSON
record is its visible assurance accounting projection, never a hidden task
controller. Only the pre-dispatch barrier reserves launches; parent result
updates preserve reservations, original expenditure and append-only amendments.
A missing/invalid projection denies a bound launch. A resumed session uses the
same record and declaration. A repair or transport failure never resets it.