@iowarp/clio-coder 0.3.7 → 0.3.8

package/docs/evidence-and-memory.md

@@ -1,7 +1,7 @@
 # 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.7). 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.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.
 
@@ -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. |
 
 ---
@@ -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 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.7).
+> **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/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.7).
+> **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.
 

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.7).
+> **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.8).
 
 Clio Coder dispatches bounded worker agents. With a fleet configured, those
 workers run on remote machines over SSH while the orchestrator keeps every
@@ -424,8 +424,18 @@ marker and no answer text.
 
 `synthesis: "none"` returns the final member answers directly. `vote` performs
 a deterministic majority tally over structured `verdict` fields without a
-model call. A vote with no majority reports `no_majority`, and a vote with no
-verdict fields reports `no_verdict_field`. `judge` runs one additional read-only judge against all final
+model call. A vote council asks each member for that verdict: the member's task
+carries the ballot directive and the member's run seals a `council-ballot`
+postcondition, `{"verdict":"...","text":"..."}`, in place of the seated
+recipe's own result contract. The seated agent, its persona, and its read-only
+tool profile are unchanged, so any recipe can be voted with. The verdict is a
+single line of at most 64 bytes and is lower-cased before the tally, so members
+who reach the same conclusion land on the same key; the reasoning belongs in
+`text`, which is what the council report shows as the member's answer. A member
+that seals no conforming ballot fails its own run and is reported as a failed
+member rather than dropping silently out of the count. A vote with no majority
+reports `no_majority`, and a vote whose final members all failed reports
+`no_verdict_field`. `judge` runs one additional read-only judge against all final
 answers. Every member run seals a receipt. A judge receipt points backward to
 every final member receipt through gate provenance. The approval artifact names
 each member's label, target, model, thinking level, node, color, round count,
@@ -521,12 +531,14 @@ The grammar for declared write boundary entries requires repository-relative POS
 Write boundary enforcement is detect-and-rollback, never OS or filesystem sandboxing. A step runs with whatever filesystem permissions its underlying execution environment possesses. Upon step completion, the orchestrator inspects the working tree to verify compliance:
 1. Snapshot baseline: Before a step executes, the orchestrator captures a snapshot (`captureWorkspaceSnapshot`) recording the baseline git HEAD commit and existing dirty path content tokens.
 2. Workspace diffing: After step completion, the orchestrator runs git status inspection (`diffWorkspace`) to identify changed paths relative to the snapshot baseline commit.
