okstra 0.186.7 → 0.187.0

package/runtime/prompts/lead/convergence.md

@@ -24,13 +24,15 @@
 
 This contract governs **Phase 5.5 (Convergence loop)** — a *lead operating phase* inside a single okstra run, not a task-type lifecycle phase. It leaves the 7 task-type lifecycle phases (`requirements-discovery` → `error-analysis` → `implementation-option-selection` → `implementation-planning` → `implementation` → `final-verification` → `release-handoff`, see [okstra-lead-contract](./okstra-lead-contract.md) "Lifecycle Phase Boundaries") unchanged; the lead operating phases (Phase 1 Intake → Phase 7 Persist, see [okstra-lead-contract](./okstra-lead-contract.md) "Quick Reference") drive a *single* task-type run.
 
-**`contested` is a final classification only.** It is NEVER an intermediate queue label. The verification queue carries findings that are *unique to a single worker* (entered in Round 0) or *mixed/unresolved after a re-verification round* (carried forward). The `contested` label is assigned only when the **last executed round** completes and the queue is still non-empty.
+**`contested` is a terminal classification, never an intermediate queue label.** The verification queue carries findings that are *unique to a single worker* (entered in Round 0) or *mixed/unresolved after a re-verification round* (carried forward). A finding is labelled `contested` in two places, both of which remove it from the queue: at the round where an adversarial `counter-evidence` refute lands (§"Adversarial Verification Mode"), and when the **last executed round** completes with the queue still non-empty. A `contested` finding is never re-dispatched.
 
 When this contract says "queue" without qualifier, it means the *verification queue*: the set of findings that are still candidates for re-verification in subsequent rounds. The queue shrinks monotonically as findings get classified as `full-consensus`, `partial-consensus`, or `worker-unique`. Findings classified into any of these three categories MUST NOT appear in any subsequent round's reverify prompt, for any worker.
 
+**Enforced:** `_validate_resolved_findings_leave_the_queue` in `validators/validate-run.py` fails a resolved finding whose `rounds[]` ledger is not a contiguous `1..N` — a gap is the finding re-entering the queue after classification.
+
 An initial pane role `verifier` is still a Phase 4/5 analysis worker; it does not mean Phase 5.5 reverify. Only a queue-scoped dispatch whose prompt/result path carries `-reverify-r<N>-` performs the reverify step described by this contract.
 
-The end-to-end artifact lifecycle is worker results → Round 0 grouping → reducer-owned queue → analyser-instance re-verification → optional `okstra convergence apply-critic-gaps` transition → validated terminal state (newly finalized v1.3, or unchanged historical v1.0–v1.2 from `reuse-final`) → report-writer narrative → deterministic report assembly. Cross-verification is queue-scoped: it does not mean that one worker reviews another worker's complete result. The reducer asks independent analyser instances to vote only on non-consensus findings selected by the persisted plan; the report writer never votes.
+The end-to-end artifact lifecycle is worker results → Round 0 grouping → reducer-owned queue → analyser-instance re-verification → optional `okstra convergence apply-critic-gaps` transition → validated terminal state (newly finalized v1.4, or unchanged historical v1.0–v1.3 from `reuse-final`) → report-writer narrative → deterministic report assembly. Cross-verification is queue-scoped: it does not mean that one worker reviews another worker's complete result. The reducer asks independent analyser instances to vote only on non-consensus findings selected by the persisted plan; the report writer never votes.
 
 Initial and reverify worker prompts carry `**Audit sidecar path:**`. Initial workers write their reading confirmation there; reverify workers use their own canonical sidecar for the reverify session without reopening the initial worker's full reading packet.
 
@@ -58,12 +60,15 @@ Configure this in the `convergence` block of `task-manifest.json`. If the block
 |------|------|------------|
 | `full-consensus` | All participating workers agree | Required |
 | `partial-consensus` | Majority of workers agree; dissenting opinions are recorded | Required |
-| `contested` | Final classification only. Assigned to a finding that remains in the verification queue after the **last executed round** completes (round index = `effectiveMaxRounds`). Each worker's position across all executed rounds is recorded. NEVER used as an intermediate label. | Required |
+| `contested` | Terminal classification. Assigned to a finding that remains in the verification queue after the **last executed round** completes (round index = `effectiveMaxRounds`), and — in adversarial mode only — to a finding refuted with `counter-evidence` at the round that refute lands. Each worker's position across all executed rounds is recorded. Either way the finding leaves the queue and is never re-dispatched. | Required |
+| `unverified` | Final classification only. Assigned to a finding that reached the last executed round with **every recorded vote** `verification-error` — a terminal non-result dispatch, or no analyser available to vote. Nobody inspected it, so `contested` would state a dispute that never happened. The gap ledger already applies the same rule (§'Gap verification'). | Required |
 | `worker-unique` | Only the discoverer confirms and ALL other non-error votes are `DISAGREE`. `verification-error` votes are excluded from the tally per §"Worker failure handling in reverify"; a finding where every non-discoverer vote is `verification-error` is carried forward, never classified `worker-unique`. | Required |
 
 ## Convergence Algorithm
 
