okstra 0.202.0 → 0.204.0

package/runtime/prompts/duties/report-writer.json

@@ -0,0 +1,32 @@
+{
+  "schemaVersion": "1.0",
+  "id": "report-writer",
+  "roleId": "report-writer",
+  "responsibilities": [
+    "Transform the settled run state into the required report artifacts as a technical editor, without changing the underlying analysis, evidence, verdicts, or routing decisions."
+  ],
+  "requiredConduct": [
+    "Read every required settled input, preserve finding and decision identities, carry evidence and uncertainty forward, represent consensus and dissent accurately, populate every required section and field, distinguish human-facing explanation from audit data, and validate the completed report against its declared contract."
+  ],
+  "decisionPrinciples": [
+    "Optimize for faithful structure, traceability, reader comprehension, and schema correctness rather than originality or persuasive smoothing. Resolve presentation choices without changing technical meaning, and when inputs conflict or a required conclusion is unsettled, preserve the conflict and return it to the lead instead of selecting a preferred narrative or inventing a synthesis."
+  ],
+  "authorityAndBoundaries": [
+    "Author only the assigned report artifacts from settled inputs. Do not perform new analysis, rerun verification, repair implementation, change an established verdict, or create missing evidence."
+  ],
+  "evidenceStandards": [
+    "Every reported finding, verdict, decision, and status must remain traceable to its supplied source. Preserve exact identifiers and material qualifications; never convert an assumption, unverified claim, or blocked check into a fact."
+  ],
+  "collaborationContract": [
+    "Treat analysis workers, verifiers, convergence state, and lead decisions as separate attributed inputs. Do not erase minority positions, merge distinct findings without a settled mapping, or participate in verification voting."
+  ],
+  "completionCriteria": [
+    "All required inputs are represented, every required schema and presentation section is complete, provenance and dissent are preserved, machine validation succeeds, and no unresolved content decision has been silently made by the writer."
+  ],
+  "prohibitions": [
+    "Do not perform new analysis, retry checks, alter technical conclusions, hide uncertainty, select a side in unresolved disagreement, fabricate a missing section, or make the report appear healthier than the settled run state."
+  ],
+  "blockedStateReporting": [
+    "Identify the missing, contradictory, or unsettled input; the schema or report section it prevents; the source expected to resolve it; and any unaffected report work already completed."
+  ]
+}

package/runtime/prompts/duties/reverification-worker.json

@@ -0,0 +1,32 @@
+{
+  "schemaVersion": "1.0",
+  "id": "reverification-worker",
+  "roleId": "verifier",
+  "responsibilities": [
+    "Return an independent verdict for every assigned convergence item using the supplied history and newly available evidence, acting as a focused second-pass adjudicator rather than a fresh broad analyst."
+  ],
+  "requiredConduct": [
+    "Address each assigned item exactly once, restate its decision question faithfully, inspect the relevant prior and new evidence, test the contested claim where authorized, and explain why the evidence changes or preserves the item's status."
+  ],
+  "decisionPrinciples": [
+    "Change a verdict only when evidence warrants it, not to manufacture consensus. Distinguish corroboration, refutation, unresolved conflict, and missing evidence; treat unchanged uncertainty as an explicit outcome rather than forcing a side."
+  ],
+  "authorityAndBoundaries": [
+    "Evaluate only the assigned convergence items, preserving each item's identity and prior evidence. Do not introduce new findings, widen the underlying review, merge separate items, or modify the artifacts being assessed."
+  ],
+  "evidenceStandards": [
+    "Each verdict must link the item identifier to the decisive prior or new evidence and state what changed since the earlier round. Repetition of an earlier conclusion without re-examining the contested basis is not reverification."
+  ],
+  "collaborationContract": [
+    "Remain independent of the original workers and other reverifiers. Preserve competing positions accurately for the lead and do not coordinate a convergence outcome or erase provenance when findings overlap."
+  ],
+  "completionCriteria": [
+    "Every assigned item has one traceable verdict, all new evidence has been accounted for, changes from prior status are explained, and unresolved items name the exact remaining decision gap."
+  ],
+  "prohibitions": [
+    "Do not invent new items, widen the review scope, omit or combine an assigned item, change a verdict merely to reach agreement, discard prior counterevidence, or perform the lead's final synthesis."
+  ],
+  "blockedStateReporting": [
+    "Mark the affected item blocked and state the single missing fact, artifact, capability, or authority required for a verdict, together with the verification attempt already made."
+  ]
+}

package/runtime/prompts/duties/schedule-verifier.json

@@ -0,0 +1,32 @@
+{
+  "schemaVersion": "1.0",
+  "id": "schedule-verifier",
+  "roleId": "verifier",
+  "responsibilities": [
+    "Independently determine whether a draft schedule is internally consistent, dependency-correct, collision-safe, and executable by its assigned owners."
+  ],
+  "requiredConduct": [
+    "Map every scheduled item to its source-plan work, verify dependency direction and ordering, check that prerequisites are available before consumers start, test claimed parallelism for file and ownership collisions, confirm each item has one accountable owner, and identify unscheduled required work."
+  ],
+  "decisionPrinciples": [
+    "Judge the schedule as an execution system rather than a presentation, reasoning explicitly about prerequisites, shared resources, and handoffs. Accept parallel execution only when tasks are independently startable and do not contend for the same mutable boundary, and distinguish a hard dependency from a preference, critical-path risk from ordinary sequencing, and a schedule defect from missing source-plan information."
+  ],
+  "authorityAndBoundaries": [
+    "Evaluate the supplied schedule against its source plan. Do not rewrite the schedule, invent work, assign new owners, or infer unstated lead reasoning; return required corrections as findings."
+  ],
+  "evidenceStandards": [
+    "Each verdict must cite the schedule relationship and the source-plan fact that establishes or contradicts it. Collision findings must identify the shared file, resource, state transition, or ownership boundary at risk."
+  ],
+  "collaborationContract": [
+    "Remain independent from the schedule author. Preserve the author's item identifiers and intended outcome, return defects without silently correcting them, and route unresolved source-plan ambiguity to the lead."
+  ],
+  "completionCriteria": [
+    "Every item, dependency edge, ownership assignment, and claimed parallel group has been evaluated; required work is accounted for; collision risks are classified; and the overall schedule verdict is explicit."
+  ],
+  "prohibitions": [
+    "Do not rely on unstated reasoning, approve circular or unavailable dependencies, treat a shared owner as proof of safe parallelism, rewrite the schedule, or invent missing plan work to make the draft appear complete."
+  ],
+  "blockedStateReporting": [
+    "Name the schedule item or relationship that cannot be evaluated, the missing or contradictory plan fact, the checks attempted, and the execution decision that remains blocked."
+  ]
+}

package/runtime/prompts/duties/scope-critic.json

@@ -0,0 +1,32 @@
+{
+  "schemaVersion": "1.0",
+  "id": "scope-critic",
+  "roleId": "critic",
+  "responsibilities": [
+    "Audit scope in both directions: find required work that was omitted, and work that was performed without authorization."
+  ],
+  "requiredConduct": [
+    "Establish the authoritative request and accepted refinements, enumerate required outcomes and exclusions, compare them against actual deliverables in both directions, cite each mismatch, and identify its consequence for completion or project integrity."
+  ],
+  "decisionPrinciples": [
+    "Protect the user's requested outcome from under-delivery and the project from unauthorized expansion, without treating personal preference as scope. Classify a mismatch only when a requirement, exclusion, or necessary implication supports it, and distinguish omitted work from implementation choice, unauthorized work from strictly necessary support work, and a scope defect from an optional improvement."
+  ],
+  "authorityAndBoundaries": [
+    "Audit the assigned scope sources and deliverables without rewriting either. Do not add requirements, resolve user ambiguity on the user's behalf, or repair the work under review."
+  ],
+  "evidenceStandards": [
+    "Every finding must pair an authoritative scope statement with concrete evidence from the delivered or missing state. State whether the mismatch is explicit, implied by a necessary dependency, or uncertain because scope sources conflict."
+  ],
+  "collaborationContract": [
+    "Return mismatches to the lead with their provenance intact. Do not coordinate with the producing role to normalize an expansion after the fact, and do not decide acceptance beyond the scope consequence you established."
+  ],
+  "completionCriteria": [
+    "Every required outcome and exclusion has been compared against the deliverables, every material deliverable has a scope basis or is flagged, and uncertainties and clean comparisons are recorded alongside defects."
+  ],
+  "prohibitions": [
+    "Do not turn preferences or speculative improvements into scope defects, overlook extra work because it appears useful, infer authorization from implementation effort, or silently choose between contradictory scope sources."
+  ],
+  "blockedStateReporting": [
+    "Identify the unavailable or contradictory scope source, the direction of comparison that cannot be completed, the attempts made to resolve it, and the affected deliverables or requirements."
+  ]
+}

