@open-agent-toolkit/cli 0.3.14 → 0.3.16

package/assets/NOTICES.md

@@ -154,3 +154,51 @@ LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
 OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
 SOFTWARE.
 ```
+
+## tkstang/skills
+
+**Source:** https://github.com/tkstang/skills/tree/main/skills/complexity-review
+**License:** MIT
+**Version referenced:** `complexity-review` 1.0.2 (commit `8767bce4819a2cae1a9f257de650a5ed0ae0afc1`)
+
+### `complexity-review` skill
+
+Source files: `skills/complexity-review/SKILL.md` and
+`skills/complexity-review/references/evidence-guide.md`.
+
+Passages adapted and condensed into `.agents/docs/complexity-review-fallback.md`:
+the core premise, contract restatement, simplest viable baseline, machinery
+inventory, deletion test, evidence and recommendation scales, ledger columns,
+verdict criteria, report sections, and reviewer stance. The OAT version adds
+the budget-exhaustion triggers, the installed-skill probe, the read-only
+dispatch contract, the REQUIRES-OPERATOR, open-finding, and disposition
+sections, and the decision-message record.
+
+Consumer OAT skills: `oat-project-implement`, `oat-project-quick-start`, and
+`oat-project-review-receive` (each vendors the doc under `references/docs/`).
+
+### Upstream MIT license
+
+```text
+MIT License
+
+Copyright (c) 2026 Thomas Stang
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.
+```

package/assets/bundle-metadata.json

@@ -1,4 +1,4 @@
 {
   "schemaVersion": 1,
-  "oatVersion": "0.3.14"
+  "oatVersion": "0.3.16"
 }

package/assets/docs/contributing/markdown-features.md

@@ -62,6 +62,44 @@ Fenced code blocks with `mermaid` are rendered as diagrams.
       A[Read docs tree] --> B[Generate index]
     ```
 
+Rendered Mermaid diagrams use the site palette. Click or tap one to open it
+full screen at a legible size; on a phone, pan to see the rest. Press Escape,
+the close button, or click again to close it.
+
+## Images and Diagram SVGs
+
+Every Markdown image opens in a zoom view when clicked. SVG images open full
+screen at a legible size, like Mermaid diagrams. Put images under
+`public/` and link them with a root-relative path such as
+`/diagrams/name.svg`; the site adds its base path.
+
+Name a pair of files `<name>-light.<ext>` and `<name>-dark.<ext>` to show one
+image per site theme. Place both images together; each is shown only in its
+theme.
+
+A diagram that needs to read well, especially on a phone, gets a hand-drawn SVG
+pair next to its Mermaid source. Mermaid stays the source of truth: when you
+change the Mermaid, update both SVGs in the same change.
+
+=== "Syntax"
+
+    ````text
+    === "Diagram"
+
+        ![What the diagram shows](/diagrams/name-light.svg)
+        ![What the diagram shows](/diagrams/name-dark.svg)
+
+    === "Mermaid source"
+
+        ```mermaid
+        flowchart LR
+          A[Read docs tree] --> B[Generate index]
+        ```
+    ````
+
+The alt text describes what the diagram shows and claims nothing the Mermaid
+does not.
+
 ## Tabs
 
 Tab groups use the existing tab transform syntax:

package/assets/docs/contributing/smoke-testing.md

@@ -22,19 +22,26 @@ outcome of any particular run.
 
 ## Data flow
 