-**Majority definition (BLOCKING).** "Majority" means *strictly greater than half* of the non-error votes for that finding (`verification-error` votes are excluded from both numerator and denominator). Ties — including the 1-AGREE / 1-DISAGREE case in a two-analyser roster — are NOT a majority: in intermediate rounds the finding is **carried forward**; in the final executed round the finding is classified `contested`. This rule applies identically to the plan-body verification round ([plan-body-verification](./plan-body-verification.md)) where the same verdict tokens are reused.
+**Majority definition (BLOCKING).** "Majority" means *strictly greater than half* of the non-error votes for that finding (`verification-error` votes are excluded from both numerator and denominator). Ties — including the 1-AGREE / 1-DISAGREE case in a two-analyser roster — are NOT a majority: in intermediate rounds the finding is **carried forward**; in the final executed round the finding is classified `contested`. In adversarial mode a tie whose DISAGREE carries `counter-evidence` does not carry forward — it is classified `contested` in that round (§"Adversarial Verification Mode"). This rule applies identically to the plan-body verification round ([plan-body-verification](./plan-body-verification.md)) where the same verdict tokens are reused.
+
+**Enforced:** the engine owns the classifier and replays it — `scripts/okstra_ctl/convergence_engine.py` `validate_final_state` recomputes each finding's expected final classification from its recorded votes and rejects the state when the persisted value differs, and `finalize` runs that same check before it writes, so a tie scored as a consensus never reaches the artifact. `okstra convergence validate` is the same call on demand. Nothing re-derives the majority rule outside the engine; a second implementation would only drift from it.
 
 ### Round 0: Parse worker results
 
@@ -87,10 +92,7 @@ Read the worker result files generated in Phase 4/5 and extract individual findi
 5. Author the fixed grouping Markdown accepted by `okstra convergence prepare-groups --run-manifest <run-manifest> --input <grouping.md>`, then run that command. Python owns the artifact identifier, target path, schema version, task identity, run-manifest reference, and every participant reference. Each Markdown group records ticket IDs, origin worker and evidence, discovering workers, source worker item IDs, and optional captured evidence. An analysis sidetrack with no ticket uses an empty `Tickets:` value, never a placeholder. Use the ordered functional roster: finding workers have the `analysis` audience, the report author has `report-writer`, and the lead uses `lead`. A lead source never votes. Never infer live evidence or functional scope from wording, provider, model, or execution label.
 
    The command sets each worker's paired `participantRef` and `sourceRoleExecutionRef` from the run manifest's canonical role state. It sets `sourceRoleExecutionRef` to the selected source `RoleExecution` row's `roleExecutionRef`, not that row's `sourceRoleExecutionRef` field.
-6. Do not write a queue or classification in this grouped-input artifact. `okstra convergence seed` classifies Round 0 by mode:
-   - Collaborative mode: multi-source groups become `full-consensus` immediately; only single-source groups enter the working queue.
-   - Adversarial mode: every finding enters the working queue regardless of source count. Semantic grouping merges provenance only; it does not decide a finding is reliable.
-   Section 6 never enters the grouped input.
+6. Do not write a queue or classification in this grouped-input artifact. `okstra convergence seed` classifies Round 0 the same way in both modes: a group whose sources are **two or more distinct role executions** becomes `full-consensus` immediately, and only single-source groups enter the working queue. Independent co-derivation is already cross-verification — the adversarial burden of proof targets single-source claims, not a finding two roles reached on their own. A source is counted once per analysis worker, and one analysis worker is exactly one `sourceRoleExecutionRef` — the same identity the reverify roster uses for independence — so two roles held by one provider count as two and no role can count twice. **Enforced:** `_parse_workers` rejects a duplicate `workerId` and `_validate_worker_execution_identity` rejects a duplicate `sourceRoleExecutionRef`, both in `scripts/okstra_ctl/convergence_engine.py`. Semantic grouping merges provenance only; it does not decide a single-source finding is reliable. Section 6 never enters the grouped input.
 
 ### Round 1-N: Re-verification Loop (queue-pruned)
 
@@ -111,12 +113,12 @@ 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.
 2. Run `okstra convergence plan-round --work-state <work> --plan <round-plan>`. This is read-only with respect to the working state.
-3. 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`.
+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>`.
-5. Repeat `plan-round` and `apply-round` until the plan action is `finalize`.
+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>`.
-8. Run `okstra convergence validate --state <final> --kind final`. Newly finalized convergence output is schema v1.3. Under `reuse-final`, a valid historical final schema v1.0, v1.1, or v1.2 remains consumable by the report-writer without rewrite; do not finalize, upgrade, or otherwise rewrite that reused artifact. Deliver the validated terminal state to the report-writer, which does not vote.
+8. Run `okstra convergence validate --state <final> --kind final`. Newly finalized convergence output is schema v1.4. Under `reuse-final`, a valid historical final schema v1.0, v1.1, v1.2, or v1.3 remains consumable by the report-writer without rewrite; do not finalize, upgrade, or otherwise rewrite that reused artifact. Deliver the validated terminal state to the report-writer, which does not vote.
 
 The planner preserves roster and queue order, excludes that finding's origin worker, emits at most one batch per analysis worker per round, and ensures the report-writer never appears in `dispatches` or `skippedWorkers`. Queue pruning is monotonic: a finding absent from the current queue cannot reappear in a later plan.
 
@@ -130,10 +132,14 @@ A valid historical final schema v1.0, v1.1, or v1.2 is reused unchanged under `r
 
 `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.
 
+A gate-closed plan states its own terminality in `dispatchable: false` and `note`; read those, not `round`. With `effectiveMaxRounds: 2` the closing plan reads `{"action": "finalize", "round": 3, "dispatchable": false, "reason": "max-rounds-reached"}` — `round: 3` names the artifact, and there is no round 3 to dispatch.
+
 #### Worker failure handling in reverify (BLOCKING)
 
 A reverify dispatch that returns a **terminal non-result** (`timeout`, `error`, no result file, or the wrapper records `cli-failure`) MUST NOT be aggregated as `DISAGREE`. Misclassifying a worker failure as DISAGREE biases the queue toward `contested`/`worker-unique` and produces meaningless final classifications.
 
+**Enforced:** `_validate_worker_failure_is_not_a_disagree` in `validators/validate-run.py` matches each round's `dispatches[].status` against that round's `votes` and fails a `disagree` recorded for a worker whose dispatch status is `timeout` / `error` / `not-run`.
+
 Rules:
 
 1. For each failed dispatch, put its actual terminal status and duration in the round-results `dispatches[]`; do not invent a vote. `okstra convergence apply-round` appends `votes[W].verdict = "verification-error"` with the terminal reason for every affected finding. A completed dispatch may separately return `UNVERIFIABLE` for a particular finding; the input alias is persisted as `verification-error` with its required non-empty explanation while the dispatch remains `completed`.
@@ -174,7 +180,7 @@ If every required analysis worker produces a non-result, the run verdict is `blo
 
 ### Scoped full-reanalysis
 