-3. Rollback execution: Unauthorized changes (modified paths not covered by the step's declared allowlist) are automatically rolled back (`rollbackPath`).
-4. Content source: Rollback restores content strictly from what git already has in the pinned baseline commit (`snapshot.head`). If a path was already dirty when the step snapshot was captured, its prior content is not stored in git, so in-place restoration cannot be guaranteed. The working tree is left as the step made it, and the status settles as `rollback-incomplete`.
-5. Violation handling: Any unauthorized change fails the step with the typed reason `writes_boundary_violation`.
-6. Window attribution: Enforcement evaluates scheduling windows (`wave-<n>` or `revalidate-<stepId>-<n>`). A wave window cannot combine steps with overlapping declared boundaries or multiple concurrent step writers, ensuring single-step attribution.
-7. Ignored paths and state subtraction: Enforcement evaluates paths reported by git status. Git-ignored paths remain outside enforcement. The Clio state directory (`.clio-coder/` or `clioStateDir()`) is subtracted from status checks so orchestrator receipts, code step log artifacts, and boundary verdicts do not trigger false violations.
-8. Durable records: Verdicts are serialized as JSON records at `write-boundaries/<rootId>/<window>.json` under the Clio state directory, carrying the baseline HEAD commit, checked paths, violations, rollback actions, status, and SHA-256 digest.
+3. Authorship attribution: A changed path outside the allowlist is blamed on the window only when it intersects what the window's own runs recorded writing. That record is the run's tool-call stream, folded by the same recorder that grounds a sealed mutation report and read back through `DispatchContract.observedRunWrites`. A change that no run in the window recorded is an unattributed concurrent change: it is listed under `unattributed` in the verdict and reported to the operator, and it is never rolled back. This is what keeps a file an operator edited while a fleet ran from being overwritten with its committed version.
+4. Open records: A run's recorded write set is read as a closed list only when the run could not have written outside it. A window whose steps do not all offer a closed record falls back to blaming every change outside the allowlist, which is the behavior that predates attribution. Three things open a record: a `kind: code` step, whose registered command publishes no tool events; a run whose tool telemetry coverage is not `complete`, such as one on a subprocess runtime; and a run that made a successful call to a tool able to mutate a path its own arguments do not name. That last set is derived from the tool surface rather than authored, as every registered tool outside the `read` and `write` action classes, which today is `bash`, `verify`, `dispatch`, and `steer`, plus any dynamic or MCP tool whose schema this process cannot read. The `git` tool is a closed status, diff, and log surface and stays enumerable. The verdict records `attributionComplete: false` and the operator-facing detail says the blame was inferred from the checkout rather than from the step's own record.
+5. Rollback execution: Attributed unauthorized changes are automatically rolled back (`rollbackPath`).
+6. Content source: Rollback restores content strictly from what git already has in the pinned baseline commit (`snapshot.head`). If a path was already dirty when the step snapshot was captured, its prior content is not stored in git, so in-place restoration cannot be guaranteed. The working tree is left as the step made it, and the status settles as `rollback-incomplete`.
+7. Violation handling: Any attributed unauthorized change fails the step with the typed reason `writes_boundary_violation`.
+8. Window attribution: Enforcement evaluates scheduling windows (`wave-<n>` or `revalidate-<stepId>-<n>`). A wave window cannot combine steps with overlapping declared boundaries or multiple concurrent step writers, ensuring single-step attribution.
+9. Ignored paths and state subtraction: Enforcement evaluates paths reported by git status, which never lists a git-ignored path. A declared `writes` entry the repository ignores is therefore refused before anything runs, by `fleet validate`, by `fleet run` preflight, and by the `/fleet run` preview, with a diagnostic naming the entry and the ignoring rule (for example `'work/' is ignored by .gitignore:1:work/`). Silently certifying such a window as clean is not an option, because nothing about it was observed. The Clio state directory (`.clio-coder/` or `clioStateDir()`) is subtracted from status checks so orchestrator receipts, code step log artifacts, and boundary verdicts do not trigger false violations.
+10. Durable records: Verdicts are serialized as JSON records at `write-boundaries/<rootId>/<window>.json` under the Clio state directory, carrying the baseline HEAD commit, checked paths, violations, unattributed concurrent changes, the attribution completeness flag, rollback actions, status, and SHA-256 digest.
 
 ### Bounded check/repair loops
 
@@ -670,6 +682,19 @@ Assignment status, attempt ids, and terminal run id are stored separately in
 Pipelines and batches await assignment terminals, so downstream stages consume
 the successful fallback output rather than an earlier failed attempt.
 
+A fleet run is the exception to "the attempts settle the record". Every step of
+a fleet dispatches under the fleet root id as its lineage root, so all of them
+share one row, and no single step is the run's verdict. The run claims the row
+by writing `verdictOwner: "fleet"` when it opens, files every settled step's
+terminal run id in `attempts` (an agent step's receipt id, a code step's
+`code-*` run id, whose report sits under `code-steps/<fleetRootId>/`), and
+writes `status` once at the end from the whole-run outcome. Until then the row
+stays `running`, and a step settling under it records its attempt without
+touching the status. A run that stops before its last step, whose final step
+fails, or that throws is `failed`; a run abandoned by a crashed process is
+reconciled to `failed` at the next startup rather than inheriting a green
+step's success.
+
 Editing assignments also own one baseline-pinned workspace transaction. Every
 attempt gets a distinct worktree. Before any winning diff can reach the
 destination checkout, a pure gate checks terminal outcome, receipt integrity,

package/docs/glossary.md

@@ -1,6 +1,6 @@
 # Clio Coder Glossary
 
-This document defines the 45 core architectural concepts and terminology used throughout Clio Coder, mapped to their authoritative TypeScript type definitions in `src/`.
+This document defines the 50 core architectural concepts and terminology used throughout Clio Coder, mapped to their authoritative TypeScript type definitions in `src/`.
 
 ---
 
@@ -185,3 +185,23 @@ This document defines the 45 core architectural concepts and terminology used th
 ### 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`.
+
+### 46. Canonical Trust Status
+- **Definition**: The six-axis record of what is known about one run: artifact integrity, validation grounding, independent review, context provenance, autonomy enforcement, and completion evidence. It is an algebra, not a score: no axis promotes another, every non-absent state names its source and authority, and `absent`, `unknown`, and `not_applicable` are states in their own right. See [docs/evidence-and-memory.md](evidence-and-memory.md#canonical-trust-status) for the full state table.
+- **Owning Type**: `CanonicalTrustStatus` in `src/domains/evidence/trust-status.ts`.
+
+### 47. Trust Projection
+- **Definition**: The one rendering of the canonical trust status every operator surface prints. The compact human line answers who claims the result, what was observed, what was independently checked, and what is still unknown, in six fixed clauses (`sealed; grounded by host-verification; not independently reviewed; mediated; context recorded; completion evidenced`). The machine projection is the same answer as a bounded, versioned record with references to the detailed artifacts. Dispatch and monitor output, `evidence inspect`, `findings.md`, the Alt+W board, the receipt view, the eval bridge, and the ACP wire all print from it.
+- **Owning Type**: `formatTrustSummary` and `TrustSummaryProjection` in `src/domains/evidence/trust-projection.ts`.
+
+### 48. Trust Verdict
+- **Definition**: The presentation tier read off the axes in a fixed order, used for styling and sorting and never as a score. `reviewed` requires an authenticated independent pass and is the only tier styled as independently verified. `grounded` is observed validation without independent review. `unverified` is a sealed receipt with nothing observed. `compromised` is a broken seal, a bypassed gate, a failed or inferred validation, a failed or correlated review, or a contradictory context record. `unknown` is an unchecked or missing seal.
+- **Owning Type**: `TrustVerdict` and `trustVerdict` in `src/domains/evidence/trust-projection.ts`.
+
+### 49. Trust Vocabulary
+- **Definition**: The standardized word for each canonical state, so the same fact is never spelled two ways. `sealed` means the receipt authenticated against the ledger row; it says nothing about correctness. `grounded` means validation was observed to run and pass, named by its claimant (`host-verification`, `validation-tool`, `receipt-quality`, `evidence-grounding`). `independently reviewed` means an authenticated reviewer that was not the run itself recorded a verdict. `inferred` means the worker claimed validation and nothing was observed to have run. `mediated` is the word for the `enforced` autonomy state: Clio's own safety gate mediated the run. `approximated` and `bypassed` name an external runtime's enforcement, always with the runtime's id. `unknown` means a named source could not answer; `not applicable` means a named authority decided the axis does not apply.
+- **Owning Type**: `TRUST_STATE_WORDS` in `src/domains/evidence/trust-projection.ts`.
+
+### 50. Commonly Confused Trust States
+- **Definition**: `sealed` is not `grounded`: a receipt can authenticate perfectly and describe a run that validated nothing. `grounded` is not `independently reviewed`: a host check is Clio observing the run's own declared command, not a second agent judging the result. A `host checks verified` unit on the board is folded into validation grounding and is never independent review. `mediated` and `enforced` are one state under two names, the receipt grade and the canonical id. `not_requested` is not a trust state at all; a run with no host check reads `no validation observed`. `completion unevidenced` (a mutation finished with no validation at the completion boundary) is distinct from `no validation observed` (no validation was linked anywhere in the run): the first is the finish contract's observation, the second the evidence linker's.
+- **Owning Type**: `TRUST_STATE_WORDS` and `trustVerdict` in `src/domains/evidence/trust-projection.ts`; the axis states in `TRUST_STATUS_STATES` in `src/domains/evidence/trust-status.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.7). 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.8). You can open it directly in any web browser to view details dynamically.
 
 ---
 

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.7).
+> **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.8).
 
 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.7).
+> **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.8).
 
 Clio Coder treats a selectable model as the intersection of three sources:
 

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.7).
+> **Interactive Spec Available:** An interactive dashboard is located at [docs/html/observability_blueprint.html](html/observability_blueprint.html) (Version: 0.3.8).
 
 `/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.
 
@@ -175,7 +175,7 @@ describes validation evidence inside that verified receipt. Likewise,
 message. Model-facing dispatch and collect output name all four concepts
 separately and never substitute one hash for another.
 
-The evidence bundle renders these sets in `transcript.md` (human sentences) and `trace.cleaned.jsonl` (structured run rows), `clio-coder evidence inspect` prints them as a `provenance <runId>:` block, and the `dispatch` tool appends a compact suffix to each run line plus additive keys on `details.runs[]`. A timed-out or denied escalation also raises an `escalation` finding in the bundle.
+The evidence bundle renders these sets in `transcript.md` (human sentences) and `trace.cleaned.jsonl` (structured run rows), `clio-coder evidence inspect` prints them as a `provenance <runId>:` block, and the `dispatch` tool appends a compact suffix to each run line plus additive keys on `details.runs[]`, including `trust`, the bounded canonical trust projection described in [evidence-and-memory.md](evidence-and-memory.md#trust-projection). A timed-out or denied escalation also raises an `escalation` finding in the bundle.
 
 The base provenance sets, steering, routing, quality, worker identity, result-conformance, council provenance, and fleet gate provenance use the strict v19 shape frozen for the release. These fields are labeled `experimental` until the schema is promoted post-1.0. For the complete version registry and migration contract across all artifacts, see [artifact-versions.md](artifact-versions.md).
 

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.7).
+> **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).
 
 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.7).