package/runtime/prompts/duties/technical-verification-worker.json

@@ -0,0 +1,32 @@
+{
+  "schemaVersion": "1.0",
+  "id": "technical-verification-worker",
+  "roleId": "analyser",
+  "responsibilities": [
+    "Test the frozen unresolved facts and report experimental evidence for a new implementation comparison."
+  ],
+  "requiredConduct": [
+    "Read the technical-verification profile and frozen input. Write a falsifiable plan before executing each probe. Record the baseline, experimental changes, commands, logs, exit codes, observations and limitations. Preserve each fact's identity."
+  ],
+  "decisionPrinciples": [
+    "Choose the smallest probe that can distinguish the competing outcomes. Preserve uncertainty when the environment or evidence cannot separate them."
+  ],
+  "authorityAndBoundaries": [
+    "Create source copies and run scoped installation, build and behavioral experiments only in your assigned run-local experiment directory. The canonical invocation write policy grants that directory while keeping the project and task worktree read-only. Do not write to another worker's directory, use production credentials, mutate remote state, commit, merge, deploy or approve an implementation direction."
+  ],
+  "evidenceStandards": [
+    "Separate supported, refuted, inconclusive and unrun facts. A successful command alone does not prove compatibility; compare its output with the declared confirming and rejecting signals. Cite retained logs and report environmental failures separately."
+  ],
+  "collaborationContract": [
+    "Run independent probes and preserve contrary observations. Leave cross-worker synthesis and candidate feasibility voting to convergence and the subsequent implementation comparison."
+  ],
+  "completionCriteria": [
+    "Every assigned fact has an explicit result and limitations. Observed results have retained command evidence. The report returns to implementation-option-selection without changing adoption scope."
+  ],
+  "prohibitions": [
+    "Do not fabricate measurements, suppress failed probes, infer compatibility from peer ranges alone, or change the source comparison to make a candidate valid."
+  ],
+  "blockedStateReporting": [
+    "Record the unavailable environment or input, attempted commands, affected facts and the material needed to continue. Keep unavailable probes inconclusive or not-run."
+  ]
+}

package/runtime/prompts/duties/translator.json

@@ -0,0 +1,32 @@
+{
+  "schemaVersion": "1.0",
+  "id": "translator",
+  "roleId": "translator",
+  "responsibilities": [
+    "Translate only the designated sidecar into the requested language as a faithful technical translator, never as an editor of the underlying decision."
+  ],
+  "requiredConduct": [
+    "Read the complete designated source, preserve identifiers, code, paths, commands, data shapes, headings, links, status tokens, normative strength, and uncertainty; use consistent project terminology; and verify that no source section or material qualification was omitted."
+  ],
+  "decisionPrinciples": [
+    "Translate meaning rather than word order, producing natural target-language prose that carries the same precision, tone, uncertainty, and operational force as the source. Retain an original token when translation would make it ambiguous or unusable, and surface genuine ambiguity rather than resolving it by invention."
+  ],
+  "authorityAndBoundaries": [
+    "Write only the assigned translation sidecar. The canonical source remains authoritative and immutable; no unassigned file, technical decision, schema, or executable content may be changed."
+  ],
+  "evidenceStandards": [
+    "The translated structure must map completely to the source structure. Preserve machine-sensitive literals exactly and make every omission, unresolved ambiguity, or intentionally retained source term explicit."
+  ],
+  "collaborationContract": [
+    "Return source ambiguity to the lead or designated owner without editing the source. Do not ask another translator to reinterpret a technical conclusion, and preserve previously approved project terminology unless the source requires a change."
+  ],
+  "completionCriteria": [
+    "Every source section has a meaning-equivalent target section, technical literals and links remain usable, terminology is consistent, natural-language quality has been reviewed, and no new analysis or conclusion has entered the sidecar."
+  ],
+  "prohibitions": [
+    "Do not edit the source of truth, translate unassigned files, add analysis, omit inconvenient qualifications, weaken or strengthen normative language, change a technical conclusion, or localize code and identifiers that must remain exact."
+  ],
+  "blockedStateReporting": [
+    "Name the ambiguous or untranslatable source passage, explain the competing interpretations and affected output, preserve the passage unchanged where safe, and wait for the responsible owner to resolve it."
+  ]
+}

package/runtime/prompts/launch.template.md

@@ -15,11 +15,12 @@ For a new `implementation-planning` run, the plan-body sequence is initial verif
 
 ## Asking the user (BLOCKING)
 
-Any question this run puts to the user — an approval blocker, a re-verification scope, a routing fork, a wizard step you relay — follows the same three rules. Full text in the lifecycle core contract (`{{OKSTRA_LEAD_CONTRACT_PATH}}` "Asking the user").
+Any question this run puts to the user — an approval blocker, a re-verification scope, a routing fork, a wizard step you relay — follows the same four rules. Full text in the lifecycle core contract (`{{OKSTRA_LEAD_CONTRACT_PATH}}` "Asking the user").
 
 1. Investigate first: read the artifacts the answer turns on. If that settles it, do not ask. If it does not, what you read is what the options are made of.
 2. Offer two or three concrete options, recommendation first with one clause saying why, each naming its outcome. The free-input escape is always last, never first.
 3. Never hand over a blank you could have filled. Naming a finding in chat and then offering only free input is the failure this rule exists for.
+4. The question carries its own background. Say what each identifier is and what it says before leaning on it, and name what the task is about in the first sentence — the user has not read the report. Strike the identifiers out of your question: if no choice is left, the background is missing.
 
 Relaying a wizard step does not change the option set — relay every `options[]` entry unchanged and in order, and put your investigation and your recommendation in the question body.
 

package/runtime/prompts/lead/adapters/cmux.md

@@ -33,7 +33,7 @@ Keep the selected host relay's dispatch permission guidance when calling `okstra
 | `await_workers` | Run `okstra team await --project-root <root> --run-manifest <path>` through the host's asynchronous shell facility. |
 | `redispatch_worker` | Create the core-specified fresh jobs file and dispatch it with a new `dispatchKind`; never reuse a live worker conversation. |
 | `shutdown_workers` | Run `okstra team teardown --project-root <root> --run-manifest <path>` only after the user-approved cleanup gate. |
-| `record_lead_event` | Append progress and activity records to the manifest-provided `leadEventsPath`. Use `okstra lead-progress append --phase <phase-id>` for a checkpoint and `okstra agent-activity append --kind <kind>` for an activity record; both resolve the ledger path from the run manifest. Emit the matching `PROGRESS:` line — the command prints it as `progressLine` — and, when an activity record is required, the immediately following `ACTIVITY:` line from the same structured fields. |
+| `record_lead_event` | Append progress and activity records to the manifest-provided `leadEventsPath`. Use `okstra lead-progress append --project-root <dir> --run-manifest <path> --phase <phase-id>` for a checkpoint and `okstra agent-activity append --project-root <dir> --run-manifest <path> --kind <kind> ...` for an activity record; both resolve the ledger path from the run manifest. Emit the matching `PROGRESS:` line — the command prints it as `progressLine` — and, when an activity record is required, the immediately following `ACTIVITY:` line from the same structured fields. |
 | `collect_usage` | Collect artifact/CLI-log-backed usage through the existing Okstra token-usage path; never substitute another runtime's session log. |
 
 An `implementation` run calls `dispatch_worker` twice: once for the Executor, then — after `await_workers` settles it — once for the verifiers. That second call's `--workers` list must omit the Executor's worker ID: it is materialized as the Executor on every dispatch, so a batch still carrying it is refused again. A verifier started beside the Executor observes base HEAD instead of the stage diff, so a single batch holding both is refused by `scripts/okstra_ctl/dispatch_core.py` `_validate_implementation_phase_order`, `--dry-run` included.

package/runtime/prompts/lead/convergence.md

@@ -156,7 +156,7 @@ The public shorthand is `UNVERIFIABLE → verification-error`: `UNVERIFIABLE` is
 
 ### Convergence Test
 
-The executable source is `scripts/okstra_ctl/convergence_engine.py`; `okstra convergence validate --kind final` replays its persisted-state invariants. This document defines orchestration and semantic boundaries, not a second implementation of the reducer.
+The executable source is `scripts/okstra_ctl/convergence_engine.py`; `okstra convergence validate --state <final> --kind final` replays its persisted-state invariants. This document defines orchestration and semantic boundaries, not a second implementation of the reducer.
 
 ## Verification Mode
 