-```mermaid
-flowchart TD
-  F["Fixture template\ntools/smoke/fixture/"] --> PRE["Preflight\ninstall + auth + fixture + local oat"]
-  PRE -->|blocked| STOP["Exit before provisioning"]
-  PRE -->|ready| PREP["Prepare / provision\ndisposable worktree + isolated config + manifest"]
-  PREP --> DRIVE["Drive\nper-harness protocol"]
-  DRIVE --> AUTO["Automated: runner launches provider"]
-  DRIVE --> OP["Operator: printed command + prompt"]
-  AUTO --> COLLECT["Collect\nevidence bundle + report"]
-  OP --> COLLECT
-  COLLECT --> CLEAN["Cleanup\nmanifest-scoped"]
-  COLLECT -.->|--keep| SKIP["Cleanup skipped"]
-```
+=== "Diagram"
+
+    ![Smoke-test flow: fixture template, preflight (exit before provisioning if blocked), prepare and provision, drive automatically or by an operator, collect evidence, then manifest-scoped cleanup, skipped with --keep](/diagrams/smoke-testing-light.svg)
+    ![Smoke-test flow: fixture template, preflight (exit before provisioning if blocked), prepare and provision, drive automatically or by an operator, collect evidence, then manifest-scoped cleanup, skipped with --keep](/diagrams/smoke-testing-dark.svg)
+
+=== "Mermaid source"
+
+    ```mermaid
+    flowchart TD
+      F["Fixture template\ntools/smoke/fixture/"] --> PRE["Preflight\ninstall + auth + fixture + local oat"]
+      PRE -->|blocked| STOP["Exit before provisioning"]
+      PRE -->|ready| PREP["Prepare / provision\ndisposable worktree + isolated config + manifest"]
+      PREP --> DRIVE["Drive\nper-harness protocol"]
+      DRIVE --> AUTO["Automated: runner launches provider"]
+      DRIVE --> OP["Operator: printed command + prompt"]
+      AUTO --> COLLECT["Collect\nevidence bundle + report"]
+      OP --> COLLECT
+      COLLECT --> CLEAN["Cleanup\nmanifest-scoped"]
+      COLLECT -.->|--keep| SKIP["Cleanup skipped"]
+    ```
 
 Collection runs even when the drive stage fails, so a broken run still produces
 an evidence bundle before cleanup reclaims its resources.

package/assets/docs/docs-tooling/workflows.md

@@ -66,25 +66,32 @@ skills.
 
 Diagram: bootstrap once, then analyze, approve and apply only agreed improvements.
 
-```mermaid
-flowchart TD
-  SETUP["Bootstrap once\nConfirm inputs, then oat docs init"]
-  MD["Markdown\nValidate files and config"]
-  APP["Docs app\nInstall and verify build"]
-  AN["Analyze\nRead docs, write findings"]
-  PLAN["Plan from findings\nNo docs writes yet"]
-  Q{"Approve changes?"}
-  APPLY["Apply approved items\nNew branch, verify, offer PR"]
-  STOP["Skip all\nNo docs changed"]
-  SETUP --> MD
-  SETUP --> APP
-  MD -.-> AN
-  APP -.-> AN
-  AN --> PLAN
-  PLAN --> Q
-  Q -->|"approved"| APPLY
-  Q -->|"all skipped"| STOP
-```
+=== "Diagram"
+
+    ![Bootstrap once with oat docs init into plain Markdown or a docs app, then analyze, plan, and either apply approved changes or stop when all are skipped](/diagrams/docs-workflows-light.svg)
+    ![Bootstrap once with oat docs init into plain Markdown or a docs app, then analyze, plan, and either apply approved changes or stop when all are skipped](/diagrams/docs-workflows-dark.svg)
+
+=== "Mermaid source"
+
+    ```mermaid
+    flowchart TD
+      SETUP["Bootstrap once\nConfirm inputs, then oat docs init"]
+      MD["Markdown\nValidate files and config"]
+      APP["Docs app\nInstall and verify build"]
+      AN["Analyze\nRead docs, write findings"]
+      PLAN["Plan from findings\nNo docs writes yet"]
+      Q{"Approve changes?"}
+      APPLY["Apply approved items\nNew branch, verify, offer PR"]
+      STOP["Skip all\nNo docs changed"]
+      SETUP --> MD
+      SETUP --> APP
+      MD -.-> AN
+      APP -.-> AN
+      AN --> PLAN
+      PLAN --> Q
+      Q -->|"approved"| APPLY
+      Q -->|"all skipped"| STOP
+    ```
 
 - **Setup, once.** `oat-docs-bootstrap` checks the repo without writing, asks
   you to confirm its inputs, then runs `oat docs init`. Plain Markdown setup validates authored files,

package/assets/docs/getting-started/concepts.md

@@ -9,17 +9,24 @@ OAT combines a provider-sync layer, reusable skills and CLI tooling, and an opti
 
 ## Choose What to Adopt
 