-Adversarial mode forces `verificationMode = "full-reanalysis"`, but the re-analysis is **scoped to the evidence the finding under attack cites** (the file paths / line ranges / log lines in its `originEvidence`), plus the immediately surrounding context. The verifier MUST NOT re-read the whole task brief, instruction-set, or `final-report-template.md`. This keeps the documented "single largest avoidable cost in requirements-discovery, error-analysis, and implementation-planning" (see §"Reverify prompt: required-reading suppression") bounded while making the refutation real rather than a text-only argument.
+Adversarial mode forces `verificationMode = "full-reanalysis"`, but the re-analysis is **scoped to the evidence the finding under attack cites** (the file paths / line ranges / log lines in its `originEvidence`), plus the immediately surrounding context. The verifier MUST NOT re-read the whole task brief, instruction-set, or `final-report-template.md`. **Enforced (template clause only):** `_validate_full_reanalysis_prompt_omits_the_report_template` in `validators/validate-run.py` fails a reverify prompt that references `final-report-template.md`; the brief and instruction-set clauses have no fixed literal to match on. This keeps the documented "single largest avoidable cost in requirements-discovery, error-analysis, and implementation-planning" (see §"Reverify prompt: required-reading suppression") bounded while making the refutation real rather than a text-only argument.
 
 ### Adversarial verdict semantics
 
@@ -194,7 +200,7 @@ Each `disagree` vote records a new field `disagreeBasis`:
 | `counter-evidence` | The verifier opened and inspected the cited evidence and found a contradiction (`file:line` / log line) recorded in `explanation`. A **hard refute**. |
 | `burden-not-met` | The verifier opened and inspected the cited evidence, but its contents were insufficient to establish the claim. |
 
-A `disagree` with `disagreeBasis == null` is a contract violation in adversarial mode — every refutation must state which of the two grounds it rests on. Bare "I disagree" without re-inspection is not allowed. If capability, credential, network, or service state prevents that inspection, the verdict is `UNVERIFIABLE`, persisted as `verification-error`; verifier failure is never converted to `DISAGREE` or `burden-not-met`. A live/external claim without `evidenceArtifacts` remains schema-valid, but a verifier that needs the missing artifact and cannot independently access the source MUST answer `UNVERIFIABLE` with a non-empty explanation.
+A `disagree` with `disagreeBasis == null` is a contract violation in adversarial mode — every refutation must state which of the two grounds it rests on. **Enforced:** `_validate_adversarial_disagree_carries_a_basis` in `validators/validate-run.py` fails such a vote when `config.adversarial` is set; non-adversarial rounds are out of scope because their verdict semantics differ. Bare "I disagree" without re-inspection is not allowed. If capability, credential, network, or service state prevents that inspection, the verdict is `UNVERIFIABLE`, persisted as `verification-error`; verifier failure is never converted to `DISAGREE` or `burden-not-met`. A live/external claim without `evidenceArtifacts` remains schema-valid, but a verifier that needs the missing artifact and cannot independently access the source MUST answer `UNVERIFIABLE` with a non-empty explanation.
 
 ### Adversarial classification (replaces the §"Convergence Algorithm" per-round classifier when `adversarial == true`)
 
@@ -212,7 +218,7 @@ ELIF all_others_disagree:
     resolve F as "worker-unique"    # only the discoverer still holds it
 ELIF len(hard_refutes) >= 1:
     # an evidence-backed refute exists and the roster is split → the claim is disputed
-    carry F forward; at the LAST executed round classify it "contested"
+    resolve F as "contested" IN THIS ROUND; F leaves the queue
 ELIF burden-not-met disagrees are a majority of non-error votes (per the Majority definition in the Convergence Algorithm section):
     carry F forward; at the LAST executed round classify it "contested"
 ELSE:
@@ -220,12 +226,14 @@ ELSE:
     resolve F as "partial-consensus"
 ```
 
-`contested` remains a **final classification only** (per §"Scope and Terminology"): a disputed finding is carried forward through intermediate rounds and labelled `contested` only at the last executed round. For `requirements-discovery` (`effectiveMaxRounds = 1`) the single round IS the last round, so a split-with-hard-refute finding is labelled `contested` in that one round. The final-classifier block of §"Convergence Algorithm" honours this: its first branch classifies an adversarially carried-forward finding `contested` regardless of the AGREE tally, so the two sections cannot assign the same finding different labels.
+`contested` stays terminal (per §"Scope and Terminology") and is reached by two routes. A finding split on `burden-not-met` doubt alone is carried forward through intermediate rounds and labelled `contested` at the last executed round; a finding carrying a `counter-evidence` hard refute is labelled `contested` in the round that refute lands and leaves the queue there. For `requirements-discovery` (`effectiveMaxRounds = 1`) the two routes coincide — the single round IS the last round. The final-classifier block of §"Convergence Algorithm" honours this: its first branch classifies an adversarially carried-forward finding `contested` regardless of the AGREE tally, so the two sections cannot assign the same finding different labels.
 
-Design intent: one `counter-evidence` refute denies a claim consensus (it cannot rise above `contested` however many others AGREE); later-round agreement does not erase that refutation history. The only resolution that overrides prior `counter-evidence` is a later round where every non-discoverer non-error worker disagrees, producing `worker-unique`. A lone `burden-not-met` doubt does not sink an otherwise-surviving claim — only a majority of them does. When every non-discoverer refutes (all_others_disagree) the finding is worker-unique regardless of refute basis — only the discoverer still holds it. A caveat is weighed the same way a weak doubt is: with zero disagrees, SUPPLEMENT lands partial-consensus only when caveats are a **majority** of the non-error votes. A single verifier's scope note does not by itself deny a claim the rest of the roster passed cleanly — the caveat is still recorded in the dissent log either way, so the majority rule changes the label, never the record. (The collaborative classifier is more permissive still: there SUPPLEMENT counts as full agreement at any count.)
+Design intent: one `counter-evidence` refute denies a claim consensus (it cannot rise above `contested` however many others AGREE). Because that refute is permanent, re-dispatching the finding buys nothing — the verifier gets no new information and re-casts the same refute, so the round is spent by construction. The refute therefore settles the finding where it lands, and the finding is reported under `## 6.2 Differences` exactly as a last-round `contested` finding is. A lone `burden-not-met` doubt does not sink an otherwise-surviving claim — only a majority of them does; that doubt IS resolvable by another round, so it still carries forward. When every non-discoverer refutes (all_others_disagree) the finding is worker-unique regardless of refute basis — only the discoverer still holds it. A caveat is weighed the same way a weak doubt is: with zero disagrees, SUPPLEMENT lands partial-consensus only when caveats are a **majority** of the non-error votes. A single verifier's scope note does not by itself deny a claim the rest of the roster passed cleanly — the caveat is still recorded in the dissent log either way, so the majority rule changes the label, never the record. (The collaborative classifier is more permissive still: there SUPPLEMENT counts as full agreement at any count.)
 
 ## Re-verification Dispatch
 
+Every finding re-verification, coverage critic, acceptance critic, and critic-verification instruction passes [okstra-lead-contract](./okstra-lead-contract.md) "Worker instruction quality gate" before materialization. The lead resolves exact finding IDs, evidence paths, requested verdict fields, allowed verdict literals, and completion conditions from the current convergence state and cited results; a worker is not asked to infer them from a round summary.
+
 ### Invocation materialization gate (BLOCKING)
 
 For every finding reverify row and critic-gap verification row, first write a
@@ -273,7 +281,7 @@ call specification; it does not prove which bytes the host primitive delivered.
 
 ### Sponsorship Optimization
 
-For each persisted round plan, build exactly one prompt per `dispatches[]` row and call `redispatch_worker(assignment, prompt, reason)` once through the selected runtime adapter. The prompt contains exactly that row's `findingIds` in plan order and MUST NOT add, remove, or reorder findings. This excludes Section 6, every resolved finding, and every finding owned by the receiving origin worker because none can appear in the engine row. The assignment, model, prompt path, Result Path, worker-results path, errors paths, and `dispatchKind` come from the current run artifacts. Every reverify is a fresh one-shot session.
+For each persisted round plan, build exactly one prompt per `dispatches[]` row and call `redispatch_worker(assignment, prompt, reason)` once through the selected runtime adapter. The prompt contains exactly that row's `findingIds` in plan order and MUST NOT add, remove, or reorder findings. **Enforced (membership only):** `_validate_reverify_prompt_matches_plan` in `validators/validate-run.py` replays `plan == prompt` as a set — it fails an added or dropped finding. Order is not machine-checked; the engine row is the order of record. This excludes Section 6, every resolved finding, and every finding owned by the receiving origin worker because none can appear in the engine row. **Ownership is compared by `sourceRoleExecutionRef`, not by `participantRef`** — a worker sharing the origin's provider and model in a *different* role is a different role contract, a different duty and a different session, so it stays in the panel (ADR-0017; the same doctrine §"Critic gaps" states for critics). **Enforced:** `_worker_is_independent_from_finding` in `scripts/okstra_ctl/convergence_engine.py`. The assignment, model, prompt path, Result Path, worker-results path, errors paths, and `dispatchKind` come from the current run artifacts. Every reverify is a fresh one-shot session.
 
 The persisted round plan is the audit record for batch membership. The lead and adapter do not branch on task type, provider, model identity, classification labels, or their own view of the queue. They dispatch only the engine-returned row through the selected runtime adapter.
 
@@ -304,7 +312,7 @@ The two error-path anchors carry the same absolute values the lead forwarded in
 
 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:**`.
 
-**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 it appends (`**Provider:**`, `**Model:**`, `**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. So the lead authors only the last part, and every rule below about ordering — the phase boundary before the instruction headings, the `**Model:** <role>, <modelExecutionValue>` line — is about the lead's own file, not about the composed document. The composer's `**Model:** <modelExecutionValue>` anchor is a different line with a different shape; do not try to reshape it, and do not count it among the 8.
+**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.
 
 For an `antigravity` assignment, append the exact `PLAIN_FILE_WRITE_HEADER`
 value from `okstra_ctl.worker_prompt_headers` immediately after
@@ -327,6 +335,15 @@ The task-instructions file the lead writes MUST open with this block, before any
 <active-run-context workflow.forbiddenActions, verbatim>
 ```
 
+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
@@ -357,6 +374,8 @@ If none of the three is available, **abort the reverify dispatch for that role**
 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.
+
 ```markdown
 ## Output Contract
 
@@ -369,6 +388,8 @@ MUST append this block verbatim after its variant-specific response format:
 
 Reverify prompts MUST NOT inject the Phase 2 `[Required reading]` clause:
 
+**Enforced:** `_validate_reverify_prompt_suppresses_required_reading` in `validators/validate-run.py` fails any `*-reverify-r*.md` prompt containing the clause.
+
 Lightweight reverify does not require the original `analysis-packet.md`, `analysis-profile.md`, `task-brief.md`, or instruction set. Its complete input is the receiving worker's current engine-planned `findingIds` batch and the evidence embedded in those findings.
 
 - **Lightweight mode**: the clause directly contradicts the "Do NOT re-analyze the original source materials" instruction below. Including it forces workers to re-read the entire instruction-set per round per worker (3 workers × 2 rounds × 5+ files in the worst case) for no quality gain.