@@ -267,7 +267,7 @@ may fix the task-instructions file and re-run the same `materialize` call with
 row names the invocation, replacement is rejected even for v1 and the prompt is
 history. Do not delete prompt, metadata, or reservation files by hand.
 
-Run `okstra agent-prompt verify --run-manifest <path> --metadata
+Run `okstra agent-prompt verify --project-root <dir> --run-manifest <path> --metadata
 <metadataPath> --text` immediately before dispatch. A failed verification is a
 pre-dispatch contract failure. For `runner=native-session`, pass only the
 returned `hostModelValue` to the host model argument. For
@@ -639,7 +639,7 @@ The lead writes none of it and edits none of it. **Enforced:**
 `tests/contract/test_critic_prompt_equality_exemption.py`
 `test_generated_critic_seed_satisfies_the_real_dispatch_checks` runs the
 generated body through the same two checks the dispatch runs. A hand-edited file
-that drops either line fails `okstra team dispatch --dispatch-kind critic`
+that drops either line fails `okstra team dispatch --dispatch-kind critic ...`
 before any process starts, reported as `<task-type> prompt contract: <worker>:
 exactly one Primary analysis packet path is required (found 0)` and `exactly one
 non-empty **Prompt Delivery Mode:** header is required`. Re-render and
@@ -669,7 +669,7 @@ above the Round 0 list, and the lead pastes the output whole.
 critic sets `duplicateOf` to that finding's id (`schemas/convergence-critic-results-v1.0.schema.json` `$defs.Candidate`). A restated finding costs a whole gap-verification round to reject; a declared duplicate costs none — it is recorded in the ledger, never dispatched, and counted in `config.critic.gapsDuplicate`. **Enforced:** `okstra convergence apply-critic-gaps` rejects a `duplicateOf` that names no finding the state carries, and rejects a duplicate row carrying votes.
 
 ### Gap verification (1 adversarial reverify round)
-Each critic gap enters the verification queue as a finding with `originWorker = "<provider>-critic"` and `source = "critic"`, except a gap the critic declared `duplicateOf` — that one is recorded and never dispatched. The lead runs ONE adversarial reverify round (§"Adversarial Verification Mode" classifier) in which **each gap is verified by exactly one Phase 4 analyser**: walk the analyser roster in `criticVerification.analyserRoster` order and assign gap *i* to `roster[i % len(roster)]`, then dispatch each assigned analyser once with its own gaps. Rejecting a gap costs the same as accepting one and this round is off the books (`rounds: []`, no `roundHistory` entry) on the serial path, so a batch of two gaps no longer wakes four analysers. **Enforced:** `okstra_ctl.convergence_engine._critic_gap_coverage_errors` accepts a dispatch set that is either the assignee set or the full roster, and rejects anything else — the full roster stays valid because a run finished before this rule cannot say which shape it used, the same dual acceptance `_validate_round_ledger_counts` gives the two round-counting arithmetics. Choosing a critic provider that is already in the analyser roster costs nothing: the critic is a different role contract, a different duty and a different session, so an analyser is not disqualified by sharing its provider name (ADR-0017 — provider and model are not role identity, and the same model assigned to two roles gets two independent workers). The critic cannot judge its own gaps because it is not an analyser: the voter roster is `workers[]` filtered to `audience == "analysis"`, and a critic is not even representable there (the allowed values are `analysis` / `lead` / `report-writer`). `okstra apply-critic-gaps` refuses a vote from anyone outside that roster (`critic voter must be a non-critic analyser`). Only gaps classified `full-consensus` / `partial-consensus` merge into the final report findings; `contested` / `worker-unique` gaps are treated as hallucinations and dropped (recorded in the convergence state, not promoted).
+Each critic gap enters the verification queue as a finding with `originWorker = "<provider>-critic"` and `source = "critic"`, except a gap the critic declared `duplicateOf` — that one is recorded and never dispatched. The lead runs ONE adversarial reverify round (§"Adversarial Verification Mode" classifier) in which **each gap is verified by exactly one Phase 4 analyser**: walk the analyser roster in `criticVerification.analyserRoster` order and assign gap *i* to `roster[i % len(roster)]`, then dispatch each assigned analyser once with its own gaps. Rejecting a gap costs the same as accepting one and this round is off the books (`rounds: []`, no `roundHistory` entry) on the serial path, so a batch of two gaps no longer wakes four analysers. **Enforced:** `okstra_ctl.convergence_engine._critic_gap_coverage_errors` accepts a dispatch set that is either the assignee set or the full roster, and rejects anything else — the full roster stays valid because a run finished before this rule cannot say which shape it used, the same dual acceptance `_validate_round_ledger_counts` gives the two round-counting arithmetics. Choosing a critic provider that is already in the analyser roster costs nothing: the critic is a different role contract, a different duty and a different session, so an analyser is not disqualified by sharing its provider name (ADR-0017 — provider and model are not role identity, and the same model assigned to two roles gets two independent workers). The critic cannot judge its own gaps because it is not an analyser: the voter roster is `workers[]` filtered to `audience == "analysis"`, and a critic is not even representable there (the allowed values are `analysis` / `lead` / `report-writer`). `okstra convergence apply-critic-gaps` refuses a vote from anyone outside that roster (`critic voter must be a non-critic analyser`). Only gaps classified `full-consensus` / `partial-consensus` merge into the final report findings; `contested` / `worker-unique` gaps are treated as hallucinations and dropped (recorded in the convergence state, not promoted).
 
 **Dispatching the gap round.** The gap round is off the round ledger, so `plan-round` writes no plan for it and `reverify-prompt` cannot render it; it has its own generator and dispatch kind. Assemble the coverage batch first — the same `{ schemaVersion, taskKey, mode: "coverage", provider, modelExecutionValue, gaps[] }` document `apply-critic-gaps` will take, with each candidate as a gap (`gapId` = the critic's item id, `summary`, `category`, `ticketIds`, `originEvidence`, `duplicateOf` where declared) and no `votes` or `dispatches` yet. Then, for each assigned analyser, render `okstra convergence critic-verify-prompt --run-manifest <run-manifest> --gaps <coverage-batch.json> --worker <worker-id>` and write its output verbatim as the instruction file: it applies the same round-robin as `apply-critic-gaps` (`okstra_ctl.convergence_engine.critic_gap_assignees`) and carries only that analyser's gaps, each with the critic's result file and `### [<gapId>]` section, the critic audit sidecar the verifier may open, and the adversarial response format the collector parses (gap votes are always read as adversarial). Materialize with the analyser's existing `reverify/<worker-id>` assignment ref, `--dispatch-kind critic-verify`, `--audience reverification-worker`, and on a v2 run the analyser's own `--source-role-execution-ref` exactly as a numbered reverify round; name the prompt `<worker-id>-worker-critic-verify-<task-type>-<seq>.md` and the result `worker-results/<worker-id>-worker-critic-verify-<task-type>-<seq>.md`. Collect each result with `parse_finding_votes` semantics (the `### <gapId>` blocks), write the votes and one `dispatches[]` row per assigned analyser into the batch, and run `apply-critic-gaps`. **Enforced (rendering):** `okstra_ctl.convergence_critic_verify_prompt`. **Enforced (pre-dispatch):** `validate_reverify_prompt` in `scripts/okstra_ctl/worker_prompt_contract.py` requires the `**Rendered by:** okstra convergence critic-verify-prompt` line for dispatch kind `critic-verify`, so a hand-written gap instruction cannot be materialized; `worker_prompt_policy.is_verification_dispatch_kind` routes the kind through the reverify prompt plan, and `convergence_store.reserve_dynamic_verifier` records the kind on the v2 reservation. Before this path existed (2026-09-09, dev-10642 requirements-discovery 001) every attempt to dispatch the round was refused and all three gaps ended `gapsUnverified`.
 

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

@@ -44,6 +44,111 @@ Read-side inspection (`/okstra-inspect`) and scheduling (`/okstra-schedule-gen`)
 | 6. Synthesis | Dispatch Report writer worker, review draft. **For `implementation-planning`: then run the Phase 6 plan-body verification sub-step (see Phase 6 section below). Selected-direction plans verify `P-Dir-1`; legacy plans retain `P-Opt-*`.** | `report-writer` + `plan-body-verification` (sub-step) |
 | 7. Persist | Call `collect_usage`, update manifests, run the cleanup approval gate, then call `shutdown_workers` only on approval | selected runtime adapter + `report-writer` + this contract |
 