+> **Interactive Spec Available:** An interactive dashboard is located at [docs/html/tools_blueprint.html](html/tools_blueprint.html) (Version: 0.3.8).
 
 Clio Coder keeps the model-facing envelope stable and moves enforcement into the runtime registry and safety policy.
 
@@ -21,7 +21,9 @@ Prompt extensions can add dynamic fragments for project rules, the operator prof
 
 Prompt templates expand into the operator's user message before submission. They do not alter the compiled system prompt or bypass the trust check on project-scope compatibility roots. The prompt-root locations, frontmatter fields, and trust rules are documented in [extensions-and-sharing.md](extensions-and-sharing.md#prompt-templates).
 
-Arguments after `/template-name` use shell-style command argument parsing. Single or double quotes keep spaces inside one argument. The template body may use `$1` through `$9` for positional arguments, `$@`, and `$ARGUMENTS` for every parsed argument joined with spaces, as well as argument slices. A positional placeholder with no matching argument expands to an empty string. Template names that collide with built-in slash commands fail closed with a diagnostic and are excluded from `/prompts`.
+The first whitespace character after `/template-name` is the command delimiter; CRLF counts as one delimiter. Leading whitespace before the slash is also command framing. Every byte after that delimiter is the argument payload, including leading or trailing whitespace, repeated spaces, tabs, quotes, and line breaks.
+
+The template body may use `$ARGUMENTS` to insert that raw payload byte-for-byte. Raw insertion is not recursively substituted, so placeholder-like text such as `$1` remains data. `$1` through `$9`, `$@`, `${@:N}`, and `${@:N:L}` retain shell-style parsing: single or double quotes group spaces within one argument, `$@` joins all parsed arguments with single spaces, `${@:N}` selects parsed arguments from one-based position `N`, and `${@:N:L}` selects `L` arguments beginning there. A positional placeholder with no matching argument expands to an empty string. Template names that collide with built-in slash commands fail closed with a diagnostic and are excluded from `/prompts`.
 
 ## Directory-scoped handbook overrides
 

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.7).
+> **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.8).
 
 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,6 +1,6 @@