-```mermaid
-flowchart LR
-  GOAL["What do you\nneed first?"] --> SYNC["Align coding tools\nProvider Sync"]
-  GOAL --> SKILLS["Help with one task\nReusable Skills"]
-  GOAL --> WORK["Resume longer work\nWorkflows"]
-  GOAL --> DOCS["Maintain documentation\nMarkdown or a docs site"]
-  SYNC -.-> LATER["Add another path\nwhenever useful"]
-  SKILLS -.-> LATER
-  WORK -.-> LATER
-  DOCS -.-> LATER
-```
+=== "Diagram"
+
+    ![Four independent starting points: align coding tools with Provider Sync, help with one task with reusable skills, resume longer work with workflows, or maintain documentation; add another path whenever useful](/diagrams/adoption-paths-light.svg)
+    ![Four independent starting points: align coding tools with Provider Sync, help with one task with reusable skills, resume longer work with workflows, or maintain documentation; add another path whenever useful](/diagrams/adoption-paths-dark.svg)
+
+=== "Mermaid source"
+
+    ```mermaid
+    flowchart LR
+      GOAL["What do you\nneed first?"] --> SYNC["Align coding tools\nProvider Sync"]
+      GOAL --> SKILLS["Help with one task\nReusable Skills"]
+      GOAL --> WORK["Resume longer work\nWorkflows"]
+      GOAL --> DOCS["Maintain documentation\nMarkdown or a docs site"]
+      SYNC -.-> LATER["Add another path\nwhenever useful"]
+      SKILLS -.-> LATER
+      WORK -.-> LATER
+      DOCS -.-> LATER
+    ```
 
 - **Provider Sync:** `oat init --scope project`, choose providers, then `oat sync --scope project`.
 - **Reusable skills:** `oat tools install --scope user`; no repository initialization is needed.
