@open-agent-toolkit/cli 0.2.72 → 0.2.73

package/assets/agents/oat-reviewer.md

@@ -1,6 +1,6 @@
 ---
 name: oat-reviewer
-version: 1.2.4
+version: 1.2.5
 description: Unified reviewer for OAT projects - mode-aware verification of requirements/design alignment and code quality. Writes a review artifact to disk by default, or returns structured findings in-memory when dispatched in structured-output mode.
 tools: Read, Bash, Grep, Glob, Write, Task
 color: yellow
@@ -93,8 +93,9 @@ When delegation is eligible:
    Mechanical workers may execute checks and report exact output, but interpretation and policy judgment require stronger classes or stay with the root reviewer.
 
 5. The generic dispatch contract owns capability, catalog, model, effort, route, authorization, launch evidence, class-floor selection, and floor-satisfaction evidence. It applies active user and repository instructions, the active-provider reference, the live nested catalog, and the supplied policy/ceiling. Select an explicit target meeting the declared floor; never silently inherit the primary reviewer's model and never hard-code provider model names. Prefer a cheaper/faster worker only when the host reliably exposes that control and the target still satisfies the floor.
-6. Give each lane an exact scope and a compact return contract: coverage, checks performed, exact `file:line` evidence, gaps, and explicit uncertainty. Reports are advisory candidate observations, not accepted findings.
-7. Workers must not mutate files, emit final findings, assign severity, make validation decisions, write review artifacts or `StructuredFindings`, or otherwise write either output sink.
+6. When the selected lane worker is the canonical `recon-worker`, construct and validate its complete Assignment Gate envelope before launch: run, wave, and lane IDs; approved manifest wave mode; worker assignment mode; bounded objective; included and excluded scope; allowed and excluded inputs; source-read authority and read-only tools; sole write path; artifact kind, schema version, and closed output schema; enforcement; deadline; and escalation path. If the complete envelope cannot be constructed, do not launch the worker; record the attempt as not attempted or failed as appropriate and cover the lane inline. Other worker roles follow their own contracts.
+7. Give each lane an exact scope and a compact return contract: coverage, checks performed, exact `file:line` evidence, gaps, and explicit uncertainty. Reports are advisory candidate observations, not accepted findings.
+8. Workers must not mutate files, emit final findings, assign severity, make validation decisions, write review artifacts or `StructuredFindings`, or otherwise write either output sink.
 
 Lanes may share one homogeneous dispatch wave only when every existing dispatch axis, `task_class`, and `model_class_floor` match. Mixed task classes require separate records and waves. The one-level fan-out limit applies across all waves.
 

package/assets/agents/recon-worker.md

@@ -1,6 +1,6 @@
 ---
 name: recon-worker
-version: 1.0.0
+version: 1.0.1
 description: Executes one bounded recon packet assignment as a non-interactive leaf worker and writes exactly one declared artifact.
 tools: Read, Bash, Grep, Glob, Write, WebSearch, WebFetch
 color: cyan
@@ -12,12 +12,31 @@ You are a non-interactive recon leaf worker. Execute exactly one assignment in
 one declared mode: `map`, `gather`, `compile`, `verify`, `adversary`, `coverage`,
 or `reconcile`. No other mode is valid.
 
+The controller maps approved manifest waves to this closed vocabulary:
+
+| Manifest wave mode         | Worker assignment mode |
+| -------------------------- | ---------------------- |
+| `map`                      | `map`                  |
+| `gather`                   | `gather`               |
+| `compile`                  | `compile`              |
+| `semantic-verification`    | `verify`               |
+| `adversarial`              | `adversary`            |
+| `coverage`                 | `coverage`             |
+| `reconciliation`           | `reconcile`            |
+| `redundant-gather`         | `gather`               |
+| `redundant-verification`   | `verify`               |
+| `contradiction-resolution` | `adversary`            |
+
+Preserve the approved wave identity and target; never select or upgrade a
+route yourself.
+
 ## Assignment Gate
 
 Before work, require a complete envelope containing run, wave, and lane IDs;