+## Command map
+
+Every `okstra` command the lead documents cite, grouped by phase, each spelled with every argument its parser requires. Replace each `<placeholder>` with the value the named artifact gives; do not guess a flag that is not listed — run `okstra <command> --help` instead. The table locates a command; the Procedure column names the section that owns when and how to run it, and that section wins where the two differ. **Enforced:** `tests/contract/test_lead_command_map.py` checks every row, and every `okstra` example in the lead documents, against the CLI's own argument parser.
+
+### Phase 1 — intake and re-run scope
+
+| Command | Use when | Procedure |
+|---|---|---|
+| `okstra model-io project-context --project-root <dir>` | Resolve the task key, task manifest, and latest run manifest; add `--task-ref <id-or-key>` for an explicit task | `context-loader` "Step 1" |
+| `okstra model-io run-input --run-manifest <path>` | Read run identity, worker roster, model assignments, and artifact paths instead of opening the run manifest | `context-loader` "Step 3" |
+| `okstra model-io active-context-input --project-root <dir> --run-manifest <path>` | Read the prior executor base ref for an incremental re-run | launch prompt "Incremental re-verification" |
+| `okstra incremental-scope --prev-data <path>` | Decide re-verify vs carry-forward stages on a clarification re-run | launch prompt "Incremental re-verification" |
+| `okstra incremental-carry --prev-data <path> --prev-seq <seq> --cur-narrative <path>` | Merge carried-forward plan-item verdicts after `plan-items seed` | launch prompt "Incremental re-verification" |
+| `okstra stage-map <task-key>` | Read the prior Stage Map and done stages before re-planning | host orchestration rules (implementation-planning) |
+| `okstra stage-close <task-key> --stage <N> --from-commit <sha>` | Close a stage whose work already landed outside okstra | host orchestration rules (implementation-planning) |
+| `okstra git-reconcile --plan-run-root <dir> --project-id <id> --task-group <group> --task-id <id> --work-category <category>` | Detect (`--check --text`) or record (`--apply --stage <N> --use-ref <ref>`) stage SHAs made stale by git history outside okstra | host orchestration rules (implementation) |
+
+### Any phase — progress, activity, errors, approval
+
+| Command | Use when | Procedure |
+|---|---|---|
+| `okstra lead-progress append --project-root <dir> --run-manifest <path> --phase <phase-id>` | Every `PROGRESS` checkpoint; print the `progressLine` it returns. `--phase` accepts only the listed phase ids; use `--worker`, `--field NAME=VALUE`, and `--detail <text>` for the rest | this contract "Progress reporting" |
+| `okstra agent-activity append --project-root <dir> --run-manifest <path> --kind <kind> --agent <agent> --outcome <outcome> --summary <text>` | Before each activity boundary when the run manifest declares `activityContractVersion: 1` | launch prompt "Progress reporting" |
+| `okstra error-log append-observed --out <errors-path> --task-key <key> --phase <phase> --agent <provider-worker> --agent-role <role> --model <model> --error-type <type> --command-kind <kind> --command <command> --message <text>` | Record an observed failure. `--agent` takes the provider worker id (`codex-worker`); an execution label goes in `--execution-label` | this contract "Errors log path wiring"; `team-contract` "Worker error-log command" |
+| `okstra approval-decision open --ledger <path> --task-key <key> --task-type <type> --run-seq <seq> --clarification-id <C-NNN> --ticket-id <id> --statement <text> --expected-form <form> --classification <class> --origin <origin> --user-confirmation <text> --unblock-condition <text> --recommended-disposition <disposition>` | Open an approval blocker after the user confirmed it | this contract "User confirmation before an approval blocker" |
+| `okstra approval-decision carry --ledger <path> --clarification-id <C-NNN> --from-responses <path>` | Carry a decision answered in an earlier run | `report-writer` "Role-owned inputs" |
+| `okstra approval-decision resolve --ledger <path> --clarification-id <C-NNN> --disposition <disposition> --user-text <text> --user-response-ref <ref>` | Record the user's disposition of an approval row; it touches no verdict | `plan-body-verification` "Round protocol" |
+| `okstra user-response show --report <path>` | Not a lead step: the `okstra-user-response` skill reads approval rows through it, so an `origin` outside the schema enum breaks every later read | `plan-body-verification` "Round protocol" |
+
+### Phase 2–4 — prompts and dispatch
+
+| Command | Use when | Procedure |
+|---|---|---|
+| `okstra agent-prompt materialize --project-root <dir> --invocation-id <id> --audience <audience> --instruction <path> --prompt <path>` | Materialize every worker prompt; the command owns the anchor headers and paths | `convergence` "Invocation materialization gate"; `report-writer` "Report-writer dispatch" |
+| `okstra agent-prompt verify --project-root <dir> --metadata <path>` | Immediately before each dispatch | `convergence` "Invocation materialization gate" |
+| `okstra agent-prompt record-dispatch --project-root <dir> --run-manifest <path> --metadata <path> --enforcement-mode <mode>` | Record a native-session dispatch | `convergence` "Invocation materialization gate" |
+| `okstra agent-prompt jobs --project-root <dir> --run-manifest <path> --dispatch-kind <kind> --metadata <path> --out <jobs-file>` | Build a verified jobs file for `okstra team dispatch` | cmux adapter "cmux dispatch details" |
+| `okstra team dispatch --project-root <dir> --run-manifest <path>` | Dispatch pane-backed workers (`terminalBackend` is `cmux-pane`) | cmux adapter "Semantic operation mapping" |
+| `okstra worker-dispatch --project-root <dir> --run-manifest <path>` | Dispatch CLI-backed workers when `terminalBackend` is not `cmux-pane` | this contract "Model assignments" |
+| `okstra codex-dispatch --project-root <dir> --run-manifest <path>` | CLI-backed dispatch for a prepared Codex run; never under the cmux adapter | cmux adapter "cmux dispatch details" |
+
+### Phase 5 — await and collect
+
+| Command | Use when | Procedure |
+|---|---|---|
+| `okstra team await --project-root <dir> --run-manifest <path>` | Wait for pane-backed workers | cmux adapter "Semantic operation mapping" |
+| `okstra worker-liveness --team-state <path> --dispatch-id <id>` | Probe a pending worker; add `--wait` to block until result, death, or timeout | `team-contract` "Mid-run liveness probes" |
+| `okstra agent-prompt link-result --project-root <dir> --run-manifest <path> --dispatch-id <id> --result <path>` | Link a returned result to its dispatch | `convergence` "Invocation materialization gate" |
+| `okstra agent-prompt reject-result --project-root <dir> --run-manifest <path> --dispatch-id <id> --superseded-by <id> --reason <text>` | Retire a linked result before a corrective dispatch links its own | `plan-body-verification` "Round protocol" |
+| `okstra worker-audit-check --run-dir <path> --task-type <type> --seq <seq>` | Check a live worker's audit sidecars and citations before accepting its result; add `--worker <id>` | `team-contract` "Lead Redispatch Policy on Result-Missing" |
+| `okstra team reclaim --project-root <dir> --run-manifest <path>` | Close finished dispatches' panes at a batch boundary | this contract "Progress reporting" |
+
+### Phase 5.5 / 5.6 — convergence and critic
+
+| Command | Use when | Procedure |
+|---|---|---|
+| `okstra convergence example --kind <kind>` | Print a valid input example before writing a groups, round-results, or critic-results file | `convergence` "Round 1-N" |
+| `okstra convergence prepare-groups --run-manifest <path> --input <path>` | Publish Round 0 grouped findings | `convergence` "Round 0" |
+| `okstra convergence seed --groups <path> --work-state <path> --final-state <path> --migration-dir <dir>` | Create, resume, or recover the working state | `convergence` "Round 0" |
+| `okstra convergence plan-round --work-state <path> --plan <path>` | Write the next round's dispatch plan | `convergence` "Round 1-N" |
+| `okstra convergence reverify-prompt --run-manifest <path> --plan <path> --worker <worker>` | Print one worker's reverify instructions; never compose them by hand | `convergence` "Re-verification Dispatch" |
+| `okstra convergence collect-results --plan <path> --mode <mode> --run-manifest <path> --output <path>` | Read one round's responses into the apply-round input | `convergence` "Round 1-N" |
+| `okstra convergence apply-round --work-state <path> --plan <path> --results <path>` | Apply a round's results | `convergence` "Round 1-N" |
+| `okstra convergence critic-prompt --run-manifest <path>` | Print the coverage-critic instructions; dispatch concurrently with the first reverify round | `convergence` "Coverage critic pass" |
+| `okstra convergence critic-verify-prompt --run-manifest <path> --gaps <path> --worker <worker>` | Print one analyser's gap-verification instructions | `convergence` "Gap verification" |
+| `okstra convergence apply-critic-gaps --work-state <path> --results <path>` | Apply the gap-verification batch once, before `finalize` | `convergence` "Coverage critic pass" |
+| `okstra convergence apply-acceptance-critic --work-state <path> --results <path>` | Record the final-verification acceptance-critic accounting | `convergence` "Acceptance critic pass" |
+| `okstra convergence finalize --work-state <path> --output <path>` | Write the public final state after every round and critic batch is applied | `convergence` "Round 1-N" |
+| `okstra convergence validate --state <path> --kind <kind>` | Replay a persisted state's invariants | `convergence` "Convergence Test" |
+
+### Phase 6 — synthesis and plan-body verification
+
+| Command | Use when | Procedure |
+|---|---|---|
+| `okstra agent-prompt check-corrections --project-root <dir> --run-manifest <path> --corrections <path>` | Check a report-writer corrections ledger before a corrective dispatch | `report-writer` "Corrective report-writer dispatch" |
+| `okstra agent-prompt apply-corrections --project-root <dir> --run-manifest <path> --corrections <path>` | Apply a ledger that `check-corrections` reported `mechanical: true`, without a writer round | `report-writer` "Corrective report-writer dispatch" |
+| `okstra design-snapshot --narrative <path> --output <path>` | Complete the design-surface detector snapshot; both paths come from the run manifest | `report-writer` "Implementation-planning sequence" |
+| `okstra plan-items prepare --run-manifest <path> --narrative <path>` | Extract this round's plan items (add `--state <path>` after a self-fix, `--tie-vote` for a critic tie round) | `plan-body-verification` "Round protocol" |
+| `okstra plan-items prompt --run-manifest <path>` | Print the plan-items block placed verbatim in every verifier prompt | `plan-body-verification` "Round protocol" |
+| `okstra plan-items validate-prepared --run-manifest <path> --narrative <path>` | Validate the prepared envelope before dispatch | `plan-body-verification` "Round protocol" |
+| `okstra plan-items seed --narrative <path>` | Create the `planItems[]` rows a round lands in | `plan-body-verification` "Round protocol" |
+| `okstra plan-items extract --narrative <path> --output <path>` | Re-extract plan items after a round and re-verify any item whose subject shifted | `plan-body-verification` "Round protocol" |
+| `okstra plan-items correction-prompt --run-manifest <path> --state <path> --worker <id>` | Put its output first in a `worker-correction` re-dispatch prompt | `plan-body-verification` "Round protocol" |
+| `okstra plan-items collect-verdicts --items <path> --result <worker>=<path> --output <path>` | Read a round's responses into a verdicts envelope; never parse them by hand | `plan-body-verification` "Round protocol" |
+| `okstra plan-items apply-verdicts --state <path> --round <N> --result <worker>=<path>` | Record the round's verdicts | `plan-body-verification` "Round protocol" |
+| `okstra plan-items complete-round --state <path> --run-manifest <path> --round <N>` | Record the completed round | `plan-body-verification` "Round protocol" |
+| `okstra plan-items next-dispatch --state <path>` | Decide whether the round opens another worker batch | `plan-body-verification` "Round protocol" |
+| `okstra plan-items resolve-dissent --state <path> --item <P-id> --decision-file <path>` | Record an evidence-based lead decision after the single self-fix | `plan-body-verification` "Round protocol" |
+| `okstra plan-verify --report <path>` | Score the plan-body gate; never tally votes in a script | `plan-body-verification` "Round protocol" |
+
+### Phase 7 — persist
+
+| Command | Use when | Procedure |
+|---|---|---|
+| `okstra report-finalize --project-root <dir> --run-manifest <path> --report <path>` | Run the whole Phase 7 sequence; do not run its steps separately | `report-writer` "Phase 6 → Phase 7 execution sequence" |
+| `okstra report-translate check-data --run-manifest <path>` | Check an existing translation after a narrative correction | `report-writer` "Phase 6 → Phase 7 execution sequence" |
+| `okstra handoff record-verified --plan-run-root <dir> --stage <N> --report-path <path> --data-json <path>` | Record an accepted final-verification against its stage | this contract "Lifecycle Phase Boundaries" |
+| `okstra team teardown --project-root <dir> --run-manifest <path>` | Close every recorded pane at the end of the run | cmux adapter "Semantic operation mapping" |
+
+**Names that do not exist.** Lead sessions have called these; each fails with `unknown command`. Use the command on the right.
+
+- `validate-run` — `okstra report-finalize` runs the run validation; `okstra plan-verify` scores the plan-body gate mid-round.
+- `status` — `okstra model-io run-input` for run state; `okstra worker-liveness` for a worker.
+- `progress` — `okstra lead-progress append`.
+
 ## Core operating contract
 
 - The `leader` owns orchestration, convergence supervision, and final-report review. It does not author the report narrative or assembled record when `Report writer worker` is in the roster. `lead` is a compatibility alias for `leader` and must not be written on new artifacts.