@@ -379,10 +400,10 @@ This is the single largest avoidable cost in `requirements-discovery`, `error-an
 ### Lightweight Re-verification Prompt
 
 ```
-Perform re-verification for <task-key> (round <N>).
-
 ## Instructions
 
+Perform re-verification for <task-key> (round <N>).
+
 Review the following findings discovered by other workers.
 For EACH finding, respond with exactly one verdict:
 
@@ -421,10 +442,10 @@ For each finding, respond as:
 Used instead of the lightweight/full-reanalysis prompt when `config.adversarial == true`. The required anchor headers (§"Required reverify-prompt anchor headers") are identical. The `[Required reading]` clause is suppressed; only the cited-evidence paths of the items under attack are injected (see §"Adversarial Verification Mode" → Scoped full-reanalysis).
 
 ```
-Perform ADVERSARIAL re-verification for <task-key> (round <N>).
-
 ## Instructions
 
+Perform ADVERSARIAL re-verification for <task-key> (round <N>).
+
 Your job is to BREAK each finding below, not to confirm it. For EACH finding,
 open the cited evidence directly and actively search for evidence that the claim
 is wrong, overstated, or unproven. Then respond with exactly one verdict:
@@ -472,10 +493,10 @@ UNVERIFIABLE is **not** `verification-error`. A verifier that opened the evidenc
 ### Full Re-analysis Re-verification Prompt
 
 ```
-Perform deep re-verification for <task-key> (round <N>).
-
 ## Instructions
 
+Perform deep re-verification for <task-key> (round <N>).
+
 Independently verify the following findings by examining the original materials.
 Use each finding as a starting point, NOT as a confirmed conclusion.
 If capability, credential, network, or service state prevents access to evidence
@@ -577,13 +598,13 @@ Save it to `runs/<task-type>/state/convergence-<task-type>-<seq>.json`.
 
 Schema rules:
 
-- `schemaVersion`: literal string `"1.3"` for all new runs — both adversarial and collaborative. Historical readers accept `"1.0"` / `"1.1"` / `"1.2"` unchanged and never rewrite those artifacts during validation. v1.3 adds the strict coverage-critic ledger and rejects unknown top-level fields; work-state remains v1.0.
+- `schemaVersion`: literal string `"1.4"` for all new runs — both adversarial and collaborative. Historical readers accept `"1.0"` / `"1.1"` / `"1.2"` / `"1.3"` unchanged and never rewrite those artifacts during validation. v1.3 added the strict coverage-critic ledger and the rejection of unknown top-level fields; v1.4 adds the `unverified` classification and its `finalClassificationCounts.unverified` key. Work-state remains v1.0.
 - `config.adversarial`: boolean. `true` when this run used adversarial verification (default for `requirements-discovery` / `error-analysis` / `implementation-option-selection` / `implementation-planning` / `project-analysis` / `feature-analysis` / `change-impact-analysis`). When `true`, `config.verificationMode` is `"full-reanalysis"` (scoped) and every `disagree` vote carries a non-null `disagreeBasis`.
-- `config.effectiveMaxRounds`: the integer the lead actually used after resolving the phase-aware default (`1` for `requirements-discovery`, `2` otherwise). MUST equal `config.maxRounds` when the manifest explicitly set it.
+- `config.effectiveMaxRounds`: the integer the lead actually used after resolving the phase-aware default (`1` for `requirements-discovery`, `2` otherwise). It may be lower than `config.maxRounds` — a phase-aware default that resolves below the manifest ceiling is the normal case — but never higher. **Enforced:** `scripts/okstra_ctl/convergence_engine.py` `_parse_config` raises `ConvergenceContractError` on `effectiveMaxRounds > maxRounds`, so a state carrying that pair cannot be loaded, and `plan_next_round` finalizes with reason `max-rounds-reached` once the executed rounds reach the effective budget rather than dispatching another one. `totalRounds` is therefore bounded by construction, not by a later re-count.
 - `findings[].ticketIds`: array of ticket keys from Phase 4 grouping (parsed per the Round 0 step 5 rule). It is empty when the phase does not require ticket tagging; `"unknown"` is not a ticket key and must not be synthesized.
 - `findings[].rounds[].votes.<worker>.verdict`: enum, one of `agree | disagree | supplement | verification-error`. Lower-case tokens; map upper-case AGREE/DISAGREE/SUPPLEMENT verdicts emitted by workers to their lower-case form and map the input alias `unverifiable` to persisted `verification-error`. The latter represents either a terminal non-result dispatch or a completed dispatch that could not verify a particular finding (§"Worker failure handling in reverify"). Every vote has a non-empty `explanation`.
 - `findings[].rounds[].votes.<worker>.disagreeBasis`: enum `counter-evidence | burden-not-met | null`. Non-null only when `verdict == "disagree"` AND `config.adversarial == true`; `null` (or absent, treated as null) otherwise. See §"Adversarial Verification Mode".
-- `findings[].classification`: enum, one of `full-consensus | partial-consensus | worker-unique | contested`. No other value is permitted.
+- `findings[].classification`: enum, one of `full-consensus | partial-consensus | worker-unique | contested | unverified`. No other value is permitted. `unverified` exists from final schema v1.4 onward; a historical v1.0-v1.3 artifact read under `reuse-final` uses the four-value vocabulary and MUST NOT be rewritten to add it.
 - `roundHistory[].inputQueueSize`: queue size at the start of this round.
 - `roundHistory[].resolvedCount`: number of findings that exited the queue this round (sum of full+partial+worker-unique classifications produced this round).
 - `roundHistory[].carriedForwardCount`: queue size at the END of this round — the single definition. In-round insertions into the queue are forbidden, so this always equals `inputQueueSize - resolvedCount`. The pseudocode's per-item `carriedForwardCount += 1` accumulator is a counting convenience that lands on the same value; persist the post-round queue length, not the loop accumulator, if the two ever diverge.