-mode; bounded objective; included and excluded scope; allowed inputs; excluded
-inputs; source-read authority and read-only tools; sole write path; artifact
-kind and schema version; output schema; enforcement level; and deadline.
+the approved manifest wave mode; exactly one worker assignment mode; bounded
+objective; included and excluded scope; allowed inputs; excluded inputs;
+source-read authority and read-only tools; sole write path; artifact kind and
+schema version; output schema; enforcement level; and deadline.
 
 Reject the assignment if inputs overlap exclusions, source authority is
 missing, the write path is not unique and packet-contained, the schema is
@@ -70,6 +89,9 @@ reasoning, synthesis prose, or prior reviews.
 Consume only declared scope, questions, and provisional statements. Search for
 counterevidence, unsupported inference, incompatible interpretations, and
 missing alternatives. Do not read gathering or prior-review conclusions.
+When assigned a `contradiction-resolution` wave, seek discriminating evidence
+for that named contradiction; do not reconcile the ledger or decide which
+interpretation wins.
 
 ### `coverage`
 
@@ -86,14 +108,26 @@ the existing ledger in place.
 
 ## Output
 
-Write one JSON artifact matching the supplied schema. Include kind, schema
-version, identities, mode, outcome, honored inputs and exclusions, findings or
-dispositions, uncertainty, contradictions, gaps, safe diagnostics, and direct
-input references where applicable.
+Write one JSON artifact using only the supplied closed schema's fields. A
+`recon.raw-dossier` identifies its approved manifest wave with `waveId` and its
+closed worker assignment with `mode`; it also includes `laneId` and `outcome`.
+A `recon.review-result` identifies its approved lane with `reviewerLane` and its
+approved review discriminator with `reviewKind`. Include the remaining
+required identity, input, exclusion, finding or disposition, uncertainty,
+contradiction, gap, diagnostic, and direct-reference fields only as the
+supplied schema permits.
+
+Do not add a second mode field or any other unknown field. The controller
+validates `waveId` and `mode`, or `reviewerLane` and `reviewKind`, against the
+approved manifest wave before promoting the artifact.
 
 Return only the artifact path and compact outcome. Do not return source bodies,
 worker reasoning, or dossier contents to the controller.
 
+The controller and caller decide whether the evidence is sufficient. Never turn
+an assignment result into a downstream recommendation, architecture verdict, or
+final review conclusion.
+
 ## Critical Rules
 
 **ONE MODE. ONE ARTIFACT.** Perform only the assigned mode and write only its

package/assets/bundle-metadata.json

@@ -1,4 +1,4 @@
 {
   "schemaVersion": 1,
-  "oatVersion": "0.2.72"
+  "oatVersion": "0.2.73"
 }

package/assets/docs/workflows/skills/recon.md

@@ -10,6 +10,12 @@ It gathers source-grounded findings through approved worker waves, validates
 their locators and assurance state, and gives the next consumer one compact
 entry point instead of every worker transcript.
 
+Recon controls the profile, routing proposal, and evidence flow. Shared
+orchestration guidance classifies the concrete assignments, the dispatch skill
+resolves and launches exact targets supported by the active harness, and the
+calling agent owns scope, approval dialogue, sufficiency judgment, and final
+conclusions.
+
 The first release is standalone. It does not automatically run from project
 discovery, quick start, `analyze`, or `deep-research`. Those workflows can
 consume an explicitly supplied packet path without changing their own
@@ -45,10 +51,11 @@ oat tools update --pack research --scope project
 
 The research pack acquires its two dispatch dependencies from the utility pack
 at the same scope. You do not need to select a named model during installation.
-At run time, OAT resolves a currently available target that meets the planned
-work's task-class floor and asks you to approve the exact provider, model,
-effort, role, topology, authority, and execution limits before any worker
-launches.
+At run time, OAT resolves each wave independently against its task class and
+floor, then asks you to approve every wave's exact supported provider-native
+axes, role, topology, rationale, conditions, authority, and finite execution
+limits before any worker launches. Active provider guidance and the live
+catalog own current qualification; recon does not maintain a second model list.
 
 ## Run a Recon
 
