@iowarp/clio-coder 0.3.2 → 0.3.4

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.2). 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.4). 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.2, 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.4, 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`.
 
@@ -48,6 +48,7 @@ Run/session evidence files:
 ├── audit-linked.jsonl
 ├── receipt.json
 ├── gate-decisions.json
+├── trust-status.json
 ├── protected-artifacts.json
 ├── findings.json
 └── findings.md
@@ -67,6 +68,7 @@ Eval evidence adds `eval-result.json` and uses empty receipt/protected-artifact
 | `audit-linked.jsonl` | Audit rows linked to run/session context when available. |
 | `receipt.json` | Receipt bundle (`{ version: 1, receipts: [...] }`); only receipts that pass integrity verification contribute verified fields. |
 | `gate-decisions.json` | Integrity-verified review verdicts, compete winner selections, and winner confirmations discovered from linked receipt ids. |
+| `trust-status.json` | Canonical per-run six-axis trust projections derived from authenticated receipts, gate decisions, grounded validation artifacts, and exact finish-contract audit rows. |
 | `protected-artifacts.json` | Protected artifact state/events. |
 | `findings.json` / `findings.md` | Structured and readable findings. |
 
@@ -159,6 +161,76 @@ whether applicable validation evidence was observed. Briefing provenance is
 also distinct from bounded project-context provenance: both can be absent or
 present independently, and neither hash is evidence for the other.
 
+### Canonical trust status
+
+`src/domains/evidence/trust-status.ts` defines the version 1 canonical trust
+status. It is a six-axis algebra, not an overall trust verdict, confidence
+percentage, or pass/fail score. Consumers project only the axes needed for a
+decision and preserve every other axis unchanged.
+
+| Axis | Closed states | Question answered |
+|---|---|---|
+| Artifact integrity | `verified`, `failed`, `absent`, `unknown`, `not_applicable` | Did the integrity verifier authenticate the referenced artifact? |
+| Validation grounding | `validated`, `failed`, `ungrounded`, `absent`, `unknown`, `not_applicable` | What correctness-bearing validation was observed and grounded? |
+| Independent review | `passed`, `failed`, `inconclusive`, `not_independent`, `absent`, `unknown`, `not_applicable` | What outcome did an authenticated independent reviewer or judge record? |
+| Context provenance | `recorded`, `invalid`, `absent`, `unknown`, `not_applicable` | Is the origin of briefing, project context, or linked evidence recorded consistently? |
+| Autonomy enforcement | `enforced`, `approximated`, `bypassed`, `absent`, `unknown`, `not_applicable` | How faithfully did the runtime enforce the selected authority? |
+| Completion evidence | `evidenced`, `incomplete`, `limited`, `absent`, `unknown`, `not_applicable` | What did the finish contract observe at the completion boundary? |
+
+`absent` means no fact was recorded and carries a reason but no invented
+attribution. `unknown` means a named source exists but cannot establish the
+answer. `not_applicable` means a named authority determined that the axis does
+not apply. Every non-absent state names both its source and its authority.
+Sources may retain up to 16 typed artifact references. References contain an
+artifact kind, identifier, and optional SHA-256 digest; they never embed the
+artifact body. Normalization sorts the references and rejects duplicates,
+unbounded lists, unknown fields, invalid identifiers, and sources that are not
+permitted to speak for an axis.
+
+The composition rules prohibit cross-axis promotion:
+
+- Verified artifact integrity never promotes validation grounding.
+- Recorded context provenance never promotes validation or correctness.
+- A passing review never establishes authorship or context origin.
+- Enforced autonomy never promotes completion evidence.
+- A completion self-report never promotes validation grounding. The linked
+  `completion_contract` audit row is the run's own report of what it did, so it
+  reaches completion evidence and no other axis. Validation grounding is filled
+  only by independently observed executions the session ledger recorded.
+
+The current adapters apply the following persisted-format compatibility rules.
+They do not mutate receipt, gate-decision, evidence-bundle, or session formats.
+
+| Existing persisted fact | Canonical mapping |
+|---|---|
+| Missing receipt | Every receipt-owned axis is `absent` with `artifact_missing`. |
+| 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 `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`. |
+| 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. |
+| Malformed audit row identifier | A blank or whitespace-only optional identifier is treated as absent. The row falls back to its derived correlation id or drops out of the trust projection; it never aborts the bundle. |
+| Bundle without `trust-status.json` | Inspection reports `projection: historical_format` with no canonical run projections. It never reconstructs positive states from older summary tags. |
+
+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.
+
+The canonical aggregate is an additive projection for downstream work. Receipt
+integrity remains version 15, evidence bundles remain version 1, gate decisions
+remain version 2, and no persisted receipt field or cryptographic algorithm
+changes.
+
 ### 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.2).
+> **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.4).
 
 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.2`.