@@ -596,17 +617,20 @@ Schema rules:
 
 ## Coverage critic pass
 
-Runs when `convergence.critic.enabled == true`. Critic is required on `requirements-discovery`, `error-analysis`, `implementation-planning`, and `final-verification` (role `min`/`max` 1; the user picks the model). `--critic off` is rejected. For `final-verification` the critic runs in a different mode — see §"Acceptance critic pass (final-verification)". This pass targets **scope in both directions** — findings that are missing (coverage) and work the findings propose that no requirement asked for (over-scope) — distinct from convergence, which targets **agreement quality** among the findings already raised. The pass keeps its `coverage` mode id and `gaps` vocabulary for both halves; the two are told apart by each candidate's `category`, so no schema or reducer distinguishes them. In `implementation-planning` the same critic slot also settles plan-body analyser 1-1 splits as `critic-worker`.
+Runs when `convergence.critic.enabled == true`. Critic is opt-in on `requirements-discovery`, `error-analysis`, `implementation-planning`, and `final-verification` (role `min` 0, `recommended`/`max` 1; the user chooses whether to add the slot and picks the model). A run without a critic slot renders `enabled: false` and skips this pass. For `final-verification` the critic runs in a different mode — see §"Acceptance critic pass (final-verification)". This pass targets **scope in both directions** — findings that are missing (coverage) and work the findings propose that no requirement asked for (over-scope) — distinct from convergence, which targets **agreement quality** among the findings already raised. The pass keeps its `coverage` mode id and `gaps` vocabulary for both halves; the two are told apart by each candidate's `category`, so no schema or reducer distinguishes them. In `implementation-planning` the same critic slot also settles plan-body analyser 1-1 splits as `critic-worker`.
 
 ### When
 
-The critic input is the Round 0 consolidated finding list. Reverify rounds only classify findings — they never add or remove them (in-round queue insertions are forbidden, see §"Convergence State Artifact" `carriedForwardCount`) — so the critic dispatch MUST NOT wait for classification to finish:
+The critic input is the Round 0 consolidated finding list. Reverify rounds only classify findings — they never add or remove them (in-round queue insertions are forbidden, see §"Convergence State Artifact" `carriedForwardCount`) — **Enforced:** `_validate_no_in_round_queue_insertion` in `validators/validate-run.py` fails a finding whose earliest `rounds[].round` is greater than 1 — so the critic dispatch MUST NOT wait for classification to finish:
 
 - **Dispatch**: immediately after Round 0 grouping, CONCURRENTLY with the first reverify round's dispatches. When the verification queue is empty after Round 0 (no reverify round runs), dispatch right after grouping. Concurrent dispatch to the same provider is safe — the critic result path (`<provider>-worker-critic-...`) never collides with a reverify result path.
 - **Gap verification + merge**: only after BOTH the finding-convergence loop has exited AND the critic result is collected, and BEFORE the Phase 6 report-writer dispatch. If the loop exited `aborted-non-result`, do NOT dispatch a gap-verification round — record every gap in `unverifiedGaps[]` per §"Gap verification".
 
 ### Dispatch (fresh one-shot)