@@ -59,21 +66,31 @@ context source, output directory, or strict authority:
 /recon "How is provider sync materialized?" --profile standard --scope packages/cli/src/providers
 ```
 
-The default profile is `standard`. Every run uses one approved model and effort
-for every pass. Profiles change pass topology, redundancy, lane caps, and
-maximum concurrency; they do not silently choose a different model tier.
-
-| Profile    | Use it for                                  | Required assurance work                                                                  | Claim ceiling |
-| ---------- | ------------------------------------------- | ---------------------------------------------------------------------------------------- | ------------- |
-| `quick`    | Bounded orientation                         | Mapping, gathering, compilation, schema validation, and locator validation               | `supported`   |
-| `standard` | Load-bearing evidence                       | Quick work plus blind semantic verification, adversarial review, coverage, and reconcile | `verified`    |
-| `thorough` | Expensive failure or correlated blind spots | Standard work plus redundant gathering and verification and contradiction resolution     | `verified`    |
-
-The approval manifest shows the exact adaptive lane count, concurrency, pass
-topology, deadlines, retries, and source/write authority. Declining approval
-launches nothing. A change to a provider, model, effort, route, role, service
-tier, or execution cap requires renewed approval; there is no silent
-substitution after approval.
+The default profile is `standard`. Each homogeneous wave has an independently
+selected and approved exact target. Bounded mapping, extraction, citation
+reopening, counterexample search, and mechanical dossier compilation start with
+economical qualified routes. A wave that genuinely requires interpretation or
+reconciliation judgment can use a stronger approved target without raising the
+cost of unrelated evidence waves.
+
+| Profile    | Use it for                                  | Required assurance work                                                                                            | Claim ceiling |
+| ---------- | ------------------------------------------- | ------------------------------------------------------------------------------------------------------------------ | ------------- |
+| `quick`    | Bounded orientation                         | Mapping, gathering, compilation, schema validation, and locator validation; no independent semantic pass by design | `supported`   |
+| `standard` | Load-bearing evidence                       | Quick work plus blind semantic verification, adversarial review, coverage, and reconcile                           | `verified`    |
+| `thorough` | Expensive failure or correlated blind spots | Standard work plus required redundant gathering and redundant verification                                         | `verified`    |
+
+A thorough run may additionally predeclare an optional, condition-bound
+`contradiction-resolution` evidence wave. It runs only when its approved
+predicate triggers and is not required when that branch is not triggered.
+
+The approval manifest shows each wave's exact target, task class, class floor,
+selection rationale, adaptive lane count, conditional rule, concurrency,
+deadlines, retries, and source/write authority. An unsupported provider-native
+control is shown explicitly as unavailable or null; recon never translates an
+effort label across harnesses or infers capability from an opaque selector.
+Declining approval launches nothing. Any target, topology, condition, or limit
+change requires renewed approval; there is no silent substitution after
+approval.
 
 Before any worker launches, recon confirms that the live launch surface can run
 the approved role, model, effort, and authority level. If it cannot, the run
@@ -82,6 +99,48 @@ launched. Deadlines are approved execution limits chosen for the task class,
 not short watchdogs; an accepted lane is never interrupted by hand because a
 displayed deadline elapsed.
 
+### Preview and Check Routing
+
+The installed proposal helper renders the complete envelope in Markdown or
+JSON without recording approval or launching work. From a project-scoped
+installation:
+
+```bash
+node .agents/skills/recon/scripts/prepare-routing.mjs --manifest draft-manifest.json --format markdown
+node .agents/skills/recon/scripts/prepare-routing.mjs --manifest draft-manifest.json --format json
+```
+
+Immediately before a launch, the controller uses the same production logic to
+compare the constructed target with that wave's approved exact target:
+
+```bash
+node .agents/skills/recon/scripts/prepare-routing.mjs --manifest manifest.json --wave gather-1 --check-target candidate-target.json
+```
+
+These commands validate structure, approval integrity, and exact identity. They
+do not launch a worker, rank model names, attest actual runtime identity, or
+measure cost.
+
+### Bounded Conditional Evidence
+
+Standard and thorough may predeclare finite conditional
+`contradiction-resolution` evidence waves. A completed predecessor can trigger
+one such wave to seek discriminating evidence; accepted failure, cancellation,
+timeout, or missing output cannot trigger a replacement. Triggered,
+not-triggered, and unresolved dispositions remain visible. Both branches feed
+the same single mandatory terminal reconciliation.
+
+A triggered condition must cite complete, digest-bound evidence from an approved
+predecessor in the same run. Evidence copied from another run cannot activate
+the destination wave and fails packet validation with
+`CONDITION_EVIDENCE_RUN_MISMATCH`.
+
+If a need for stronger reconciliation judgment is foreseeable, select that one
+terminal target before approval. If it appears only after approval, recon
+preserves completed evidence and returns an unresolved, out-of-envelope gap for
+renewed approval or a new run. It never mutates the target, silently retries,
+or launches a second reconciliation.
+
 ## Destination Precedence
 
 `recon` always creates a new topic-and-run directory. It never overwrites an
@@ -119,6 +178,26 @@ non-publishable candidate generation withdraws any existing `packet.md`:
 - `raw/` contains worker dossiers, candidate artifacts, and safe failure
   diagnostics. It is not normal consumer input.
 
+The `recon.packet-manifest` contract accepts version 2 only. Evidence artifact
+kinds remain independently versioned at version 1. Approval is session-local
+and records only `{ type, approvedAt }`: resuming, reloading, or changing the
+proposal requires a fresh preview and explicit approval before launch.
+
+Every valid packet renders a compact Intended Routing section from the already
+validated normalized view. It labels exact targets and condition dispositions
+as approved intent, not proof of the native process that ran, launcher receipts,
+token or billing totals, or universal correctness. A valid packet continues to
+reference version 1 evidence artifacts. Evidence, claims, contradictions, and
+gaps remain the packet's main consumer context.
+
+Every dossier and review result identifies the approved wave and lane that wrote
+it. Primary and redundant gather artifacts therefore satisfy only their owning
+waves; lanes from one gather wave cannot impersonate the other pass. In a
+thorough run, redundant gathering finishes before compilation, and the compiled
+ledger must reference every completed primary and redundant gather dossier by
+exact path and digest before review briefs are created. Missing provenance fails
+with `MISSING_THOROUGH_GATHER_LEDGER_INPUT`.
+
 The ledger compiler and packet validator enforce categorical referential
 integrity on `synthesis.keyClaimIds` and `synthesis.unresolvedQuestionIds`. Any
 reference to an unknown claim or question ID fails validation with
@@ -143,9 +222,11 @@ percentages:
 - `unresolved`: available evidence cannot settle the claim; and
 - `unsupported`: valid supporting evidence is absent or verification failed.
 
-A quick packet never promotes a claim to `verified`. Stronger profiles can do
-so only when their required review artifacts validate and were written by
-approved lanes.
+A quick packet is an evidence packet for an intelligent consumer and has no
+independent semantic pass by design. It never promotes a claim to `verified`;
+the caller assesses sufficiency and conclusions. Stronger profiles can promote
+claims only when their required independent review artifacts validate and were
+written by approved lanes.
 
 When an independent semantic review rejects a proposed claim, the reconciler
 transitions it to `unsupported` rather than deleting it. This preserves the
@@ -189,7 +270,17 @@ omitted passes, material gaps, affected claims, and required assurance
 downgrades. A run may be partial even when it achieved the requested profile if
 a material evidence gap remains. The achieved profile is derived from the
 complete typed artifacts in the packet; each required pass without a complete
-result needs a material `PASS_FAILED` or `PASS_OMITTED` gap naming it.
+result needs a material `PASS_FAILED` or `PASS_OMITTED` gap. Each approved lane
+must likewise have a complete artifact or a material outcome gap carrying its
+exact `waveId` and `laneId`; legacy mode-only gaps remain valid only when the mode
+unambiguously identifies one single-lane wave.
+
+A complete artifact and material failure or omission for the same exact wave and
+lane are contradictory, so validation fails closed with
+`CONTRADICTORY_PASS_OUTCOME`. Complete evidence from one lane and exact failure
+evidence from a different lane are not contradictory: the completed lane can
+preserve the achieved pass while the failed lane makes the published run an
+honest `partial` packet at that achieved profile.
 
 Status updates and the final handoff label each failure as `worker`,
 `provider/dispatch`, `contract validation`, or `source availability`, and

package/assets/public-package-versions.json

@@ -1,6 +1,6 @@
 {
-  "cli": "0.2.72",
-  "docs-config": "0.2.72",
-  "docs-theme": "0.2.72",
-  "docs-transforms": "0.2.72"
+  "cli": "0.2.73",
+  "docs-config": "0.2.73",
+  "docs-theme": "0.2.73",
+  "docs-transforms": "0.2.73"
 }

package/assets/skills/oat-project-review-receive/SKILL.md

@@ -5,7 +5,7 @@ disable-model-invocation: false
 user-invocable: true
 allowed-tools: Read, Write, Bash(git:*), Bash(oat:*), Glob, Grep, AskUserQuestion
 metadata:
-  version: 1.6.4
+  version: 1.6.6
 ---
 
 # Receive Review
@@ -82,6 +82,19 @@ When executing this skill, provide lightweight progress feedback so the user can
 - Routing to oat-project-implement
 - For `artifact` reviews: updating reviewed artifact files directly after user confirmation
 
+## Review Artifact Ownership
+
+The receiving/root agent reads the selected review artifact completely and
+interprets every finding. Do not delegate review-artifact reading, parsing,
+finding analysis, disposition judgment, or artifact edits to an explorer or
+reconnaissance worker.
+
+After the root has read the artifact, it may delegate a bounded inspection of
+explicitly scoped related code or evidence when corroboration is useful. That
+assignment must exclude the review artifact, return exact `file:line` evidence,
+and leave finding analysis, disposition, and all lifecycle mutations with the
+receiving/root agent.
+
 ## Artifact Hygiene
 
 Artifact hygiene contract: Before finishing or committing, format every file you created or edited. Use the concrete write/fix formatting command supplied by the governing plan, task, or brief. If none is usable, discover the repository's documented write/fix command from applicable `AGENTS.md`/`CLAUDE.md` instructions and relevant package manifests; do not infer or hardcode a formatter. Prefer a file-scoped invocation when supported, and avoid rewriting unrelated files. If no command is discoverable, warn once with `no format command discovered in repo instructions; skipping`, then continue.

package/assets/skills/recon/SKILL.md

@@ -6,15 +6,18 @@ disable-model-invocation: true
 user-invocable: true
 allowed-tools: Read, Write, Glob, Grep, Bash, AskUserQuestion, Agent, mcp__*
 metadata:
-  version: 1.1.1
+  version: 1.1.2
 ---
 
 # Recon
 
 Compile a bounded investigation into a durable, validated evidence-packet
-directory. `recon` is a provider-neutral controller: it owns decomposition,
-artifact boundaries, assurance, and user interaction while installed dispatch
-dependencies own live catalogs, target selection, and launch mechanics.
+directory. `recon` is a provider-neutral controller: it owns profile topology,
+routing proposals, evidence flow, artifact boundaries, and assurance.
+`subagent-orchestration` owns task-class and qualification guidance;
+`oat-dispatch-subagents` owns live target resolution and launch mechanics. The
+calling agent owns scope, approval dialogue, evidence-sufficiency judgment, and
+all downstream conclusions.
 
 ## When to Use
 
@@ -115,12 +118,19 @@ Initialize `manifest.json` and the directory skeleton, but do not create
 
 Read `references/profiles.md`. Partition the scope into non-overlapping,
 adaptive lanes within the profile's hard caps. Classify every required and
-conditionally allowed wave before selection. Record each wave's task class and
-floor, then compute the run-wide maximum model-class floor.
-
-All lanes within a launch are a homogeneous wave. All waves use the same
-approved model and effort. Profiles change topology, redundancy, and
-concurrency—not the target tier.
+conditionally allowed wave from its concrete bounded assignment, not its phase
+label. Start with the economical provider-qualified route for the actual work;
+narrow the assignment before escalating, and preserve stronger capability when
+the work itself requires judgment.
+
+Use the complete mode policy from `references/profiles.md` and
+`scripts/lib/routing.mjs`. Map manifest wave modes to the worker's closed
+assignment vocabulary: `redundant-gather` to `gather`;
+`semantic-verification` and `redundant-verification` to `verify`; `adversarial`
+and `contradiction-resolution` to `adversary`; and only `reconciliation` to
+`reconcile`. The remaining modes keep their same-named assignment. All lanes
+within one launch are a homogeneous wave. Select each wave independently; a
+stronger wave never raises unrelated waves' targets or effort.
 
 ### Step 4: Prepare One Exact Dispatch Manifest
 
@@ -141,34 +151,55 @@ pack is already installed, `oat tools update --pack utility --scope
 
 Read `${UTILITY_SKILLS_ROOT}/oat-dispatch-subagents/SKILL.md` and perform
 only the selection steps of its Full-Information Selection: observe the