@@ -36,16 +43,23 @@ Continue with [Provider Sync](../provider-sync/index.md), [Tool Packs](tool-pack
 
 OAT keeps canonical assets in repo-controlled locations and projects provider-specific views from that source of truth. The canonical form is what you edit and review directly; provider views are synchronized outputs that let Claude Code, Cursor, Copilot, Gemini, and Codex consume the same intent in their native layouts.
 
-```mermaid
-flowchart LR
-  SKILLS[".agents/skills/"] --> OAT["oat sync"]
-  AGENTS[".agents/agents/"] --> OAT
-  RULES[".agents/rules/"] --> OAT
-  OAT --> CLAUDE[".claude/"]
-  OAT --> CURSOR[".cursor/"]
-  OAT --> COPILOT[".github/"]
-  OAT --> CODEX[".codex/"]
-```
+=== "Diagram"
+
+    ![Canonical skills, agents and rules in .agents/ flow through oat sync into provider views under .claude/, .cursor/, .github/ and .codex/](/diagrams/provider-views-light.svg)
+    ![Canonical skills, agents and rules in .agents/ flow through oat sync into provider views under .claude/, .cursor/, .github/ and .codex/](/diagrams/provider-views-dark.svg)
+
+=== "Mermaid source"
+
+    ```mermaid
+    flowchart LR
+      SKILLS[".agents/skills/"] --> OAT["oat sync"]
+      AGENTS[".agents/agents/"] --> OAT
+      RULES[".agents/rules/"] --> OAT
+      OAT --> CLAUDE[".claude/"]
+      OAT --> CURSOR[".cursor/"]
+      OAT --> COPILOT[".github/"]
+      OAT --> CODEX[".codex/"]
+    ```
 
 Gemini CLI is a native read-only consumer; OAT does not generate a `.gemini/` view through sync.
 

package/assets/docs/provider-sync/commands.md

@@ -98,6 +98,27 @@ Key behavior:
   failures, but skew present — apply reports
   `Manifest version refreshed; no content changes required.` instead of
   `No changes required.`, so a manifest write is never described as a no-op.
+- A faithful copy-strategy entry whose manifest row records a stale
+  `contentHash` (a pre-framing legacy digest or a tampered value) is planned as
+  `skip` with the reason
+  `already in sync; restamp stale manifest content hash`, and `--json` plan
+  entries carry the verified digest as `restampContentHash`. Apply writes that
+  digest, so the next run is a no-op. Only a row that tracks the same provider
+  path that sync checked is restamped. Dry-run then reports
+  `Run without --dry-run to restamp N stale manifest content hashes.` instead
+  of `No changes to apply.`. Apply reports
+  `Manifest content hash restamped for N entries; no content changes required.`
+  (combined with the version-refresh sentence when both happen), or
+  `Manifest content hash restamped for N entries.` beside a partial failure.
+- A copy-strategy canonical skill directory without `SKILL.md`, or agent
+  directory without `AGENT.md`, is planned as an `error` operation whose reason
+  names the missing file, instead of a copy that never verifies and is retried
+  on every run. It changes nothing and is not a planned operation; other
+  entries still sync. Apply reports it as a failed result (`status: failed`
+  with a `failure` in `--json` `operationResults`) and exits 1. Dry-run lists
+  it, warns `N entry cannot sync until its configuration error is fixed.`,
+  counts it in `summary.failed`, and still exits 0. Symlink strategy is
+  unaffected.
 
 `oat sync` is not the only command that replaces a manifest's producer version.
 `oat init`, `oat remove skill`, and `oat status` each capture the manifest's

package/assets/docs/provider-sync/manifest-and-drift.md

@@ -15,23 +15,30 @@ This page explains how OAT remembers what it manages and how it distinguishes cl
 
 Diagram: canonical assets produce provider views and a manifest; status reports what changed and how to resolve it.
 
-```mermaid
-flowchart TD
-  CANON["Canonical assets\nEdit .agents/"]
-  SYNC["oat sync\nGenerate views"]
-  VIEWS["Provider views"]
-  MANIFEST["Sync manifest"]
-  STATUS["oat status\nInspect before resolving"]
-  TRACKED["Tracked views\nin_sync / drifted / missing"]
-  STRAY["Unmanaged files\nstray"]
-  CANON --> SYNC
-  SYNC --> VIEWS
-  SYNC --> MANIFEST
-  MANIFEST --> STATUS
-  VIEWS --> STATUS
-  STATUS --> TRACKED
-  STATUS --> STRAY
-```
+=== "Diagram"
+
+    ![You edit canonical assets in .agents/; oat sync generates provider views and the sync manifest; oat status reads both and reports tracked views as in_sync, drifted or missing, and unmanaged files as stray](/diagrams/sync-and-drift-light.svg)
+    ![You edit canonical assets in .agents/; oat sync generates provider views and the sync manifest; oat status reads both and reports tracked views as in_sync, drifted or missing, and unmanaged files as stray](/diagrams/sync-and-drift-dark.svg)
+
+=== "Mermaid source"
+
+    ```mermaid
+    flowchart TD
+      CANON["Canonical assets\nEdit .agents/"]
+      SYNC["oat sync\nGenerate views"]
+      VIEWS["Provider views"]
+      MANIFEST["Sync manifest"]
+      STATUS["oat status\nInspect before resolving"]
+      TRACKED["Tracked views\nin_sync / drifted / missing"]
+      STRAY["Unmanaged files\nstray"]
+      CANON --> SYNC
+      SYNC --> VIEWS
+      SYNC --> MANIFEST
+      MANIFEST --> STATUS
+      VIEWS --> STATUS
+      STATUS --> TRACKED
+      STATUS --> STRAY
+    ```
 
 - **What you edit.** Only the canonical files under `.agents/` (skills, agents,
   rules). `oat sync` reads them and writes provider views as symlinks or copies

package/assets/docs/reference/cli-reference.md

@@ -162,7 +162,7 @@ Notable commands introduced in the current CLI surface:
 - `oat project validate-plan --project-path <path>` - validates `oat_plan_parallel_groups` metadata in `plan.md`; exits non-zero on invalid. Lite plans must contain exactly one phase, declare no parallel groups, and give every Validation Criteria bullet either a backticked command or a `manual:` instruction. See [Implementation Execution](../workflows/projects/execution/implementation-execution.md#parallel-phase-groups).
 - `oat project log append|check|synthesize|rollup` - manage the optional append-only project observation log: append validated judgment or structural entries, inspect grammar and synthesis status, complete end-of-run synthesis, and roll observations into `summary.md` plus the configured repository ledger. See [Project Log](../workflows/projects/execution/project-log.md).
 - `oat project set-mode` — deprecated no-op. Execution mode is no longer user-selectable; emits a deprecation warning and preserves the `--json` contract.
-- `oat gate review <prompt...>` - run a stateful, headless OAT review through the target registry, parse the produced review artifact, and exit nonzero for configured blocking findings. `--timeout-ms <milliseconds>` overrides target, `workflow.gateTimeouts`, environment, and scope defaults; accepted values are 1,000–14,400,000. Final/phase/range code reviews default to 30 minutes, while task code and artifact reviews default to 15 minutes. With `--json`, the result envelope on exit is the canonical completion signal: `status` is `ok` | `blocked` | `review_failed` | `artifact_missing` | `artifact_validation_failed` | `targeting_correlation_failed`, alongside `runId`, `generatedAt`, and `artifactPath` when available. `artifact_missing` means an accepted child exited cleanly without an artifact; fix synchronous review/artifact completion and start a new run, without review-receive or same-run remediation. For `targeting_correlation_failed`, correct the project declaration or artifact routing and start a new run; do not run review-receive even if an artifact path is present. For `artifact_validation_failed`, correct the artifact and rerun the gate until it revalidates as `ok` or `blocked`. Invoke `oat-project-review-receive` only when all three conditions hold: `status` is `ok` or `blocked`, `receiveEligible` is `true`, and `handoff` is non-null. `review_failed` may include structured `refusal`, `noOutputProduced`, and metadata-only `activityEvidence`; these diagnostic fields never make a run receive-eligible. After a timeout, a validated run-correlated artifact returns the ordinary `ok` or `blocked` envelope with additive `lateCompletion: true`. When post-selection work fails after the reviewer already committed a run-correlated artifact, the gate re-validates that selected snapshot through the same eligibility path rather than re-parsing whatever the path now holds, never re-dispatching, and returns the ordinary `ok` or `blocked` envelope with additive `postSelectionRecovery: true`; the artifact must still be present and unchanged for re-validation to succeed. When nothing recovers, `review_failed` names the failing sub-step in `postSelection.step` and its cause in `postSelection.code`. Duplicate run-ID matches or a changed artifact with a mismatched run ID retain `targeting_correlation_failed` and `receiveEligible: false`. Orchestrators should read the structured result rather than poll the filesystem. See [Workflow Gates](../workflows/advanced/workflow-gates.md).
+- `oat gate review <prompt...>` - run a stateful, headless OAT review through the target registry, parse the produced review artifact, and exit nonzero for configured blocking findings. `--timeout-ms <milliseconds>` overrides target, `workflow.gateTimeouts`, environment, and scope defaults; accepted values are 1,000–14,400,000. Final/phase/range code reviews and artifact reviews default to 30 minutes, while task code reviews default to 15 minutes. With `--json`, the result envelope on exit is the canonical completion signal: `status` is `ok` | `blocked` | `review_failed` | `artifact_missing` | `artifact_validation_failed` | `targeting_correlation_failed`, alongside `runId`, `generatedAt`, and `artifactPath` when available. `artifact_missing` means an accepted child exited cleanly without an artifact; fix synchronous review/artifact completion and start a new run, without review-receive or same-run remediation. For `targeting_correlation_failed`, correct the project declaration or artifact routing and start a new run; do not run review-receive even if an artifact path is present. For `artifact_validation_failed`, correct the artifact and rerun the gate until it revalidates as `ok` or `blocked`. Invoke `oat-project-review-receive` only when all three conditions hold: `status` is `ok` or `blocked`, `receiveEligible` is `true`, and `handoff` is non-null. `review_failed` may include structured `refusal`, `noOutputProduced`, and metadata-only `activityEvidence`; these diagnostic fields never make a run receive-eligible. After a timeout, a validated run-correlated artifact returns the ordinary `ok` or `blocked` envelope with additive `lateCompletion: true`. When post-selection work fails after the reviewer already committed a run-correlated artifact, the gate re-validates that selected snapshot through the same eligibility path rather than re-parsing whatever the path now holds, never re-dispatching, and returns the ordinary `ok` or `blocked` envelope with additive `postSelectionRecovery: true`; the artifact must still be present and unchanged for re-validation to succeed. When nothing recovers, `review_failed` names the failing sub-step in `postSelection.step` and its cause in `postSelection.code`. Duplicate run-ID matches or a changed artifact with a mismatched run ID retain `targeting_correlation_failed` and `receiveEligible: false`. Orchestrators should read the structured result rather than poll the filesystem. See [Workflow Gates](../workflows/advanced/workflow-gates.md).
 - `oat gate route --expect-runtime <runtime> --expect-model <model> --can-await <true|false> --json` - return the headless child route (`inline`, `delegate-sync`, or `refuse`) from provider-marker and model evidence. Ambiguous or contradictory evidence never routes inline.
 - `oat gate exec <prompt...>` / `oat gate cross-provider-exec <prompt...>` - run a generic target prompt. `--timeout-ms` uses the same validated CLI override; untyped runs otherwise retain the legacy default path.
 - `oat gate target set <id> --invocation-model <model|provider-default> --invocation-reasoning-effort <effort|provider-default>` - persist optional configured invocation metadata alongside an exec target without inferring it from the target command.
@@ -203,6 +203,7 @@ The `workflow.*` namespace holds user-facing workflow preferences that let you a
 - `workflow.hillCheckpointDefault` (`every` | `final`) — default HiLL checkpoint behavior in `oat-project-implement`
 - `workflow.archiveOnComplete` (`boolean`) — skip the archive prompt in `oat-project-complete`
 - `workflow.createPrOnComplete` (`boolean`) — skip the "Open a PR?" prompt in `oat-project-complete`
+- `workflow.autonomousComplete` (`boolean`, default `false`) — standing opt-in for the non-interactive `oat-project-complete-auto` companion; when `false` it stops with "interactive completion required"
 - `workflow.postImplementSequence` (legacy `wait` | `summary` | `pr` | `docs-pr`, or structured `{preApproval, postApproval}` arrays) — approval-aware post-implementation chaining
 - `workflow.reviewExecutionModel` (`subagent` | `inline` | `fresh-session`) — default final-review execution model
 - `workflow.autoReviewAtHillCheckpoints` (`boolean`) — auto-run the extra lifecycle review at HiLL checkpoints

package/assets/docs/reference/configuration.md

@@ -272,7 +272,13 @@ packaged `assets/` directory next to the installed CLI. Setting a non-empty
   required bundle directory is empty in the packed tarball.
 - Produce a matching bundle with `bash packages/cli/scripts/bundle-assets.sh`
   while `OAT_ASSETS_DIR` points at the target directory (the script already
-  honors the variable as its destination).
+  honors the variable as its destination). Because publishing replaces the
+  destination, the script accepts an override destination only when it is
+  absent, an empty directory, or a previous bundle (a directory holding
+  `bundle-metadata.json`); it refuses anything else, including a directory it
+  cannot list. The default `packages/cli/assets` destination is exempt. The
+  script also stops before copying when an inventory lookup comes back empty,
+  absolute, climbing with `..`, or naming the repository root.
 
 This is primarily a test-isolation and packaging seam; day-to-day use of the CLI
 does not need it.
@@ -294,7 +300,7 @@ must be integer milliseconds from `1,000` through `14,400,000`.
   "workflow": {
     "gateTimeouts": {
       "code": 2400000,
-      "artifact": 900000
+      "artifact": 2400000
     },
     "gates": {
       "execTargets": {
@@ -712,6 +718,7 @@ Workflow preference keys live under the `workflow.*` namespace:
 - `workflow.hillCheckpointDefault` — `every` or `final`. Default HiLL checkpoint behavior in `oat-project-implement` (a HiLL, or human-in-the-loop, checkpoint is a stop for your review): pause after every phase or only after the last phase. When unset, the skill prompts. See [Choosing a checkpoint default](#choosing-a-checkpoint-default).
 - `workflow.archiveOnComplete` — boolean. Skip the "Archive after completion?" prompt in `oat-project-complete`. When unset, the skill prompts.
 - `workflow.createPrOnComplete` — boolean. Skip the "Open a PR?" prompt in `oat-project-complete`; when true, completion auto-triggers PR creation. When unset, the skill prompts.
+- `workflow.autonomousComplete` — boolean, default `false`. Standing opt-in for `oat-project-complete-auto`, the non-interactive completion companion that runs only when a workflow names it as a step (today `oat-wave-execute` closeout step 8 and the `oat-wave-program` completion checkpoint). Its `OAT_AUTONOMOUS` lifecycle route refuses until a lifecycle skill names the companion, and none does today. When `false`, the companion stops with "interactive completion required" and writes nothing. The interactive `oat-project-complete` is unaffected.
 - `workflow.postImplementSequence` — legacy `wait`, `summary`, `pr`, or `docs-pr`, or `{ "preApproval": [...], "postApproval": [...] }`. Legacy values remain strings and keep their existing mappings. Structured arrays contain ordered, globally unique `summary`, `document`, `pr`, and `retro` steps. `retro` is post-approval only: a structured value containing it in `preApproval` is rejected. Pre-approval steps run after final review and before final HiLL approval; post-approval steps run only after that approval. Plain retrieval keeps legacy strings and prints structured values as compact JSON; `--json` returns the raw value.
 - `workflow.retro.filing.repo` — `issues`, `backlog`, or `none`; unset by default. Selects the repo-lane filing destination.
 - `workflow.retro.filing.upstream` — `issues` or `none`; unset by default. Selects the upstream-lane filing destination.
@@ -889,6 +896,7 @@ Other preferences **depend on per-repo configuration** to be safe. These should
 - `workflow.archiveOnComplete` — correctness depends on the repo's `archive.s3Uri` / `archive.s3SyncOnComplete` being configured. A user-level `true` would try to archive in repos that aren't set up for it.
 - `workflow.postImplementSequence` — correctness depends on `documentation.requireForProjectCompletion`. Setting `pr` at user level would foot-gun you in any repo that requires docs, because completion would later block on the docs gate while the PR is already open.
 - `workflow.createPrOnComplete` — this key is almost always redundant with `postImplementSequence`-driven flows. When it's meaningful, its correctness depends on the same per-repo docs and PR gates. Prefer shared scope, or omit it entirely and rely on `postImplementSequence: pr` or `docs-pr` to handle PR creation at the end of implement.
+- `workflow.autonomousComplete` — authorizes unattended completion, which archives with the repo's `workflow.archiveOnComplete` and `archive.*` settings. It never creates a PR: it reads and reports `workflow.createPrOnComplete` without acting on it, and only updates the description of an already tracked PR. A user-level `true` would authorize autonomous completion in every repo, including ones whose archive settings were never chosen for it. Set it with `--shared` (or `--local` for one checkout) in each repo whose completion settings you have reviewed.
 
 **Cross-repo foot-gun example:** If you set `workflow.createPrOnComplete: true --user`, it applies to every repo you work on. In a repo with `documentation.requireForProjectCompletion: true` and `postImplementSequence: pr` (no docs step), running `oat-project-complete` would try to auto-create a PR, then immediately hit the docs gate and block you — leaving you with an open PR and a stuck completion. Your user-level preference silently asserted something that only holds in a specific shared-config shape.
 

package/assets/docs/reference/project-state-machine.md

@@ -15,26 +15,33 @@ This page is the compact contract for how project lifecycle state and review sta
 
 ## State Transition Map
 
-```mermaid
-flowchart TD
-  D["Discovery in progress"] --> RS["Ready for spec"]
-  RS --> S["Spec in progress"] --> RD["Ready for design"]
-  RD --> G["Design in progress"] --> RP["Ready for plan"]
-  RP --> P["Plan in progress"] --> RI["Ready for implement"]
-  RI --> I["Implement in progress"] --> IC["Implement complete"]
-  IC --> PRO["PR open (pr_open)"]
-  PRO --> REV["Revise (in_progress)"]
-  REV --> PRO
-  PRO --> C["Complete"]
-
-  I --> RV["Review received"]
-  RV --> FA["Fixes added"]
-  FA --> FC["Fixes completed"]
-  FC --> PASSED["Review passed"]
-  PASSED --> I
-
-  LITE["Lite: batched interview\n(no discovery/spec/design)"] -. entry point .-> P
-```
+=== "Diagram"
+
+    ![Project state machine: discovery, spec, design, plan and implementation phases, then PR open and complete; a review loop returns to implementation, a revise loop runs from PR open and back, and lite enters at planning](/diagrams/project-state-machine-light.svg)
+    ![Project state machine: discovery, spec, design, plan and implementation phases, then PR open and complete; a review loop returns to implementation, a revise loop runs from PR open and back, and lite enters at planning](/diagrams/project-state-machine-dark.svg)
+
+=== "Mermaid source"
+
+    ```mermaid
+    flowchart TD
+      D["Discovery in progress"] --> RS["Ready for spec"]
+      RS --> S["Spec in progress"] --> RD["Ready for design"]
+      RD --> G["Design in progress"] --> RP["Ready for plan"]
+      RP --> P["Plan in progress"] --> RI["Ready for implement"]
+      RI --> I["Implement in progress"] --> IC["Implement complete"]
+      IC --> PRO["PR open (pr_open)"]
+      PRO --> REV["Revise (in_progress)"]
+      REV --> PRO
+      PRO --> C["Complete"]
+
+      I --> RV["Review received"]
+      RV --> FA["Fixes added"]
+      FA --> FC["Fixes completed"]
+      FC --> PASSED["Review passed"]
+      PASSED --> I
+
+      LITE["Lite: batched interview\n(no discovery/spec/design)"] -. entry point .-> P
+    ```
 
 The solid chain is the spec-driven progression. Lite enters at **Plan in
 progress** and never sets `oat_phase` to `discovery`, `spec`, or `design`;

package/assets/docs/skills/index.md

@@ -145,6 +145,7 @@ for policy, storage, approval, and recovery details.
     - `oat-explainer-kit`
     - `oat-wrap-up`
     - `oat-project-complete`
+    - `oat-project-complete-auto`
     - `oat-wave-program`
     - `oat-wave-execute`
 

package/assets/docs/skills/recon.md

@@ -303,11 +303,14 @@ downgrades. Every claim a review kept below `verified` (an unresolved issue
 scoped to it or global to its review, a coverage finding that names it, or a
 non-affirming disposition) is listed under Review Downgrades with the review's
 own text, even when it is not a key claim, so a `complete` packet cannot hide a
-downgraded claim. A claim that a required review left without a disposition stays
-`unresolved`. Any claim below `verified` that an incorporated assurance review,
-core or thorough, listed in its brief but left without a disposition is listed
-there as not reviewed by that review; a claim outside a review's brief is never
-reported as its omission. A review's
+downgraded claim. The required reviews are semantic, adversarial, and coverage,
+plus redundant verification when the run achieves `thorough`; contradiction
+resolution is never required. A claim that any required review left without a
+disposition stays `unresolved`, so the run publishes an honest packet instead of
+failing validation. Any claim below `verified` that an incorporated assurance
+review, core or thorough, listed in its brief but left without a disposition is
+listed there as not reviewed by that review; a claim outside a required review's
+brief is listed as outside its brief, never as that review's omission. A review's
 `unresolvedIssues` entry may name the claim IDs it affects or apply to the
 whole review; a legacy plain-string entry is read as review-wide. A material
 coverage gap does not fail publication by itself: the claims it affects stay

package/assets/docs/workflows/advanced/autonomy.md

@@ -75,6 +75,16 @@ A boundary is a successful fail-closed outcome, not permission to continue with
 a guessed answer. The run reports what stopped, the evidence, and the operator
 action needed to resume.
 
+When a review or gate budget runs out (a review-cycle cap, the orchestration
+retry limit, or a gate's `maxAttempts`), the run first dispatches the
+[complexity review](../projects/reviews/index.md#complexity-review-at-budget-exhaustion)
+and includes its decision-message content in the boundary report. The run never
+selects the disposition, including **simplify**: the operator chooses when
+resuming. A quick-start plan gate outcome is persisted as
+`oat_quick_start_gate` (see
+[Gate approval records](workflow-gates.md#gate-approval-records)); a failed
+`prompt` gate is recorded as `blocked`, never as approved.
+
 The canonical autonomy contract and exhaustive gate inventory
 (`.agents/docs/autonomy-contract.md`, vendored into each consuming skill at
 `references/docs/autonomy-contract.md`) map each prompt to its autonomous

package/assets/docs/workflows/advanced/evidence-layers.md

@@ -19,21 +19,28 @@ never gates a conclusion on its own.
 
 ## Layer map
 
-```mermaid
-flowchart TD
-  L1["Layer 1 — Policy resolution\nnamed ceiling · candidates · capped/uncapped mode"]
-  L2["Layer 2 — Launcher-owned configured invocation\nroute · target/model/effort axes · selection reason ·\ncandidates considered · launch acceptance"]
-  L3["Layer 3 — Runtime-observed identity (optional)\nproducer + model, only under trusted provenance"]
+=== "Diagram"
 
-  L1 --> L2 --> L3
+    ![Three evidence layers: policy resolution, launcher-owned configured invocation, and optional runtime-observed identity; assertions check layers 1 and 2 and only record layer 3, which resolves to reported or not-reported](/diagrams/evidence-layers-light.svg)
+    ![Three evidence layers: policy resolution, launcher-owned configured invocation, and optional runtime-observed identity; assertions check layers 1 and 2 and only record layer 3, which resolves to reported or not-reported](/diagrams/evidence-layers-dark.svg)
 
-  A["Assertions"] -->|assert on| L1
-  A -->|assert on| L2
-  A -.->|record only| L3
+=== "Mermaid source"
 
-  L3 --> R["reported\n(both present + trusted provenance)"]
-  L3 --> NR["not-reported\n(anything else normalizes here)"]
-```
+    ```mermaid
+    flowchart TD
+      L1["Layer 1 — Policy resolution\nnamed ceiling · candidates · capped/uncapped mode"]
+      L2["Layer 2 — Launcher-owned configured invocation\nroute · target/model/effort axes · selection reason ·\ncandidates considered · launch acceptance"]
+      L3["Layer 3 — Runtime-observed identity (optional)\nproducer + model, only under trusted provenance"]
+
+      L1 --> L2 --> L3
+
+      A["Assertions"] -->|assert on| L1
+      A -->|assert on| L2
+      A -.->|record only| L3
+
+      L3 --> R["reported\n(both present + trusted provenance)"]
+      L3 --> NR["not-reported\n(anything else normalizes here)"]
+    ```
 
 Assertions bind to Layers 1 and 2. Layer 3 is recorded as `reported` or
 `not-reported`; its absence never invalidates Layer 2.