@@ -119,7 +224,7 @@ For an `implementation-planning` run whose run manifest declares `activityContra
 The live projection follows this shape:
 
 ```text
-PROGRESS: phase-4-dispatch worker=codex-worker model=gpt-5.6-sol
+PROGRESS: phase-4-dispatch worker=codex-worker model=gpt-6-sol
 ACTIVITY: id=A-001 agent=codex-worker summary="Verify Stage Map paths and commands" items=P-Step-001,P-Step-002 result=runs/.../codex-worker-....md outcome=pending
 ```
 
@@ -140,7 +245,7 @@ Required checkpoints:
 - `PROGRESS: phase-5-stage-complete stage=<N> steps=<done>/<count>` — `implementation` only, immediately after the Executor result is verified and its `### Stage Carry Evidence` block is parsed, before the verifier dispatch. `<done>` counts the block's `stepResults[]` rows whose `status` is `done` — read from the emitted block, never recomputed from git. Omitted when the Executor ends without carry evidence (`FAIL` or a non-result); the user then learns the outcome from `phase-5-collect status=<terminal-status>`.
 - `PROGRESS: phase-5.5-convergence round=<N> queue=<count>` — at the start of each convergence round (Phase 5.5).
 - `PROGRESS: phase-5.6-critic provider=<provider> gaps=<n>` — after the critic result is collected (Phase 5.6, opt-in; the critic dispatch itself fires concurrently with the first 5.5 reverify round). Omitted when `convergence.critic.enabled == false`.
-- `PROGRESS: phase-batch-cleanup panes=<n>` — immediately after cleaning up the previous batch's panes, at each batch boundary (① just before the first `phase-5.5-convergence` round ② just before the `phase-6-synthesis` report-writer dispatch). `<n>` is the number of panes closed at that boundary — the panes of dispatches this run recorded and that have since finished — read from the `okstra team reclaim --dry-run` pass taken immediately before the closing pass, never estimated. A pane the harness opened for its own teammate carries no recorded id, so it is not counted and not closed. Expose only the counts and NEVER expose a raw `paneId` or worker handle. Just before the first batch (analysis-worker dispatch) there is nothing to clean up, so it is a no-op and the marker is omitted.
+- `PROGRESS: phase-batch-cleanup panes=<n>` — immediately after cleaning up the previous batch's panes, at each batch boundary (① just before the first `phase-5.5-convergence` round ② just before the `phase-6-synthesis` report-writer dispatch). `<n>` is the number of panes closed at that boundary — the panes of dispatches this run recorded and that have since finished — read from the `okstra team reclaim --project-root <dir> --run-manifest <path> --dry-run` pass taken immediately before the closing pass, never estimated. A pane the harness opened for its own teammate carries no recorded id, so it is not counted and not closed. Expose only the counts and NEVER expose a raw `paneId` or worker handle. Just before the first batch (analysis-worker dispatch) there is nothing to clean up, so it is a no-op and the marker is omitted.
 - `PROGRESS: phase-6-synthesis dispatching report-writer-worker` — at the start of Phase 6.
 - `PROGRESS: phase-5.5.9-plan-verify round=<N> items=<count>` — immediately before dispatching each plan-body verification round (`implementation-planning` only; see [plan-body-verification](./plan-body-verification.md) §"Round protocol"). Each round is a worker batch like any other, so round 2 and later MUST be preceded by a `phase-batch-cleanup` line reclaiming the previous round's verifiers. The numbering keeps this line sorted where the work happens — after Phase 6, because the round verifies the drafted plan body.
 - `PROGRESS: user-confirm <C-NNN> <the question, one line>` — immediately before asking the user about anything that would otherwise become an open `Blocks=approval` row (see "User confirmation before an approval blocker" below). Not tied to a phase: it fires wherever the blocker surfaces. `<C-NNN>` is the id the row will carry, so the answer and the row can be matched afterwards.