-catalog, resolve one exact target, and record the selection. Stop before its
-launch step; nothing launches until Step 5 runs after approval. From the same
-root, read
+catalog, resolve each wave's exact target, and record each selection. Stop
+before its launch step; nothing launches until Step 5 runs after approval. From
+the same root, read
 `subagent-orchestration/references/model-selection-principles.md`, exactly one
 active-provider selection reference, and the matching
 `oat-dispatch-subagents` provider mechanics reference. Do not copy provider
 catalogs or exact launch construction into this skill.
 
-Resolve every planned and conditional wave against one exact target satisfying
-the run-wide floor. Prefer the canonical `recon-worker` role. If that role is
-unavailable, plan the generic role with the complete worker contract as a
-visible generic role fallback before approval. A fallback after approval is
-forbidden.
+Resolve every planned and conditional wave independently against its recorded
+task class and class floor. Preserve provider, route, role, model, effort,
+reasoning mode, and service tier as separate provider-native axes. A null axis
+means the adapter exposes no independently requested control; never translate
+effort between harnesses or normalize an opaque selector. Prefer the canonical
+`recon-worker` role. If that role is unavailable, plan the generic role with the
+complete worker contract as a visible generic role fallback before approval. A
+fallback after approval is forbidden.
+
+Prepare a `schemaVersion: 2` draft manifest. Its execution object contains a
+complete inherited `target`, limits, waves, conditions, and later the approval.
+Every wave records `taskClass`, `classFloor`, a substantive
+`selectionReason`, its lanes and conditional flag, and an optional complete
+replacement `target`. Partial target overrides are invalid. Use the production
+proposal helper rather than manually reinterpreting the manifest:
+
+```bash
+node scripts/prepare-routing.mjs --manifest manifest.json --format markdown
+```
 