+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.4`.
 
 Source implementations: `src/cli/` and `src/entry/`.
 

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.2).
+> **Interactive Spec Available:** An interactive dashboard is located at [docs/html/extensions_blueprint.html](html/extensions_blueprint.html) (Version: 0.3.4).
 
 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.2",
+    "clioVersion": "0.3.4",
     "createdAt": "...",
     "files": []
   },

package/docs/fleet-dispatch.md

@@ -1,6 +1,6 @@
 # Fleet Dispatch
 
-> **Interactive Spec Available:** An interactive fleet node topology planner, scout router, receipt verifier, and failure taxonomy simulator is located at [docs/html/fleet_dispatch_blueprint.html](html/fleet_dispatch_blueprint.html) (Version: 0.3.2).
+> **Interactive Spec Available:** An interactive fleet node topology planner, scout router, receipt verifier, and failure taxonomy simulator is located at [docs/html/fleet_dispatch_blueprint.html](html/fleet_dispatch_blueprint.html) (Version: 0.3.4).
 
 Clio Coder dispatches bounded worker agents. With a fleet configured, those
 workers run on remote machines over SSH while the orchestrator keeps every
@@ -579,6 +579,19 @@ basis unknown/not applicable). A read-only Scout can therefore report `receipt_i
 bounded `project_context` provenance are also rendered independently; neither
 hash substitutes for the other.
 
