okstra 0.189.3 → 0.190.0

package/runtime/prompts/lead/convergence.md

@@ -111,10 +111,10 @@ convergence-<task-type>-<seq>.json
 Follow this protocol exactly:
 
 0. Version-selected schemas describe what the reducer reads: `schemas/convergence-groups-v1.0.schema.json` accepts only legacy groups, `schemas/convergence-groups-v2.0.schema.json` accepts only explicit v2 execution identity, and `schemas/convergence-round-results-v1.0.schema.json` feeds step 4's `apply-round --results`. `schemas/convergence-critic-results-v1.0.schema.json` is a fourth shape but **not** a reducer input — it describes the critic worker's own result document. Step 6's `apply-critic-gaps --results` takes the coverage batch you assemble from those candidates plus each analyser's vote (`{schemaVersion, taskKey, mode, provider, modelExecutionValue, dispatches[], gaps[]}`, spelled out in §"Coverage critic pass" §"State"); feeding the critic document straight in is rejected, by design. `okstra convergence example --kind <groups|round-results|critic-results>` prints a deterministic valid v1 instance of each and writes only JSON to stdout.
-1. Run `okstra convergence seed --groups <groups> --run-manifest <current-run-manifest> --work-state <work> --final-state <final> --migration-dir <state/migrations>` for a v2 worker roster. `--run-manifest` must be the exact current manifest named by the groups document's `runManifestPath`; a previous run from the same task is not interchangeable. Omit the flag for a legacy v1 roster. A `reuse-final` action means validate the existing final and continue to Phase 6. `create-work`, `resume-work`, and `restart-round0` continue with planning.
+1. Run `okstra convergence seed --groups <groups> --run-manifest <current-run-manifest> --work-state <work> --final-state <final> --migration-dir <state/migrations>` for a v2 worker roster. `--run-manifest` must be the exact current manifest named by the groups document's `runManifestPath`; a previous run from the same task is not interchangeable. `seed` refuses a grouping that cites a worker whose initial attempt the mutation audit discarded (`contract-failed-unattributed`, `mutation-present-unresolved`) — the result file is still on disk, but the ledger says it was never accepted. Re-dispatch that worker as a new invocation and cite the new result, or leave it out of the grouping. **Enforced:** `discarded_worker_errors` in `scripts/okstra_ctl/convergence_provenance.py`, called by `_seed`. Omit the flag for a legacy v1 roster. A `reuse-final` action means validate the existing final and continue to Phase 6. `create-work`, `resume-work`, and `restart-round0` continue with planning.
 2. Run `okstra convergence plan-round --work-state <work> --plan <round-plan>`. This is read-only with respect to the working state.
 3. Every plan carries `dispatchable`: `true` on an `action: "dispatch"` plan, `false` on an `action: "finalize"` plan. When the plan action is `dispatch`, create exactly one reverify prompt for each `dispatches[]` row and dispatch it through the selected runtime adapter. Its findings are exactly that row's `findingIds`.
-4. Convert parsed verdicts and every terminal dispatch outcome into `convergence-round-<N>-results-<task-type>-<seq>.json`; then run `okstra convergence apply-round --work-state <work> --plan <round-plan> --results <round-results>`.
+4. Run `okstra convergence collect-results --plan <round-plan> --mode <adversarial|collaborative> --result <worker>=<path>… --run-manifest <current-run-manifest> --output convergence-round-<N>-results-<task-type>-<seq>.json`. Each planned worker's terminal outcome and `durationMs` come from the manifest's attempt ledger, not from the lead: an attempt still `started` refuses the collect — run `okstra team await` first so the attempt closes — and a worker whose attempt did not close `ok` cannot contribute a vote even if its result file exists. **Enforced:** `_dispatch_rows_from_manifest` in `scripts/okstra_ctl/convergence.py`. Then run `okstra convergence apply-round --work-state <work> --plan <round-plan> --results <round-results>`.
 5. Repeat `plan-round` and `apply-round` until the plan action is `finalize`. A `finalize` plan is **never dispatched**: it carries `dispatchable: false`, an empty `dispatches[]`, and a `note` naming the next command. Its `round` is only the `<N>` in `convergence-round-<N>-plan-<task-type>-<seq>.json` — not a round to run — so do not open reverify workers for it. **Enforced:** `okstra convergence apply-round` refuses a non-dispatch plan and returns the gate's closing reason with the remedy (`scripts/okstra_ctl/convergence_engine.py` `apply_round_results`).
 6. When the coverage critic is enabled, convert its verification batch to the canonical `dispatches[]` / `gaps[]` result shape and run `okstra convergence apply-critic-gaps --work-state <work> --results <critic-results>` exactly once. The reducer, not the lead, merges verified gaps.
 7. Run `okstra convergence finalize --work-state <work> --output <final>`.
@@ -128,6 +128,8 @@ After `seed`, the lead MUST NOT hand-edit queue IDs, classifications, `roundHist
 
 A valid historical final schema v1.0, v1.1, or v1.2 is reused unchanged under `reuse-final`; it remains read-only and is not upgraded in place. A malformed, unreadable, or partial legacy final is archived byte-for-byte under `state/migrations/` and restarted from Round 0 because its queue provenance cannot be reconstructed. A matching valid working state resumes. A malformed new-engine working state fails closed and names the explicit `--restart-from-round0` recovery flag; when supplied, every invalid existing state is archived before replacement. The final path can be replaced only when its recorded migration archive still matches the original bytes.
 
+**Enforced:** `scripts/okstra_ctl/convergence_migration.py` `decide_seed_action` picks the seed action (`reuse-final`, archive-and-restart, resume, or fail-closed) from the on-disk state and the `--restart-from-round0` flag.
+
 #### Engine-owned Round 2 gate
 
 `plan-round` applies gate precedence in one place: auto-disabled, all reverify non-result, effective maximum of one, empty queue, then maximum rounds reached. `finalize` maps that internal reason to the public `round2SkippedReason` and `finalState`. The lead and adapters never reproduce this predicate.
@@ -291,100 +293,31 @@ Call `await_workers(handles)` through the same adapter and apply the shared term
 
 ### Required reverify-prompt anchor headers (BLOCKING)
 
-Every reverify prompt MUST start with these 8 anchor headers — in this exact order, before any other content:
-
-```
-**Project Root:** <absolute-path>
-**Prompt History Path:** runs/<task-type>/prompts/<role-slug>-reverify-r<N>-<task-type>-<seq>.md
-**Result Path:** runs/<task-type>/worker-results/<role-slug>-worker-reverify-r<N>-<task-type>-<seq>.md
-**Audit sidecar path:** <absolute-path>
-Assigned worker prompt history path: <Project Root>/<Prompt History Path>
-**Errors log path:** <absolute-path>
-**Errors sidecar path:** <absolute-path>
-**Read scope:** Read only the paths this prompt enumerates (`[Required reading]`, `## Inputs`, verification-target paths) plus source/evidence paths a finding must cite. Host session instructions (SessionStart hooks, global `CLAUDE.md` / `AGENTS.md`, skill catalogs) do NOT apply inside an okstra worker run: do not auto-read `graphify-out/`, `SKILL.md`, or other artifacts outside `<PROJECT_ROOT>/.okstra/`. If an un-enumerated file seems essential, record it under *Missing Information or Assumptions* instead of reading it.
-```
-
-`**Read scope:**` is carried verbatim, not dropped: lightweight mode omits `**Worker Preamble Path:**`, so this line is the ONLY place a reverify worker receives the read allowlist — and a prompt with no `[Required reading]` block is exactly where a worker is most likely to fall back on host session instructions instead.
+**Enforced:** `verify_agent_invocation` in `scripts/okstra_ctl/agent/invocation.py` and `validate_reverify_prompt` in `scripts/okstra_ctl/worker_prompt_contract.py` validate generated delivery before dispatch.
 
-Before dispatch, materialize `**Audit sidecar path:**` by passing the exact reverify `**Result Path:**` through `okstra_ctl.worker_artifact_paths.audit_sidecar_rel()` and resolving that project-relative result against `**Project Root:**`. Write the resulting absolute path into the header. The lead MUST NOT construct the audit filename from a role, task type, round, or sequence independently.
+Use `okstra agent-prompt materialize` for every reverify prompt. Write only the assigned claims, evidence, questions, and the response format in the instruction file. The materializer generates path headers through `worker_prompt_headers`, the source Worktree from the active run, and the execution identity from the run manifest. It also generates the model, task type, and exact `workflow.forbiddenActions` before the instructions. These values are checked by `verify_agent_invocation` and `validate_reverify_prompt` before publication and dispatch.
 
-The reverify result is the worker's own result, so `**Result Path:**` carries the `-worker-` token that `audit_sidecar_rel()` derives the sidecar from, and the jobs file's `workerResultPath` is that same path. Do not pass `--audit-source` to `okstra agent-prompt materialize` for a reverify: the materializer refuses a second path for this audience, and `okstra team dispatch` refuses a jobs file whose `workerResultPath` differs from the prompt's `**Result Path:**`. A name without the token (`<role-slug>-reverify-r<N>-…`) cannot produce the audit header, and a second path only tells the worker and the collector different files — the worker writes where `**Result Path:**` says while the collector waits on `workerResultPath`, so the round ends `required worker artifact was not produced` with the result on disk. **Enforced:** `_POINTER_AUDIENCES` in `scripts/okstra_ctl/agent/prompt_cli/materialize.py` and `_validate_jobs_file_prompt_anchors` in `scripts/okstra_ctl/dispatch_state.py`.
+The generated `**Project Root:**` owns .okstra artifacts; `**Worktree:**` names the source checkout. Use the prompt's `**Invocation metadata path:**` for its invocation metadata. The result passed as `--result` is the worker's own result and carries the canonical `-worker-` token used by `audit_sidecar_rel`. Reverify has one result path, so omit `--audit-source`. The materializer supplies the audit, errors, read scope, and provider-specific plain-file write instructions.
 
-The two error-path anchors carry the same absolute values the lead forwarded in the initial Phase 4 dispatch for that role (source: the launch prompt's `## Run Logs (error-log wiring)` section). Workers use the errors log path with the typed error-log command from [team-contract](./team-contract.md) "Error reporting". The errors sidecar path only reserves the runtime-owned write-artifact path used by dispatch validation; no model-authored error JSON file is part of reverify.
+The generated `**Errors log path:**` and `**Errors sidecar path:**` headers use the run's error wiring. Report observed failures with `okstra error-log append-observed` as specified in [team-contract](./team-contract.md). The errors sidecar is runtime-owned; no model-authored error JSON file is part of reverify.
 