-Write the approval envelope into `manifest.execution`. It binds:
+The proposal shown for approval includes:
 
-- provider, route, role, model, effort, reasoning mode, and service tier;
+- every wave's exact effective provider, route, role, model, effort, reasoning
+  mode, and service tier;
 - authority level, maximum concurrency, per-lane deadline, and retry limit; and
-- every wave with its mode, task class, and conditional flag, and every lane
-  with its identity, read scope, and worker-owned write root.
-
-Its canonical fingerprint covers every field above.
-
-Present the exact provider, model and effort for explicit approval before any
-worker launch, together with the full topology and hard execution limits. Named model examples are
-illustrative and non-normative; never route from an example. Declining approval
-leaves the run at `awaiting-approval` and launches nothing. Approval records
-`explicit-user-approval`, the approval time, and the fingerprint.
+- every wave with its mode, task class, class floor, selection reason, target,
+  and conditional flag; every condition with its predecessor, destination,
+  predicate, and single-activation cap; and every lane with its identity, read
+  scope, and worker-owned write root.
+
+Present every wave's exact supported target axes, class/floor, lane count,
+selection rationale, conditions, and finite worst-case concurrency, deadline,
+retry, lane, and condition limits for explicit approval before any worker
+launch. Name unsupported controls as null instead of inventing them. Named
+model examples are illustrative and non-normative; never route from an example.
+Declining approval leaves the run at `awaiting-approval` and launches nothing.
+Approval records `explicit-user-approval` and the approval time. Approval is
+session-local: it authorizes only the exact proposal shown in the same
+uninterrupted control flow. If the run is resumed, reloaded, or changed before
+launch, remove the approval, return to `awaiting-approval`, render the current
+proposal again, and obtain fresh approval.
 
 **Deadlines.** Choose the per-lane deadline from the expected task class and
 scope, and show it in the approval envelope; it is an approved execution limit,
