@open-agent-toolkit/cli 0.2.72 → 0.2.74

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/oat-project-summary/SKILL.md

@@ -5,7 +5,7 @@ disable-model-invocation: false
 user-invocable: true
 allowed-tools: Read, Write, Bash(git:*), Bash(jq:*), Bash(oat config:*), Bash(oat decision:*), Bash(oat pjm:*), Bash(oat project log:*), Bash(oat project push:*), Bash(oat project scope:*), Bash(oat tools:*), Glob, Grep, AskUserQuestion
 metadata:
-  version: 1.5.5
+  version: 1.5.6
 ---
 
 # Project Summary
@@ -258,21 +258,21 @@ spec, or design artifacts.
 
 **Non-lite section sources:**
 
-| Section                        | Primary Sources                                                                   |
-| ------------------------------ | --------------------------------------------------------------------------------- |
-| Overview                       | discovery.md initial request, spec.md problem statement                           |
-| What Was Implemented           | implementation.md task outcomes, plan.md phase structure                          |
-| Key Decisions                  | design.md decisions, implementation.md notes/decisions                            |
-| Design Deltas                  | implementation.md deviations table; review-received design drift notes            |
-| Notable Challenges             | implementation.md issues/blockers in task notes                                   |
-| Tradeoffs Made                 | implementation.md decisions, design.md tradeoff sections                          |
-| Integration Notes              | implementation.md notes about cross-cutting concerns                              |
-| Revision History               | plan.md p-revN phases, implementation.md revision notes                           |
-| Follow-up Items                | implementation.md deferred findings, plan.md deferred items                       |
-| Associated Issues              | state.md `associated_issues` field                                                |
-| Workflow Observations          | project-log.md via `oat project log rollup` only                                  |
-| Autonomous Execution Learnings | oat-execution-learnings.md dated entries                                          |
-| Explainer Outcome              | project-recap `manifest.json` and `build-record.json`, or the recorded recap skip |
+| Section                        | Primary Sources                                                                |
+| ------------------------------ | ------------------------------------------------------------------------------ |
+| Overview                       | discovery.md initial request, spec.md problem statement                        |
+| What Was Implemented           | implementation.md task outcomes, plan.md phase structure                       |
+| Key Decisions                  | design.md decisions, implementation.md notes/decisions                         |
+| Design Deltas                  | implementation.md deviations table; review-received design drift notes         |
+| Notable Challenges             | implementation.md issues/blockers in task notes                                |
+| Tradeoffs Made                 | implementation.md decisions, design.md tradeoff sections                       |
+| Integration Notes              | implementation.md notes about cross-cutting concerns                           |
+| Revision History               | plan.md p-revN phases, implementation.md revision notes                        |
+| Follow-up Items                | implementation.md deferred findings, plan.md deferred items                    |
+| Associated Issues              | state.md `associated_issues` field                                             |
+| Workflow Observations          | project-log.md via `oat project log rollup` only                               |
+| Autonomous Execution Learnings | oat-execution-learnings.md dated entries                                       |
+| Explainer Outcome              | project-recap `manifest.json` and `qa/result.json`, or the recorded recap skip |
 
 **Explainer Outcome (conditional):**
 
@@ -282,11 +282,11 @@ section with exactly one item. A run that happened uses the first form:
 ```markdown
 ## Explainer Outcome
 
-- **project-recap:** {generated | degraded} {outcome} — `{run path}`{optional warning or recovery note}
+- **project-recap:** {generated | generated — needs review | failed} — `{run path}`{optional reason or cause}
 ```
 
-A recap that never ran because a required seam was unavailable uses the second
-form, which has a reason and no run path:
+A recap that did not run because persisted intent records a skip uses the
+second form, which has a reason and no run path:
 
 ```markdown
 ## Explainer Outcome
@@ -294,11 +294,21 @@ form, which has a reason and no run path:
 - **project-recap:** skipped — {skip reason}
 ```
 
-Include exactly one concise item with its recipe, state (`generated`, `degraded`, or `skipped`), and either its outcome (`built-durable`, `built-not-durable`, `built-needs-review`, or `failed`) with run path, or its skip reason. Add a warning or recovery note when applicable. Use `generated` for `built-durable`, `degraded` for any other terminal outcome, and `skipped` only for a recap whose intent resolved to skip.
+Include exactly one concise item with its recipe and run path or skip reason:
 
