@iowarp/clio-coder 0.3.6 → 0.3.8

package/docs/configuration-and-targets.md

@@ -1,7 +1,7 @@
 # Configuration, Targets, Runtimes, and Auth
 
 > [!TIP]
-> **Interactive Spec Available:** An interactive configuration validator, target resolver, and CLI command generator is located at [docs/html/configuration_blueprint.html](html/configuration_blueprint.html) (Version: 0.3.6).
+> **Interactive Spec Available:** An interactive configuration validator, target resolver, and CLI command generator is located at [docs/html/configuration_blueprint.html](html/configuration_blueprint.html) (Version: 0.3.8).
 
 Clio Coder is target-first: chat and fleet dispatch resolve through configured targets in `settings.yaml`, not through provider-specific ad hoc flags. Chat and print targets are HTTP and native engine-backed runtimes. Fleet dispatch can also target the sanctioned Claude Code subscription runtimes described below.
 
@@ -31,6 +31,8 @@ Default config file:
 
 Role contents: config holds user-authored files (settings, credentials, agents, skills, prompts, extensions, runtimes); data holds durable artifacts (memory, evidence, evals); state holds machine-produced session state (sessions, audit, receipts, runs.json, recent-models.json, install.json, interop.json, interviews, scratch); cache holds disposable derived files.
 
+The `library` settings block configures the private resource catalog. `library.catalog` is an optional path and defaults to `<configDir>/library.yaml`. `library.remote` is an optional git remote URL, and the catalog repository must name that git remote `library`. `library.sync` defaults to `false`, which makes sync and push refuse before spawning git. `library.confirmedRemote` is written by `clio-coder library remote confirm <url>` and must exactly match `library.remote` before sync or push can run. Confirmation sets both values when `library.remote` is unset and refuses a differing configured URL with `library_remote_mismatch`. See [resource-library.md](resource-library.md).
+
 `clio-coder paths --json` prints the resolved directories and is the single source of truth for scripts.
 
 ---
@@ -80,11 +82,16 @@ clio-coder configure \
   --id local-lmstudio \
   --runtime lmstudio \
   --url http://127.0.0.1:1234 \
-  --model your-model-id \
+  --model qwen3.8-27b \
   --set-orchestrator \
   --set-fleet-default
 ```
 
+`--model` must be an id the server advertises. `configure` fetches the
+server's model list and refuses an id that is not on it, printing the ids it
+found and which of them are loaded; `--force` saves the target anyway. Replace
+`qwen3.8-27b` with an id from `lms ls` (LM Studio) or your server's model list.
+
 Use the id you chose, probe it, then launch the TUI:
 
 ```bash
@@ -174,6 +181,17 @@ workers:
     model: your-model-id
     thinkingLevel: off
   profiles: {}
+  rosters:
+    design:
+      members:
+        - label: local-a
+          target: local-lmstudio
+          model: your-model-id
+          thinking: medium
+          color: accent
+        - label: local-b
+          target: local-vllm
+          color: "#5ba8ff"
   agentBindings: {}
   maxRetries: 2
   onPermission: deny
@@ -208,6 +226,11 @@ terminal:
   tuiMode: regular              # regular terminal scrollback or fullscreen sticky layout
   fullscreenScrollbar: auto    # hidden, auto, or always in fullscreen mode
   smoothStreaming: off         # off, conservative auto, or explicit on
+  notify: false                # content-free desktop notification, interactive TTY only
+watchdog:
+  enabled: false               # opt-in read-only review of every mutating turn
+  # target: local-lmstudio     # route the review at a cheap model
+  # cadenceToolCalls: 20       # also review every N tool calls inside a turn
 skills:
   trustProjectCompatRoots: false
 delegation:
@@ -467,7 +490,8 @@ The Settings Center organizes all configuration under four non-selectable group
 | **RUNTIME** | Budget (`budget`) | `budget.sessionCeilingUsd`, `defaults.maxTokens`, and `budget.concurrency` (restart required). |
 | **RUNTIME** | Compaction (`compaction`) | `compaction.auto`, `compaction.threshold`, and `compaction.excludeLastTurns`. |
 | **RUNTIME** | Retry (`retry`) | `retry.enabled`, `retry.maxRetries`, `retry.baseDelayMs`, and `retry.maxDelayMs`. |
-| **EXPERIENCE** | Terminal (`terminal`) | `terminal.showTerminalProgress`, `terminal.outputVerbosity` (`minimal`, `default`, `verbose`), `terminal.tuiMode` (`regular`, `fullscreen`), `terminal.fullscreenScrollbar` (`hidden`, `auto`, `always`), `terminal.smoothStreaming` (`off`, `auto`, `on`), and `theme`. |
+| **EXPERIENCE** | Terminal (`terminal`) | `terminal.showTerminalProgress`, `terminal.outputVerbosity` (`minimal`, `default`, `verbose`), `terminal.tuiMode` (`regular`, `fullscreen`), `terminal.fullscreenScrollbar` (`hidden`, `auto`, `always`), `terminal.smoothStreaming` (`off`, `auto`, `on`), `terminal.notify`, and `theme`. |
+| **EXPERIENCE** | Watchdog (`watchdog`) | `watchdog.enabled`, `watchdog.target`, and `watchdog.cadenceToolCalls`. The two optional keys are editable text rows that render their absence as `(session target)` and `(turn end only)`; submitting an empty value removes the key from `settings.yaml` rather than storing a blank. |
 | **EXPERIENCE** | Advanced (`advanced`) | `runtimePlugins`, `attribution.gitCommits`, `compaction.model`, `compaction.systemPrompt`, `delegation.defaults.connectTimeoutMs`, `delegation.defaults.turnTimeoutMs`, `delegation.defaults.permissionTimeoutMs`, `keybindings`, and `delegation.agents`. |
 
 `retry.streamStallMs` has no Settings Center row; edit it in `settings.yaml`.