@@ -187,18 +218,30 @@ result. If any approved axis cannot be satisfied, stop with a
 launch nothing. Never substitute a different axis to make the launch fit.
 
 Launch each wave through the dispatch dependency with exactly the approved
-axes. Immediately before each launch, compare the axes that will actually run
-against the approval fingerprint. Any drift returns the complete manifest for
-renewed approval. Launch acceptance is distinct from worker completion. After
-acceptance there is no replacement child, alternate route, target
-substitution, or no silent retry. If an accepted lane fails, is cancelled, or
-times out, record that pass as failed with a material `PASS_FAILED` gap
-naming the pass.
+axes. Immediately before each launch, check the constructed target through the
+same production helper used by preview:
+
+```bash
+node scripts/prepare-routing.mjs --manifest manifest.json --wave <wave-id> --check-target <candidate-target.json>
+```
+
+Any constructed-target mismatch returns the complete manifest for renewed
+approval. This check proves invocation intent, not actual runtime
+identity. Launch acceptance is distinct from worker completion. After
+acceptance there is no replacement child, alternate route, target substitution,
+and no silent retry. If an accepted lane fails, is cancelled, or times out,
+record that lane as failed with a material `PASS_FAILED` gap carrying its exact
+approved `waveId` and `laneId`. This structured identity is required for
+conditional and non-conditional lanes alike; prose is descriptive, not
+identity.
 
 Run the passes in this order:
 
 1. `map` and `gather` workers write unique dossiers under `raw/dossiers/`.