-Use `manifest.json` and `build-record.json` as the source of truth for a run, and the recorded recap intent for a skip; refresh the existing item instead of appending a duplicate.
+- `generated` for manifest outcome `built`;
+- `generated — needs review` for `built-needs-review`, including the reason
+  from `qa/result.json`;
+- `failed` for `failed` or `incomplete`, including the sanitized cause; and
+- `skipped` only when persisted recap intent resolves to skip.
 
-Omit `Explainer Outcome` only when no project-recap attempt and no recorded recap skip exist. A degraded or skipped recap remains visible as its own product outcome; do not reinterpret either as project implementation failure. A `capability_probe` skip means the host had no provider configured for a required seam, not that the recap failed.
+Use `manifest.json` and `qa/result.json` as the source of truth for a run, and
+the persisted recap intent for a skip. Refresh the existing item instead of
+appending a duplicate.
+
+Omit `Explainer Outcome` only when no project-recap attempt and no persisted
+recap skip exist. A failed or skipped recap remains visible as its own product
+outcome; do not reinterpret it as project implementation failure.
 
 **Autonomous Execution Learnings (conditional):**
 
@@ -652,6 +662,6 @@ Summary tracks: last task {task_id}, {N} revision phases
   ledger graduation
 - When the PJM tool pack is available, each Key Decision is promoted to a canonical `reference/decisions/DR-YYMMDD-slug` record via `oat decision new` (status `accepted`), deduped on the date-independent slug so re-runs never create duplicate records
 - When the PJM tool pack is unavailable, decision promotion is skipped silently with no prompt
-- A project-recap attempt or recorded capability skip appears once in a concise
-  Explainer Outcome section sourced from its manifest and build record, or from
-  the recorded recap intent
+- A project-recap attempt or recorded skip appears once in a concise Explainer
+  Outcome section sourced from `manifest.json` and `qa/result.json`, or from the
+  persisted recap intent

package/assets/skills/oat-wave-execute/SKILL.md

@@ -6,7 +6,7 @@ disable-model-invocation: false
 user-invocable: true
 allowed-tools: Read, Write, Edit, Bash, Grep, Glob, Task
 metadata:
-  version: 1.9.3
+  version: 1.9.4
 ---
 
 # Execute a Wave of External Plans
@@ -460,41 +460,16 @@ archive anything first.
 
 #### Program-close recap explainer caller
 
-The orchestrator owns fact-base synthesis. At program close it synthesizes an
-`explainer-kit.fact-base/v1` document from the reconciled execution-program
-artifact, ALL wave summaries, and ALL completion records. Its required keys are
-exactly:
-`schemaVersion, generatedAt, mode, freshnessPolicy, sources, claims, unresolvedClaims, overrides`.
-
-The caller also owns CONTENT AUTHORING, exactly as it owns critic execution and
-fact-base synthesis: the kit validates structure and fact consistency, but
-nothing in it owns prose quality. Every recap run requires exactly one
-provider-neutral author seam — in-process callers supply an `author(request)`
-callback; JSON/CLI callers supply `authorModulePath` naming a module with an
-`author` function export. The core invokes it for every floor and accepted
-expansion artifact with `author-request/v2`: the artifact brief is inlined,
-the fact base is attached, and artistic requests include the resolved theme
-and hash-pinned shell. Authors may propose only recipe-declared expansion
-profiles and return `author-result/v2`; runs fail on absent or invalid author
-results or excessive verbatim source copying. Callbacks and module paths never
-enter persisted run requests.
-
-The mechanical caller constructs an `explainer-kit.run-request/v1` document whose
-required keys are exactly:
-`schemaVersion, recipe, slug, outputRoot, factBase, mode`. Set `recipe` to
-`{ "id": "program-recap", "version": "1" }`; this is an object with exactly
-`id` and `version`. Set `outputRoot` to
-`.oat/repo/reference/explainers/<slug>/`. Bind the
-synthesized fact-base file through `factBase` with the required keys
-`mode, freshnessPolicy`, set `mode` to `"supplied"`, set `freshnessPolicy` to
-`"live-wins"`, and set `path` to that file.
-
-After the run, read the `explainer-kit.manifest/v1` document. Its required keys
-are exactly:
-`schemaVersion, runId, slug, recipe, createdAt, source, theme, artifacts, immutableHashes, outcome, buildRecord, warnings`.
-Record the default program recap's manifest `runId` and `outcome` in the
-program ledger; use a wave ledger row only for an explicitly requested per-wave
-recap. Publishing is human-gated; this caller never invokes publish.
+At program close, invoke `oat-explainer-kit` § Generate with recipe
+`program-recap` over the reconciled execution-program artifact and the selected
+wave summaries and completion records. The adapter resolves approved inputs,
+theme, and the repository output root, then runs bundle, host-agent authoring,
+verification, and recording in unattended mode.
+
+Record the resulting manifest `runId` and `outcome` in the program ledger; use
+a wave ledger row only for an explicitly requested per-wave recap. If the flow
+fails before recording, preserve the sanitized cause and record the explicit
+retry or skip disposition.
 
 ## Success Criteria
 