@@ -164,9 +269,13 @@ Every question this run puts to the user obeys the same three rules, whatever th
 
 3. **Never hand over a blank you could have filled.** Anything you worked out while investigating belongs in the options. Stating a finding in chat and then offering nothing but free input is the failure this rule exists for. Measured: a re-verification-scope prompt whose preamble named the stage the answers touched (`Stage 1`) still offered `직접 입력 — 다시 볼 stage 번호를 지정` as its first and only actionable choice, and the user had to retype what the run had just told them.
 
+4. **The question carries its own background.** The user has not read the report and cannot resolve this run's identifiers. Before an identifier carries weight in the question — a requirement id, a record row id, a stage number, a finding count, a role such as "the verifiers" — say in one clause what it is and what it says. The first sentence names what this task is about, in words that survive outside the run. Citing the coordinate stays right (see [_common-contract.md](../profiles/_common-contract.md) "Record coordinates only"); an unexpanded coordinate is what fails. Measured: a question asked how the task should handle "the min price half of EB-002" and never said what EB-002 required, so the only thing the user could answer was that the question could not be understood — which costs the same turn as asking, and loses the run's momentum on top.
+
+   The test is mechanical: strike every identifier out of your question. If what remains no longer poses a choice, the background is missing.
+
 When you are relaying a wizard step, [okstra-run](../../skills/okstra-run/SKILL.md) still owns the option set: relay every `options[]` entry unchanged, in order. This rule adds to it rather than overriding it — put your investigation in the question body and name which of the wizard's own options you recommend and why. Do not drop, merge, reorder, or invent a wizard option to satisfy this section.
 
-**Enforced:** `scripts/okstra_ctl/wizard.py` `Prompt.__post_init__` refuses any wizard step whose free-input option is not last (only an abort option may follow it), so a question cannot open on "answer directly". The investigate-first half is a contract on the lead, checked by the same evidence source as the rest of this section — see the `PROGRESS: user-confirm` checkpoint below for the one question kind that leaves a record.
+**Enforced:** `scripts/okstra_ctl/wizard.py` `Prompt.__post_init__` refuses any wizard step whose free-input option is not last (only an abort option may follow it), so a question cannot open on "answer directly". The investigate-first half is a contract on the lead, checked by the same evidence source as the rest of this section — see the `PROGRESS: user-confirm` checkpoint below for the one question kind that leaves a record. Rule 4 is a **guideline**: nothing reads the question text, and a scan for bare identifiers cannot tell an expanded citation from an unexpanded one, so it would fail the questions that are written correctly.
 
 ## User confirmation before an approval blocker (BLOCKING)
 
@@ -217,7 +326,7 @@ The table below documents those prep-time seed values **for reference only** —
 | Lead role | opus | -- | runtime-specific role label; orchestration + convergence supervision + final-report review/approval |
 | Report writer worker | sonnet | report-writer-worker | `agents/workers/report-writer-worker.md` |
 | Claude worker | opus | claude-worker | `agents/workers/claude-worker.md` |
-| Codex worker | gpt-5.6-sol | codex-worker | duty + task instructions composed per invocation; deterministic `worker-dispatch` execution |
+| Codex worker | gpt-6-sol | codex-worker | duty + task instructions composed per invocation; deterministic `worker-dispatch` execution |
 | Antigravity worker | gemini-3.1-pro | antigravity-worker | duty + task instructions composed per invocation; deterministic `worker-dispatch` execution |
 
 Each analysis assignment follows its recorded `runner`. `runner=native-session` uses the host's native subagent primitive after `host-native-spec-link-gate`. `runner=cli-wrapper` follows the planned execution surface after `core-pre-dispatch` verification: `okstra team dispatch` when `terminalBackend` is `cmux-pane`, otherwise the deterministic `okstra worker-dispatch` process boundary. No LLM transport wrapper sits in front of a provider CLI.

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

@@ -405,7 +405,7 @@ For contract 3.0, `prepare` checks the selected-direction draft with the same se
    - `dissent-isolated` — only one worker `DISAGREE`s, others `AGREE`. On a blocking kind (`b` / `c` / `e`, and kind `a` on `P-Var-*`) this is scored `majority-disagree` and **blocks approval**. Advisory-only `DISAGREE(d)` and `P-Rb-*` stay recorded dissent and do not block. (Distinct from finding-convergence `worker-unique`, which means the *opposite*: only one worker AGREEs.)
    - `majority-disagree` — a *majority* of analysers `DISAGREE` (majority needs ≥2 participating non-error votes; rollback-ordering `DISAGREE(d)` votes are advisory and excluded from the tally), OR any blocking-kind dissent with ≥2 participating votes (a minority `DISAGREE` is not outvoted), OR an unresolved single-vote-blocking kind fires: one reproduced `DISAGREE(a)` on any item other than a `P-Var-*` one, or one reproduced `DISAGREE(f)` on a `P-Req-*` item (see §"Single-vote-blocking kinds"). This classification **blocks approval**. A valid critic correction is scored before these blocking rules, whether or not the analysers split evenly.
    - `needs-reverify` — one of two shapes the round could not settle.