-2. `compile` writes a candidate canonical claim ledger.
+   Thorough runs complete their independent `redundant-gather` wave here too.
+2. `compile` writes a candidate canonical claim ledger. A thorough candidate
+   directly references a complete dossier from every approved primary and
+   redundant gather lane before any review brief is created.
 3. Source preflight: run `scripts/validate-artifact.mjs` on the candidate
    manifest and ledger, then reopen every declared source and evidence locator
    with the checks in `scripts/validate-packet.mjs`. Resolve source roots to
@@ -206,10 +249,26 @@ Run the passes in this order:
    mark them unavailable, and add a material gap for every ineligible source
    and each affected claim. Do not create review briefs until the candidate
    manifest and ledger pair validates.
-4. profile-required `verify`, `adversary`, and `coverage` workers consume only
+4. Profile-required `verify`, `adversary`, and `coverage` workers consume only
    immutable selectively blind briefs created by
    `scripts/create-review-brief.mjs` at unique paths.
-5. `reconcile` writes a new candidate ledger without mutating the prior ledger.
+5. Evaluate each predeclared evidence condition only after its completed
+   predecessor artifacts exist. Record exactly one root-authored condition
+   outcome. A triggered `contradiction-resolution` wave runs once as an
+   `adversary` evidence assignment; a not-triggered or unresolved wave supplies
+   no artifact. Accepted failure, cancellation, timeout, or missing output never
+   authorizes replacement work.
+6. Standard and thorough execute exactly one terminal `reconciliation` wave,
+   mapped to `reconcile`, after required review evidence and any triggered
+   contradiction investigation. It writes a new candidate ledger without
+   mutating the prior ledger.
+
+If `reconciliation-needs-judgment` is foreseeable, select an adequate target
+for that one terminal wave before approval. If it appears after approval and
+the approved target is inadequate, preserve completed evidence and return an
+explicit unresolved, out-of-envelope gap for renewed approval or a new run.
+Never mutate the target, launch a second reconciliation, or substitute a
+contradiction search for synthesis.
 
 Use `references/worker-contract.md` for every assignment. Never allow two
 workers to share a write path. Every dossier records its approved wave and lane;
@@ -247,6 +306,10 @@ refer to a different canonical generation.
 Derive the achieved profile from complete, typed, digest-bound same-run
 artifacts written by approved lanes. Do not accept a worker or manifest
 assertion of achievement. A `quick` run can reach `supported` but never `verified`.
+Quick is deliberately an evidence packet for an intelligent consumer and has
+no independent semantic pass. Its consumer, not the packet, judges sufficiency
+and conclusions. Standard and thorough retain their independent typed semantic,
+adversarial, coverage, and single-terminal reconciliation requirements.
 `verified` claims require unique complete semantic, adversarial, and coverage
 results bound to immutable briefs and correct claim dispositions. Unresolved
 material challenge prevents verification. A run with contested claims may