-Write the critic-only task instructions, then run `okstra agent-prompt
+Render the critic-only task instructions with `okstra convergence critic-prompt
+--run-manifest <run-manifest>` and write that output to the instructions file
+verbatim — the same pattern as `okstra plan-items prompt` at round 1. Then run
+`okstra agent-prompt
 materialize` with `--audience scope-critic`, `--assignment-ref critic/scope`,
 the critic worker ID, and `--dispatch-kind critic`. Verify the returned
 `metadataPath` before dispatch and use its `promptPath` without modification.
@@ -619,33 +643,37 @@ persisted assignment or either model value required by its runner is absent,
 record `critic-skipped: model-unresolved`; never resolve a replacement model.
 Result path: `runs/<task-type>/worker-results/<provider>-worker-critic-<task-type>-<seq>.md`.
 
-**What the critic task-instructions file MUST contain (BLOCKING).** A critic
-dispatch is not a reverify dispatch: `dispatchKind = "critic"` keeps
+**What the generated critic task-instructions file contains.** A critic dispatch
+is not a reverify dispatch: `dispatchKind = "critic"` keeps
 `audience = "analysis"`, so `worker_prompt_contract.validate_initial_prompts`
 judges it by the full initial-analysis contract. Two of those requirements are
 satisfied by the generated body for a Phase 4 worker
-(`okstra_ctl.worker_prompt_body`) and by nothing at all for a critic, whose
-instructions the lead writes — the materializer's anchor block supplies neither.
-Put both in the instructions file:
-
-```markdown
-**Prompt Delivery Mode:** eager-include
-```
-
-and, under the file's `## Inputs`, exactly one line in this shape — the literal
-label and the backticks are what the check matches, so a bare path or a
-differently-worded label counts as zero:
-
-```markdown
-- Primary analysis packet: `<path ending in analysis-packet.md>`
-```
-
-Omitting either one 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`. Fix the instructions
-file and re-materialize with `--replace-undispatched` (§"Invocation
-materialization gate") rather than editing the published prompt.
+(`okstra_ctl.worker_prompt_body`) and by nothing in the materializer's anchor
+block for a critic — `critic-prompt` emits both itself: the
+`**Prompt Delivery Mode:** eager-include` header, and under `## Inputs` exactly
+one `Primary analysis packet` line whose backticked path ends in
+`analysis-packet.md`, read from the run manifest's `analysisPacketPath` (the
+command fails when that field is missing, rather than emitting a body the
+dispatch will reject). The rest of the body is:
+
+- the Round 0 consolidated finding list, from the run's published grouping;
+- one line per Phase 4 analyser — worker id, its result path, and the finding
+  ids that worker sourced — so "open the named result" points at a real file;
+- when the task already has an implementation-planning report on disk (a rerun),
+  an **already-covered** index from it: requirement-coverage row ids,
+  clarification row ids, and stage titles. Ids and titles only, never body text;
+- the two mandates below, including the `duplicateOf` declaration rule.
+
+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`
+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
+re-materialize with `--replace-undispatched` (§"Invocation materialization
+gate") rather than editing the published prompt.
 
 The `-worker-` token is load-bearing, not decoration: the critic prompt carries the same generated anchor headers as every other worker ([team-contract](./team-contract.md) §"Worker prompts"), and its `**Audit sidecar path:**` comes from passing that result path through `okstra_ctl.worker_artifact_paths.audit_sidecar_rel()`, which inserts `-audit-` after the token and raises without it. A `<provider>-critic-...` name leaves the lead choosing between breaking the contract and hand-inventing the sidecar name. Note that `originWorker` stays `"<provider>-critic"` — that is a worker id in the convergence state, not a filename, and the two do not have to match.
 
@@ -661,35 +689,16 @@ Required reading before proposing a gap or an over-scope candidate:
 
 Operational guardrails are not task requirements. A gap must trace to a brief requirement, an analysis-packet scope item, a source path the packet authorizes, or an evidence claim in a worker result. Do NOT infer missing verification from a one-line summary; open the named result and audit sidecar first.
 
-```
-Inspect scope coverage for <task-key>. Below are the consolidated findings the
-workers produced. Your job has exactly two halves. Answer both.
-
-(1) MISSING — name what nobody covered:
-- files / directories / execution paths nobody inspected,
-- requirements or acceptance points with zero findings,
-- claims raised but never verified.
-For each, emit a NEW finding with evidence (file:line or the requirement quote).
-
-(2) UNREQUESTED — name work these findings propose that no requirement asked for:
-- a finding whose proposed change serves no requirement, scope item, or
-  acceptance point you can QUOTE from the analysis packet,
-- an abstraction, configuration knob, or generalization proposed for a caller or
-  a case nobody has stated,
-- a rewrite, migration, or cleanup of code the requirements never mention.
-For each, emit a candidate with `category: "unrequested-scope"`, quote the
-proposed work verbatim, and state which requirement you searched for and did not
-find.
-
-Do NOT restate an existing finding. Judge (2) against the analysis packet's
-requirements and scope, never against your own preference for how the code should
-look — "I would have done it differently" is not unrequested work, and neither is
-work the packet authorizes but you consider unnecessary. If a half has nothing,
-say so explicitly for that half; silence on one half is an incomplete result.
-```
+The two mandates and the `duplicateOf` rule live in the generator
+(`okstra_ctl/convergence_critic_prompt.py` `_MANDATES`), not here. There is no
+second copy to keep in step: `critic-prompt` renders that text under `## Mandate`
+above the Round 0 list, and the lead pastes the output whole.
+
+**A candidate that overlaps an existing finding is declared, not restated.** The
+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"`. The lead runs ONE adversarial reverify round (§"Adversarial Verification Mode" classifier) with **every Phase 4 analyser as a voter**. 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 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).
 
 **A gap that received no verdict is NOT a rejected gap (BLOCKING).** Dropping applies only to gaps the voters actually judged. A gap can also end the round *unjudged* — the verification dispatch returned a terminal non-result (`timeout`, `error`, no result file), the returned result covered only some of the gaps, or no non-critic analyser was available to vote at all. Nobody inspected those, so classifying them as hallucinations is a fabricated verdict. Each one MUST be recorded as a `## 5. Missing Information and Risks` row (`missingInformation`, `source: "critic-unverified"`) whose `risk` names the gap and the reason verification did not complete, and counted in `config.critic.gapsUnverified`. They are **not** promoted to findings (unverified) and **not** raised as `clarification` items — an unverified gap needs an analyser to verify it on the next run, not a decision from the user. Silently losing them is a contract violation: the batch that times out is exactly the batch of gaps too expensive to check, so the highest-risk items are the ones that vanish.
 
@@ -704,13 +713,13 @@ The asymmetry is deliberate and runs the opposite way from the coverage half: a
 ### State
 - `convergence.critic` manifest block: `{ enabled, provider, modelExecutionValue }`.
 - Each candidate's `category` tells the two halves apart: literal `"unrequested-scope"` for the over-scope half, any other value for a coverage gap. `schemas/convergence-critic-results-v1.0.schema.json` leaves `category` a free string, so this needs no schema or reducer change — but it also means nothing machine-checks the spelling. A misspelled category is read as a coverage gap and silently takes the drop-on-contested path.