-# v0.3.7 Release-Cut Checklist
+# v0.3.8 Release-Cut Checklist
 
-The ordered steps that turn the prepared `v0.3.7` branch into a published
+The ordered steps that turn the prepared `v0.3.8` 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
@@ -11,16 +11,17 @@ state of every step.
 
 | Item | State |
 | --- | --- |
-| Branch | `v0.3.7`, pushed to `origin` under the explicit refspec `refs/heads/v0.3.7`; sixteen feature and docs commits, the version-bump commit, and the fix commits the interactive release testing produced, ahead of `main` |
-| `package.json` version | `0.3.7`; the top `CHANGELOG.md` heading is `## 0.3.7 - 2026-08-24` |
-| `main` | `9b54219d`, the v0.3.6 release SHA; it is an ancestor of `v0.3.7` and moves only at Part 4 |
-| `origin/main` | `9b54219d`, matching `main` |
-| Tags | `v0.3.6` exists on `9b54219d`; none for 0.3.7, local or remote |
-| GitHub Release | `v0.3.6` published 2026-08-24; none for 0.3.7 |
-| npm registry | `@iowarp/clio-coder@0.3.7` absent; `latest` is `0.3.6` |
-| npm history | Published versions 0.3.0 through 0.3.4 and 0.3.6. Version 0.3.5 was published and withdrawn and can never be reused. |
-| Milestone | `v0.3.7` holds the thirteen issues this branch closes (#155, #204, #206 through #216); the ten off-map items (#156, #158 through #164, #198, #199) moved to `v0.3.8` on 2026-08-24 |
-| 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. |
+| Branch | After the release-cut evidence commit, `v0.3.8` is 30 commits ahead of `main`: the 29-commit candidate through `9b7b80cc` plus the final documentation and verification-evidence commit. The candidate includes the original implementation, the four release-test fixes (#233, #235, #238, #239), the WTF-P extension-resource merge, the `$ARGUMENTS` fidelity fix (#240), and the extension-agent resolution fix (#241). `origin/v0.3.8` remains at `af6546b2`, 17 commits behind the final local tip. |
+| `package.json` version | `0.3.8`; `package-lock.json` agrees at both version fields; the top changelog heading is `## 0.3.8 - 2026-08-29`. |
+| `main` | `598be99c`, the v0.3.7 release SHA; it is an ancestor of the final `v0.3.8` candidate and moves only at Part 4. |
+| `origin/main` | `598be99c`, matching local `main` and still an ancestor of the final candidate. |
+| Tags | `v0.3.7` exists on `598be99c`; no `v0.3.8` tag exists locally or remotely. The redundant `wtfp-safety` tag was deleted. The eight local `tmp-032-*` recovery tags remain and must never be pushed. |
+| GitHub Release | `v0.3.7` is published; no GitHub Release exists for `v0.3.8`. |
+| npm registry | `@iowarp/clio-coder@0.3.8` is absent; `latest` is `0.3.7`; the 0.3.8 dist-tag is undecided. |
+| npm history | Published versions are 0.3.0 through 0.3.4, 0.3.6, and 0.3.7. Version 0.3.5 was published and withdrawn and can never be reused. |
+| Milestone | `v0.3.8` has six open issues, all fixed on the branch: #233, #235, #238, #239, #240, and #241. They close from their `Fixes` trailers when the final candidate reaches `main`. |
+| Interactive release test | The original three-round report is `docs/release-notes/v0.3.8-release-test.md` (57 PASS / 8 FAIL / 3 PARTIAL / 6 OBSERVATION / 2 NOT RUN). The continuation is `docs/release-notes/v0.3.8-verification.md` (44 PASS / 6 non-blocking FAIL / 7 OBSERVATION / 1 NOT RUN), which closes the blocker, verifies the three later merges, and carries the final `CUT` verdict. |
+| Commit provenance identity | Still a post-release maintainer follow-up rather than a release gate; unchanged from 0.3.7. |
 
 ---
 
@@ -69,35 +70,37 @@ Run against the exact final candidate with `NO_COLOR` unset and
 ## Part 2: version and notes (repeatable)
 
 14. Files carrying a version reference, to update together if the number
-    changes: `package.json` and `package-lock.json`, the `## 0.3.7 - <date>`
-    heading in `CHANGELOG.md`, the `(Version: 0.3.7)` markers in `docs/*.md`,
-    the `Blueprint (v0.3.7)` titles in `docs/html/*.html`, the `--branch`
+    changes: `package.json` and `package-lock.json`, the `## 0.3.8 - <date>`
+    heading in `CHANGELOG.md`, the `(Version: 0.3.8)` markers in `docs/*.md`,
+    the `Blueprint (v0.3.8)` 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. For 0.3.7 the tarball measured 6.5 MB packed and
-    37.9 MB unpacked, inside the 10 MB and 50 MB ceilings set for 0.3.6.
-15. Confirm the `## 0.3.7` section of `CHANGELOG.md` describes every
+    37.9 MB unpacked; re-measure for 0.3.8, inside the 10 MB and 50 MB ceilings set for 0.3.6.
+15. Confirm the `## 0.3.8` section of `CHANGELOG.md` describes every
     user-visible behavior change under `### Added`, and every change to an
     existing behavior under `### Changed`, and carries no Workbench release
     narrative. The release workflow uses this section verbatim as the GitHub
     Release body.
 16. `docs/artifact-versions.md` lists every persisted artifact this release
-    added or re-versioned: run receipt integrity v19, fleet contract v5, the
-    fleet run record, the checkout writer lease, the out-of-turn usage ledger,
-    and the library pin file.
+    added or re-versioned. For 0.3.8 that is run receipt integrity v20, which
+    adds `pathProvenance` on dispatch intent and the resolved `pathScope`, and
+    whose entry must also record that a receipt below v20 is reported as
+    retired rather than invalid, and the durable assignment record, which now
+    carries its owner pid, process birth token, and acquisition time.
 17. Re-run `npm run ci:release` after any version edit and commit as one
-    commit on `v0.3.7`.
+    commit on `v0.3.8`.
 
 ## Part 3: present the gate
 
-18. Report to the operator before touching `main`: the exact final `v0.3.7`
+18. Report to the operator before touching `main`: the exact final `v0.3.8`
     SHA and clean status, the commits added since the handoff SHA, the gate
     commands with pass/fail totals, the package version and changelog heading,
     the tarball audit, the clean-install results, the interactive test table,
     and any deferred live check, confirmation that no tag, GitHub Release, or
     npm version exists yet, the proposed commands for Parts 4 through 6, and
     the npm dist-tag. The dist-tag is the operator's call; for 0.3.7 the
-    operator chose `latest` on 2026-08-24.
+    operator chose `latest` on 2026-08-24; 0.3.8's dist-tag is undecided.
 
 ---
 
@@ -110,35 +113,35 @@ confirming the exact SHA and the commands.
 ## Part 4: fast-forward `main`
 
 19. `git fetch origin` immediately before integrating; require `origin/main`
-    to be an ancestor of the reviewed `v0.3.7` tip and confirm no other
+    to be an ancestor of the reviewed `v0.3.8` tip and confirm no other
     worktree has `main` checked out.
-20. `git checkout main && git merge --ff-only v0.3.7`. No merge commit, no
+20. `git checkout main && git merge --ff-only v0.3.8`. No merge commit, no
     rebase, no reset. Verify `main` equals the reviewed SHA and is clean.
 21. `git fetch origin` once more; stop on any unexpected remote movement. Then
     `git push origin main`. Never `--force` or `--force-with-lease`. The push
-    closes the thirteen milestone issues through their `Fixes` trailers.
+    closes the six milestone issues through their `Fixes` trailers.
 
 ## Part 5: exact-SHA CI, tag, GitHub Release
 
-22. The `main` push triggers the `ci` workflow. It is a useful signal but not
-    a gate on tagging, because `release.yml` runs the same gate on the tagged
-    tree itself. A red run still blocks the cut; investigate it rather than
+22. The `main` push triggers the `ci` workflow. Require that exact-SHA run to
+    finish green before tagging; `release.yml` then runs the same gate again on
+    the tagged tree itself. A red run blocks the cut: investigate it rather than
     tagging around it, and never silence a flake with an unrelated change.
-23. Reconfirm that tag `v0.3.7` and the GitHub Release do not exist, then
-    `git tag -a v0.3.7 -m "Clio Coder 0.3.7"` on the green SHA and
-    `git push origin refs/tags/v0.3.7`.
+23. Reconfirm that tag `v0.3.8` and the GitHub Release do not exist, then
+    `git tag -a v0.3.8 -m "Clio Coder 0.3.8"` on the green SHA and
+    `git push origin refs/tags/v0.3.8`.
 24. The tag push triggers `.github/workflows/release.yml`, which verifies the
     tag matches `package.json`, runs `npm run ci:release` on the tagged tree,
-    extracts the `## 0.3.7` section of `CHANGELOG.md` as the release body, and
+    extracts the `## 0.3.8` 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.
 
 ## Part 6: npm publication (irreversible)
 
 25. `npm whoami` and confirm the registry and account; reconfirm
-    `@iowarp/clio-coder@0.3.7` is still absent.
+    `@iowarp/clio-coder@0.3.8` is still absent.
 26. Obtain the operator's explicit dist-tag decision. `latest` makes this the
-    default install for every user; `--tag next` keeps `0.3.6` as the default.
+    default install for every user; `--tag next` keeps `0.3.7` as the default.
 27. Run `npm publish` once. `prepublishOnly` re-runs `ci:release` as a safety
     net; it is not a substitute for Part 1.
 28. A published version cannot be replaced. `npm unpublish` is restricted and
@@ -146,13 +149,13 @@ confirming the exact SHA and the commands.
 
 ## Part 7: post-publish verification and follow-ups
 
-29. `npm view @iowarp/clio-coder@0.3.7` and the selected dist-tag.
+29. `npm view @iowarp/clio-coder@0.3.8` and the selected dist-tag.
 30. 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.
-31. From an installation of 0.3.6, verify `clio-coder upgrade` finds and
-    applies 0.3.7.
+31. From an installation of 0.3.7, verify `clio-coder upgrade` finds and
+    applies 0.3.8.
 32. 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.
 33. Maintainer follow-up, independent of the release: verify the commit

package/docs/safety-model.md

@@ -1,7 +1,7 @@
 # Clio Coder Safety Model
 
 > [!TIP]
-> **Interactive Spec Available:** An interactive dashboard is located at [docs/html/safety_blueprint.html](html/safety_blueprint.html) (Version: 0.3.7).
+> **Interactive Spec Available:** An interactive dashboard is located at [docs/html/safety_blueprint.html](html/safety_blueprint.html) (Version: 0.3.8).
 
 Clio Coder's safety posture is code-enforced, not prompt-only. As the orchestrator coding agent in the [IOWarp](https://iowarp.ai) ecosystem developed by the [Gnosis Research Center](https://grc.iit.edu) at Illinois Tech under NSF Award [#2411318](https://www.nsf.gov/awardsearch/showAward?AWD_ID=2411318), Clio gates execution by target capabilities, the tool registry, the safety policy engine, project policies, protected-artifact checks, and audit receipts.
 

package/docs/scientific-validation.md

@@ -1,7 +1,7 @@
 # Clio Coder Scientific Validation Contracts
 
 > [!TIP]
-> **Interactive Spec Available:** An interactive numerical tolerance calculator and HPC queue execution simulator is located at [docs/html/validation_blueprint.html](html/validation_blueprint.html) (Version: 0.3.7).
+> **Interactive Spec Available:** An interactive numerical tolerance calculator and HPC queue execution simulator is located at [docs/html/validation_blueprint.html](html/validation_blueprint.html) (Version: 0.3.8).
 
 Scientific software development cannot treat simple file presence as proof of correctness. A simulation script that crashes on rank 48, or writes out NetCDF arrays filled with `NaN`s, may still successfully write a file to the disk. 
 

package/docs/skills-marketplace.md

@@ -1,7 +1,7 @@
 # Skills Marketplace
 
 > [!TIP]
-> **Interactive Spec Available:** An interactive dashboard is located at [docs/html/skills_blueprint.html](html/skills_blueprint.html) (Version: 0.3.7).
+> **Interactive Spec Available:** An interactive dashboard is located at [docs/html/skills_blueprint.html](html/skills_blueprint.html) (Version: 0.3.8).
 
 The Skills Hub (`/skill`) shows project skills, user skills, and the marketplace. Every marketplace row comes from the same local lookup that `clio-coder skills install <name>` and `/skill <name>` resolve through, so the hub lists nothing it cannot install.
 

package/docs/tool-usage.md

@@ -1,7 +1,7 @@
 # Tool Usage Reference
 
 > [!TIP]
-> **Interactive Spec Available:** An interactive seven-plane tool atlas and observation envelope truncation/offload calculator is located at [docs/html/tool_usage_blueprint.html](html/tool_usage_blueprint.html) (Version: 0.3.7).
+> **Interactive Spec Available:** An interactive seven-plane tool atlas and observation envelope truncation/offload calculator is located at [docs/html/tool_usage_blueprint.html](html/tool_usage_blueprint.html) (Version: 0.3.8).
 
 This is the deep usage reference behind the deliberately terse tool descriptions in the prompt envelope. Toolkit v2 keeps rich guidance out of tool descriptions and puts it here, where `context(scope="docs", query=...)` retrieves it section by section. Each tool below has its own self-contained `##` section covering the argument surface, defaults, truncation and continuation behavior, and concrete calls. Source of truth is `src/tools/`.
 

package/docs/trace-store.md

@@ -1,7 +1,7 @@
 # Trace store contract
 
 > [!TIP]
-> **Interactive Spec Available:** An interactive trace database viewer, schema inspector, and SQL query validator simulator is located at [docs/html/trace_blueprint.html](html/trace_blueprint.html) (Version: 0.3.7).
+> **Interactive Spec Available:** An interactive trace database viewer, schema inspector, and SQL query validator simulator is located at [docs/html/trace_blueprint.html](html/trace_blueprint.html) (Version: 0.3.8).
 
 Clio's trace database is a rebuildable, queryable mirror. Receipts, session
 ledgers, gate artifacts, and evidence remain the source of truth. Removing

package/docs/tui-design.md

@@ -1,7 +1,7 @@
 # Clio TUI Design System
 
 > [!TIP]
-> **Interactive Spec Available:** An interactive color/glyph token laboratory and terminal transcript preview renderer is located at [docs/html/tui_design_blueprint.html](html/tui_design_blueprint.html) (Version: 0.3.7).
+> **Interactive Spec Available:** An interactive color/glyph token laboratory and terminal transcript preview renderer is located at [docs/html/tui_design_blueprint.html](html/tui_design_blueprint.html) (Version: 0.3.8).
 
 This document is the reference specification for the Clio Coder TUI visual layout, styling, and behavior. It describes color semantics, the glyph vocabulary, structural recipes, and state choreography for all surfaces under [src/interactive/](../src/interactive/).