@@ -517,6 +541,10 @@ Label to config path mapping:
 | TUI mode | `terminal.tuiMode` (`regular` or `fullscreen`, restart required) |
 | Fullscreen scrollbar | `terminal.fullscreenScrollbar` (`hidden`, `auto`, or `always`, restart required) |
 | Smooth streaming | `terminal.smoothStreaming` (`off`, `auto`, or `on`, live) |
+| Desktop notifications | `terminal.notify` |
+| Turn-end watchdog | `watchdog.enabled` |
+| Watchdog target | `watchdog.target` (blank clears the key) |
+| Watchdog cadence (tools) | `watchdog.cadenceToolCalls` (integer ≥ 1; blank clears the key) |
 | Theme | `theme` |
 | Runtime plugins | `runtimePlugins` |
 | Clio commit provenance | `attribution.gitCommits` (`enabled` or `disabled`, live) |
@@ -555,6 +583,15 @@ These are saved defaults, not a live control surface. See [Live routing vs saved
 
 ### Safety and worker policy
 
+`workers.rosters.<name>.members` defines council membership beside
+`workers.profiles`. Every member accepts `label`, `target`, and the optional
+keys `model`, `thinking`, and `color`. Labels must match
+`[a-z][a-z0-9_-]{0,31}` and must be unique inside the roster. A roster contains
+two to five members. Colors accept a theme token such as `accent`, `success`,
+or `reason`, or a six-digit hexadecimal value such as `#5ba8ff`. Unknown roster
+and member keys are rejected during configuration load. The existing settings
+watcher validates and publishes roster changes with every other hot reload.
+
 | Key | Default | Validation | When it applies |
 | --- | --- | --- | --- |
 | `autonomy` | `auto-edit` | `read-only`, `suggest`, `auto-edit`, `full-auto` | immediately |
@@ -564,8 +601,13 @@ These are saved defaults, not a live control surface. See [Live routing vs saved
 | `workers.maxRetries` | `2` | integer ≥ 0 | next dispatch |
 | `workers.resilienceCooldownMs` | `15000` | integer ≥ 0 | next dispatch |
 | `workers.profiles` | `{}` | map of profile name to a target/model/thinking choice | next dispatch |
+| `workers.rosters` | `{}` | map of roster name to 2 to 5 council members | next dispatch |
 | `workers.agentBindings` | `{}` | map of agent id to a key present in `workers.profiles` | next dispatch |
 | `skills.trustProjectCompatRoots` | `false` | boolean | restart |
+| `library.catalog` | `null` | string or null | immediately |
+| `library.remote` | `null` | string or null | immediately |
+| `library.confirmedRemote` | `null` | string or null | immediately |
+| `library.sync` | `false` | boolean | immediately |
 
 ### Git commit provenance
 
@@ -623,6 +665,34 @@ Generic provider and transport errors are classified by transient retry rules, i
 | `memory.intervention.maxTokens` | `400` | integer ≥ 1 | next turn |
 | `memory.intervention.timeoutMs` | `180000` | integer ≥ 1 | next turn |
 
+### Turn-end watchdog
+
+| Key | Default | Validation | When it applies |
+| --- | --- | --- | --- |
+| `watchdog.enabled` | `false` | boolean | immediately |
+| `watchdog.target` | unset | non-empty target id | immediately |
+| `watchdog.cadenceToolCalls` | unset | integer ≥ 1 | immediately |
+
+The watchdog is off by default because it spends one worker run per mutating
+turn. With `enabled: true`, a turn that changed the tree is handed to one
+read-only `verifier` run briefed with the turn's coalesced diff and the task
+board's current scope. Its blockers become one transcript notice naming the
+count and the first three failed checks, and nothing else: it never follows up,
+never queues a turn, and never mutates. A passing report emits nothing at all. A
+turn with no file mutations never fires it.
+
+`watchdog.target` routes the run at a named target, which is how a cheap local
+model reviews turns run on a subscription route; unset, the run takes the
+session's active target. `watchdog.cadenceToolCalls: N` additionally fires the
+watchdog after every N tool calls inside a turn, with the same diff-and-scope
+briefing, so mid-turn scope drift is visible before the turn ends. At most one
+watchdog run is in flight at a time; a trigger that arrives while one is running
+is dropped and counted rather than queued. Headless and ACP runs never fire the
+watchdog regardless of the setting, because neither has an operator reading a
+transcript. The block has its own Settings Center section under EXPERIENCE ›
+Watchdog; clearing the target or the cadence row removes that key from
+`settings.yaml` rather than writing an empty value.
+
 ### Delegation
 
 | Key | Default | Validation | When it applies |
@@ -645,10 +715,22 @@ Generic provider and transport errors are classified by transient retry rules, i
 | `terminal.tuiMode` | `regular` | `regular`, `fullscreen` | restart |
 | `terminal.fullscreenScrollbar` | `auto` | `hidden`, `auto`, `always` | restart |
 | `terminal.smoothStreaming` | `off` | `off`, `auto`, `on` | immediately |
+| `terminal.notify` | `false` | boolean | immediately |
 | `modelSelector.favorites` | `[]` | list of strings | immediately |
 | `modelSelector.recentLimit` | `12` | integer ≥ 1 | immediately |
 | `keybindings` | `{}` | map of binding id to a key string or list of them | restart |
 
+`terminal.notify` turns on a content-free desktop notification for the three
+moments an operator is waiting: a turn ends, a detached fleet batch settles, and
+a worker permission or `ask_user` request parks. The payload is fixed. The title
+is always `clio-coder` and the body comes from a closed vocabulary (`turn
+finished`, `batch <shortId> settled`, `approval needed`), so no prompt text, file
+path, or model output ever leaves the process in a notification. Clio emits OSC
+777 by default and OSC 9 on iTerm2, Windows Terminal, and ConEmu, never both for
+one event. Headless, ACP, and non-TTY runs never emit one regardless of the
+setting. The knob has a Settings Center row under EXPERIENCE › Terminal,
+labeled `Desktop notifications`.
+
 Recently selected models are runtime state and live in `recent-models.json` under the state directory, not here. A `state.recentModels` key in `settings.yaml` is an unknown-key error.
 
 ### Structural and catalog keys
@@ -691,7 +773,7 @@ clio-coder configure \
   --id local-llamacpp \
   --runtime llamacpp \
   --url http://127.0.0.1:8080 \
-  --model your-model-id \
+  --model qwen3.8-27b \
   --set-orchestrator \
   --set-fleet-default
 ```

package/docs/context-engine.md

@@ -1,7 +1,7 @@
 # Context Engine
 
 > [!TIP]
-> **Interactive Spec Available:** An interactive dashboard is located at [docs/html/context_blueprint.html](html/context_blueprint.html) (Version: 0.3.6).
+> **Interactive Spec Available:** An interactive dashboard is located at [docs/html/context_blueprint.html](html/context_blueprint.html) (Version: 0.3.8).
 
 Clio Coder tracks context pressure, records per-turn snapshots, and protects the provider context with bounded tool results plus single-threshold compaction.
 

package/docs/development-pipeline.md

@@ -80,7 +80,7 @@ New `area:*` labels are proposed in an issue, not created ad hoc.
 
 ## Milestones are releases
 
-Each open milestone is the next version (`v0.3.6`, `v0.4.0`). Triage means
+Each open milestone is the next version (`v0.3.7`, `v0.4.0`). Triage means
 assigning an issue to a milestone or explicitly leaving it in the backlog.
 A release cut requires every issue in its milestone to be closed
 or bumped; the milestone closes when the tag is published.

package/docs/dispatch-architecture-rationale.md

@@ -28,7 +28,7 @@ split would use. They cross them.
 | Write-boundary attribution is per scheduling *window*, so the compiler refuses a wave with two writers | scheduling, write boundaries, plan compilation | `execution-plan.ts`, `write-boundary.ts` |
 | A loop's later nodes are `unneeded`, decided by the scheduler, not the plan | plan compilation, scheduling, receipts | `fleet-plan.ts`, `execution-scheduler.ts` |
 | Staleness revalidation re-runs a verification a later workspace step invalidated | scheduling, plan compilation, code steps | `execution-scheduler.ts` |
-| Receipt integrity v15 seals normalized routing intent | routing, receipts | `receipt-integrity.ts`, `routing-intent.ts` |
+| Receipt integrity v16 seals normalized routing intent | routing, receipts | `receipt-integrity.ts`, `routing-intent.ts` |
 
 The write-boundary and loop rows are the sharpest. Both are properties of a
 *wave*, which is a scheduling concept computed by the plan compiler and enforced

package/docs/documentation-coverage.md

@@ -1,6 +1,6 @@
 # Clio Coder Documentation Coverage Matrix
 
-This matrix maps every top-level directory in `src/` and every domain directory under `src/domains/` to its authoritative documentation page. It records coverage status (`documented`, `partial`, `undocumented`), missing concepts, and key source contracts for `v0.3.6`.
+This matrix maps every top-level directory in `src/` and every domain directory under `src/domains/` to its authoritative documentation page. It records coverage status (`documented`, `partial`, `undocumented`), missing concepts, and key source contracts for `v0.3.7`.
 
 ## Coverage Matrix
 
@@ -19,7 +19,7 @@ This matrix maps every top-level directory in `src/` and every domain directory
 | `src/domains/components/` | Component scanning, snapshots, hashing, diffing | [middleware-and-components.md](middleware-and-components.md) | `documented` | Documented in active component snapshot and middleware guide. |
 | `src/domains/config/` | Configuration contracts, file watcher, keybinding definitions, setting classifiers | [configuration-and-targets.md](configuration-and-targets.md), [commands-and-modes.md](commands-and-modes.md) | `documented` | Documented in configuration targets and command/keybinding reference. |
 | `src/domains/context/` | `CLIO-CODER.md` bootstrap, codewiki generation, prompt context assembly, project rules, non-destructive working-set eviction (`age-horizon` and `structural-v1` policies, protection predicates, path index, byte-stable markers, recall by ref) | [context-engine.md](context-engine.md), [context-working-set.md](context-working-set.md) | `documented` | Context window, token accounting, and the three compaction mechanisms in the engine reference; the working-set layer has its own guide covering the vocabulary, both ledger record kinds and format v4, the marker contract, both policies with their rule order, recall semantics, and the operator surfaces. |
-| `src/domains/dispatch/` | Fleet orchestration, assignment store, batch tracker, admission, route planner, receipt integrity v15 | [fleet-dispatch.md](fleet-dispatch.md), [dispatch-architecture-rationale.md](dispatch-architecture-rationale.md), [worker-dispatch-mechanics.md](worker-dispatch-mechanics.md) | `documented` | Multi-node fleet dispatch, admission invariants, and receipt verification fully documented. |
+| `src/domains/dispatch/` | Fleet orchestration, assignment store, batch tracker, admission, route planner, receipt integrity v16 | [fleet-dispatch.md](fleet-dispatch.md), [dispatch-architecture-rationale.md](dispatch-architecture-rationale.md), [worker-dispatch-mechanics.md](worker-dispatch-mechanics.md) | `documented` | Multi-node fleet dispatch, admission invariants, and receipt verification fully documented. |
 | `src/domains/eval/` | Suite v2 YAML schema, eval runner, metrics, reporters, workspace sandboxing | [eval-runner.md](eval-runner.md), [evals-internal.md](evals-internal.md) | `documented` | Product evals are documented independently from external benchmarks. |
 | `src/domains/evidence/` | Evidence bundles, findings taxonomy, provenance store, failure attribution | [evidence-and-memory.md](evidence-and-memory.md) | `documented` | Documented in evidence directory structures and memory retrieval guide. |
 | `src/domains/evolution/` | Falsifiable Change Manifest JSON templates and `clio-coder evolve` self-edit gates | [evolution.md](evolution.md) | `documented` | Documented in evolution manifest reference and mutation validation rules. |
@@ -35,7 +35,7 @@ This matrix maps every top-level directory in `src/` and every domain directory
 | `src/domains/scheduling/` | Capacity lease acquisition, heartbeats, expiry, cross-process locks, cluster scheduling | [capacity-and-scheduling.md](capacity-and-scheduling.md), [fleet-dispatch.md](fleet-dispatch.md) | `documented` | Dedicated capacity leasing, heartbeat TTL, and cross-process lock reference. |
 | `src/domains/session/` | Session ledger format v4, tree branching (`/tree`), `/fork`, `/resume`, checkpoints, protected-artifact journal | [session-lifecycle.md](session-lifecycle.md), [context-working-set.md](context-working-set.md) | `documented` | Dedicated session lifecycle guide covering branching, journal, and recovery; the `contextEviction` and `contextRecall` records added at format v4 are specified in the working-set guide. |
 | `src/domains/share/` | Portable share archive bundles, manifest verification, import/export flows | [extensions-and-sharing.md](extensions-and-sharing.md) | `documented` | Share archives and portable bundle formats documented in extensions guide. |
-| `src/domains/webhook/` | Empty directory | None (Inert) | `inert` | Directory contains no active modules or exports in v0.3.6. |
+| `src/domains/webhook/` | Empty directory | None (Inert) | `inert` | Directory contains no active modules or exports in v0.3.7. |
 
 ## Cross-Cutting Reference Guides
 

package/docs/documentation-guide.md

@@ -1,7 +1,7 @@
 # Documentation Standards and Codebase Alignment
 
 > [!TIP]
-> **Interactive Spec Available:** An interactive documentation link linter, phrasing/claim evaluator, and alignment portal is located at [docs/html/documentation_blueprint.html](html/documentation_blueprint.html) (Version: 0.3.6).
+> **Interactive Spec Available:** An interactive documentation link linter, phrasing/claim evaluator, and alignment portal is located at [docs/html/documentation_blueprint.html](html/documentation_blueprint.html) (Version: 0.3.8).
 
 Clio Coder is an experimental community alpha. Documentation should help contributors and early users work from the source of truth without overstating maturity. When docs drift, prefer the current source and tests over older prose or aspirational roadmap notes.
 
@@ -46,10 +46,10 @@ Classify claims clearly:
 | [alcf-provider.md](alcf-provider.md) | `src/domains/providers/runtimes/cloud/alcf.ts`, `src/engine/alcf-oauth.ts` | Globus PKCE OAuth, openAuthStorage(), Sophia vLLM, Metis API, chatTemplateKwargsUnsupported. |
 | [environment-variables.md](environment-variables.md) | `src/core/guardrails.ts`, `src/core/xdg.ts`, `src/domains/providers/knowledge-base-path.ts` | Comprehensive env var matrix: guardrail overrides, directory layout (CLIO_CODER_HOME), debug toggles, and internal plumbing. |
 | [built-in-agents.md](built-in-agents.md) | `src/domains/agents/**`, `src/domains/agents/builtins/*.md`, `src/domains/dispatch/**` | Builtin agent recipes, discovery roots, frontmatter schema, fleet contract shadowing (`.clio-coder/fleets/<name>.md`), active route automation. |
-| [fleet-dispatch.md](fleet-dispatch.md) | `src/domains/dispatch/**` | Multi-node SSH dispatch: process-safe admission, capacity leases, Contract v4 write boundaries (detect-and-rollback), bounded check/repair loops (`loop_bound_exhausted`), deterministic code steps, attestation, receipts v15. |
+| [fleet-dispatch.md](fleet-dispatch.md) | `src/domains/dispatch/**` | Multi-node SSH dispatch: process-safe admission, capacity leases, Contract v4 write boundaries (detect-and-rollback), bounded check/repair loops (`loop_bound_exhausted`), deterministic code steps, attestation, receipts v16. |
 | [capacity-and-scheduling.md](capacity-and-scheduling.md) | `src/domains/scheduling/**`, `src/domains/dispatch/capacity-lease.ts`, `src/domains/dispatch/reservation-store.ts` | Multi-process capacity leases (`dispatch-admission.json`), heartbeat TTLs, cross-process transaction locks (`dispatch-admission.json.lock`), and cluster drain controls. |
 | [worker-dispatch-mechanics.md](worker-dispatch-mechanics.md) | `src/worker/**` | NDJSON parent-child socket protocols, control/bulk lane demuxing, watchdog timers, worker attestation (13 protocol fields), permission parking, exit codes. |
-| [fleet-demo-runbook.md](fleet-demo-runbook.md) | `src/domains/dispatch/**` | Multi-node fleet demo: SSH setup, C++ build/repair workflow, reviewer gates, receipt verification v15. |
+| [fleet-demo-runbook.md](fleet-demo-runbook.md) | `src/domains/dispatch/**` | Multi-node fleet demo: SSH setup, C++ build/repair workflow, reviewer gates, receipt verification v16. |
 | [session-lifecycle.md](session-lifecycle.md) | `src/engine/session.ts`, `src/domains/session/**` | Session lifecycle, on-disk ledger format v4 (`current.jsonl`), tree branching (`tree.json`), active-path lineage selection, `/fork`, `/resume`, checkpoints, and write-ahead protected-artifact journal. |
 | [acp.md](acp.md) | `src/engine/acp/**`, `src/cli/acp.ts` | Agent Client Protocol (ACP) server over stdio, tool mediation, non-stall permission handling, timeout bounds, and error taxonomy. |
 | [artifact-versions.md](artifact-versions.md) | `src/domains/dispatch/receipt-integrity.ts`, `src/engine/session.ts`, `src/worker/spec-contract.ts`, `src/domains/agents/fleet-contract.ts`, `src/domains/eval/schema/`, `src/domains/observability/trace-store.ts` | Version registry and migration policies for all 9 serialized artifact schemas across Clio Coder. |

package/docs/eval-runner.md

@@ -1,7 +1,7 @@
 # Clio Coder Local Evaluation Runner
 
 > [!TIP]
-> **Interactive Spec Available:** An interactive task suite validator, subprocess execution simulator, and compare calculator is located at [docs/html/eval_blueprint.html](html/eval_blueprint.html) (Version: 0.3.6).
+> **Interactive Spec Available:** An interactive task suite validator, subprocess execution simulator, and compare calculator is located at [docs/html/eval_blueprint.html](html/eval_blueprint.html) (Version: 0.3.8).
 
 The local evaluation runner executes repository-local YAML task suites as deterministic subprocess checks. It is useful for comparing harness changes, prompts, tools, or local workflows.
 

package/docs/evals-internal.md

@@ -1,7 +1,7 @@
 # Internal Eval Suites
 
 > [!TIP]
-> **Interactive Spec Available:** An interactive blueprint is available at [docs/html/evals_internal_blueprint.html](html/evals_internal_blueprint.html) (Version: 0.3.6).
+> **Interactive Spec Available:** An interactive blueprint is available at [docs/html/evals_internal_blueprint.html](html/evals_internal_blueprint.html) (Version: 0.3.8).
 
 Private suites should live outside this repository. Keep datasets, prompts,
 live fleet coordinates, calibration outputs, and raw run artifacts in a private

package/docs/evidence-and-memory.md

@@ -1,9 +1,9 @@
 # Evidence Corpus and Long-Term Memory
 
 > [!TIP]
-> **Interactive Spec Available:** An interactive memory lifecycle dashboard and simulator is located at [docs/html/memory_blueprint.html](html/memory_blueprint.html) (Version: 0.3.6). Use it to design, validate, and simulate memory proposals, approval loops, pruning rules, and token budgets.
+> **Interactive Spec Available:** An interactive memory lifecycle dashboard and simulator is located at [docs/html/memory_blueprint.html](html/memory_blueprint.html) (Version: 0.3.8). Use it to design, validate, and simulate memory proposals, approval loops, pruning rules, and token budgets.
 
-Clio Coder treats run claims and agent lessons as structured artifacts to support reproducibility and scientific provenance. In evaluations such as [SWE-bench](https://www.swebench.com), capturing granular execution evidence is essential for validating agent claims. Evidence corpora are deterministic directories built from run ledgers, receipts, sessions, audits, and eval artifacts. In v0.3.6, forensic evidence auto-builds on dispatch run completion: when a run finalizes, the observability domain automatically compiles the evidence bundle under `<dataDir>/evidence/run-<id>/` and updates a compact sidecar index row in `<stateDir>/evidence-index.json`. Long-term memory records are local, evidence-linked, and only injected after explicit approval. Use the TUI [`/view`](observability.md) command for interactive inspection of receipts, dispatch output, durable tool output, compaction summaries, and session accountability before building or citing evidence.
+Clio Coder treats run claims and agent lessons as structured artifacts to support reproducibility and scientific provenance. In evaluations such as [SWE-bench](https://www.swebench.com), capturing granular execution evidence is essential for validating agent claims. Evidence corpora are deterministic directories built from run ledgers, receipts, sessions, audits, and eval artifacts. In v0.3.7, forensic evidence auto-builds on dispatch run completion: when a run finalizes, the observability domain automatically compiles the evidence bundle under `<dataDir>/evidence/run-<id>/` and updates a compact sidecar index row in `<stateDir>/evidence-index.json`. Long-term memory records are local, evidence-linked, and only injected after explicit approval. Use the TUI [`/view`](observability.md) command for interactive inspection of receipts, dispatch output, durable tool output, compaction summaries, and session accountability before building or citing evidence.
 
 Source of truth: `src/domains/evidence/**`, `src/domains/memory/**`, `src/cli/evidence.ts`, and `src/cli/memory.ts`.
 
@@ -76,7 +76,7 @@ Eval evidence adds `eval-result.json` and uses empty receipt/protected-artifact
 
 Session ledger entries are attributed to a run by the run id the producer stamped on the entry at write time. Rows built from those entries carry that provenance in a `runLink` field (`{ kind, confidence, candidateRunIds? }`) in `tool-events.jsonl` and `protected-artifacts.json`; a write-time stamp is `kind: "entry-run-id"`, `confidence: "exact"`. Entries written without run context fall back to timestamp windowing, labeled `kind: "timestamp-window"`, `confidence: "best-effort"`, and printed as `link=timestamp-window` in the transcript. Concurrent dispatch runs share one clock and their windows overlap, so an entry inside more than one window has no owner the bundle can name. Such an entry is reported in the bundle of every run it may belong to, with `runId: null`, `kind: "ambiguous-timestamp-window"`, and a `candidateRunIds` list, plus a `best-effort-link` finding counting them. It is never dropped and never claimed as exact.
 
-When a run was chained (pipeline), composed with a persona override, or escalated for a permission, `transcript.md` and `trace.cleaned.jsonl` surface the receipt's provenance field sets, and `clio-coder evidence inspect` prints them as a `provenance <runId>:` block. The field paths, types, and stability labels are documented in the [receipt provenance schema](./observability.md#receipt-fields-for-dispatch-provenance).
+When a run was chained (pipeline), composed with a persona override, or escalated for a permission, `transcript.md` and `trace.cleaned.jsonl` surface the receipt's provenance field sets, and `clio-coder evidence inspect` prints them as a `provenance <runId>:` block. The block is the detail behind the canonical trust projection, never a second reading of it: it is printed only for a run whose seal the projection verified, its `autonomy:` line carries the policy name, external mode, and bypass flag and never the axis word (`mediated`, `approximated`, `bypassed` are the trust summary's to print), and a run whose seal was rejected or retired gets no block at all, so the output never publishes a value the projection reported as `absent`. The field paths, types, and stability labels are documented in the [receipt provenance schema](./observability.md#receipt-fields-for-dispatch-provenance).
 
 ### Task and decision provenance
 
@@ -106,6 +106,7 @@ Clio Coder classifies every run, session, and eval record using a closed set of
 | `blocked-tool` | Failure | The safety net blocked a tool call requested by the model. |
 | `escalation` | Precaution | A worker permission escalation timed out or was denied; see the receipt provenance schema below. |
 | `receipt-integrity` | Security | Forensic verification detected receipt modification or checksum mismatch. |
+| `receipt-retired` | Provenance | The receipt was sealed under an integrity version this build no longer verifies. It is not migrated and not read as evidence; the row names both versions. An info row, never the security warning a modified receipt gets. |
 | `protected-artifact`| Precaution | Mutating a path protected by project or system safety policies. |
 | `tool-loop` | Constraint | The model repeatedly called the same tool with identical arguments. |
 | `test-failure` | Failure | A verification command containing test/lint keywords exited non-zero. |
@@ -116,6 +117,9 @@ Clio Coder classifies every run, session, and eval record using a closed set of
 | `auth-failure` | Failure | Missing or invalid credentials/API keys. |
 | `external-bypass` | Security | An external runner bypassed standard safety gates. |
 | `external-approximation`| Validation | An external runner approximated results rather than fully executing. |
+| `independent-review` | Validation | The canonical independent-review axis: a failed, correlated, or inconclusive review is a warning; a successful run with no review at all is an info row saying its result rests on its own receipt. |
+| `context-provenance` | Provenance | The canonical context-provenance axis read `invalid`: the receipt's briefing or project-context record contradicts itself. |
+| `completion-evidence` | Validation | The canonical completion-evidence axis: a mutation that finished without validation evidence at the completion boundary is a warning; an explicit limitation is an info row. |
 | `unknown` | Undefined | Unclassified execution failure. |
 
 ---
@@ -148,11 +152,11 @@ Each run receipt (persisted under `<stateDir>/receipts/<runId>.json`) carries an
 ### Computation and Lifecycle
 - **Circular Dependency Prevention**: To prevent circular dependencies, `findingsSummary` is calculated **cheaply in-memory** at receipt-record time using the draft envelope and tool statistics (in `src/domains/dispatch/receipt-findings.ts`). It never reads from disk or calls `buildEvidence`.
 - **First-Pass Success**: Calculated as `true` only if the terminal outcome was `"succeeded"`, the lineage attempt was `0` (no dispatch retries), the tool stats confirm at least one successful validation tool was executed, and no failure-cause tags were detected.
-- **Cryptographic Coverage**: Current receipts use strict v15 and authenticate every current receipt field, including briefing and steering provenance, routing intent and decision, route quality, worker identity, execution role, and result-contract conformance, against the reconstructed ledger. Every version other than v15 is rejected; there is no historical receipt reader.
+- **Cryptographic Coverage**: Current receipts use strict v19 and authenticate every current receipt field, including briefing and steering provenance, routing intent and decision, route quality, worker identity, execution role, result-contract conformance, council provenance, and fleet gate provenance, against the reconstructed ledger. Every version other than v19 is rejected; there is no historical receipt reader.
 
 | Version | Verification policy | Compatibility policy |
 |---|---|---|
-| v15 | Current canonical projection; every current receipt and reconstructible ledger field is authenticated | Accepted |
+| v19 | Current canonical projection; every current receipt and reconstructible ledger field is authenticated | Accepted |
 | Any other version | No reader | Rejected; remove or archive the incompatible state rather than expecting migration |
 
 Receipt integrity and evidence verification answer different questions. The
@@ -207,11 +211,12 @@ They do not mutate receipt, gate-decision, evidence-bundle, or session formats.
 | Current receipt present but integrity not checked | Artifact integrity is `unknown`; the receipt's own digest never authenticates itself. The other receipt-owned axes are `absent` with `not_observed` until authentication succeeds. |
 | Historical receipt missing its integrity block | Receipt-owned axes are `unknown` through the compatibility source, even if a caller presents a contradictory positive verification result. |
 | Integrity verification succeeds or fails | Artifact integrity is `verified` or `failed`. A failure leaves the receipt-owned validation grounding, context provenance, and autonomy enforcement `absent`; no untrusted receipt claim contributes a positive state. Validation the session ledger observed on its own (a validation command that ran and exited 0) still grounds the run, so a tampered run can read `artifactIntegrity: failed` beside `validationGrounding: validated`. The two axes name different artifacts and different authorities, and the bundle's `receipt-integrity` finding is what flags the pairing. |
+| Receipt sealed under a retired integrity version | Artifact integrity is `unknown` through the compatibility source `run_receipt:<runId>:integrity-v<N>-retired`, which is where the human clause reads the version back from (`seal v19 retired (this build verifies v20)`); `failed` and "seal broken" are reserved for a seal this build checked and rejected. The receipt-owned axes are `absent` with `historical_format`, and the verdict is `unknown` rather than `compromised`. The receipt is not migrated and not read as evidence: the bundle records a `receipt-retired` info finding, `evidence build` prints it as a note and exits 0, and `/view verify` reports `verify retired` with both versions. |
 | Receipt `verification.state: verified` | Validation grounding is `validated` unless a stronger typed failure or ungrounded claim is present. |
 | Receipt `verification.state: unverified` | Validation grounding is `absent` with `not_observed`; lack of a validation tool is not a failed validation. |
 | Receipt verification `unknown` or `not_applicable` | Validation grounding preserves `unknown` or `not_applicable`. A missing historical verification field maps to `unknown`. |
 | Typed receipt validation or result-contract quality | A passing correctness-bearing fact maps to `validated`; a failing fact maps to `failed`; an ungrounded passing claim maps to `ungrounded`. |
-| Valid bounded project context or valid briefing hash | Context provenance is `recorded`. Explicit project-context tier `none` with no briefing is `not_applicable`; a missing historical field is `unknown`; a contradictory block is `invalid`. |
+| Valid bounded project context, valid none-tier workspace-root record, or valid briefing hash | Context provenance is `recorded`. A `none`-tier run still receives the workspace-root message, so a none-tier block naming exactly `workspace-root` with a well-formed count and hash is `recorded`. Explicit project-context tier `none` with no content and no briefing is `not_applicable`; a missing historical field is `unknown`; a contradictory block (a handbook section under a none policy, a hash with no section, a malformed count) is `invalid`. |
 | Gate decision | An authenticated independent pass or fail maps to `passed` or `failed`. Correlated review maps to `not_independent`. Unauthenticated artifacts map to `unknown`; operator or full-auto confirmation alone is `not_applicable` to independent review. |
 | Receipt autonomy grade | `mediated`, `approximated`, and `bypassed` map to `enforced`, `approximated`, and `bypassed`. A dangerous-bypass flag always normalizes to `bypassed`; a missing historical block is `unknown`. |
 | Finish-contract assessment | `validation_evidence`, `unvalidated_mutation`, `explicit_limitation`, and `no_mutation` map to `evidenced`, `incomplete`, `limited`, and `not_applicable`. A run whose receipt was presented and rejected downgrades `evidenced` to `unknown`: the row still points at its own record, but a rejected receipt authenticates nothing about the run it names. |
@@ -222,15 +227,74 @@ Receipt inspection, worker output, monitor details, and evidence rebuilding all
 use the same authenticated receipt projection boundary. Evidence rebuilding
 then composes independently authenticated gate decisions and exact
 finish-contract records without changing receipt-owned axes. Findings such as
-`no-validation`, `proxy-validation`, `external-approximation`, and
-`external-bypass` are selected from the canonical states, while their detailed
-domain artifacts remain in the receipt, gate, audit, and trace files.
+`no-validation`, `proxy-validation`, `external-approximation`,
+`external-bypass`, `independent-review`, `context-provenance`, and
+`completion-evidence` are selected from the canonical states, so every axis
+reaches `findings.md`, while their detailed domain artifacts remain in the
+receipt, gate, audit, and trace files.
 
 The canonical aggregate is an additive projection for downstream work. Receipt
-integrity remains version 15, evidence bundles remain version 1, gate decisions
+integrity remains version 18, evidence bundles remain version 1, gate decisions
 remain version 2, and no persisted receipt field or cryptographic algorithm
 changes.
 
+### Trust projection
+
+`src/domains/evidence/trust-projection.ts` is the one place the canonical
+status is turned into words. Every operator surface prints from it, so the
+same canonical input renders the same verdict on the dispatch run line, in a
+monitor block, under `clio-coder evidence inspect`, in `findings.md`, on the
+Alt+W board, in the `/view` receipt header, in eval metrics, and on the ACP
+wire.
+
+The compact human line has six fixed clauses in a fixed order and answers the
+four operator questions without receipt internals:
+
+```text
+trust v1: sealed; grounded by host-verification; not independently reviewed; mediated; context recorded; completion evidenced
+```
+
+| Clause | Axis | Question it answers |
+|---|---|---|
+| `sealed` / `seal broken` / `seal unchecked` / `no receipt` | Artifact integrity | Can the record be trusted to be what was written? |
+| `grounded by <claimant>` / `validation failed by <claimant>` / `inferred: validation claimed, none observed` / `no validation observed` / `validation unknown (<system>)` / `validation not applicable` | Validation grounding | Who claims the result, and what was observed? |
+| `independently reviewed: pass` / `independently reviewed: fail` / `independent review inconclusive` / `review not independent` / `not independently reviewed` | Independent review | What did a second, uncorrelated authority check? |
+| `mediated` / `approximated (<runtime>)` / `bypassed (<runtime>)` / `autonomy not recorded` | Autonomy enforcement | Did Clio's own gate mediate the run? |
+| `context recorded` / `context record invalid` / `context not recorded` | Context provenance | Is what the worker was given recorded consistently? |
+| `completion evidenced` / `completion unevidenced` / `completion limited` / `completion not applicable` | Completion evidence | What did the finish contract observe? |
+
+`mediated` is the word for the `enforced` state because it is what the
+receipt grade already says; `inferred` is the word for an `ungrounded` claim.
+Every `unknown` and `absent` state prints as such, so what remains unknown is
+part of the line, never an omission.
+
+The drill-down line prints every axis by its canonical state id and is the
+same on every text surface:
+
+```text
+trust_status=v1 artifactIntegrity:verified validationGrounding:validated independentReview:absent contextProvenance:recorded autonomyEnforcement:enforced completionEvidence:evidenced
+```
+
+The machine projection (`TrustSummaryProjection`, `trust` on the `dispatch`
+tool's `details.runs[]` entries and on the `monitor` receipt details) is
+bounded and versioned: the verdict tier, the six axis states, the claimant,
+the axes still unknown, the compact text, and up to 8 `<kind>:<id>`
+references into the detailed artifacts. It is flat by design so a depth-capped
+wire such as ACP `rawOutput` carries it whole where the nested canonical
+status's artifact references fall off the depth cap.
+
+The verdict tier styles a surface and never scores a run. `reviewed` is the
+only tier styled as independently verified; a sealed receipt with observed
+validation is `grounded`, a sealed receipt with nothing observed is
+`unverified`, a broken seal, bypassed gate, failed or inferred validation,
+failed or correlated review, or contradictory context record is
+`compromised`, and an unchecked or missing seal is `unknown`. The Alt+W board
+never carries a verdict on the terminal bus event: the event is published the
+moment the receipt is sealed, before anything has read it back and
+authenticated it against the ledger row, so the board reads the receipt file
+back and projects that authenticated status, and shows `trust: receipt not
+read back` until it can.
+
 ### Mutation-Report Grounding
 
 Mutation-report receipts are grounded directly against observed tool events recorded in the run ledger:

package/docs/evolution.md

@@ -1,7 +1,7 @@
 # Evolution and Change Manifests
 
 > [!TIP]
-> **Interactive Spec Available:** An interactive change manifest editor, authority risk assessor, and checklist workspace is located at [docs/html/evolution_blueprint.html](html/evolution_blueprint.html) (Version: 0.3.6).
+> **Interactive Spec Available:** An interactive change manifest editor, authority risk assessor, and checklist workspace is located at [docs/html/evolution_blueprint.html](html/evolution_blueprint.html) (Version: 0.3.8).
 
 Clio Coder uses change manifests to make harness changes reviewable, falsifiable, and rollback-friendly. CLIO stands for Context Layer for Input/Output, named for the Greek muse of history. A manifest is JSON, generated or checked with `clio-coder evolve manifest`, and should describe what changed, why, what evidence supports it, what could regress, how to validate it, and how to roll it back.
 

package/docs/exit-codes-and-output.md

@@ -1,6 +1,6 @@
 # Exit Codes & Machine-Readable Output Contracts
 
-This document specifies the process exit codes, machine-readable JSON streaming formats, standard I/O separation rules, and `--help` conventions across all Clio Coder CLI commands in `v0.3.6`.
+This document specifies the process exit codes, machine-readable JSON streaming formats, standard I/O separation rules, and `--help` conventions across all Clio Coder CLI commands in `v0.3.7`.
 
 Source implementations: `src/cli/` and `src/entry/`.
 
@@ -66,6 +66,9 @@ Many Clio CLI subcommands provide structured JSON output for integration with sc
 | `clio-coder targets` | `--json` | JSON object containing the configured `targets` array. |
 | `clio-coder models` | `--json` | JSON array of catalog models with capability flags. |
 | `clio-coder fleet status` | `--json` | JSON snapshot object with `generatedAt`, `admission` (`open` or `draining`), `running`, `retrying`, and `totals`. Each run row carries its `node`, defaulting to `local`. |
+| `clio-coder fleet validate` | `--json` | JSON report with `valid`, `fleet`, and either successful `checks` plus `planHash` or failure `diagnostics`. Validation failures exit `1`; usage errors exit `2`. |
+| `clio-coder fleet graph` | `--json` | JSON object with `fleet`, `planHash`, compiled `waves`, and expanded `loops`. Contract failures exit `1`; usage errors exit `2`. |
+| `clio-coder fleet run --resume` | `--json` | NDJSON step records include `status: "replayed"` and the original receipt reference for replayed prefix steps. Plan or variable mismatches exit `1`. |
 | `clio-coder trace runs` | `--json` | JSON array of trace run records. |
 | `clio-coder trace sql` | Positional query | JSON array of rows returned by the read-only SQLite query. A single `SELECT` or read-only `WITH` statement is accepted; multiple statements and mutating keywords are refused with exit code 2. |
 | `clio-coder paths` | `--json` | JSON object mapping platform directory names to absolute paths. |

package/docs/extensions-and-sharing.md

@@ -1,7 +1,7 @@
 # Extensions, Prompt Templates, Skills, and Share Archives
 
 > [!TIP]
-> **Interactive Spec Available:** An interactive dashboard is located at [docs/html/extensions_blueprint.html](html/extensions_blueprint.html) (Version: 0.3.6).
+> **Interactive Spec Available:** An interactive dashboard is located at [docs/html/extensions_blueprint.html](html/extensions_blueprint.html) (Version: 0.3.8).
 
 Clio Coder has lightweight community-oriented resource packaging. Extensions are filesystem bundles that contribute prompts and skills. Share archives are portable JSON files for moving project/user Clio resources between machines or collaborators. Themes are built into the engine and are no longer loaded from extensions.
 
@@ -251,7 +251,7 @@ Share archives are single JSON files:
   "formatVersion": 1,
   "manifest": {
     "format": "clio.share.v1",
-    "clioVersion": "0.3.6",
+    "clioVersion": "0.3.7",
     "createdAt": "...",
     "files": []
   },
@@ -280,6 +280,8 @@ Options:
 | `--skills` | Include skills. |
 | `--settings` | Include non-secret settings fragment. |
 | `--extensions` | Include extension bundle files, excluding extension `state.json`. |
+| `--agents` | Include agent recipe files. |
+| `--fleets` | Include fleet contract files. |
 | `--all` | Include every supported resource class. |
 
 If no include flags are supplied, export includes all supported classes for the selected scope.
@@ -296,6 +298,8 @@ clio-coder share import project.clio-coder-share.json --force
 
 Dry-run imports produce a plan and report conflicts without writing. Without `--force`, conflicting destination files block writes. With `--force`, conflicting files are overwritten and supported settings-fragment keys are merged into the current settings file.
 
+Archives accept `agent` and `fleet` file entry types alongside prompts and skills. Agent entries import into the user agent root and must pass the recipe parser and policy checks. Fleet entries import into the user fleet root and must pass `parseFleetContract` before any write. Dry-run plans report both types by kind.
+
 Aliases:
 
 ```bash

package/docs/fleet-demo-runbook.md

@@ -136,7 +136,7 @@ clio-coder evidence inspect <evidenceId>
 run ledger; a tampered or mismatched receipt fails the build with the field
 that diverged. The receipts of the remote runs verify on the orchestrator host because the
 ledger and receipts live on the shared filesystem. Current receipts use strict
-v15 and authenticate every current receipt and reconstructed-ledger field.
+v16 and authenticate every current receipt and reconstructed-ledger field.
 Every other receipt version is rejected rather than reported as partial; the
 current binary has no historical receipt reader.
 
@@ -168,7 +168,7 @@ reconstruct:
    complete receipt schema and its stable ledger row. `clio-coder evidence build
    --run <id>` recomputes and cross-checks it; `verifyReceiptIntegrity` in
    `src/domains/dispatch/receipt-integrity.ts` is the reference
-	implementation. Current receipts use v15 and every other version fails
+	implementation. Current receipts use v16 and every other version fails
 	verification. Incompatible state must be archived or removed; it is never
 	read as evidence through a compatibility verifier.