+The canonical terminology for these facts is the six-axis trust status in
+[`evidence-and-memory.md`](evidence-and-memory.md#canonical-trust-status).
+Receipt integrity projects onto artifact integrity; receipt verification,
+typed quality, and validation grounding project onto validation grounding;
+gate decisions project onto independent review; briefing and project context
+project onto context provenance; and `autonomyEnforcement` projects onto
+autonomy enforcement. A receipt does not contain independent-review or
+completion-evidence outcomes merely because it is sealed. Those axes remain
+`absent` until an authenticated gate artifact or finish assessment is composed.
+In particular, verified integrity cannot validate claims, known provenance
+cannot establish correctness, and a review verdict cannot establish
+authorship.
+
 Gate references point backward: a reviewer references the builder it
 reviewed, a revise builder references the reviewer whose findings it
 received, and a judge references every candidate. Because a worker receipt
@@ -682,11 +695,13 @@ After `npm run build`, an operator with a configured model target can run the
 single-turn, read-only fleet lifecycle check explicitly:
 
 ```bash
-CLIO_CODER_LIVE_EVAL=1 npm run test:live-eval:fleet-dispatch
+npm run live:fleet-dispatch -- --target <id> [--model <wireId>] [--thinking medium]
 ```
 
-It is not part of deterministic CI. The script copies the repository into an
-isolated committed workspace, sandboxes all Clio config/state/data/cache,
-exercises Scout, bounded spot-checking, detached Debugger briefing, steering,
-wait, and collect, and fails if any workspace content changes. Failures retain
-their isolated artifacts for diagnosis.
+It is not part of deterministic CI. The driver
+(`benchmarks/internal/live-fleet-dispatch.ts`) copies the repository into a
+committed temporary workspace, sandboxes all Clio config, state, data, and
+cache under a scratch home holding only the chosen target, exercises Scout,
+bounded spot-checking, detached Debugger briefing, steering, wait, and
+collect, and fails if any workspace content changes. A failed run retains its
+scratch tree for diagnosis.

package/docs/glossary.md

@@ -1,6 +1,6 @@
 # Clio Coder Glossary
 
-This document defines core architectural concepts and terminology used throughout Clio Coder, mapped to their authoritative TypeScript type definitions in `src/`.
+This document defines the 45 core architectural concepts and terminology used throughout Clio Coder, mapped to their authoritative TypeScript type definitions in `src/`.
 
 ---
 
@@ -165,3 +165,23 @@ This document defines core architectural concepts and terminology used throughou
 ### 40. Delegate
 - **Definition**: Another coding agent Clio drives over ACP stdio as if it were a worker, configured under `delegation.agents` and invoked with `/delegate`. A delegate is a foreign harness, not a model target.
 - **Owning Type**: `DelegationAgentConfig` in `src/core/defaults.ts`.
+
+### 41. Working Set
+- **Definition**: The part of the session ledger the model receives on the next request. It is the ledger with the current eviction projection applied, and it exists only in memory; the ledger itself is never narrowed. Not to be confused with the context ledger, which is the accounting of how the window is spent.
+- **Owning Type**: `WorkingSetView` in `src/domains/context/working-set/contract.ts`.
+
+### 42. Projection
+- **Definition**: The pure, idempotent transform from ledger entries to the entries the replay builder hands the model. It substitutes markers for evicted bodies and drops thinking from closed turns, returning unaffected entries by reference. Nothing about it is persisted.
+- **Owning Type**: `projectWorkingSet` in `src/domains/context/working-set/project.ts`.
+
+### 43. Eviction
+- **Definition**: The decision that a tool-result body or an assistant turn's thinking leaves the working set, recorded as an append-only ledger entry with a typed reason. It removes nothing: the original entry stays in the ledger and stays visible in the transcript, `/resume`, `/fork`, and the HTML export.
+- **Owning Type**: `ContextEvictionEntry` in `src/domains/session/entries.ts`.
+
+### 44. Recall
+- **Definition**: Readmitting an evicted body by ref, through `context(scope="recall", ref=...)` for the model or `/context recall <ref>` for the operator. A recall does not un-evict: the marker stays where it was so the provider prefix cache is untouched, and repeated recalls of one ref are the churn signal.
+- **Owning Type**: `ContextRecallEntry` in `src/domains/session/entries.ts`; resolution in `resolveRecall` in `src/domains/context/working-set/recall.ts`.
+
+### 45. Marker
+- **Definition**: The byte-stable one-line stub the projection renders in place of an evicted body, naming the ref, the reason, the tool, the size, and the exact recall call. It carries no timestamp and no counter, because a marker whose bytes drifted between renders would cold-start the prefix cache on a turn that evicted nothing new.
+- **Owning Type**: `renderMarker` in `src/domains/context/working-set/marker.ts`.

package/docs/installation-and-lifecycle.md

@@ -3,7 +3,7 @@
 Clio Coder is designed to be self-contained and platform-compliant. This document outlines the default directory paths, file purposes, permission levels, and lifecycle commands (`install`, `reset`, `upgrade`, and `uninstall`). Clio Coder installs from npm as `@iowarp/clio-coder` (`npm install -g @iowarp/clio-coder`, published since v0.3.0) or from a source checkout with a deterministic local symlink; the CLI classifies both install kinds and `clio-coder upgrade` handles each.
 
 > [!TIP]
-> **Interactive Spec Available:** An interactive dashboard with a path simulator and visual flowcharts is located at [docs/html/lifecycle_blueprint.html](html/lifecycle_blueprint.html) (Version: 0.3.2). You can open it directly in any web browser to view details dynamically.
+> **Interactive Spec Available:** An interactive dashboard with a path simulator and visual flowcharts is located at [docs/html/lifecycle_blueprint.html](html/lifecycle_blueprint.html) (Version: 0.3.4). You can open it directly in any web browser to view details dynamically.
 
 ---
 
@@ -221,25 +221,25 @@ next `clio-coder` launch refreshes it. `install.json` then reads
 `upgradedFrom: "0.3.0"`; doctor's row becomes
 `0.3.1 (installed ..., upgraded ... from 0.3.0)`.
 
-#### Upgrading to 0.3.2
+#### Upgrading to 0.3.3
 
-Upgrading from 0.3.1 to 0.3.2 is automated:
+Upgrading from 0.3.1 to 0.3.3 is automated:
 
 ```bash
 clio-coder upgrade
 ```
 
-Key lifecycle and operational updates in v0.3.2:
+Key lifecycle and operational updates in v0.3.4:
 - Upgraded the underlying engine SDK libraries to 0.84.0 with signal-aware OAuth cancellation.
 - Hardened migration resilience: damaged `credentials.yaml` files no longer block upgrades when no renames are needed (#121); `--skip-migrations` is available as a recovery override.
-- Fullscreen TUI mode (`terminal.tuiMode`, `terminal.fullscreenScrollbar`) is available via Settings → Terminal (restart required). Adaptive presentation pacing is the live `terminal.smoothStreaming` setting; 0.3.2 defaults it to `off`, with conservative `auto` and explicit `on` available from the same section.
+- Fullscreen TUI mode (`terminal.tuiMode`, `terminal.fullscreenScrollbar`) is available via Settings → Terminal (restart required). Adaptive presentation pacing is the live `terminal.smoothStreaming` setting; 0.3.3 defaults it to `off`, with conservative `auto` and explicit `on` available from the same section.
 - Interactive launch paints a measured Stage 0 shell on the same terminal and editor that Stage 1 hydrates. Typing, queued submits, resize, and Ctrl+C remain live during hydration; set `CLIO_CODER_INSTANT_SHELL=0` for the legacy fully hydrated first-frame path.
 - Turn settlement is enforced on `/new`, `/resume`, `/tree`, and `/fork` to cleanly commit in-flight streams before session writer replacement (#114).
 - Resumed and forked session entry replays standardize message prefixes through `src/engine/messages.ts`.
 - `AI_AGENT=clio-coder` is set on all child processes for system attribution.
 
 The first interactive launch after upgrading shows the version notice:
-`clio: upgraded 0.3.1 → 0.3.2. What changed at the keyboard: ...`
+`clio: upgraded 0.3.1 → 0.3.3. What changed at the keyboard: ...`
 Recorded once per version in `install.json` as `noticedVersion`.
 
 ### C. System Resets (`clio-coder reset`)

package/docs/middleware-and-components.md

@@ -1,7 +1,7 @@
 # Middleware and Component Registry
 
 > [!TIP]
-> **Interactive Spec Available:** An interactive dashboard with an interactive component scanner and a dynamic hook-and-effect pipeline is located at [docs/html/middleware_blueprint.html](html/middleware_blueprint.html) (Version: 0.3.2).
+> **Interactive Spec Available:** An interactive dashboard with an interactive component scanner and a dynamic hook-and-effect pipeline is located at [docs/html/middleware_blueprint.html](html/middleware_blueprint.html) (Version: 0.3.4).
 
 Clio Coder has two related but separate surfaces:
 

package/docs/model-catalog.md

@@ -1,7 +1,7 @@
 # Model Catalog, Runtime Refresh, and Field Notes
 
 > [!TIP]
-> **Interactive Spec Available:** An interactive dashboard mapping capabilities, probe discovery, and target resolution is located at [docs/html/models_blueprint.html](html/models_blueprint.html) (Version: 0.3.2).
+> **Interactive Spec Available:** An interactive dashboard mapping capabilities, probe discovery, and target resolution is located at [docs/html/models_blueprint.html](html/models_blueprint.html) (Version: 0.3.4).
 
 Clio Coder treats a selectable model as the intersection of three sources:
 
@@ -39,14 +39,12 @@ worker spec and receipt are written.
 
 ## Benchmarking Models
 
-Model and config benchmark adapters ship under [benchmarks/community/](../benchmarks/community/). These adapters (such as `bench:swe`, `bench:scicode`, and the fleet benchmark `bench:tb`) drive Clio through the CLI or `clio-coder eval`. 
-
-For example, to run the fleet benchmark:
-```sh
-npm run bench:tb -- --limit 3
-```
-
-The benchmarks record context-window, thinking, sampling, weight quantization, and KV-cache settings so sweeps can be compared consistently.
+The public benchmark adapters under [benchmarks/community/](../benchmarks/community/)
+(SWE-bench Lite, Terminal-Bench, SciCode, HumanEval) drive Clio through
+`clio-coder run --json` or `clio-coder eval run`, each taking `--target` and
+`--model` from the configured targets. `benchmarks/README.md` has the
+commands. The run manifests record the target profile (runtime, model,
+thinking level) so sweeps can be compared consistently.
 
 ## What "sanctioned" means
 

package/docs/observability.md

@@ -1,7 +1,7 @@
 # Observability Viewer
 
 > [!TIP]
-> **Interactive Spec Available:** An interactive dashboard is located at [docs/html/observability_blueprint.html](html/observability_blueprint.html) (Version: 0.3.2).
+> **Interactive Spec Available:** An interactive dashboard is located at [docs/html/observability_blueprint.html](html/observability_blueprint.html) (Version: 0.3.4).
 
 `/view` is the interactive artifact viewer for a Clio session. It keeps the live transcript compact while preserving a full inspection path for durable artifacts, task ledgers, and successful workspace outputs.
 
@@ -69,7 +69,7 @@ Clio resolves directories under platform-specific XDG defaults (on Linux, these
 | **Dispatch outputs** | Logs and ledger records detailing worker execution. | `<stateDir>/runs.json` and `<stateDir>/receipts/<runId>.json` |
 | **Task ledgers** | Per-turn task-board goals, active runs, required validation evidence, and operator-task provenance when present. | `<stateDir>/sessions/<cwdHash>/<sessionId>/current.jsonl` |
 | **Workspace outputs** | Latest successful `artifact`, `write`, or `edit` result for each normalized path on the active session branch. Missing files remain visible as durable recorded facts. | Recorded path beneath the session metadata `cwd` |
-| **Tool outputs** | Offloaded large outputs or execution logs. | `<stateDir>/scratch/<sessionId>/<toolCallId>.txt` |
+| **Tool outputs** | Offloaded large outputs or execution logs. | `<stateDir>/scratch/<sessionId>/<sha256 of the captured text>.txt` |
 | **Protected artifacts** | Validation-protected artifact metadata and its absolute artifact path when available. | Session ledger record plus the protected workspace path |
 | **Compaction** | Summaries of compacted history sessions. | `<stateDir>/sessions/<cwdHash>/<sessionId>/current.jsonl` |
 | **Prompt manifests** | One validated record per prompt compile: `systemPromptHash`, previous hash, token estimate, thinking dial at compile time, per-section token estimates, and per-fragment content hashes. Identifies the exact compiled prompt and supports hash diffs without storing prompt text. Malformed records appear as an explicit read-error artifact. | `<stateDir>/sessions/<cwdHash>/<sessionId>/prompt-manifest.jsonl` |
@@ -159,8 +159,8 @@ The base provenance sets, steering, routing, quality, worker identity, and resul
 | `safety.toolTelemetry.ingestionErrors` | `number` | Current dispatch receipts | Malformed or lost frames, event-fold/source errors, and drain timeouts that make otherwise mediated telemetry incomplete | experimental |
 | `safety.toolTelemetry.unfinished` | `{ tool, count }[]` | Current dispatch receipts | Tool starts that had no matching finish when the receipt sealed | experimental |
 | `safety.toolTelemetry.workspaceMutationPossible` | `boolean` | Current dispatch receipts | Whether incomplete or unavailable telemetry could conceal a shared-workspace mutation; retry admission fails closed when true | experimental |
-| `autonomyEnforcement.grade` | `string` | Always in v0.3.2 | The autonomy grade level enforced for the run | experimental |
-| `autonomyEnforcement.autonomy` | `string` | Always in v0.3.2 | The effective autonomy level name (e.g. auto-edit, suggest, read-only, full-auto) | experimental |
+| `autonomyEnforcement.grade` | `string` | Always in v0.3.4 | The autonomy grade level enforced for the run | experimental |
+| `autonomyEnforcement.autonomy` | `string` | Always in v0.3.4 | The effective autonomy level name (e.g. auto-edit, suggest, read-only, full-auto) | experimental |
 | `autonomyEnforcement.externalMode` | `string` | When running external worker | The execution mode of the external worker runtime | experimental |
 | `autonomyEnforcement.dangerousBypass` | `boolean` | When running external worker | Whether a safety bypass was explicitly activated | experimental |
 | `validationGrounding.claimed` | `number` | Validation grounding evaluated | Count of validations claimed by worker | experimental |

package/docs/performance-methodology.md

@@ -101,7 +101,7 @@ chunk name. Every lazy-graph contract must prove the heavyweight marker absent
 before first use and present after a real invocation, then repeat from a packed
 installation in a foreign working directory.
 
-## Corrected 0.3.2 baseline
+## Corrected 0.3.3 baseline
 
 These observations were recorded on 2026-08-19 in WSL2 Linux
 `6.18.33.2-microsoft-standard-WSL2`, x86-64, with an 80x24 `xterm-256color`
@@ -384,7 +384,7 @@ and the dispatch reservation, approval, gate, detach, monitor, and steer suites.
 ## Adaptive stream-pacer observations
 
 `terminal.smoothStreaming` is presentation-only. `off` is the exact existing
-16 ms coalescer and remains the 0.3.2 default. `auto` uses the pacer only on a
+16 ms coalescer and remains the 0.3.3 default. `auto` uses the pacer only on a
 capable local TTY with no accessibility, remote/multiplexer, CI, or observed
 backpressure signal. `on` requests pacing, but frame construction still stops
 behind stdout backpressure. The pacer never republishes slices on the public

package/docs/proactive-memory.md

@@ -1,6 +1,6 @@
 # Proactive task memory
 
-> **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.2).
+> **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.4).
 
 Clio's proactive task memory protects long-running work from behavioral state
 decay: a requirement, environment fact, failed attempt, or diagnosis can still

package/docs/prompt-envelope-and-tools.md

@@ -1,7 +1,7 @@
 # Prompt Envelope and Tools
 
 > [!TIP]
-> **Interactive Spec Available:** An interactive dashboard is located at [docs/html/tools_blueprint.html](html/tools_blueprint.html) (Version: 0.3.2).
+> **Interactive Spec Available:** An interactive dashboard is located at [docs/html/tools_blueprint.html](html/tools_blueprint.html) (Version: 0.3.4).
 
 Clio Coder keeps the model-facing envelope stable and moves enforcement into the runtime registry and safety policy.
 
@@ -85,7 +85,7 @@ Several tools absorb what used to be separate tools:
 - `find(pattern, path?, order?, limit?, include_ignored?)` locates paths by glob pattern (`*`, `**`, `?`, `[abc]`), default limit 500. `order="path"` (default) returns fd's native order; `order="mtime"` returns newest first from a bounded candidate set instead of statting the whole tree, and reports `details.candidates` when the candidate cap made the ordering approximate.
 - `grep(pattern, path?, mode?, glob?, ignore_case?, literal?, context?, limit?, include_ignored?)` searches file contents with ripgrep, degrading to a bounded pure-Node search when rg is absent. `mode=content` (default) returns line-referenced matches, `mode=files` returns matching paths, `mode=count` returns per-file counts. Context lines are consumed from rg's `--json` stream.
 - `context(scope="workspace"|"docs"|"skills")` is the one OBSERVE entry point for material about the working environment: the session workspace snapshot, retrieval over Clio's bundled documentation (`query` required), and skill listing or loading (`name` optional, `include_tree` for the skill's resource files).
-- `verify(check?, path?, args?, browser?, cwd?, timeout_ms?)` runs declared verification. `verify()` with no arguments lists declared checks grouped by source (package.json verification scripts today), `verify(check="<script>")` runs one through the safe-exec spine with no shell, and `verify(check="frontend", path=...)` validates an HTML/CSS/JS artifact without granting shell access.
+- `verify(check?, path?, args?, browser?, cwd?, timeout_ms?)` runs declared verification. `verify()` lists package.json verification scripts and strict version-1 `.clio-coder/verifiers.yaml` entries through the same `{id, description, command, cwd, timeoutMs, tags, source}` projection. `verify(check="<id>")` runs a package script or the catalog's exact argv/cwd/timeout through safe-exec with no shell. Model `args`, cwd, timeout, output-cap, and environment fields cannot mutate a project entry. `verify(check="frontend", path=...)` validates an HTML/CSS/JS artifact without granting shell access.
 - `artifact(kind="plan"|"review"|"report", content, ...)` writes named artifacts behind one surface: Markdown documents (default `.clio-coder/artifacts/PLAN.md`/`REVIEW.md`/`REPORT.md`; `path` may override inside the workspace) that terminate the turn, because writing the artifact is the answer. Skills are not artifacts; a `SKILL.md` is written with the ordinary write tool and validated by the skills loader.
 - `dispatch(task?, tasks?, mode?, ...)` supports a first-class singular assignment (`task`) and a batch (`tasks`), never both. `task` is worker instructions; `briefing` is optional bounded parent context/data and cannot replace it. Briefing stays a separate dynamic message and receipt provenance, never part of the receipt task. A shared top-level briefing applies to strings and objects without an override; an object-level briefing wins. Blank values are omitted, the cap is 12,000 UTF-8 bytes, and approval pins the exact canonical value. Ordinary handles enter one registered event consumer immediately. Synchronous calls auto-wait for stream-and-receipt completion; `detach:true` returns ids after durable batch registration while the same consumer continues. Review and compete retain gate-sensitive direct drains. Task objects may include `persona` and `tool_profile`. Pipeline output is threaded as bounded data. A successful native or ACP run requires a nonempty receipt-sealed final output; exit zero without one fails as `worker_final_output_missing`, with unfinished text retained only as partial diagnostics. `dispatch(list=true)` renders the catalog.
 - `monitor(run_id?, mode?)` is read-only visibility into known synchronous and detached runs: `list` enumerates, `status` reports one, `peek` returns the in-process event tail, `receipt` exposes the stored evidence, and `wait` observes one run without collecting or canceling it. `collect` is the authoritative terminal batch operation over a detached batch or run-id list; collect before final synthesis. Completed output reports receipt integrity, evidence verification, briefing provenance, and bounded project-context provenance as different fields.
@@ -107,7 +107,7 @@ The six content-returning OBSERVE tools (`read`, `grep`, `find`, `ls`, `code_nav
 
 Unknown segments are omitted. `<total>` renders as `N+` when the search was killed early at its limit, meaning matches beyond it exist but were never counted. `next` is always an exact continuation call fragment such as `limit=200` or `offset=451`, never prose. Untruncated results get no notice. Empty results are standardized: `grep` returns `No matches found`, `find` returns `No files found matching pattern`, `ls` returns `(empty directory)`, and the JSON-format tools return valid JSON with empty arrays and `next` populated.
 
-**Offload on truncation.** When a byte cap cuts collected content, the tool spills its full rendering to the per-session scratch file (`<stateDir>/scratch/<sessionId>/<toolCallId>.txt`) and reports the path in the notice, so no collected match, path, or line is ever unrecoverable. Two deliberate exceptions exist: `read` never offloads because the source file is directly re-addressable via `next: offset=N`, and a bare item-limit truncation without a byte cut continues via `next` alone, since an offload would only duplicate the body.
+**Offload on truncation.** When a byte cap cuts collected content, the tool spills its full rendering to the per-session scratch file (`<stateDir>/scratch/<sessionId>/<sha256 of the captured text>.txt`) and reports the path in the notice, so no collected match, path, or line is ever unrecoverable. Two deliberate exceptions exist: `read` never offloads because the source file is directly re-addressable via `next: offset=N`, and a bare item-limit truncation without a byte cut continues via `next` alone, since an offload would only duplicate the body.
 
 **Always-valid JSON.** `code_nav` and the JSON scopes of `context` declare `format: "json"`. A JSON payload must parse or be replaced whole; it is never cut mid-document. An oversize payload is offloaded and the body is replaced by the parseable stub:
 
@@ -133,7 +133,7 @@ Tool descriptions are tiered by how much a wrong call costs. The hot tools the m
 
 Clio uses two context-protection mechanisms.
 
-1. Tool results are capped at the source and again at the registry boundary. OBSERVE tools use the envelope caps above. Exact mutation tools (`write`, `edit`, `artifact`) use 8KB; `steer` and `credential_present` use 4KB; `ask_user` has a 20KB policy. Summary-kind tools (`bash`, `git`, `verify`, `dispatch`, `monitor`) use 16KB at the registry boundary. `web_fetch` is bounded at 16KB after shaping and may read more before it: its `max_bytes` argument defaults to 600KB and is hard-capped at 5MB. Tools without an explicit result-size policy use an approximately 18KB generic backstop. Over-cap generic results are shown briefly and, when possible, saved under `<stateDir>/scratch/<sessionId>/<toolCallId>.txt` with an `offloadPath` detail and a 10MB scratch-file cap.
+1. Tool results are capped at the source and again at the registry boundary. OBSERVE tools use the envelope caps above. Exact mutation tools (`write`, `edit`, `artifact`) use 8KB; `steer` and `credential_present` use 4KB; `ask_user` has a 20KB policy. Summary-kind tools (`bash`, `git`, `verify`, `dispatch`, `monitor`) use 16KB at the registry boundary. Bash also exposes the canonical per-call `output_policy`: omitted/`bounded` keeps its diagnostic tail, `summary` selects stable redacted head/error/tail evidence, `metadata-only` keeps facts and retrieval without stdout/stderr context, and `full` succeeds only inside the same hard result budget or records a typed downgrade. This model-context choice does not change the folded tail-biased operator presentation. `web_fetch` is bounded at 16KB after shaping and may read more before it: its `max_bytes` argument defaults to 600KB and is hard-capped at 5MB. Tools without an explicit result-size policy use an approximately 18KB generic backstop. Over-cap generic results are shown briefly and, when possible, saved under `<stateDir>/scratch/<sessionId>/<sha256 of the captured text>.txt` with an `offloadPath` detail and a 10MB scratch-file cap.
 2. Auto-compaction uses one pressure threshold. The default threshold is 0.8. When pressure crosses the threshold, Clio first masks stale tool observations and stale thinking older than `excludeLastTurns`. If pressure remains above the threshold, it runs the LLM summary compaction path and replays from the compacted session view.
 
 Manual `/context compact`, `CLIO_CODER_FORCE_COMPACT=1`, and overflow recovery force the LLM summary path directly.

package/docs/provider-adapter-cookbook.md

@@ -1,7 +1,7 @@
 # Provider Adapter Cookbook
 
 > [!TIP]
-> **Interactive Spec Available:** An interactive runtime adapter descriptor builder and probe sequence capability checklist is located at [docs/html/provider_adapter_blueprint.html](html/provider_adapter_blueprint.html) (Version: 0.3.2).
+> **Interactive Spec Available:** An interactive runtime adapter descriptor builder and probe sequence capability checklist is located at [docs/html/provider_adapter_blueprint.html](html/provider_adapter_blueprint.html) (Version: 0.3.4).
 
 This cookbook guides developers through implementing custom model runtimes and inference server integrations within Clio Coder. It explains the runtime descriptor interfaces, probing protocols, model synthesis, and how to configure reasoning and thinking behaviors.
 

package/docs/release-cut-checklist.md

@@ -1,23 +1,23 @@
-# v0.3.2 Release-Cut Checklist
+# v0.3.4 Release-Cut Checklist
 
-The ordered steps that turn the prepared `v0.3.2` branch into a published
+The ordered steps that turn the prepared `v0.3.4` branch into a published
 release. Everything above the line marked **AUTHORIZATION BOUNDARY** is
 repeatable and reversible and is run locally before the cut. Everything below
 it is external or irreversible and needs an explicit decision from the
-operator. Issue #112 is the release umbrella and carries the live state of
-every step; this page is the procedure.
+operator. This page is the procedure and the release report carries the live
+state of every step.
 
 ## Status of the prepared tree
 
 | Item | State |
 | --- | --- |
-| Branch | `v0.3.2`, local only; no remote `v0.3.2` branch |
-| `package.json` version | `0.3.2`; the top `CHANGELOG.md` heading is `## 0.3.2 - 2026-08-20` |
-| `main` | fast-forwarded prematurely to `c4c344ba` during Eneko's port integration and pushed. It is an ancestor of `v0.3.2`, must not move backward, and is fast-forwarded again only at Part 4. |
-| `origin/main` | `c4c344ba`, the same premature push |
-| Tags | none for 0.3.2, local or remote |
-| GitHub Release | none for 0.3.2 |
-| npm registry | `@iowarp/clio-coder@0.3.2` absent; `latest` is `0.3.1` |
+| Branch | `v0.3.4`; `origin/v0.3.4` exists and is pushed to the reviewed tip before the cut |
+| `package.json` version | `0.3.4`; the top `CHANGELOG.md` heading is `## 0.3.4 - 2026-08-22` |
+| `main` | `8a1c8304`, the published `v0.3.3` commit; it is an ancestor of `v0.3.4` and moves only at Part 4. |
+| `origin/main` | `8a1c8304`, matching the published `v0.3.3` commit |
+| Tags | none for 0.3.4, local or remote |
+| GitHub Release | none for 0.3.4 |
+| npm registry | `@iowarp/clio-coder@0.3.4` absent; `latest` is `0.3.3` |
 | Commit provenance identity | Post-release maintainer follow-up, not a gate: verifying `clio-coder@iowarp.ai` on IOWarp-controlled GitHub and GitLab identities (such as `clio-coder-bot` or `iowarp-clio`, with `assets/clio-coder-avatar-512.png` as the avatar) only changes how those platforms render the trailers. |
 
 ---
@@ -40,11 +40,11 @@ Run against the exact final candidate with `NO_COLOR` unset and
    resources, and the tarball and unpacked size budgets)
 9. Step 8 again under the other supported Node major. Both Node 22 and
    Node 24 must be green; the repo is developed against 22.22.3 and 24.9.0.
-10. `npm run test:lifecycle` for the twenty-case lifecycle matrix against a real
-    `npm pack` installed into a temporary prefix. Case 9 needs `--live` plus
-    `CLIO_CODER_LIFECYCLE_URL` and `CLIO_CODER_LIFECYCLE_MODEL` naming a target
-    whose model is already resident; report it separately when no such target
-    is available.
+10. `npm run live:smoke -- --target <id>` for one real headless turn through
+    the built binary against a configured target, which is the one release
+    check a deterministic suite cannot give. The packaged-install lifecycle
+    (pack, install into a clean prefix, run the installed launcher) is
+    `tests/smoke/pack-install.test.ts` and already ran under step 5.
 11. `npm pack --dry-run`, then a real `npm pack` into a temporary directory.
     Inspect the complete file list: `skills/`, `docs/*.md`, the builtin
     agents, the model catalogs, and `damage-control-rules.yaml` are present;
@@ -58,22 +58,22 @@ Run against the exact final candidate with `NO_COLOR` unset and
 ## Part 2: version and notes (repeatable)
 
 13. Files carrying a version reference, to update together if the number
-    changes: `package.json` and `package-lock.json`, the `## 0.3.2 - <date>`
-    heading in `CHANGELOG.md`, the `(Version: 0.3.2)` markers in `docs/*.md`,
-    the `Blueprint (v0.3.2)` titles in `docs/html/*.html`, the `--branch`
+    changes: `package.json` and `package-lock.json`, the `## 0.3.4 - <date>`
+    heading in `CHANGELOG.md`, the `(Version: 0.3.4)` markers in `docs/*.md`,
+    the `Blueprint (v0.3.4)` titles in `docs/html/*.html`, the `--branch`
     pin in the README install block (the hygiene lint checks it), and the
     measured-at figures in `scripts/check-release.mjs` if the package size
     moved materially.
-14. Confirm the `## 0.3.2` section of `CHANGELOG.md` describes every
+14. Confirm the `## 0.3.4` section of `CHANGELOG.md` describes every
     user-visible behavior change, including the ones that alter existing
     behavior, and carries no Workbench release narrative. The release workflow
     uses this section verbatim as the GitHub Release body.
 15. Re-run `npm run ci:release` after any version edit and commit as one
-    commit on `v0.3.2`.
+    commit on `v0.3.4`.
 
 ## Part 3: present the gate
 
-16. Report to the operator before touching `main`: the exact final `v0.3.2`
+16. Report to the operator before touching `main`: the exact final `v0.3.4`
     SHA and clean status, the commits added since the handoff SHA, the gate
     commands with pass/fail totals for both Node majors, the package version
     and changelog heading, the tarball audit, the clean-install results and any
@@ -92,9 +92,9 @@ confirming the exact SHA and the commands.
 ## Part 4: fast-forward `main`
 
 17. `git fetch origin` immediately before integrating; require `origin/main`
-    to be an ancestor of the reviewed `v0.3.2` tip and confirm no other
+    to be an ancestor of the reviewed `v0.3.4` tip and confirm no other
     worktree has `main` checked out.
-18. `git checkout main && git merge --ff-only v0.3.2`. No merge commit, no
+18. `git checkout main && git merge --ff-only v0.3.4`. No merge commit, no
     rebase, no reset. Verify `main` equals the reviewed SHA and is clean.
 19. `git fetch origin` once more; stop on any unexpected remote movement. Then
     `git push origin main`. Never `--force` or `--force-with-lease`.
@@ -105,12 +105,12 @@ confirming the exact SHA and the commands.
     Node 24 jobs must succeed on the exact release SHA. A red or pending run
     blocks the tag; a flake is rerun only with concrete evidence, never
     silenced with an unrelated change.
-21. Reconfirm that tag `v0.3.2` and the GitHub Release do not exist, then
-    `git tag -a v0.3.2 -m "Clio Coder 0.3.2"` on the green SHA and
-    `git push origin v0.3.2`.
+21. Reconfirm that tag `v0.3.4` and the GitHub Release do not exist, then
+    `git tag -a v0.3.4 -m "Clio Coder 0.3.4"` on the green SHA and
+    `git push origin v0.3.4`.
 22. The tag push triggers `.github/workflows/release.yml`, which requires a
     successful `ci` run for the tagged SHA, verifies the tag matches
-    `package.json`, builds and audits the artifact, extracts the `## 0.3.2`
+    `package.json`, builds and audits the artifact, extracts the `## 0.3.4`
     section of `CHANGELOG.md` as the release body, and attaches the tarball.
     Do not create a release by hand. Verify the run's SHA, the notes, the
     attached tarball, and the URL.
@@ -118,9 +118,9 @@ confirming the exact SHA and the commands.
 ## Part 6: npm publication (irreversible)
 
 23. `npm whoami` and confirm the registry and account; reconfirm
-    `@iowarp/clio-coder@0.3.2` is still absent.
+    `@iowarp/clio-coder@0.3.4` is still absent.
 24. Obtain the operator's explicit dist-tag decision. `latest` makes this the
-    default install for every user; `--tag next` keeps `0.3.1` as the default.
+    default install for every user; `--tag next` keeps `0.3.3` as the default.
 25. Run `npm publish` (or `npm publish --tag next`) once. `prepublishOnly`
     re-runs `ci:release` as a safety net; it is not a substitute for Part 1.
 26. A published version cannot be replaced. `npm unpublish` is restricted and
@@ -128,15 +128,15 @@ confirming the exact SHA and the commands.
 
 ## Part 7: post-publish verification and follow-ups
 
-27. `npm view @iowarp/clio-coder@0.3.2` and the selected dist-tag.
+27. `npm view @iowarp/clio-coder@0.3.4` and the selected dist-tag.
 28. On a clean machine, `npm install -g @iowarp/clio-coder` from the registry
     rather than from a local tarball, then repeat step 12 against it, plus
     `configure` to a real target and one real turn when one is authorized.
     This is the only step that tests what users actually receive.
-29. From an installation of 0.3.1, verify `clio-coder upgrade` finds and
-    applies 0.3.2.
-30. Close #112 with the SHA, CI URL, tag, GitHub Release URL, npm version and
-    dist-tag, tarball evidence, and the post-publish verification.
+29. From an installation of 0.3.3, verify `clio-coder upgrade` finds and
+    applies 0.3.4.
+30. Record the SHA, CI URL, tag, GitHub Release URL, npm version and dist-tag,
+    tarball evidence, and the post-publish verification in the release report.
 31. Maintainer follow-up, independent of the release: verify the commit
     provenance email `clio-coder@iowarp.ai` on IOWarp-controlled GitHub and
     GitLab identities such as `clio-coder-bot` or `iowarp-clio`, and upload