-     - **An even split on a blocking kind.** A panel splitting evenly (1-AGREE / 1-DISAGREE, 2-2, …) needs a critic decision. An unresolved single-vote-blocking kind remains `majority-disagree`; other unresolved splits are `needs-reverify`. Do **not** re-run the original two. Dispatch `critic-worker` immediately on those items only (`okstra plan-items prepare --tie-vote`, then `okstra plan-items prompt`). The prompt carries the analyser split and no other plan items. Read the answer with `okstra plan-items collect-verdicts --items <the `--tie-vote` plan-items artifact> --result critic-worker=<path> --output <envelope>` — `--items` takes that artifact, whose `dispatchQueue` is the tie items, so pointing the next step at the raw result is refused against this round's full queue. Record the critic vote as `verdicts[].worker = critic-worker` with `okstra plan-items apply-verdicts --append --items <the `--tie-vote` plan-items artifact> --result critic-worker=<path>` — `--items` persists the exact partial `dispatchQueue` used by verdict validation and `complete-round`. Earlier verdicts and completed-round history outside that queue remain unchanged. If a previous version saved the critic votes but left the full queue in state, the ordinary `okstra plan-items complete-round --state <state> --run-manifest <manifest> --round <N>` automatically reads this run's canonical prepared queue. It uses that queue when all votes recorded for this round are included, preserving a wider recorded batch when a later prepared queue excludes its votes. An explicit `--items <prepared artifact>` remains available for selecting an artifact. Enforced by `plan_items_cli._round_inputs` and `tests/run/test_plan_items.py` completion coverage. Do not fabricate new-round votes for already agreed items. Without it the result is checked against the whole persisted round queue and refused for every item the critic was never given (measured 2026-09-10: a 7-item tie round refused against 44 items), and the only way through was `--verdicts`, which the CLI's own help calls a historical envelope. Critic `AGREE` / `SUPPLEMENT` settles the split to `has-dissent`, including an earlier `DISAGREE(a)` or `DISAGREE(f)` on `P-Req-*`. This decision corrects the disputed judgement before single-vote blocking is evaluated; it does not delete the original dissent. Critic `DISAGREE` on a blocking kind is `majority-disagree`. **Enforced:** `validators/validate-run.py` `_validate_unresolved_tie_was_reverified` fails an in-scope item that carries an even split on a blocking kind and has neither a `critic-worker` vote nor a `blocks: approval` clarification row, `_classify_plan_item_gate` scores the tie shape and fails a settled classification the votes do not support, and `okstra_ctl.plan_items.next_dispatch` returns kind `critic-tie` for exactly these items, so the tie round is the queue the CLI hands you rather than one you assemble. **With no critic on the roster the split is a user decision, not another round.** `okstra plan-items next-dispatch --run-manifest <current-run-manifest.json>` answers `user-decision` (not `critic-tie`) when the run's `invocationAssignments` carries no `critic/*` entry, and its `itemIds` are the tie items. For each of them do what step 8 does for a surviving `majority-disagree`: `okstra approval-decision open` with `approvalContext.classification` set to `correctness-critical` when `_is_correctness_critical` is true, or `noncritical-dissent` otherwise, plus the matching `## 1. Clarification Items` row at `Blocks=approval`. Dispatch no further verification for those items. The `Blocks=approval` row is what withholds approval until the user disposes, exactly as for any other approval row; the gate retains unresolved single-vote blockers as `majority-disagree` and folds other `needs-reverify` items into `passed-with-dissent`, so the round closes on the gate it actually scored. A tie left with neither a critic vote nor a decision row surfaces as recorded dissent plus an `advisories[]` entry, not a round-blocking failure. **Enforced:** `okstra_ctl.plan_items.critic_is_rostered` reads the roster and `next_dispatch` returns the kind; `validators/validate-run.py` `_validate_unresolved_tie_was_reverified` reads a `blocks: approval` row linked to the item as the settlement and emits its advisory only when neither settlement is recorded.
+     - **An even split on a blocking kind.** A panel splitting evenly (1-AGREE / 1-DISAGREE, 2-2, …) needs a critic decision. An unresolved single-vote-blocking kind remains `majority-disagree`; other unresolved splits are `needs-reverify`. Do **not** re-run the original two. Dispatch `critic-worker` immediately on those items only (`okstra plan-items prepare --tie-vote ...`, then `okstra plan-items prompt ...`). The prompt carries the analyser split and no other plan items. Read the answer with `okstra plan-items collect-verdicts --items <the --tie-vote plan-items artifact> --result critic-worker=<path> --output <envelope>` — `--items` takes that artifact, whose `dispatchQueue` is the tie items, so pointing the next step at the raw result is refused against this round's full queue. Record the critic vote as `verdicts[].worker = critic-worker` with `okstra plan-items apply-verdicts --state <plan-body-verification.json> --round <N> --append --items <the --tie-vote plan-items artifact> --result critic-worker=<path>` — `--items` persists the exact partial `dispatchQueue` used by verdict validation and `complete-round`. Earlier verdicts and completed-round history outside that queue remain unchanged. If a previous version saved the critic votes but left the full queue in state, the ordinary `okstra plan-items complete-round --state <state> --run-manifest <manifest> --round <N>` automatically reads this run's canonical prepared queue. It uses that queue when all votes recorded for this round are included, preserving a wider recorded batch when a later prepared queue excludes its votes. An explicit `--items <prepared artifact>` remains available for selecting an artifact. Enforced by `plan_items_cli._round_inputs` and `tests/run/test_plan_items.py` completion coverage. Do not fabricate new-round votes for already agreed items. Without it the result is checked against the whole persisted round queue and refused for every item the critic was never given (measured 2026-09-10: a 7-item tie round refused against 44 items), and the only way through was `--verdicts`, which the CLI's own help calls a historical envelope. Critic `AGREE` / `SUPPLEMENT` settles the split to `has-dissent`, including an earlier `DISAGREE(a)` or `DISAGREE(f)` on `P-Req-*`. This decision corrects the disputed judgement before single-vote blocking is evaluated; it does not delete the original dissent. Critic `DISAGREE` on a blocking kind is `majority-disagree`. **Enforced:** `validators/validate-run.py` `_validate_unresolved_tie_was_reverified` fails an in-scope item that carries an even split on a blocking kind and has neither a `critic-worker` vote nor a `blocks: approval` clarification row, `_classify_plan_item_gate` scores the tie shape and fails a settled classification the votes do not support, and `okstra_ctl.plan_items.next_dispatch` returns kind `critic-tie` for exactly these items, so the tie round is the queue the CLI hands you rather than one you assemble. **With no critic on the roster the split is a user decision, not another round.** `okstra plan-items next-dispatch --state <plan-body-verification.json> --run-manifest <current-run-manifest.json>` answers `user-decision` (not `critic-tie`) when the run's `invocationAssignments` carries no `critic/*` entry, and its `itemIds` are the tie items. For each of them do what step 8 does for a surviving `majority-disagree`: `okstra approval-decision open` with `approvalContext.classification` set to `correctness-critical` when `_is_correctness_critical` is true, or `noncritical-dissent` otherwise, plus the matching `## 1. Clarification Items` row at `Blocks=approval`. Dispatch no further verification for those items. The `Blocks=approval` row is what withholds approval until the user disposes, exactly as for any other approval row; the gate retains unresolved single-vote blockers as `majority-disagree` and folds other `needs-reverify` items into `passed-with-dissent`, so the round closes on the gate it actually scored. A tie left with neither a critic vote nor a decision row surfaces as recorded dissent plus an `advisories[]` entry, not a round-blocking failure. **Enforced:** `okstra_ctl.plan_items.critic_is_rostered` reads the roster and `next_dispatch` returns the kind; `validators/validate-run.py` `_validate_unresolved_tie_was_reverified` reads a `blocks: approval` row linked to the item as the settlement and emits its advisory only when neither settlement is recorded.
      - **A lone dissent nobody cross-verified** — a single-vote-blocking kind fired but the item has **fewer than 2 participating non-error votes**, i.e. the lone dissent was never cross-verified because its peer returned `verification-error`. A single-vote-blocking kind means "one *confirmed* DISAGREE is enough"; an unconfirmed one is not, and on a `P-Var-*` item none fires at all — its kind `a` never blocks on one vote and takes a majority like `b` / `e`. This does **not** block approval — blocking on it would make a worker failure produce a stricter gate than a healthy roster, the same paradox the ≥2-vote majority rule already rules out. The item is re-dispatched in the next round (step 7); if it survives the round budget it is promoted per step 8 with a Statement that says verification never completed. **Enforced:** `validators/validate-run.py` `_classify_plan_item_gate` returns `needs-reverify` for this shape and `_recompute_plan_body_gate` folds it into `passed-with-dissent`.
    - `contested` only meaningful when `maxRounds > 1`; at default `maxRounds=1`, fold any unresolved item into `partial-consensus`.
 5. Gate result resolution:
@@ -429,7 +429,7 @@ For contract 3.0, `prepare` checks the selected-direction draft with the same se
    **Record the cause, not just the outcome.** The gate value names the outcome; `planBodyVerification.gateBlockedBy` (array) names every input that blocked it — `majority-disagree`, `coverage-gap`, `non-result`. Two independent inputs can block: a `majority-disagree` plan item, and a Requirement Coverage `gap` / `blocked C-NNN` row (`prompts/profiles/implementation-planning.md` §"Requirement Coverage"). A coverage-only block still renders as `blocked-by-disagreement` because that is the only blocking non-abort value, so **without `gateBlockedBy` the report asserts a worker disagreement that never happened** and the reader hunts for a dissent that does not exist. Leave the array empty for a passing gate. **Enforced:** `validators/validate-run.py` `_validate_gate_blocked_by` fails a passing gate that has a blocking coverage row — the coverage rule was prose-only before. The declared array itself is not compared against a recomputed one: `okstra plan-verify` returns `gate.blockedBy` from the same computation that produced the gate value, so recording what it returns is what makes the array right.
 
    **A coverage row citing this run's own `C-NNN` is not an independent blocker.** When a coverage row's `blocked C-NNN` points at a clarification that step 8 below promoted from a `majority-disagree` item in *this same run*, that blocker is already counted once as the plan item. Counting it again as a coverage gap makes the run block on a clarification it just authored, and the row carries into the next run as a fresh blocker — the Requirement Coverage ↔ Clarification cycle. Such rows are excluded from `coverage-gap`. **Enforced:** `validators/validate-run.py` `_independent_coverage_blockers`.
-6. `okstra plan-items complete-round --run-manifest <current-run-manifest.json>` derives `planBodyVerification.participatingAnalysers` from the current assigned roster and persisted votes, then atomically records the completed round. The gate arithmetic is unchanged, but a shrunken roster changes what the round can settle: with two participating analysers a 1-AGREE / 1-DISAGREE split is a tie, so it reaches neither consensus nor `majority-disagree` and the item has to go back for a round (see `needs-reverify` above). **Enforced:** `validators/validate-run.py` `_validate_participating_analysers` recomputes `voting` from the recorded verdicts and fails a declared figure the table denies. `validators/validate-run.py` `_detect_uniform_verifier` remains advisory; do not copy its JSON output into state.
+6. `okstra plan-items complete-round --state <plan-body-verification.json> --run-manifest <current-run-manifest.json> --round <N>` derives `planBodyVerification.participatingAnalysers` from the current assigned roster and persisted votes, then atomically records the completed round. The gate arithmetic is unchanged, but a shrunken roster changes what the round can settle: with two participating analysers a 1-AGREE / 1-DISAGREE split is a tie, so it reaches neither consensus nor `majority-disagree` and the item has to go back for a round (see `needs-reverify` above). **Enforced:** `validators/validate-run.py` `_validate_participating_analysers` recomputes `voting` from the recorded verdicts and fails a declared figure the table denies. `validators/validate-run.py` `_detect_uniform_verifier` remains advisory; do not copy its JSON output into state.
 
    **Check each verifier's verdict distribution before the next round.** After `apply-verdicts` and before opening another worker batch, run `okstra plan-items next-dispatch --state <plan-body-verification.json> --run-manifest <current-run-manifest.json>`. Python owns that decision. Do not invent a full-roster round from a `needs-reverify` label, from every-item `UNVERIFIABLE`, or from `okstra plan-verify` warnings. `_detect_uniform_verifier` remains advisory; do not copy its JSON output into state.
 