package/assets/skills/oat-wave-program/SKILL.md

@@ -6,7 +6,7 @@ disable-model-invocation: false
 user-invocable: true
 allowed-tools: Read, Write, Edit, Bash, Grep, Glob, Task
 metadata:
-  version: 1.5.2
+  version: 1.5.3
 ---
 
 # Program a Corpus of External Plans into Waves
@@ -129,46 +129,22 @@ target (same disclaimer as the plan indexes).
    `SKILL.md` as a document until then, and flip every
    `completion tail: deferred to program close` ledger disposition to `done`. On
    no or defer, record the standing deferral and its owner in the program ledger.
-   This is the program completion gate and mirrors the recap publish gate; never
-   answer it autonomously or repeat it once per wave.
+   This is the program completion gate; never answer it autonomously or repeat
+   it once per wave.
 
 ### Program-close explainer caller
 
 At program close by default, or for a per-wave recap explicitly requested by the
-operator, the orchestrator owns fact-base synthesis. For the default program
-recap it synthesizes an `explainer-kit.fact-base/v1` document from the reconciled
-execution-program artifact, ALL wave summaries, and ALL completion records. Its
-required keys are exactly:
-`schemaVersion, generatedAt, mode, freshnessPolicy, sources, claims, unresolvedClaims, overrides`.
-
-The caller also owns CONTENT AUTHORING, exactly as it owns critic execution and
-fact-base synthesis: the kit validates structure and fact consistency, but
-nothing in it owns prose quality. Every recap run requires exactly one
-provider-neutral author seam — in-process callers supply an `author(request)`
-callback; JSON/CLI callers supply `authorModulePath` naming a module with an
-`author` function export. The core invokes it for every floor and accepted
-expansion artifact with `author-request/v2`: the artifact brief is inlined,
-the fact base is attached, and artistic requests include the resolved theme
-and hash-pinned shell. Authors may propose only recipe-declared expansion
-profiles and return `author-result/v2`; runs fail on absent or invalid author
-results or excessive verbatim source copying. Callbacks and module paths never
-enter persisted run requests.
-
-The mechanical caller constructs an `explainer-kit.run-request/v1` document whose
-required keys are exactly:
-`schemaVersion, recipe, slug, outputRoot, factBase, mode`. Set `recipe` to
-`{ "id": "program-recap", "version": "1" }`; this is an object with exactly
-`id` and `version`. Set `outputRoot` to
-`.oat/repo/reference/explainers/<slug>/`. Bind the
-synthesized fact-base file through `factBase` with the required keys
-`mode, freshnessPolicy`, set `mode` to `"supplied"`, set `freshnessPolicy` to
-`"live-wins"`, and set `path` to that file.
-
-After the run, read the `explainer-kit.manifest/v1` document. Its required keys
-are exactly:
-`schemaVersion, runId, slug, recipe, createdAt, source, theme, artifacts, immutableHashes, outcome, buildRecord, warnings`.
-Record the manifest's `runId` and `outcome` in the wave or program ledger row.
-Publishing is human-gated; this caller never invokes publish.
+operator, invoke `oat-explainer-kit` § Generate with recipe `program-recap`
+over the reconciled execution-program artifact and the selected wave summaries
+and completion records. The adapter resolves the approved inputs, theme, and
+repository output root, then runs bundle, host-agent authoring, verification,
+and recording in unattended mode.
+
+Record the resulting manifest `runId` and `outcome` in the program ledger. Use
+a wave ledger row only for an explicitly requested per-wave recap. If the flow
+fails before recording, preserve the sanitized cause and record the explicit
+retry or skip disposition.
 
 ## Integration with `oat-wave-execute`
 

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