-Relative to the Phase 4 anchor set rendered by `okstra_ctl.worker_prompt_headers.worker_prompt_headers()`, a reverify prompt drops two anchors whose targets lightweight mode never reads: `**Worker Preamble Path:**` and `**Worker Error Contract Path:**`.
+An older instruction file may already contain the fixed boundary. Matching values are retained once; conflicting model, task type, or forbidden-actions values are reported with the expected value and a materialization remedy. Do not edit a dispatched prompt. Use a fresh invocation ID and prompt path for a dynamic reverify correction; undispatched initial prompts can be regenerated in place by the existing recovery path.
 
-**Where the composer's sections go.** `okstra agent-prompt materialize` (§"Invocation materialization gate") writes the dispatched body itself, as: these anchors, then the model-assignment block (`**Provider:**`, `**Model execution value:**`, `**Runner:**`, `**Host runtime:**`, and `**Host model value:**` for a native host), then `## Duty Contract`, then `## Task Instructions` followed verbatim by the task-instructions file the lead wrote. The composed prompt carries exactly one `**Model:**` header. Materialization preserves a lead-authored `**Model:** <role>, <modelExecutionValue>` line and omits its own model line in that case; when the task instructions have no model line, materialization writes `**Model:** <modelExecutionValue>` in the assignment block. The lead counts the composed document rather than assuming that both forms may coexist.
+After materialization, generate the batch file from the returned metadata paths:
 
-For an `antigravity` assignment, append the exact `PLAIN_FILE_WRITE_HEADER`
-value from `okstra_ctl.worker_prompt_headers` immediately after
-`**Read scope:**` and before the prompt body. Copy it verbatim from that role's
-persisted initial Phase 4 prompt; do not paraphrase or reconstruct it. If the
-persisted initial prompt does not contain that generated header, abort the
-reverify dispatch and record a `contract-violation` event instead of
-dispatching without the plain-file safeguard. This provider-specific header is
-outside the common 8-header count above. Other providers do not receive it.
+Name the reverify result `<role-slug>-worker-reverify-r<N>-<task-type>-<seq>.md` under the run's authorized worker-results directory. Its generated audit path is checked before dispatch.
 