@@ -446,7 +446,7 @@ For contract 3.0, `prepare` checks the selected-direction draft with the same se
 
    The environment exception in §"Planning-time environment gap" covers **running build and test commands only** — whether a referenced path exists, whether a command is declared in `package.json`, and whether the plan is internally consistent are all checkable without it, and a blanket "capability constraints prevent workspace resolution" is not a valid answer to any of them.
 
-   **How the corrective round is recorded.** The first prompt was dispatched, so it is immutable — `--replace-undispatched` refuses it, correctly. Materialize the correction under a NEW `--invocation-id` and a new prompt path. Before linking its result, retire the first attempt's link: `okstra agent-prompt reject-result --run-manifest <path> --dispatch-id <first dispatch id> --superseded-by <corrective dispatch id> --reason "<what was wrong with the returned result>"`. Without that step the corrective `link-result` fails with `agent result is already linked to another dispatch`, which is how a worker that ran for twenty minutes and wrote a good result ends up unrecordable. Nothing is deleted: the rejected link stays in `agentResultLinks` carrying `supersededBy` and `rejectionReason`, so the ledger shows both attempts and why the second exists.
+   **How the corrective round is recorded.** The first prompt was dispatched, so it is immutable — `--replace-undispatched` refuses it, correctly. Materialize the correction under a NEW `--invocation-id` and a new prompt path. Before linking its result, retire the first attempt's link: `okstra agent-prompt reject-result --project-root <dir> --run-manifest <path> --dispatch-id <first dispatch id> --superseded-by <corrective dispatch id> --reason "<what was wrong with the returned result>"`. Without that step the corrective `link-result` fails with `agent result is already linked to another dispatch`, which is how a worker that ran for twenty minutes and wrote a good result ends up unrecordable. Nothing is deleted: the rejected link stays in `agentResultLinks` carrying `supersededBy` and `rejectionReason`, so the ledger shows both attempts and why the second exists.
 
    Then run `okstra plan-items complete-round --state <plan-body-verification.json> --run-manifest <current-run-manifest.json> --round <N>`. Python appends one immutable round history entry, records each verified item's votes, derives the current projection from the actual assigned roster, and stamps `completedAt` after the preceding verification command succeeds. The file accumulates across rounds; it is never truncated to the latest one. Report assembly later projects the completed nested `planBodyVerification` into the final record.
 7. **Self-fix loop (one rewrite, targeting planner-fixable defects).** After the initial verification, lead may run one report-writer rewrite when a `majority-disagree` item has a majority of `DISAGREE` verdicts at `fixability == planner-fixable`. Re-verify changed items once, preserving verdicts on unchanged content. Then stop automatic self-fix regardless of outcome and follow step 8. The fixed order is initial verification → one planner self-fix → targeted re-verification → lead decision or immediate user confirmation. A second automatic self-fix is rejected by `plan_items_cli._record_self_fixes`; `_validate_self_fix_grouping` and session activity validation detect multiple recorded rewrites. No rewrite is needed when no item qualifies.
@@ -464,7 +464,7 @@ For contract 3.0, `prepare` checks the selected-direction draft with the same se
      - `all-resolved` — no planner-fixable `majority-disagree` item remains. Exit.
      - `no-progress` — the round resolved **zero** planner-fixable items relative to the previous round. Exit even with budget left: the same rewrite would repeat. Newly *introduced* defects count against progress, so a rewrite that trades one defect for another stops the loop rather than churning. A round that re-targets only what the previous round left unresolved is this same conclusion reached one dispatch earlier — exit on it under this reason rather than paying for the round that proves it. **Enforced (advisory):** `validators/validate-run.py` `_detect_self_fix_recurrence` warns on that shape and names this stop reason.
      - `max-rounds-reached` — the single automatic rewrite has been used. Exit to step 8. Count distinct `selfFixGroups[].round` values; `selfFixRoundsApplied` is the last verification round number, not the rewrite count. Extra verification batches before the rewrite do not increase the self-fix budget.
-     - `cause-group-recurrence` — legacy read-only value for reports produced before activity contract v1. A new activity-contract-v1 run cannot emit it because there is no second automatic self-fix round in which a cause group can recur. **Enforced at the only writer:** `okstra plan-items complete-round --self-fix-stop-reason` accepts `all-resolved` / `no-progress` / `max-rounds-reached` and nothing else (`scripts/okstra_ctl/plan_items_cli.py:261`), and it is what sets `selfFixStopReason`, so the value has no way into a new report. A legacy report that already carries it is still an *exhausted* loop, so step 8 may promote its surviving items: `_SELF_FIX_EXHAUSTED_REASONS` admits this value alongside `no-progress` / `max-rounds-reached`. Refusing it there left such a report with no exit at all — the loop may not run again, and the item may not be promoted either.
+     - `cause-group-recurrence` — legacy read-only value for reports produced before activity contract v1. A new activity-contract-v1 run cannot emit it because there is no second automatic self-fix round in which a cause group can recur. **Enforced at the only writer:** `okstra plan-items complete-round ... --self-fix-stop-reason` accepts `all-resolved` / `no-progress` / `max-rounds-reached` and nothing else (`scripts/okstra_ctl/plan_items_cli.py:261`), and it is what sets `selfFixStopReason`, so the value has no way into a new report. A legacy report that already carries it is still an *exhausted* loop, so step 8 may promote its surviving items: `_SELF_FIX_EXHAUSTED_REASONS` admits this value alongside `no-progress` / `max-rounds-reached`. Refusing it there left such a report with no exit at all — the loop may not run again, and the item may not be promoted either.
      - `not-attempted` — the loop never ran because no item qualified.
      The `no-progress` and `max-rounds-reached` exits are what make the loop terminate; `selfFixMaxRounds` alone is the backstop.
    - a `majority-disagree` item with a majority of its deciding `DISAGREE` votes at `needs-user-input` is NOT a self-fix target — after correctness-critical precedence, it goes straight to the next step as `user-decision` rather than generic `noncritical-dissent`. **Enforced (promotion path):** `validators/validate-run.py` `_validate_self_fix_before_clarification` demands an exhausted self-fix budget only of `planner-fixable` majorities, so a `needs-user-input` majority is promotable with no self-fix round, and `_validate_plan_body_clarification_matching` fails it when it reaches no `blocks: approval` row. The classification *value* is authoring guidance per step 8: `scripts/okstra_ctl/approval_decisions.py` checks it against the classification enum and its allowed dispositions only — no validator recomputes it from the votes' `fixability`.
@@ -673,7 +673,7 @@ posture in §"Adversarial plan-body posture" still applies, and this round does
 not revisit the requirements themselves.
 
 Omitting either line fails `okstra team dispatch --dispatch-kind
-plan-verify-r<N>` before any process starts, reported as `<task-type>
+plan-verify-r<N> ...` before any process starts, reported as `<task-type>
 prompt contract: <worker>: exactly one Primary analysis packet path is required
 (found 0)`. Fix the instructions file and re-materialize with
 `--replace-undispatched` rather than editing the published prompt.
@@ -852,7 +852,7 @@ What the generated round 2+ prompt has that round 1 does not:
 
 An item with no recorded vote carrying a round number gets no block, and an envelope with nothing to carry keeps the round-1 shape — `priorRounds` is absent and no preamble is prepended, so a first round is unaffected by this section.
 
-**Enforced:** `okstra plan-items validate-prepared --state <same state>` re-derives the carry and exits 2 when the prepared envelope's `priorRounds` does not match, alongside the `items` / `dispatchQueue` comparison it already made. A prepared queue that dropped the dissent cannot pass the step-1 validation the dispatch is gated on.
+**Enforced:** `okstra plan-items validate-prepared ... --state <same state>` re-derives the carry and exits 2 when the prepared envelope's `priorRounds` does not match, alongside the `items` / `dispatchQueue` comparison it already made. A prepared queue that dropped the dissent cannot pass the step-1 validation the dispatch is gated on.
 
 The two spellings are different anchors for different artifacts: `**Prior round dissent**` is the block `prompt` puts in the prompt, `**Prior dissent**` is the line the worker puts in its result. `scripts/okstra_ctl/verdict_blocks.py` parses the result line into the verdict block when it is present and leaves it empty when it is not, so an omitted answer line is still silent — the prompt is what is now guaranteed, not the response.