-- The lead passes one canonical coverage batch with `{ schemaVersion, taskKey, mode, provider, modelExecutionValue, dispatches, gaps }`; each gap carries its candidate fields plus `gapId` and `votes`. `dispatches[]` contains exactly one row for every Phase 4 analyser except the critic, even when execution did not produce a result: persist `status: timeout | error | not-run` and the elapsed `durationMs` instead of omitting that analyser. `apply-critic-gaps` rejects a non-terminal main queue, duplicate or missing analysers, unknown workers, critic dispatches/votes, votes without a completed dispatch, and a second batch.
-- Convergence state artifact: merged gaps appear in `findings[]` with `source: "critic"` and `rounds: []`. The separate `criticVerification.gaps[]` ledger retains each gap's `summary`, `category`, `ticketIds`, `originEvidence`, optional `evidenceArtifacts`, classification, merge link, and votes. Strict v1.3 validation deterministically replays each complete critic-origin finding from that ledger; a critic batch never increments `roundHistory` or `totalRounds` and never creates a fake main round.
-- `config.critic` is `{ provider, modelExecutionValue, gapsProposed, gapsMerged, gapsRejected, gapsUnverified }`, with `gapsProposed = gapsMerged + gapsRejected + gapsUnverified`. `full-consensus` / `partial-consensus` gaps merge, `contested` / `worker-unique` gaps count as rejected, and gaps with no usable analyser vote appear in both the ledger and final `unverifiedGaps[]`.
+- The lead passes one canonical coverage batch with `{ schemaVersion, taskKey, mode, provider, modelExecutionValue, dispatches, gaps }`; each gap carries its candidate fields plus `gapId` and `votes`, or `duplicateOf` and no votes. `dispatches[]` contains exactly one row per **assigned** analyser (§"Gap verification"), even when execution did not produce a result: persist `status: timeout | error | not-run` and the elapsed `durationMs` instead of omitting that analyser. A batch that dispatched every Phase 4 analyser instead is still accepted. `apply-critic-gaps` rejects a non-terminal main queue, a dispatch set matching neither shape, duplicate analysers, unknown workers, critic dispatches/votes, votes without a completed dispatch, a `duplicateOf` naming no existing finding, and a second batch.
+- Convergence state artifact: merged gaps appear in `findings[]` with `source: "critic"` and `rounds: []`. The separate `criticVerification.gaps[]` ledger retains each gap's `summary`, `category`, `ticketIds`, `originEvidence`, optional `evidenceArtifacts`, classification, merge link, votes, and `duplicateOf` when the critic declared one. Strict validation deterministically replays each complete critic-origin finding from that ledger; a critic batch never increments `roundHistory` or `totalRounds` and never creates a fake main round.
+- `config.critic` is `{ provider, modelExecutionValue, gapsProposed, gapsMerged, gapsRejected, gapsUnverified, gapsDuplicate }`, with `gapsProposed = gapsMerged + gapsRejected + gapsUnverified + gapsDuplicate`. `full-consensus` / `partial-consensus` gaps merge, `contested` / `worker-unique` gaps count as rejected, gaps with no usable analyser vote appear in both the ledger and final `unverifiedGaps[]`, and a declared duplicate takes classification `duplicate` — it makes no finding and joins no other counter. A state written before `gapsDuplicate` existed omits the key and stays valid; the validator reads its absence as 0.
 
 ## Acceptance critic pass (final-verification)
 
-The `final-verification` phase uses the same fresh one-shot `redispatch_worker` pattern and the same dispatch timing as §"Coverage critic pass" §"When" (provider + `config.critic.modelExecutionValue` from the `convergence.critic` block; critic is required; same model-unresolved skip rule) — the delivered work the critic inspects is likewise fixed before the reverify round starts. Only the prompt, the verification semantics, and the output sink differ — final-verification's findings are defects/blockers, so the critic acts as an **acceptance devil's advocate** (find reasons NOT to accept), and its candidate blockers are NEVER dropped (that would suppress real defects).
+The `final-verification` phase uses the same fresh one-shot `redispatch_worker` pattern and the same dispatch timing as §"Coverage critic pass" §"When" (provider + `config.critic.modelExecutionValue` from the `convergence.critic` block; critic is opt-in — the pass is skipped when the run resolved no critic; same model-unresolved skip rule) — the delivered work the critic inspects is likewise fixed before the reverify round starts. Only the prompt, the verification semantics, and the output sink differ — final-verification's findings are defects/blockers, so the critic acts as an **acceptance devil's advocate** (find reasons NOT to accept), and its candidate blockers are NEVER dropped (that would suppress real defects).
 
 Before that call, write the acceptance-only task instructions and run `okstra
 agent-prompt materialize` with `--audience acceptance-critic`,
@@ -751,13 +760,13 @@ Promoted blockers enter `## 5.8 Acceptance Blockers`; since `accepted` requires
 
 ### State
 
-Critic output lives in the run's `worker-results/` directory (`runs/final-verification/worker-results/` for whole-task verification, `runs/final-verification/stage-<N>/worker-results/` for single-stage), filename `<provider>-worker-critic-final-verification-<seq>.md` (same `-worker-` token rule as §"Coverage critic pass" — the audit sidecar is derived from it). The convergence state `config.critic` summary records `mode: "acceptance-devils-advocate"`, `candidatesProposed`, `confirmedBlockers`, `downgradedToResidual`; v1.3 enforces `candidatesProposed = confirmedBlockers + downgradedToResidual`, so no candidate can be silently dropped.
+Critic output lives in the run's `worker-results/` directory (`runs/final-verification/worker-results/` for whole-task verification, `runs/final-verification/stage-<N>/worker-results/` for single-stage), filename `<provider>-worker-critic-final-verification-<seq>.md` (same `-worker-` token rule as §"Coverage critic pass" — the audit sidecar is derived from it). The convergence state `config.critic` summary records `mode: "acceptance-devils-advocate"`, `candidatesProposed`, `confirmedBlockers`, `downgradedToResidual`; v1.4 enforces `candidatesProposed = confirmedBlockers + downgradedToResidual`, so no candidate can be silently dropped.
 
 ## Output
 
 Information to be passed to Phase 6 after completing this contract:
 
-- Newly finalized convergence output is schema v1.3. Under `reuse-final`, a valid historical final schema v1.0, v1.1, or v1.2 remains consumable by the report-writer without rewrite. Either validated terminal artifact contains the four-category classification of all findings; the report-writer consumes it and does not vote
+- Newly finalized convergence output is schema v1.4. Under `reuse-final`, a valid historical final schema v1.0, v1.1, v1.2, or v1.3 remains consumable by the report-writer without rewrite. Either validated terminal artifact contains the classification of every finding; the report-writer consumes it and does not vote
 - Round history and votes per worker for each finding
 - Path to the convergence state artifact
 - Convergence summary (count per category)