-The rationale for both drops is §"Reverify prompt: required-reading suppression" below.
-
-The task-instructions file the lead writes MUST open with this block, before any
-`##` heading of its own:
-
-```markdown
-**Model:** <role>, <modelExecutionValue>
-**Task Type:** <task-manifest taskType>
-**Forbidden actions:**
-<active-run-context workflow.forbiddenActions, verbatim>
+```bash
+okstra agent-prompt jobs --project-root <root> --run-manifest <manifest> --dispatch-kind reverify-r<N> --metadata <first-meta.json> --metadata <second-meta.json> --out <run-state>/reverify-jobs-r<N>.json
 ```
 
-Nothing may sit between the forbidden-actions text and the file's first `##`
-heading — not even the prompt's own opening sentence. The block's value is read
-from the line after `**Forbidden actions:**` up to the next `## ` heading or
-`**X:**` header, so any line placed in that gap is folded into the value and the
-exact-match check fails while the text is plainly correct. This is why each
-prompt-body example below opens at `## Instructions` and states its round line
-inside that section. **Enforced:** `_section_values` in
-`scripts/okstra_ctl/worker_prompt_contract.py`.
-
-This is the same placement `okstra_ctl.worker_prompt_body` uses for an initial
-Phase 4 prompt, and it is where the checks look: `validate_reverify_prompt()`
-reads the region after `## Task Instructions`, so a `**Model:**` line left in
-the anchors is invisible to it, and a phase boundary written below the file's
-first heading fails. Both rules are about this file — the composer's own
-`## Duty Contract` heading sits above everything here and is not what they
-measure against.
-
-Do not summarize, shorten, or reconstruct the forbidden-actions text. The
-selected adapter validates the task type and exact block through
-`okstra_ctl.worker_prompt_contract.validate_reverify_prompt()` before starting
-the wrapper. `validators/validate-run.py` separately fails the run when the
-run-level error log records a phase-boundary `contract-violation`; a correct
-finding does not make evidence obtained across the phase boundary admissible.
-
-`<modelExecutionValue>` MUST be resolved from one of these canonical sources, in priority order:
-
-1. `task-manifest.json` → `resultContract.requiredWorkerRoles[].modelExecutionValue` for the receiving role
-2. `team-state-<task-type>-<seq>.json` → `workers[].usage.cliModel` for that role (initial run's actual execution value)
-3. The `**Model:**` line of the initial Phase 4 prompt for that role (read from its persisted prompt-history file)
-
-If none of the three is available, **abort the reverify dispatch for that role** and record a `contract-violation` event via `okstra error-log append-observed`. Do NOT guess or fall back to a runtime default. The selected adapter receives the exact value through the assignment and owns how it reaches the worker runtime. The current Codex catalog default is `gpt-5.6-sol`, but that reference value never replaces the manifest assignment.
-
-**Enforced:** `okstra_ctl.dispatch_state` hands the job's own `modelExecutionValue` to `validate_reverify_prompt(expected_model=...)`, so a `**Model:**` header that disagrees with the model this dispatch will run fails **before** launch. Carrying a stale value from an earlier round's prompt — the round-1 model into a round-2 header — is the shape this catches; without it the mismatch surfaces as a provider 400 that reads as a worker fault. `tests/contract/test_reverify_dispatch_anchors.py` pins both the check and the dispatch-side hand-off.
+Pass only the current engine-planned batch. The generator reads the actual result headers and canonical role execution, verifies all inputs, then publishes the file. Dispatch the emitted file with the selected adapter's `--jobs-file`; do not copy identity, path, or digest fields by hand. Existing v1 jobs-file consumers remain available.
 
 ### Required reverify output contract (BLOCKING)
 
-Every lightweight, adversarial, full-reanalysis, and plan-body reverify prompt
-MUST append this block verbatim after its variant-specific response format:
-
-**Enforced:** `okstra_ctl.worker_prompt_contract.validate_reverify_prompt` runs at dispatch (`dispatch_state.py`) and rejects a prompt without this block, or with the heading but a missing clause. It matches the three clauses by their distinctive tokens rather than byte-for-byte — a hand-copied block's whitespace must not decide whether a round runs.
+**Enforced:** `validate_reverify_prompt` and `_validate_output_contract_block` in `scripts/okstra_ctl/worker_prompt_contract.py` validate the three persistence clauses before dispatch.
 
-```markdown
-## Output Contract
-
-- Write the complete response to the exact `**Result Path:**` before returning.
-- Write the reverify-session audit to `**Audit sidecar path:**` before returning; list the evidence paths actually inspected, or state that the prompt required no external evidence reads.
-- Do not return only an inline response. Inline text is diagnostic output, not the persisted worker result.
-```
+The materializer appends [the canonical output contract](../../templates/reverify-output-contract.md) when the instruction has none. It requires a persisted Result Path and Audit sidecar path before returning and rejects an inline-only response. An existing output block is checked for the same three clauses by `validate_reverify_prompt`. Plan-body verification retains its own response format; its instructions can reference the same output contract.
 
 ### Reverify prompt: required-reading suppression
 
@@ -506,6 +439,8 @@ needed for a finding, you MUST answer UNVERIFIABLE with a non-empty explanation.
 You MUST NOT answer DISAGREE merely because access or reproduction failed;
 UNVERIFIABLE is persisted as `verification-error` and excluded from consensus.
 
+**Enforced:** `scripts/okstra_ctl/convergence_engine.py` `_VERDICTS` accepts the verdict as `verification-error`, and `classify_collaborative_round` drops those votes before counting consensus.
+
 ## Task bundle paths
 - Instruction set: <instruction-set path>
 - Task brief: <task-brief path>
@@ -756,6 +691,8 @@ Each candidate blocker is verified by the Phase 4 analysers — all of them, on
 - **Confirmed** (an analyser reproduces it or cites supporting evidence) → promote to a `## 5.8 Acceptance Blockers` row (keep severity + recommended follow-up phase).
 - **Not confirmed** (cannot reproduce, or evidence is weak) → **downgrade to a Residual Risk row — never drop it.** Record the escalation trigger so the user can re-judge a high-severity-but-unconfirmed candidate.
 
+**Enforced:** `validators/validate-run.py` `_validate_final_verification_consistency` fails a report whose `acceptanceBlockers` and `finalVerdict` disagree, so a promoted blocker cannot sit beside an `accepted` verdict and an `accepted` report cannot carry one.
+
 ### Verdict impact
 
 Promoted blockers enter `## 5.8 Acceptance Blockers`; since `accepted` requires zero blockers, the verdict moves to `conditional-accept` / `blocked` automatically. The existing verdict↔blocker consistency validator (`validators/validate-run.py` `_validate_final_verification_consistency`) enforces this unchanged — no new enum or validator.

package/runtime/prompts/lead/okstra-lead-contract.md

@@ -55,6 +55,8 @@ Read-side inspection (`/okstra-inspect`) and scheduling (`/okstra-schedule-gen`)
 - If the brief is incomplete, continue with explicit uncertainty markers rather than fabricating confidence.
 - Required roles must not be replaced by unnamed generic parallel workers. Before the final verdict, every selected worker must have either a saved result file or an explicit terminal status with reason. Any attempted worker with status `completed`, `timeout`, or `error` must also have a saved worker prompt history file at its assigned run-level prompt path.
 
+**Enforced:** `validators/validate-run.py` `validate_team_state` fails a run whose worker carries a terminal status with no result file or no saved prompt history. The lead's only sanctioned change to the writer's narrative is a mechanical correction ledger — `scripts/okstra_ctl/report_corrections.py` `check_corrections` sets `mechanical` false for any `rewrite` entry, and `okstra agent-prompt apply-corrections` refuses to apply such a ledger.
+
 ## Worker instruction quality gate (BLOCKING)
 
 This gate applies before every initial dispatch, retry, re-verification, critic, and correction, regardless of worker role or transport. The lead performs it on the complete proposed instruction before persisting or sending that instruction.
@@ -98,10 +100,14 @@ User-utterance interpretation rule:
 - If the current phase's outputs are already complete and the user clearly wants to advance, reply with the phase-transition checklist above and the exact next-run command. Wait for explicit user confirmation before any action that belongs to the next phase.
 - If the Next-Phase Pointer target (`nextRecommendedPhase.phase`) is `implementation-planning`, the next run produces a **plan**, not code. The next run after that is `implementation`.
 
+**Enforced:** the Forbidden actions column is declared in `prompts/profiles/forbidden-actions.json` and scanned post-hoc by `validators/forbidden_actions.py` `scan_forbidden_actions`, which matches this run's task type through `forbidden_patterns_for` against the commands the run actually executed.
+
 ## Progress reporting (BLOCKING)
 
 A single okstra run frequently spans 30–120 minutes with multi-minute silent windows while workers run; without progress signals the user cannot distinguish "still working" from "hung". Lead MUST emit a single short progress line at each checkpoint below — plain user-facing text in a separate brief message (not buried inside a tool call), one line per checkpoint, format: `PROGRESS: <phase-id> <verb-phrase>`. Emit the line raw — the literal `PROGRESS:` token must begin the line. Do NOT wrap it in inline-code backticks (`` `PROGRESS: ...` ``) or a ```` ``` ```` code fence; markdown wrapping is what the post-hoc conformance validator scrapes around, and raw emit keeps the signal unambiguous.
 
+Record each checkpoint with `okstra lead-progress append --project-root <dir> --run-manifest <path> --phase <phase-id>`, then emit the `progressLine` it prints as the user-facing line. The command resolves `leadEventsPath` from the run manifest and writes the checkpoint there — on a host whose adapter declares `sessionAccounting: artifact-only` that ledger is the only place the post-hoc validator can read it, so a conversation line alone leaves no trace and the run is reported as missing the checkpoint. Pass `--worker <role>` on the per-worker checkpoints (it rewrites a phase-specific functional label into the roster role team-state records), `--field NAME=VALUE` for the remaining `key=value` tokens in the order the line carries them, and `--detail <text>` where the line ends in a verb phrase; the wording listed below is the default for the fixed-prose checkpoints.
+
 For an `implementation-planning` run whose run manifest declares `activityContractVersion: 1`, record every required activity boundary with `okstra agent-activity append` against the manifest-provided `leadEventsPath`. Model-facing calls pass prose through `--summary-file <md>` and a command through `--command`, `--command-cwd`, `--command-exit-code`, and `--command-output-file <md>`; do not construct `--command-record` JSON. The ordering is fixed: the structured append succeeds first, the matching `PROGRESS:` line is emitted second, and the immediately following `ACTIVITY:` line projects the same structured fields into the conversation language. Do not reconstruct structured activity from conversation text. If the append fails, do not present that activity boundary as completed.
 
 The live projection follows this shape:
@@ -138,7 +144,7 @@ Required checkpoints:
 
 Do NOT replace them with prose ("Now I'm starting Phase 2..."), do NOT skip a checkpoint because "the previous message already said that", and do NOT batch multiple checkpoints into one. Each line stands alone so the user (or any operator scraping stdout) can timestamp it externally.
 
-`okstra-run` surfaces these lines to the user directly; other launch paths persist them in the selected adapter's declared conformance evidence/event source for post-hoc retrieval.
+`okstra-run` surfaces these lines to the user directly; `okstra lead-progress append` persists them in the selected adapter's declared conformance evidence/event source for post-hoc retrieval.
 
 **Enforcement:** the Phase 7 validator (`validators/validate-run.py` → `validate_session_conformance.py`) reads the selected adapter's declared conformance evidence/event source within the run window and fails the run as `contract-violated` when a required checkpoint is missing — including the per-worker `phase-4-dispatch` / `phase-5-collect` lines (which must name each worker's role) and the `phase-batch-cleanup` lines that MUST precede the first `phase-5.5-convergence` round and the `phase-6-synthesis` report-writer dispatch. When the plan-body state file records two or more rounds, `_check_plan_verify_cleanup_checkpoints` additionally requires a `phase-5.5.9-plan-verify` line per round and a `phase-batch-cleanup` between consecutive rounds. For `implementation`, `_check_progress_checkpoints` additionally requires the `phase-5-stage` announcement once any worker is dispatched, and the `phase-5-stage-complete` line once an implementer worker completed. For activity-contract-v1 planning, `_check_activity_contract` validates the structured worker pairs, verification and self-fix counts, user-decision references, and `A-NNN` ordering. `phase-7-teardown` and `complete` fire after validation and are not checked.
 
@@ -166,7 +172,7 @@ The sequence is fixed:
 
 1. Investigate before asking. Read every cited plan item, worker finding, and `path:line` the question depends on. You are not ready to ask while any option's outcome cannot be named as a concrete change: the extra work it creates, the already-decided thing it reverses, and which files or stages it touches. If a citation cannot be read, say so in the question; do not invent the missing fact.
 2. Emit `PROGRESS: user-confirm <C-NNN> <the question, one line>` with the id the row would carry.
-3. Ask in the user's language through the selected adapter's `prompt_user` mapping. Do not lead with `C-NNN`, `Kind`, `Blocks`, or `expectedForm`. The question body is why this is being asked, what is already decided, the fork, and each option as "if you pick this, then …". Keep the report-owned impact axes (reach or scope, added work, direction change). One question at a time. When that mapping names a native question function and the option count fits the relay `nativeLimits`, call that function with `{label, description}` options. Do not print a numbered list in chat while the native tool is available. Numbered text is only for a text-only relay or a prompt that does not fit `nativeLimits`.
+3. Ask in the user's language through the selected adapter's `prompt_user` mapping. Do not lead with `C-NNN`, `Kind`, `Blocks`, or `expectedForm`. The question body is why this is being asked, what is already decided, the fork, and each option as "if you pick this, then …". Keep the report-owned impact axes (reach or scope, added work, direction change). One question at a time. When that mapping names a native question function and the option count fits the relay `nativeLimits`, call that function with `{label, description}` options. Do not print a numbered list in chat while the native tool is available. Numbered text is only for a text-only relay or a prompt that does not fit `nativeLimits`. Emit the question as the last thing in that turn — no restatement, rationale, or status line after the call. Anything emitted after it renders below the question and separates it from the user's answer.
 4. On an answer — record the raw text in the row's `userInput`, set `status: answered` and `userConfirmation: asked-and-answered`, and apply the selected disposition in this run.
 5. Only when asking fails does the row stay open: `asked-awaiting` when the user has not answered, `deferred-no-interactive-session` when this run has no user to ask.
 
@@ -221,6 +227,8 @@ Lead MUST dispatch Edit/Write-bearing work only through that executor binding: u
 
 Executor is chosen at run-prep time via `--executor <claude|codex|antigravity>` (or `OKSTRA_DEFAULT_EXECUTOR`, fallback `claude`); the model used by the executor is taken from the corresponding worker model flag (`--claude-model` / `--codex-model` / `--antigravity-model`). For CLI-backed executors, the underlying file mutation happens inside the executor CLI's own auto-edit mode (e.g. `codex exec --sandbox danger-full-access`), not through the lead runtime's `write_artifact` operation.
 
+**Enforced:** every non-executor assignment is dispatched under `writePolicy.sourcePolicy.mode` `source-readonly`, and `scripts/okstra_ctl/execution_mutation_audit.py` `_source_changes` compares the before/after snapshots and reports a read-only worker that mutated source; `assert_compatible_batch` refuses a batch that mixes a mutating worker with read-only ones.
+
 #### Task worktree (BLOCKING for every task-type)
 
 Okstra provisions dedicated `git worktree`s at run-prep time. Lead, the Executor, and every verifier MUST treat the provisioned worktree as the canonical working directory regardless of task-type.
@@ -235,6 +243,7 @@ Okstra provisions dedicated `git worktree`s at run-prep time. Lead, the Executor
   - `project_root` is already inside a non-main worktree (the run reuses the caller's worktree to avoid nesting).
   - `project_root` is not inside a git repository at all.
 - **Failure mode**: any other error during `git worktree add` (on-disk path collision not tracked by the registry, branch collision with a different task-key, detached-HEAD with no SHA) raises `PrepareError`. Re-run after manually removing the stale path/branch — the worktree is intentionally not garbage-collected.
+- **Enforced:** `scripts/okstra_ctl/dispatch_state.py` `worktree_path` resolves the provisioned worktree for every task-type and materialization writes it into each worker prompt as the `**Worktree:**` anchor; `scripts/okstra_ctl/worker_prompt_contract.py` `_REQUIRED_TARGET_PREFIXES` requires that anchor on the prompts that carry it, and `scripts/okstra_ctl/execution_mutation_audit.py` `_source_changes` audits mutations against that root.
 - **Lifecycle**: kept after the run for follow-up phases, manual PR authoring, rollback verification, and `final-verification`. Manual cleanup: `git -C <main-worktree> worktree remove <path>` then `git -C <main-worktree> branch -D <branch>`; remove the corresponding (task- or stage-) key from the registry by hand.
 
 ## Phase 1: Task-bundle intake and required reading order
@@ -312,6 +321,8 @@ For `improvement-discovery`, Lead records `## Primary Pass Assignments` in the P
 4. Persist the setup outcome in team-state using the existing fields required by that backend.
 5. Emit the canonical `PROGRESS: phase-3-team-create <adapter-specific-status>` checkpoint. The phase id remains stable for artifact compatibility; only the adapter-owned verb phrase varies.
 
+**Enforced:** `validators/validate_session_conformance.py` `_check_progress_checkpoints` requires the `phase-3-team-create` checkpoint once any worker was dispatched, and `validate-run.py` `validate_team_state` reads the setup outcome this phase persists.
+
 ### Phase 4 / Phase 5 — Dispatch, await, and error-log recording
 
 For each selected worker assignment, persist the exact prompt history, emit the per-worker Phase 4 checkpoint, and call `dispatch_worker(assignment, promptPath)` through the selected adapter — the dispatch hands the worker the persisted prompt's path, never a re-inlined copy of its body. Then call `await_workers(handles)`. A dispatch acknowledgement or process/pane creation is never completion: verify the terminal status, Result Path, and worker-results audit path required by `team-contract` before emitting the Phase 5 collection checkpoint.
@@ -343,7 +354,7 @@ For deterministic Codex/Antigravity provider processes: if the CLI returns non-z
 ```bash
 okstra error-log append-observed \
   --out <absolute-errors-log-path-from-launch-prompt> \
-  --task-key <taskKey> --phase 5.5 \
+  --task-key <taskKey> --phase <task-type> \
   --agent codex-worker --agent-role worker --model <model> \
   --error-type cli-failure \
   --command "okstra-codex-exec.sh <project-root> <model> <prompt-path>" \
@@ -387,6 +398,8 @@ If convergence is disabled, `seed`/`finalize` produce the auto-disabled final st
 
 **REQUIRED RESOURCE:** Read [report-writer](./report-writer.md) for report ownership, dispatch, assembly, and Phase 7 rules.
 
+**Enforced:** `validators/validate_session_conformance.py` `_check_progress_checkpoints` requires the `phase-6-synthesis` checkpoint once the report writer was dispatched, `validators/validate-run.py` `validate_team_state` requires that dispatch's result and prompt history, and `scripts/okstra_ctl/report_corrections.py` `check_corrections` keeps the narrative the writer's — the obligations this resource carries. Loading the document itself is not separately checked.
+
 ### Authoring ownership (BLOCKING)
 
 If `Report writer worker` is in the selected roster (`recommendedWorkers` / `resultContract.requiredWorkerRoles`), Lead dispatches it to author only `report-writer-narrative-<task-type>-<seq>.md`, its worker-result pointer, and its audit sidecar. The worker may read the complete run context but cannot write `final-report-*.data.json` or another role's ledger. After every required input exists, Phase 7 runs report assembly, which validates the role-owned inputs and atomically publishes the report record once. Phase 7 then renders the human HTML from that record. Contract v2 artifacts remain readable but no new run writes them. **Enforced:** report-writer dispatch completion paths in `scripts/okstra_ctl/dispatch_state.py`, granted artifacts in `scripts/okstra_ctl/dispatch_core.py`, and `scripts/okstra_ctl/report_assembly.py` `assemble_report`.
@@ -451,8 +464,8 @@ The detailed persistence sequence lives in [report-writer](./report-writer.md).
 
 Order of operations:
 
-1. Run `okstra report-finalize ...`. Contract v3 collects usage, assembles the role-owned inputs into `data.json` once, checks the source, renders views, persists follow-ups, validates the run, and performs eligible teardown in order.
-2. When `meta.reportLanguage` is not `en`, first run only `token-usage`, `project-activity`, and `check-source`. Dispatch the translator against that assembled record, then resume with only `render-views`, `spawn-followups`, `validate-run`, and `teardown-stages` so assembly is not repeated.
+1. Run `okstra report-finalize ...`. Contract v3 collects usage, assembles the role-owned inputs into `data.json` once, checks the source, renders views, persists follow-ups, validates the run, records this run's conclusion into the task-group's `group-context.md` for the group's sibling tasks, and performs eligible teardown in order. When the task's pointer is terminal and the group has a task not yet started, the result's `nextInGroup` names it and `nextCommand` closes on starting it from its brief — the group's start order is the brief ordinal; the briefs' Related Task Graph edges are quoted as `waits for` and do not reorder it.
+2. When `meta.reportLanguage` is not `en`, first run only `token-usage`, `project-activity`, and `check-source`. Dispatch the translator against that assembled record, then resume with only `render-views`, `spawn-followups`, `validate-run`, `record-group-memory`, and `teardown-stages` so assembly is not repeated.
 
 Keep the assigned worker prompt history paths stable in `team-state`, `run-manifest`, and `task-manifest`. Do not rewrite prompt artifacts to `/tmp` or omit prompt metadata for attempted workers.
 
@@ -470,6 +483,7 @@ For every other task type:
 
 - Pointer `status: ready` → `/okstra-run` for that `phase`. Quote the pointer's `rationale` — that sentence is this run's report saying why that phase comes next, and it is the analysis the user asked for.
 - Pointer `status: terminal` → the lifecycle ends here. Say the task is finished and quote the pointer's `rationale`. Do not propose a run and do not send the user to `/okstra-inspect`: the decision is already made, so there is nothing to inspect. If this run registered follow-up tasks, name them and the command that starts one.
+- Pointer `status: terminal` and the result carries `nextInGroup` → the task is finished and the task-group has a task not yet started: say this task is finished, then close on `/okstra-run` for `nextInGroup.briefId` from its `brief` path — the group's start order is the brief ordinal, and `nextCommand.note` already names the task and its brief.
 - Pointer `status: blocked` → the pointer's `rationale` names what is in the way and what to run. Quote it and issue that command — `/okstra-user-response` for the `C-NNN` ids it lists, or `/okstra-run` for the phase it names.
 - Pointer `status: pending` with a `rationale` → the comparison finished and the user's own choice is what comes next. Quote the `rationale` and issue the command it names. Do not re-run the phase that just completed, and do not send the user to `/okstra-inspect`: a finished phase has nothing to inspect, and re-running it discards the result the user is being asked to choose from.
 - Phase 7 `validate-run` failed → one line naming the blocking cause, then `/okstra-run` to re-run this phase with the recorded sidecar. Only a failure matching the blocking allowlist (`okstra_ctl.blocking_checks`) reaches this row; every other finding was demoted to an advisory, printed as `validate-run: advisory — <finding>`, and the run passed. Name those advisories in one line and take the command from the matching pointer row above — an advisory is not a reason to re-run.
@@ -477,7 +491,11 @@ For every other task type:
 
 When the host native picker is available and two of those rows could apply, ask with that picker (recommended first). Do not end the turn after the status dump.
 
-**Every run-artifact path in this reply MUST be task-qualified** — report the human report as `.okstra/tasks/<task-group>/<task-id>/runs/<task-type>/reports/final-report-<task-type>-<seq>.html` rooted at the task bundle, NOT the bare `runs/<task-type>/reports/...` form (byte-for-byte identical across every task of the same task-type, so it cannot identify the task). Under that, cite the report record (`.data.json`) and one line to render the full reading copy: `okstra render-final-report <task-qualified data.json>`. The same task-qualified rule applies to the team-state path, resume command path, and any other run-artifact path this reply cites.
+**Cite run-artifact paths, do not assemble them.** The `report-finalize` result's `reportPaths` carries this run's `humanReport`, `reportRecord`, `teamState`, and `renderFullCopy` command, each already rooted at the project (`.okstra/tasks/<task-group>/<task-id>/runs/...`). Every other run-artifact path the reply cites — the resume command among them — comes from the launch prompt's `## Manifests` / `## Run Paths` lists, which are rooted the same way. A path you compose from a `runs/<task-type>/...` pattern instead is identical across every task of that task-type, so it names no task and does not resolve from the project root either.
+
+**Write every file you name to the user as a markdown link** — `[<what it is>](<path>)`, the path inside the parentheses. The host renders the reply as markdown, so that is the only form the user can click; a path in backticks or bare prose is text they have to copy out and open by hand. `reportPaths.markdown` already carries this run's report, report record, and team state in that form — paste those strings. Apply the same shape to every other file the reply names (a worker result, the errors log, a brief), using the project-rooted path from the launch prompt's `## Manifests` / `## Run Paths`. Commands stay in backticks; only files become links.
+
+**Enforced:** `scripts/okstra_ctl/report_finalize.py` `_closeout_report_paths` builds the task-qualified paths and `closeout_command` builds the close, so neither is re-derived; `validators/validate_session_conformance.py` `_check_progress_checkpoints` requires the `phase-7-persist` checkpoint this phase opens with.
 
 The run-level error log lives at `<runDir>/logs/errors-<task-type>-<seq>.jsonl`. It is informational. Its presence or absence does not affect the final verdict. Do not block report writing on it.
 

package/runtime/prompts/lead/plan-body-verification.md

@@ -25,6 +25,8 @@ Phase 4   workers produce independent analyses (Findings F-001…)
 
 Plan-body verification MUST NOT replace, precede, or be conflated with the Phase 5.5 finding convergence above. They are two distinct rounds with different inputs (findings vs. consolidated plan body), different ID schemes (`F-*` vs. `P-*`), and different state files.
 
+**Enforced:** `validators/validate-run.py` `_validate_queue_mutual_exclusion` fails a run whose finding queue carries a `P-*` id or whose plan-item queue carries an `F-*` / `C-*` id — the two rounds cannot be merged without tripping it.
+
 ## MUTUAL EXCLUSION (BLOCKING)
 
 The finding queue (Phase 5.5, [convergence](./convergence.md)) and the plan-item queue (this contract) are **disjoint**:
@@ -312,6 +314,8 @@ which is what sends the item into a self-fix round that can only paper over it.
 
 Plan-body verification only supports **lightweight mode** (defined in [convergence](./convergence.md) §"Verification Mode"). `full-reanalysis` is not meaningful here because the "original source materials" for a plan item are the worker's own analysis plus the lead-mediated synthesis — there is no independent ground truth to re-read. The manifest's top-level `verificationMode` is ignored for this round; lightweight is always used.
 
+**Enforced:** `scripts/okstra_ctl/convergence_engine.py` `_parse_config` rejects a `verificationMode` outside `_VERIFICATION_MODES`, and the plan-body round is seeded with `lightweight` rather than the manifest value.
+
 Exception for `P-Req-*`: verifiers still MUST NOT re-open the original task brief for this round, but they MUST compare the requirement text embedded in the `Requirement Coverage` row with the cited Option / Stage / Step in the draft plan. A row is not sound merely because it says `covered`; the cited plan item must actually satisfy the row's stated requirement. A `documented-deviation` never earns automatic `AGREE`: verify all four parts independently — the original requirement, the concrete alternative in `coveredBy`, every `decisionRefs` target, and the `approvalDisposition`. `accepted` requires a referenced user-confirmed clarification; `blocked C-NNN` requires that same-report clarification to be open and block approval.
 
 ## Adversarial plan-body posture
@@ -385,7 +389,7 @@ round before any host or provider process starts.
    **Score the gate with `okstra plan-verify`, never by hand (BLOCKING).** Once this round's verdicts are in the data.json, lead runs
 
    ```
-   okstra plan-verify --report <runs/<task-type>/reports/final-report-<task-type>-<seq>.data.json>
+   okstra plan-verify --report <the launch prompt's `## Run Paths` → `Final report` value>
    ```
 
    and records what it returns: `gate.recomputed` is the round's gate value, `gate.blockedBy` its `gateBlockedBy` causes, `gate.blockingItems` the items that block. The same call runs every plan-body check a round can be judged on alone — provenance, fixability, subject substance, self-fix grouping, round recording, clarification matching, state-file rounds — and exits 2 with `failures[]` when the round is not contract-clean. **A round is not complete while that exit code is non-zero.**
@@ -670,12 +674,15 @@ What concrete false-positive input, failure ordering, or omitted dependency
 would make this plan item incorrect even if its happy path succeeds?
 ```
 
-Even for `AGREE`, the worker MUST record the considered counterexample and why
-the supplied `payload` excludes it in the verdict note. If capability,
+Even for `AGREE`, the worker records the considered counterexample and why
+the supplied `payload` excludes it in the verdict note — that is what the
+explanation below has to contain. If capability,
 credential, network, or service state prevents verification, record
 `UNVERIFIABLE` for that item. It is persisted as `verification-error`, excluded from both numerator and denominator, and must not be converted to `DISAGREE`.
 Every verdict requires a non-empty explanation.
 
+**Enforced:** `scripts/okstra_ctl/convergence_engine.py` `_parse_vote` rejects a vote whose `explanation` is empty and whose verdict is outside `_VERDICTS`; `classify_collaborative_round` drops `verification-error` votes from both numerator and denominator.
+
 For `P-Req-*` items, compare only the requirement text embedded in the row
 against the cited plan item(s). Do not open the original brief, but do reject
 coverage rows that cite no concrete option/stage/step or cite a plan item that

package/runtime/prompts/lead/report-writer.md

@@ -24,12 +24,19 @@ Report assembly reads the role-owned inputs, validates them, derives links and s
 
 An active clarification exists only in `activeClarifications[]`. A decision carried from a previous run exists only in `carriedDecisions[]`; do not recreate it as an active question.
 
-Prepare seeds `carriedDecisions[]` when it creates the ledger: every clarification the run's carry-in record answered or resolved, plus every row that record's user-responses sidecars answered, arrives carried (`scripts/okstra_ctl/approval_decisions.py` `seed_carried_decisions`). A carried plan row's `requirementCoverage[].decisionRefs` may still name a `C-NNN` the carry-in record does not answer — a decision from an older run. Carry it before assembly: `okstra approval-decision carry --ledger <approvalDecisionsPath> --from-responses <instruction-set/clarification-response.md> --clarification-id C-NNN` — repeat `--clarification-id` to take several in one call. That bundle is the source of truth for an earlier run's answer: it is task-level and cumulative, so no prior run seq has to be located, and each response section names the report that posed the question, which is where the row's `statement`, `expectedForm`, and options come from. A carried row lands as `answered`, not `resolved` — it was resolved in another run, and `resolution.checkRefs` names *this* run's activity rows. Carrying an answer also obliges a `supersessionLedger` entry for it.
+Prepare seeds `carriedDecisions[]` when it creates the ledger: every clarification the run's carry-in record answered or resolved, plus every row that record's user-responses sidecars answered, arrives carried (`scripts/okstra_ctl/approval_decisions.py` `seed_carried_decisions`). The carry-in record is the `--clarification-response` file; for a new plan it is the option-selection record `--selected-direction` names, and for an implementation run the approved plan `--approved-plan` names (`render._carry_in_source`) — the same pointer assembly writes to `clarificationCarryIn.sourceFile`, so the page links those ids to the prior run's page. A carried plan row's `requirementCoverage[].decisionRefs` may still name a `C-NNN` the carry-in record does not answer — a decision from an older run. Carry it before assembly: `okstra approval-decision carry --ledger <approvalDecisionsPath> --from-responses <instruction-set/clarification-response.md> --clarification-id C-NNN` — repeat `--clarification-id` to take several in one call. That bundle is the source of truth for an earlier run's answer: it is task-level and cumulative, so no prior run seq has to be located, and each response section names the report that posed the question, which is where the row's `statement`, `expectedForm`, and options come from. A carried row lands as `answered`, not `resolved` — it was resolved in another run, and `resolution.checkRefs` names *this* run's activity rows. Carrying an answer also obliges a `supersessionLedger` entry for it.
 
 Each decision option has `role`, `answer`, `rationale`, `disposition`, `reach`, optional `scopeEffects`, `addedWork`, and `directionChange`. `reach` is exactly one of `in-repo` or `cross-repo`. `scopeEffects` may contain `new-schema` and `deferrable`. A `correctness-critical` option cannot use `select` or `accept-risk`; a `noncritical-dissent` option cannot use `select`.
 
 Resolution `checkRefs` name existing `A-NNN` activity rows. Those activity rows carry `clarificationRefs[]`; their `planItemIds[]` let report assembly derive the reverse plan-item links. Do not store copied plan or activity identifiers in `approvalContext`.
 
+## Field content rules
+
+Two rules the assembled record is checked against, both learned from the 2026-09-05 audit of shipped pages:
+
+- **An empty value is empty, never a null literal.** A prose field with nothing to say is omitted or left `""`. `"None"`, `"null"`, `"undefined"` and `"NaN"` are serialisation artefacts the page prints as text (`tradeoffMatrix` cells in nlpvibe planning-009…014). The lowercase `none` an option's `addedWork`/`directionChange` uses to mean "nothing" is a contract token and stays. **Enforced:** `validators/validate-run.py` `_validate_no_null_literals_in_prose` fails a prose field holding one of those literals.
+- **Citations name rows the reader can reach.** `evidenceRefs`, `supportingEvidence` and the other citation lists carry the record's own ids (`E-`, `CV-`, `D-`, `EA-`, `C-`, `A-`) or a `path:line`. A worker's own finding number (`F-NNN`) reaches the reader only through a promoted `evidence.primary[]` row whose `sourceItems` name it as `<worker>:F-NNN` — the page links a bare `F-NNN` to that row when exactly one row carries it, and leaves it as dead text otherwise. **Enforced:** `_unbridged_worker_finding_refs` in `validators/validate-run.py` warns on every bare `F-NNN` no `sourceItems` entry carries; the narrative rule `_validate_no_opaque_id_references` already fails one in a reader-facing sentence.
+
 ## Report-writer dispatch
 
 For report contract 3.0, prompt materialization first freezes one report synthesis
@@ -64,7 +71,9 @@ Materialize the duty prompt with `okstra agent-prompt materialize --audience rep
 
 The errors sidecar anchor reserves the runtime-owned write-artifact path used by dispatch validation. No model-authored error JSON file is part of report-writer dispatch; failures use the typed error-log command from the worker error contract.
 
-Register the dispatch with `okstra agent-prompt record-dispatch`. When `terminalBackend` is `cmux-pane`, run `okstra team dispatch`; for `runner: cli-wrapper`, run `okstra worker-dispatch --audience report-writer`. Attach the result through `okstra agent-prompt link-result`. The result path is the report narrative Markdown, not the final record.
+After materialization, generate a v2 jobs file with `okstra agent-prompt jobs --project-root <root> --run-manifest <manifest> --dispatch-kind report-writer --metadata <returned-meta.json> --out <run-state>/report-writer-jobs.json`. Pass the generated file through the selected deterministic dispatcher's `--jobs-file`. The generator reads the narrative and worker-result headers and validates their existing manifest contract. For host-native dispatch, use `okstra agent-prompt record-dispatch` and `link-result`; deterministic dispatchers record their own invocation lifecycle.
+
+When `terminalBackend` is `cmux-pane`, use `okstra team dispatch --project-root <root> --run-manifest <manifest> --jobs-file <jobs-file>`. For a CLI wrapper, use `okstra worker-dispatch --project-root <root> --run-manifest <manifest> --jobs-file <jobs-file>`. Both paths use `okstra team await` to collect completion.
 
 The pointer record contains the narrative and audit paths. Completion never depends on the final record because assembly runs after writer completion.
 
@@ -114,7 +123,7 @@ For historical schema-v1 Markdown only, the following heading table remains a re
 
 **Enforced:** `okstra_ctl.report_finalize.V3_STEP_ORDER` is the order — `report-finalize` runs the steps from that tuple, so the sequence cannot be reordered by a caller. Running the steps by hand is what this rule forbids, and that path is not reachable through the CLI.
 
-Do not run the seven steps below manually. Invoke `okstra report-finalize`; contract 3.0 runs them in this order:
+Do not run the eight steps below manually. Invoke `okstra report-finalize`; contract 3.0 runs them in this order:
 
 1. **`token-usage`** — collect usage into team state without touching the final record.
 2. **`project-activity`** — report assembly validates every owner input and publishes the final record once.
@@ -122,13 +131,14 @@ Do not run the seven steps below manually. Invoke `okstra report-finalize`; cont
 4. **`render-views`** — render the Markdown reading copy and human HTML.
 5. **`spawn-followups`** — materialize registered follow-up tasks.
 6. **`validate-run`** — validate the record, views, run manifest, and team state.
-7. **`teardown-stages`** — remove eligible stage worktrees after successful validation.
+7. **`record-group-memory`** — write this run's conclusion (headline, decisions, watch-outs, open follow-ups, record path, next phase) and the group's start order into the task-group's `group-context.md` okstra region, creating the file when the group has none; skipped, like teardown, when an earlier step failed. Sibling tasks read it as `## Task-Group Memory`.
+8. **`teardown-stages`** — remove eligible stage worktrees after successful validation.
 
 After `report-finalize` returns, the lead — not the report writer — closes the run with the launch prompt's User closeout: one command the user can run now.
 
 ### Before `report-finalize`: the translation sidecar
 
-Never dispatch the translator before report assembly and `check-source`. For a non-English human report, first run `report-finalize --only token-usage --only project-activity --only check-source`; the extraction command refuses to build a work list from a non-English source. Then dispatch the translator worker with `okstra agent-prompt materialize --audience translator`, `okstra agent-prompt record-dispatch`, `okstra worker-dispatch --audience translator`, and `okstra agent-prompt link-result`. Resume with `report-finalize --only render-views --only spawn-followups --only validate-run --only teardown-stages`; do not assemble the record a second time. `render-views` refuses a non-English report that has no translation sidecar — it does not ship Korean chrome over an English body.
+Never dispatch the translator before report assembly and `check-source`. For a non-English human report, first run `report-finalize --only token-usage --only project-activity --only check-source --only render-views`; the extraction command refuses to build a work list from a non-English source. `render-views` belongs in that first call: the HTML view renders from the report body and never reads the translation sidecar, so rendering it early costs one rerun and means a translator that never starts does not also cost the run its only human-readable artifact. Then dispatch the translator worker with `okstra agent-prompt materialize --audience translator --worker-id translator --dispatch-kind translator --assignment-ref translator --result <run>/worker-results/translator-translations-<task-type>-<seq>.md --audit-source <run>/worker-results/translator-worker-<task-type>-<seq>.md`, `okstra agent-prompt record-dispatch`, `okstra worker-dispatch --workers translator`, and `okstra agent-prompt link-result`. `--result` is the translator's own report and `--audit-source` the worker result the audit sidecar derives from; the two must differ, and the materializer refuses a translator prompt without a distinct `--audit-source` because `worker-dispatch` reads both from the prompt's `**Result Path:**` and `**Worker Result Path:**` anchors and refuses a prompt missing the second. A translator prompt that failed a pre-dispatch gate is re-materialized under the **same** invocation id with `--replace-undispatched`; a second invocation id leaves two undispatched reservations for one run, there is no command that withdraws a reservation, and `worker-dispatch` refuses to choose between them. **Enforced:** `_materialize_run` in `scripts/okstra_ctl/agent/prompt_cli/materialize.py`; `_translator_job_from_reservation` in `scripts/okstra_ctl/dispatch_core.py`. Resume with `report-finalize --only render-views --only spawn-followups --only validate-run --only record-group-memory --only teardown-stages`; do not assemble the record a second time. `render-views` is idempotent and overwrites the view it already wrote, this time with the translation overlaid. When the translator cannot run at all — a host approval gate, an unavailable provider — say so and finish the sequence anyway: the run keeps an English view rather than no view, and `report-finalize` inserts the missing `render-views` itself when a `--only validate-run` call would otherwise validate a report that has none (**Enforced:** `okstra_ctl.report_finalize._with_view_the_validator_reads`).
 
 ## Routing pointer
 

package/runtime/prompts/lead/team-contract.md

@@ -68,11 +68,11 @@ Only workers selected from `recommendedWorkers` in `task-manifest.json` and `res
 
 ## Worker Prompt Composition
 
-`okstra_ctl.initial_prompt_materialization` is the canonical owner of roster-derived initial prompt rendering, validation, and immutable publication. Code-backed `dispatch_worker` mappings leave missing roster prompts to `materialize_initial_prompts()` and pass the selected adapter's declared `initialPromptDeliveryMode`; they do not compose or overwrite those prompts themselves. Native in-process dispatch uses the same headers and the adapter's declared `lazy-path-reference` mode, persists the prompt before dispatch, and remains outside reverify and critic handling. The native dispatch payload is a summon message carrying the persisted prompt path and the instruction to read that document in full — never the prompt body itself (the host adapter's `dispatch_worker` row owns the exact summon wording).
+`okstra_ctl.initial_prompt_materialization` is the canonical owner of roster-derived initial prompt rendering, validation, and immutable publication. Code-backed `dispatch_worker` mappings leave missing roster prompts to `materialize_initial_prompts()` and pass the selected adapter's declared `initialPromptDeliveryMode`; they do not compose or overwrite those prompts themselves. That declaration reaches the materializer through the run manifest's `leadAdapter.initialPromptDeliveryMode`, which render copies from the host descriptor — or from the dispatch adapter that took worker dispatch over, such as cmux. Every adapter currently declares `eager-include`: `lazy-path-reference` drops the clarification-answer and fix-carry blocks out of an implementation prompt without listing them as resource paths, so it is not a mode an adapter may declare until that gap is closed. **Enforced:** `okstra_ctl.dispatch_core._initial_prompt_delivery_mode` refuses a manifest declaring anything outside `okstra_ctl.initial_prompt_materialization.PromptDeliveryMode`. Native in-process dispatch uses the same headers and the same declared mode, persists the prompt before dispatch, and remains outside reverify and critic handling. The native dispatch payload is a summon message carrying the persisted prompt path and the instruction to read that document in full — never the prompt body itself (the host adapter's `dispatch_worker` row owns the exact summon wording).
 
 Every initial worker instruction and result-missing retry also passes [okstra-lead-contract](./okstra-lead-contract.md) "Worker instruction quality gate" before it is persisted or sent. Prompt-shape validation does not replace that content check: the lead verifies current paths, exact constrained values, role boundaries, and completion conditions against their authoritative artifacts.
 
-Every worker prompt MUST start with the anchor headers rendered by `okstra_ctl.worker_prompt_headers.worker_prompt_headers()` (the generating SSOT — never hand-author or reorder them). Every persisted initial prompt also carries exactly one non-empty `**Prompt Delivery Mode:** <mode>` header whose value is `eager-include` or `lazy-path-reference`. Redispatch reuses that persisted initial prompt byte-for-byte; it never regenerates or overwrites it. The generated absolute `**Audit sidecar path:**` is derived by `audit_sidecar_rel()` from the canonical worker result path; workers write to that header and never synthesize a `runs/<task-type>/...` destination. Their meaning and extraction rules for workers are owned by `okstra_ctl.worker_prompt_headers.worker_prompt_headers()`. Phase-specific extra headers (implementation worktree, final-verification target snapshot, improvement-discovery grilling log) are emitted there too.
+Every worker prompt MUST start with the anchor headers rendered by `okstra_ctl.worker_prompt_headers.worker_prompt_headers()` (the generating SSOT — never hand-author or reorder them). Every persisted initial prompt also carries exactly one non-empty `**Prompt Delivery Mode:** <mode>` header whose value is `eager-include` or `lazy-path-reference`. Redispatch reuses that persisted initial prompt byte-for-byte, with one exception it performs for you: a prompt published before an anchor the current contract renders is rewritten in place under the same invocation id, and only while no dispatch row names that invocation. The generated absolute `**Audit sidecar path:**` is derived by `audit_sidecar_rel()` from the canonical worker result path; workers write to that header and never synthesize a `runs/<task-type>/...` destination. Their meaning and extraction rules for workers are owned by `okstra_ctl.worker_prompt_headers.worker_prompt_headers()`. Phase-specific extra headers (final-verification target snapshot, improvement-discovery grilling log) are emitted there too. The `**Worktree:**` anchor is not phase-specific: `okstra_ctl.initial_prompt_materialization._worktree_anchor_lines` renders it into every initial prompt whose run has a provisioned worktree, so an analysis worker anchors its reads to the same tree the executor mutates. **Enforced:** `okstra_ctl.initial_prompt_materialization._anchor_predates_this_contract` republishes a prompt that predates the anchor rather than refusing the dispatch.
 
 The `**Coding preflight pack:**` anchor is emitted only for the `implementation-executor` and `implementation-verifier` audiences. An implementation report-writer never receives it. A pane display role named `verifier` during `final-verification` is still an initial analysis worker; it neither receives implementation conventions nor becomes a Phase 5.5 reverify dispatch. Reverify is identified by the `-reverify-r<N>-` prompt/result path contract in [convergence](./convergence.md).
 
@@ -149,9 +149,11 @@ One selector serves every worker kind: `--team-state <path> --worker <id>`, repe
 | `livenessMode` | Backend | What it reads |
 |---|---|---|
 | `audit-heartbeat` | in-process dispatch (including `claude-worker` and `report-writer-worker`) | the row's `auditSidecarPath` — its newest `- PROGRESS:` heartbeat, measured from `startedAt` |
-| `wrapper-status` | CLI wrapper (`codex-worker` / `antigravity-worker`) | the row's `promptPath`, then `<prompt>.log` / `<prompt>.status.json`, measured from `startedAt` |
+| `wrapper-status` | CLI wrapper (`codex-worker` / `antigravity-worker`) | canonical wrapper artifacts resolved by `worker-liveness` from the row's `promptPath`, measured from `startedAt` |
 
-The mismatch is not intermittent, it is guaranteed: only the `okstra-*-exec.sh` wrappers ever write `<prompt>.log` / `<prompt>.status.json`, so an in-process worker produces neither by construction. That is why the mode decides the artifact and you never name it. Each grace begins at the atomic `in-progress` transition's `startedAt`, never at prompt-materialization time and never at an artifact's mtime.
+Only CLI wrappers write wrapper logs and status sidecars; in-process workers report through their audit sidecar. Each grace begins at the persisted `startedAt`, not prompt-materialization time or an artifact's mtime.
+
+For diagnostics, open the dispatch record's `statusSidecarPath` and follow its `log_path` value. `wrapper_status.log_path_for_prompt` removes the prompt's `.md` suffix for the log (`p.log`), while the status path keeps it (`p.md.status.json`). If the status sidecar is absent, use `worker-liveness` or `team await`; do not infer a dead worker from a guessed log filename.
 
 This is a transport-adapter liveness choice only. It does not change the reducer's worker identity or its verification responsibility: both remain bound to the registered worker instance and canonical artifacts.
 
@@ -166,21 +168,21 @@ After each worker attempt returns (regardless of role), Lead MUST verify the can
 - The deterministic provider process returned an explicit `*_RESULT_MISSING` sentinel.
 - The result file is absent at the resolved absolute path even though the worker returned without a `*_RESULT_MISSING` sentinel — for example, claude-worker returned its final assistant message but never persisted the artifact, or the wrapper exited 0 and the codex/antigravity sub-agent forwarded raw stdout despite the contract.
 - The result file exists but cannot be parsed (frontmatter unreadable, sections 1–5 entirely missing). A truncated file in the middle of section 5 is NOT covered here — it goes to the validator's regular `error` path, not the retry path.
-- `okstra worker-liveness --team-state <path> --worker <id>` reports a **CLI-wrapper** worker (`codex` / `antigravity`) `did-not-launch` — neither `<prompt-path>.log` nor `<prompt-path>.status.json` exists after the persisted `startedAt` plus the launch grace (default 60s). The wrapper writes its status sidecar before invoking the CLI and hard-fails loudly with a distinct exit code on every argument check before that, so the absence of BOTH artifacts means the dispatch itself never reached the script. Without this trigger the only evidence was a lead noticing two missing files by eye, and the run paid the full polling cap for a worker that never started.
+- `okstra worker-liveness --team-state <path> --worker <id>` reports a **CLI-wrapper** worker `did-not-launch` after its launch grace. The probe resolves both wrapper artifacts through `wrapper_status`; a missing guessed filename is not this verdict. Use the persisted probe outcome before retrying.
 - `okstra worker-liveness --team-state <path> --worker <id>` reports an **in-process** worker `stalled` — its registered audit sidecar's newest `- PROGRESS:` heartbeat is older than the cadence budget, or the sidecar carries no heartbeat at all. This is the in-process equivalent of the CLI wrappers' idle watchdog: the wrapper reaps a silent CLI itself, but nothing reaped a silent in-process worker until its deadline. The same selector serves both worker kinds — the sidecar is reused when a worker is re-dispatched, so the probe needs the row's `startedAt` to tell the previous attempt's last heartbeat apart from this dispatch's silence. A budget breach is not a verdict on its own: the probe re-reads the sidecar after half that stage's budget and reports `stalled` only when the newest heartbeat has not advanced, so an unhealthy verdict costs that confirmation window before it returns. That window is what separates a worker inside one long uninterruptible tool call — which cannot append a heartbeat at all — from a worker that died, and measuring it is the probe's job, not yours: do not second-guess a verdict by checking mtimes yourself. Tune it with `--stall-confirm <seconds>`; `0` restores the immediate verdict.
 - The result file exists but its audit sidecar does not, at `runs/<task-type>/worker-results/<worker>-audit-<task-type>-<seq>.md`. Workers write both in the same step, so a result without a sidecar means the Reading Confirmation block — the only evidence the worker read its inputs — was never produced. `validate-run.py` fails the run on this at Phase 7 either way (`validate_worker_results_audit`); checking it here spends the existing one-retry budget while the role can still be re-dispatched, instead of surfacing hours later when the worker session is gone.
-- `okstra worker-audit-check --run-dir <runs/<task-type>/> --task-type <t> --seq <n> --worker <id>` exits 2 on a backticked `path:line` citation in the worker's result that has no matching Evidence read row in its audit sidecar. Run it the moment you collect each result. Phase 7 enforces the same rules from the same implementation (`okstra_ctl.worker_audit_ledger`), but by then the worker session is gone and the only remaining moves are editing the result yourself — which destroys the audit chain the ledger exists to provide — or ending the run `contract-violated`. While the session is alive, `SendMessage` to the worker so it corrects its own citation; that costs about a minute against a re-dispatch or a failed run.
+- `okstra worker-audit-check --run-dir <runDirectoryPath from the active run context> --task-type <t> --seq <n> --worker <id>` exits 2 on a backticked `path:line` citation in the worker's result that has no matching Evidence read row in its audit sidecar. Run it the moment you collect each result. Phase 7 enforces the same rules from the same implementation (`okstra_ctl.worker_audit_ledger`), but by then the worker session is gone and the only remaining moves are editing the result yourself — which destroys the audit chain the ledger exists to provide — or ending the run `contract-violated`. While the session is alive, `SendMessage` to the worker so it corrects its own citation; that costs about a minute against a re-dispatch or a failed run.
 
 The same audit check parses command evidence from canonical rows such as `- Evidence command: {"command":"npm run check","cwd":"<project-root>","exitCode":0,"outputSummary":"all checks passed"}`. Workers record only commands that produced or verified a conclusion, not exploratory `rg`, `ls`, or file-opening commands. A malformed row is a contract failure returned by `okstra_ctl.worker_audit_ledger`; send the failure to the worker while its session is still available. Nothing scans these rows for secrets, so a row is never refused for how a setting is named — `AUTH_MODE=off` and `TOKEN_TTL=60` record verbatim. Do not tell a worker to drop or paraphrase a row on those grounds: a worker that cannot record the command it ran has no way to satisfy the evidence ledger that demands it.
 
 **One-retry policy:**
 
-1. On the FIRST result-missing trigger for a given role within a single run, Lead MUST call `redispatch_worker` with the byte-identical prompt — same `**Result Path:**`, same `**Prompt History Path:**`, same model assignment, and same adapter-native assignment identity. The redispatch counts as a second attempt against the existing role slot; do NOT create a new role-id, do NOT change the result file path, do NOT switch to a different model as a "workaround".
+1. On the FIRST result-missing trigger for a role within a run, use the adapter's retry operation with the same logical instructions, Result Path, model assignment, and role identity. V2 retries use `materialize_retry_invocation`: it preserves the previous prompt and metadata, generates the next attempt's Prompt History Path, metadata path, and attempt number, and verifies the new pair. The logical `invocationRef` remains unchanged. Do not copy the prior prompt's attempt fields or create a new role slot.
 2. If the SECOND attempt also fails the same check, Lead records the role's terminal status as `error` with `--message "result-missing after 1 retry"` and proceeds to Phase 5.5 / Phase 6 with the remaining workers' results. Lead MUST NOT retry a third time — convergence and the report writer are designed to operate on reduced-confidence single-or-two-analyser mode when one role is absent (`prompts/lead/okstra-lead-contract.md` "If only one worker result is usable: reduced-confidence synthesis").
 3. The retry counter is **per-run, per-role** and is NOT preserved across runs. A subsequent okstra run for the same task-key starts each role's counter fresh.
 4. Convergence reverify rounds (Phase 5.5) inherit the same one-retry budget — a reverify dispatch that triggers result-missing may be re-dispatched once.
-5. **Reading-plan exception for a deterministic failure.** Byte-identical is the rule because it stops a lead from hiding a failure behind a different model, provider, or result path. It does not fit a failure the prompt *causes*: when the first attempt exhausted its whole time budget with no output and the required reading it named is large enough to explain that, an identical retry buys a second timeout at the same cost. In that case only, Lead MAY change the **reading plan** — which files the worker reads and in what order, including skipping a file whose content is already reachable by another named path. Everything the invariant exists to protect stays fixed: same `**Result Path:**`, same `**Prompt History Path:**`, same model, same adapter-native assignment identity, same role-id, same task.
-   - The exception applies only when the first attempt produced **no result file** after consuming its full timeout. A worker that failed fast, errored, or returned a partial artifact is a transient/regular failure — retry it byte-identically.
+5. **Reading-plan exception for a deterministic failure.** When the first attempt exhausted its time budget without a result and measured input size explains that failure, the lead may revise the reading plan through a fresh corrective invocation. Preserve the Result Path, model assignment, and role identity. Use `agent-prompt materialize` with a fresh invocation ID and prompt path; changed task instructions cannot reuse a logical invocation whose input digest is already reserved. The new prompt supplies its own execution headers.
+   - The exception applies only when the first attempt produced **no result file** after consuming its full timeout. A worker that failed fast, errored, or returned a partial artifact follows the ordinary retry contract above.
    - Lead MUST log the deviation with the normal `contract-deviation` entry naming the removed or reordered reads and the measured evidence that motivated it (byte counts, elapsed time). An unlogged reading-plan change is a contract violation, not an exception.
    - This exception never licenses changing what the worker is asked to *produce*. Narrowing the deliverable to make it finish is a contract violation.
 
@@ -199,6 +201,8 @@ Lead-facing duties that stay here:
 - Lead and report-writer MUST preserve worker ticket tagging and `worker:item` source pairs when carrying findings into the final report.
 - Lead's result-missing redispatch check parses the frontmatter and sections 1–5 presence per the preamble contract (see "Lead Redispatch Policy on Result-Missing").
 
+**Enforced:** `scripts/okstra_ctl/convergence.py` `_parse_group_source` rejects a finding source that is not a `worker:item-id` pair, so a finding stripped of its worker attribution cannot enter the convergence queue the report is assembled from.
+
 ### Worker error-log command
 
 Workers record a tool failure through the typed `okstra error-log append-observed` command in `templates/worker-error-contract.md`. They do not create a JSON sidecar or pass JSON text. The command receives the assigned worker identity, task key, phase, model, and observed scalar fields; the Python writer owns JSONL serialization and validation.
@@ -215,6 +219,8 @@ Workers record a tool failure through the typed `okstra error-log append-observe
 - **No external timeout around `worker-dispatch`.** The deterministic dispatch owns BOTH timeout mechanisms: (1) the process polling cap (30min + optional 5min mtime grace), and (2) the shared runner's stream-idle watchdog. If the CLI produces nothing for `<idle-timeout-seconds>`, the runner terminates the process group and marks the status sidecar timed out. Lead MUST NOT layer an earlier host timeout around it.
 - `contract-violation` events (C) are recorded by Lead via `okstra error-log append-observed --error-type contract-violation ...` after inspecting worker outputs.
 
+**Enforced:** `scripts/okstra_ctl/worker_prompt_policy.py` `ERRORS_PATH_HEADERS` is the literal the prompt emitter writes and `scripts/okstra_ctl/worker_prompt_contract.py` treats as a non-body header, so the anchor reaches the worker rather than being synthesized; `scripts/okstra_ctl/dispatch_core.py` owns the polling cap and the runner's idle watchdog, leaving no place for a lead-side timeout.
+
 ## Convergence Phase Rules
 
 1. Re-verification uses the same worker roles and model assignments as the initial run.

package/runtime/prompts/profiles/_common-contract.md

@@ -44,6 +44,7 @@ profile document.
     `[CONFIRMED <YYYY-MM-DD> → RC-N]` markers on `Open Questions` rows are the per-row signal that the reporter has answered; their answers live verbatim under `## Reporter Confirmations` in the brief.
   - `Source Material` is reporter-verbatim. Do NOT paraphrase, summarize, reorder, or restructure it. Quote it directly when needed.
   - `## Task-Group Context` (present in the analysis packet only when the task-group has `.okstra/briefs/<task-group>/group-context.md`, copied to `instruction-set/task-group-context.md`) is background shared by every task in the group — why the group exists, how the result is measured, group-wide constraints, ticket relations. It is not this task's requirement ledger: the brief decides this run's scope, the group context decides the measure and what no task may break. Reason from the group's measure (its stated denominator) rather than from a quantity only this ticket exposes, and where the brief and the group context conflict, raise a `Clarification Items` row instead of resolving the conflict silently in either direction.
+  - `## Task-Group Memory` (present after `## Task-Specific Brief Extract` when a sibling task of the group has recorded a run) is what the other tasks of this task-group concluded in their latest run: per task, the phase it reached and its next phase, the headline, accumulated decisions, watch-out items, open follow-ups, and the record path. okstra writes it into the group's `group-context.md` at every `report-finalize` (`record-group-memory`); the region also opens with the group's start order (brief ordinal; graph edges quoted as `waits for`). A headline is a claim — read the cited record before building on it. A sibling's decision does not bind this run: where it conflicts with the brief, raise a `Clarification Items` row rather than re-deriving what the sibling settled or overriding it silently. This task's own entry is not carried; its history arrives through the timeline, prior-planning, and fix-history sections.
   - `Related Task Graph` is the structured task-topology handoff. If the section is present and not `_(none)_`, read it before classification, diagnosis, candidate discovery, fan-out, or next-step routing. Preserve the edge direction exactly as written: `From` → `To` is load-bearing for `depends-on`, `blocks`, parent/child, follow-up, and split relations.
     - Valid relations are `parent-of`, `child-of`, `depends-on`, `blocks`, `blocked-by`, `follow-up-of`, `split-from`, `duplicates`, and `related-to`. `duplicates` / `related-to` are undirected; every other relation is directed.
     - Treat `Source` as the edge provenance. Do not invent graph edges from filename similarity, topic overlap, or worker preference. If a needed edge is missing or contradictory, raise a `Clarification Items` row instead of silently reordering tasks.
@@ -90,7 +91,7 @@ profile document.
   - if a schema-v1 table or an analysis-worker result table requires a recommended answer, alternatives, or an evidence-check note, encode it inside the existing 4-column schema: put evidence notes in `Statement` as `Evidence checked: <path:line>` or `Evidence checked: none — <human-only reason>`, and put recommendations/options in `Expected form` as `Recommended: (a) <answer> — <rationale>; Alternatives: (b) <option> (c) <option>`. The recommended answer is always the first option and MUST carry the `(a)` label; alternatives continue the same letter sequence from `(b)` (a lone alternative is `(b) <option>`, never restart at `(a)`), so the full option set reads `(a) (b) (c) …` in order and renders each as its own selectable option. Do **not** append a pick-one answer-space summary such as `(pick 1 of A / B)` or `(pick N of …)` to `<options>` — the rendered `<select>` already enforces single choice, and that annotation leaks verbatim into an option label. Do not add `Recommended`, `Evidence`, `Alternatives`, or `evidence-checked` columns, and do not break the merged record-meta cell back into separate columns.
   - For schema v2, data.json is canonical and the HTML exports answers to a user-response sidecar; the source report is never edited. `--resume-clarification` carries those answers into the next run. The lower-level `--clarification-response <path>` remains available for scripted runs.
   - When a response is carried in, reconcile every prior `clarificationItems[]` row against new evidence and update its status to `resolved` or `obsolete` before issuing the next verdict. Schema-v1 compatibility Markdown may additionally render its conditional Section 0; the schema-v2 full reading copy records decisions under `## Clarification and User Decisions`.
-  - **Supersession (BLOCKING).** Reconciling the `C-*` row is only half of incorporating an answer. An answer does not merely *add* a decision — it *invalidates* whatever the previous run wrote under the opposite assumption. Before issuing the next decision, walk the prior deliverable prose for every statement the answer makes false and **delete or rewrite it**, then record the retirement. Adding the new decision while leaving the contradicting sentence in place puts two opposite instructions for the same symbol in one document; the implementer must then guess which is live, and the next verification round correctly blocks on it. In `implementation-planning` this record is `implementationPlanning.supersessionLedger[]` — one entry per answered clarification, either `disposition: superseded` (with the retired statement, its replacement, and the sections revised) or `disposition: no-dependent-statement` (with a rationale). **Enforced:** `validators/validate-run.py` `_validate_supersession_ledger` requires an entry per answered clarification; whether the claim is *true* is what the §5.5.9 adversarial round tests.
+  - **Supersession (BLOCKING).** Reconciling the `C-*` row is only half of incorporating an answer. An answer does not merely *add* a decision — it *invalidates* whatever the previous run wrote under the opposite assumption. Before issuing the next decision, walk the prior deliverable prose for every statement the answer makes false and **delete or rewrite it**, then record the retirement. Adding the new decision while leaving the contradicting sentence in place puts two opposite instructions for the same symbol in one document; the implementer must then guess which is live, and the next verification round correctly blocks on it. In `implementation-planning` this record is `implementationPlanning.supersessionLedger[]` — one entry per answered clarification, either `disposition: superseded` (with the retired statement, its replacement, and the sections revised) or `disposition: no-dependent-statement` (with a rationale). A plan built from a selected direction inherits the answers the option-selection record carried before it has any statement to retire, so those carried rows need no entry; the rows this plan itself raised and settled still do. **Enforced:** `validators/validate-run.py` `_validate_supersession_ledger` requires an entry per answered clarification, exempting the ledger's `carriedDecisions[]` ids on a selected-direction plan; whether the claim is *true* is what the §5.5.9 adversarial round tests.
 - Verdict Card data consistency (shared; schema-v1 Markdown keeps the legacy visible card):
   - The Card carries no verdict token — the token lives once, in `finalVerdict.verdictToken`, and every gate reads it there. `verdictCard.direction` byte-matches `finalVerdict.direction`; next-step routing agrees with `recommendedNextSteps[0]`. The full reading copy and human summary are derived from the data fields without repeating both visible sections. **Enforced in part:** the v3.0 schema's `verdictCard` is `additionalProperties: false` with no verdict-token property, so the token cannot be duplicated onto the Card, and `scripts/okstra_ctl/report_narrative.py` `_writer_owned_schema` applies the finished report's `$defs.Direction` enum to the narrative, rejecting an off-enum `direction` while the writer can still be re-run. The byte-match between the two `direction` fields is not compared by anything — assembly overwrites `nextStep` on both when the plan-body gate passes (`scripts/okstra_ctl/report_assembly.py:590-604`) but leaves `direction` as the writer wrote it.
 - Cross-worker traceability (shared — applies to every analysis worker output and to the lead's `## 6.` / `## 2.` tables in the final-report):