@iowarp/clio-coder 0.3.3 → 0.3.6

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.3). 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.6). 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.3, 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.6, forensic evidence auto-builds on dispatch run completion: when a run finalizes, the observability domain automatically compiles the evidence bundle under `<dataDir>/evidence/run-<id>/` and updates a compact sidecar index row in `<stateDir>/evidence-index.json`. Long-term memory records are local, evidence-linked, and only injected after explicit approval. Use the TUI [`/view`](observability.md) command for interactive inspection of receipts, dispatch output, durable tool output, compaction summaries, and session accountability before building or citing evidence.
 
 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:
@@ -174,7 +246,8 @@ Mutation-report receipts are grounded directly against observed tool events reco
 
 ```bash
 clio-coder memory list
-clio-coder memory propose --from-evidence <evidenceId>
+clio-coder memory propose --from-evidence <evidenceId> [scope options]
+clio-coder memory promote --from-handoff <path> [--entry <id>...] --scope <scope> [scope options]
 clio-coder memory approve <memoryId>
 clio-coder memory reject <memoryId>
 clio-coder memory prune --stale
@@ -195,6 +268,8 @@ The store is capped at `500` records and is sorted by scope, key, creation time,
 ```mermaid
 stateDiagram-v2
     evidence --> proposed: propose --from-evidence
+    taskBank --> proposed: /memory selected-entry action
+    redactedHandoff --> proposed: promote --from-handoff
     proposed --> approved: approve <id>
     proposed --> rejected: reject <id>
     approved --> rejected: reject <id>
@@ -205,6 +280,45 @@ stateDiagram-v2
 
 Records must cite at least one evidence ID to be considered for prompt injection. Rejected records remain in the store until stale pruning so the same bad lesson is not immediately re-proposed from the same evidence.
 
+Task-bank promotion is a reviewed export from transient execution memory. The
+`/memory` overlay offers repo and global proposal actions only on selected
+knowledge and procedural rows. Status remains private and cannot enter the
+promotion service. The first global action arms a warning, and the second
+action acknowledges the broader applicability. A successful action writes an
+unapproved record and names the separate `memory approve` command required to
+make it injectable.
+
+The CLI consumes a version 2 `clio-task-memory` handoff snapshot. Omitting
+`--entry` proposes every knowledge and procedural entry; repeating `--entry`
+selects exact entry IDs. Version 2 snapshots carry source session, evidence,
+runtime, agent, timestamps, and export-redaction facts. Version 1 snapshots
+remain seedable but cannot be promoted because they do not carry source
+session or evidence provenance.
+
+Every promotion redacts secret-shaped values before `records.json` is written.
+The durable provenance block records the source kind, session, selected entry,
+entry class and timestamps, plus the replacement count and source field paths.
+Promotion never approves its own output.
+
+### Explicit scope selection
+
+Reviewed scope options are closed to four choices:
+
+| Scope | Required selection | Validation |
+| --- | --- | --- |
+| `repo` | `--repository <canonical-absolute-path>` | The path must exist and already equal its canonical absolute identity. Symlink aliases and paths containing unresolved segments are rejected. |
+| `global` | `--acknowledge-global` | The acknowledgement is separate from `--scope global`. |
+| `runtime` | `--runtime <id>` | The ID must be valid and must occur in the source provenance. |
+| `agent` | `--agent <id>` | The ID must be valid and must occur in the source provenance. |
+
+The same options may be added to `memory propose --from-evidence`. With no
+scope option, evidence proposals keep the existing inference order. An
+explicit repository may differ from the repository that produced the
+evidence, which supports a reviewed lesson about repository A learned while
+working in repository B. Runtime and agent overrides may only select an exact
+identity already recorded by the evidence. Global scope always requires its
+own acknowledgement. No inference path widens an explicit choice.
+
 ---
 
 ## Prompt injection rules
@@ -215,7 +329,7 @@ Defaults:
 
 | Constraint | Default |
 | --- | --- |
-| Scopes | `global`, `repo` |
+| Base scopes | `global`, `repo` |
 | Token budget | `400` estimated tokens |
 | Max records | `5` |
 | Required status | `approved: true` |
@@ -224,6 +338,12 @@ Defaults:
 
 Rendered memory lines always cite record ID, scope, lesson, and evidence IDs. The prompt tells the model not to extrapolate beyond cited findings.
 
+Interactive main-agent sessions additionally admit records for the exact
+active runtime. `clio-coder run --agent` admits records for the exact resolved
+runtime and selected agent. Runtime and agent records use structured identity
+fields; `appliesWhen` text cannot grant either applicability. Missing,
+malformed, or different active identities exclude those records.
+
 ### Repository-scoped identity
 
 Repository memory is selected by an exact canonical absolute-path identity. The interactive orchestrator and `clio-coder run --agent` compute that identity from the active working directory; symlink aliases collapse to the same key. A repository move, a different Git worktree path, a subdirectory launch, a malformed identity, or a missing identity does not inherit another repository's memory. Global records are unaffected.
@@ -236,15 +356,27 @@ Every `scope: "repo"` record must carry:
 
 The structured `repository` field is the only applicability mechanism: store validation rejects repo records without it, and `appliesWhen` tokens never grant repository applicability. There is intentionally no automatic path rewrite for moved repositories or worktrees: a filesystem move produces a different identity and the record simply stops applying until it is re-scoped with new evidence.
 
+Runtime and agent records follow the same fail-closed shape:
+
+```json
+{ "runtime": { "kind": "runtime", "key": "openai" } }
+```
+
+```json
+{ "agent": { "kind": "agent", "key": "coder" } }
+```
+
+Only the field matching the record scope is present.
+
 ---
 
 ## Recommended workflow
 
 1. Build evidence from the run/session/eval that taught the lesson.
 2. Inspect the evidence and findings.
-3. Propose memory from the evidence.
-4. Review the proposed lesson for correctness and scope.
-5. Approve only if it is durable and useful.
+3. Propose memory from the evidence, or promote selected public task memory from `/memory` or a redacted handoff.
+4. Review the proposed lesson, source provenance, redaction facts, and exact scope.
+5. Approve only if it is durable and useful under that scope.
 6. Reject incorrect or overbroad records.
 7. Prune stale records periodically.
 

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.3).
+> **Interactive Spec Available:** An interactive change manifest editor, authority risk assessor, and checklist workspace is located at [docs/html/evolution_blueprint.html](html/evolution_blueprint.html) (Version: 0.3.6).
 
 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.3`.
+This document specifies the process exit codes, machine-readable JSON streaming formats, standard I/O separation rules, and `--help` conventions across all Clio Coder CLI commands in `v0.3.6`.
 
 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.3).
+> **Interactive Spec Available:** An interactive dashboard is located at [docs/html/extensions_blueprint.html](html/extensions_blueprint.html) (Version: 0.3.6).
 
 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.3",
+    "clioVersion": "0.3.6",
     "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.3).
+> **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.6).
 
 Clio Coder dispatches bounded worker agents. With a fleet configured, those
 workers run on remote machines over SSH while the orchestrator keeps every
@@ -77,7 +77,11 @@ briefing wins. Supplying both `task` and `tasks` fails instead of choosing one.
 After approval, execution consumes only the registry-owned resolved plan, so
 later mutation of raw arguments cannot change either field.
 
-Recipes may declare `budget: {toolCalls, readReserve, synthesis}`. `toolCalls` is the admitted-call phase boundary; the final `readReserve` slots accept canonical `read` plus the agent's granted mutation tools, so a writer can still deliver inside its own reserve; `synthesis: true` forces a text-only final round, while `false` stops after the admitted phase. `guardrails.workerToolCallCap` is transported separately as the ceiling on executed calls and always wins when lower. Native workers and Claude SDK enforce this policy. Claude Code and Antigravity reject explicit-budget recipes because their black-box loops cannot provide equivalent per-call mediation. Before launch, every admitted WorkerSpec v3 contains one concrete effective budget and a settings fingerprint, including custom recipes whose source omitted a budget.
+Recipes declare a default with `budget: {toolCalls, readReserve, synthesis}`. They may also declare `maximum: {toolCalls, readReserve}` inside that object. A recipe without `maximum` is an exact pin, which preserves the fixed behavior of existing recipes. A ranged recipe admits the optional dispatch request `budget: {toolCalls, readReserve, retryRevision?}` only when the request is inside its maximum. `retryRevision` has the same two integer fields and preauthorizes the ceiling that a later automatic retry, bounded result-contract revision, or review revision may select. The loop guard raises a result-contract revision boundary only in this case. A phase without that ceiling cannot grow and retains the existing text-only repair behavior.
+
+`toolCalls` is the admitted-call phase boundary. The final `readReserve` slots accept canonical `read` plus the agent's granted mutation tools, so a writer can still deliver inside its own reserve. Admission requires integers and `0 <= readReserve < toolCalls` for every declared phase. `synthesis: true` forces a text-only final round, while `false` stops after the admitted phase. `guardrails.workerToolCallCap` remains the operator-controlled lifetime ceiling and always wins when lower. A default may be clamped by a lower operator cap so default callers retain their prior behavior; an explicit request outside the operator cap is denied.
+
+Admission computes one immutable envelope with the recipe policy, invocation request, effective worker budget, and every clamp or escalation reason. Native workers and Claude SDK enforce the effective budget. Claude Code, Antigravity, and ACP delegation reject invocation envelopes because their black-box loops cannot provide equivalent per-call mediation. Before launch, every admitted WorkerSpec v3 still contains one concrete effective budget and a settings fingerprint. The envelope provenance is sealed in the run ledger and receipt and appears in monitor, fleet status, and the live fleet card.
 
 ## Node setup
 
@@ -579,6 +583,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
@@ -645,6 +662,27 @@ hard block.
   renders `local`), gate badges (`gate reviewer c2`), reroute badges, live
   tool activity (names only; arguments never cross the worker stdout seam),
   and a per-worker context meter.
+- `Enter` on the selected Fleet Runs row opens its worker detail: the phase,
+  the running call with a redacted action descriptor (`bash running npm
+  test`), and the bounded tail of the worker's own prose. The default list
+  stays compact, so a fan-out of scouts costs one card each until an operator
+  opens one. Detail follows the cursor rather than pinning to a run.
+- The board and the transcript worker block read one projection
+  (`src/interactive/worker-progress.ts`), so they cannot disagree about what a
+  worker is saying or touching. It keeps 40 lines and 4096 bytes of tail, 8
+  distinct tool names, 4 recent actions, and accepts 16 KB of delta bytes per
+  250 ms; what the bounds refuse is counted and named on the card beside the
+  `/view dispatch:<runId>` deep link.
+- Action descriptors are composed where the arguments are trusted: the tool
+  registry's admission path, the Claude tool mapper, and the ACP update
+  mapper. Each reads a fixed verb vocabulary and a fixed argument-field
+  allowlist, scrubs credentials, strips escape sequences, and bounds the
+  result to 64 characters before it crosses the worker stdout seam. Raw
+  argument objects never cross at all.
+- Reasoning content is never displayed. The detail may name a `thinking`
+  phase and the usage facts the card already carries, never the text.
+- Settlement replaces the provisional tail with the sealed receipt's answer;
+  a run whose receipt cannot be read keeps its own last durable message.
 - The context meter renders the worker's last-message context occupancy
   against the model's context window: healthy below 80 percent, warn from 80,
   critical from 95.
@@ -654,6 +692,7 @@ hard block.
 - The monitor tool reports the node and reroute lineage on `status`, `list`,
   and `collect`.
 - `clio-coder fleet status [--json]` shows the durable ledger view cross-process.
+- A worker permission escalation uses the `Worker escalation` consequence tier in operator presentation. The tier names the worker agent and run and describes where the one-shot answer returns. It does not approve the request, change the worker's inherited autonomy, or weaken the safety net; the existing worker escalation protocol remains the only resolution path.
 
 ## Speculation observer
 
@@ -682,11 +721,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.3). 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.6). You can open it directly in any web browser to view details dynamically.
 
 ---
 
@@ -229,7 +229,7 @@ Upgrading from 0.3.1 to 0.3.3 is automated:
 clio-coder upgrade
 ```
 
-Key lifecycle and operational updates in v0.3.3:
+Key lifecycle and operational updates in v0.3.6:
 - 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.3 defaults it to `off`, with conservative `auto` and explicit `on` available from the same section.

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.3).
+> **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.6).
 
 Clio Coder has two related but separate surfaces:
 
@@ -114,7 +114,24 @@ Middleware hook budgets are phase-aware through `DEFAULT_MIDDLEWARE_HOOK_BUDGETS
 
 Per-phase budgets can be overridden via `CLIO_CODER_HOOK_BUDGET_<PHASE>_MS` or global `CLIO_CODER_HOOK_BUDGET_MS`. Warmup grace exempts initial calls (`DEFAULT_HOOK_BUDGET_WARMUP_CALLS = 1`), and steady-state warnings trigger when at least 3 of the last 5 post-warmup calls exceed budget (`DEFAULT_HOOK_BUDGET_WINDOW = 5`, `DEFAULT_HOOK_BUDGET_THRESHOLD = 3`). Overruns are reported but do not abort the turn. The orchestrator and workers share the middleware contract, but worker guard state is process-local.
 
-Middleware reminders are visible request text, not hidden prompt state. `turn_start` reminders flush into the same accepted request; `turn_end` reminders flush once on the next request. The built-in stalled-turn rule can request one automatic continuation for a user prompt, then stops rather than looping forever.
+Middleware reminders are visible request text, not hidden prompt state. `turn_start` reminders flush into the same accepted request; `turn_end` reminders flush once on the next request. A `request_continuation` from any producer is capped at one automatic continuation per user prompt; a second producer in the same prompt gets a footer notice that the nudge is spent, and the turn is handed back to the operator rather than looped.
+
+### Built-in registrations
+
+These ship in every interactive session. Each is one bounded behavior with a visible reminder; none changes a tool policy or a safety verdict.
+
+| Id | Hooks | What it does |
+| --- | --- | --- |
+| `nudge.stalled-turn` | `turn_end` | The one declarative rule. A turn that called no tools and ended on an announced action ("Next I will inspect `src/cli/index.ts`") is continued once with a reminder to perform it or say plainly that it is finished. Questions, "let me know", conditional offers ("if you want me to"), and completion statements are not announcements. |
+| `observer.skills-reminder` | `turn_start`, `turn_end` | Once per session, on the first substantive turn, when installed or installable skills exist, injects one line teaching the suggestion protocol: list with `context(scope="skills")`, open the reply with `Suggested skill: /skill <name>` when one matches, then continue the task in the same turn. Only the operator loads a skill. At `turn_end`, a reply that made the suggestion and stopped with only listing calls behind it is continued once (#184): the suggestion is not the task. Greetings do not spend the session's one reminder; a resumed or forked session never gets one. |
+| `observer.task-board-reminder` | `turn_start` | Once per session, when the operator's text literally enumerates three or more steps (`1)`, `2.`, `step 3:`, or three bulleted lines), injects one line asking for `tasks action="plan"` before the first edit. Prose that merely mentions numbers never counts. |
+| `nudge.open-tasks` | `turn_end` | A settled work turn (one that called tools) that ends while the session task board still has pending or active tasks is continued once with the open list. Pure conversation turns, aborted or errored turns, and boards where every remaining task is blocked do not trigger. |
+| `nudge.detached-dispatch` | `turn_end` | A settled turn that ends while a detached dispatch batch has every run terminal and uncollected is continued once, naming the ready batches; `monitor mode="collect"` clears it, including across resume. Batches with runs still in flight, and surfaces without `monitor`, do not trigger. |
+| `nudge.read-only-exploration` | `after_tool`, `turn_end` | After nine or more read-only calls (`read`, `grep`, `find`, `ls`, `code_nav`, read-only shell) in one user turn without a successful Scout dispatch, injects one advisory to delegate broad reconnaissance to Scout. One advisory per user turn, and only on surfaces that have `dispatch`. |
+| `rail.unbacked-worker-claim` | `after_tool`, `turn_end` | A reply that reports worker or Scout results in a turn with no `dispatch` call gets one warning that the claim is not backed by a receipt. A `[worker result]` note the operator shared is receipt-backed and exempt. No continuation: the operator decides. |
+| `observer.memory-intervention` | `after_tool` | Every `memory.intervention.everyNTools` tool calls, asks a background model for a bounded reflection over the recent window and injects it as a reminder when it arrives. Governed by the `memory.intervention` settings block. |
+
+Two coded controls sit beside the registrations rather than among them. `tool-choice-control` turns `require_tool` and `lock_tools` effects into the provider's tool-choice field for the next round: a required tool clears when that tool starts, a lock lasts until the next submitted turn and outranks later requirements. `hook-receipts` is the durable ring (200 entries, throttled to one write per two seconds) of user-defined hook executions that `clio-coder config inspect` reads.
 
 User-defined hook declarations load from three places: `<extensionRoot>/hooks.yaml`, `.clio-coder/hooks.yaml`, and `.clio-coder/hooks.local.yaml`. A hook can be `prompt`, `effect`, or `command`. Command hooks run an argv array without a shell, under the workspace with a timeout and bounded output, and every hook execution emits a receipt.
 

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.3).
+> **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.6).
 
 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.3).
+> **Interactive Spec Available:** An interactive dashboard is located at [docs/html/observability_blueprint.html](html/observability_blueprint.html) (Version: 0.3.6).
 
 `/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.3 | The autonomy grade level enforced for the run | experimental |
-| `autonomyEnforcement.autonomy` | `string` | Always in v0.3.3 | The effective autonomy level name (e.g. auto-edit, suggest, read-only, full-auto) | experimental |
+| `autonomyEnforcement.grade` | `string` | Always in v0.3.6 | The autonomy grade level enforced for the run | experimental |
+| `autonomyEnforcement.autonomy` | `string` | Always in v0.3.6 | 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/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.3).
+> **Interactive Spec Available:** An interactive memory lifecycle dashboard and simulator is located at [docs/html/memory_blueprint.html](html/memory_blueprint.html) (Version: 0.3.6).
 
 Clio's proactive task memory protects long-running work from behavioral state
 decay: a requirement, environment fact, failed attempt, or diagnosis can still
@@ -133,7 +133,7 @@ it runs detached from it.
 | Interval | After `memory.intervention.everyNTools` completed tools since the last prompted step; default 10. This is the nondeterministic/citation-gated path. |
 | Tool-error streak | Two consecutive error outcomes. A successful tool resets the streak. |
 | Loop signal | Reuses the orchestrator loop guard's verdict; it does not infer a second competing loop detector. |
-| Repeated failure | The rules tier records failed tool fingerprints and annotates the failing tool result once the same failure appears twice in the bounded trajectory. |
+| Repeated failure | The rules tier records failed operation fingerprints and annotates the failing tool result once the same failure appears twice in the bounded trajectory. |
 | Post-compaction | The first turn start after compaction restores status and knowledge once, without a model call, because compaction is precisely where execution facts leave the active window. |
 
 ### Two delivery channels
@@ -145,11 +145,13 @@ repeated failure uses exactly one of them:
 
 - **Mid-turn annotation.** The second identical failure appends one cited
   `Memory:` advisory to that tool's own result, through the existing
-  `annotate_tool_result` effect the loop guard already uses. The advisory digest
-  takes the first line of the tool error that names a problem, falling back to
-  the first line when no line names one. The model reads it on its very next round.
-  This is spent once per fingerprint per turn and re-earned in a later turn, because
-  the same command failing again after an operator turn is news again.
+  `annotate_tool_result` effect the loop guard already uses. The advisory uses
+  the canonical result-disposition digest when one is available. Older hook
+  producers fall back to the first tool-error line that names a problem. Every
+  digest is redacted and byte-capped before it reaches the task bank. The model
+  reads the advisory on its very next round. This is spent once per operation
+  fingerprint per turn and re-earned in a later turn, because the same command
+  failing again after an operator turn is news again.
 - **Next-turn reminder.** Post-compaction reactivation and any background-model
   reminder ride the `inject_reminder` buffer into the next submitted turn, inside
   the visible `<system-reminder>` block, and persist in the session ledger.
@@ -319,15 +321,23 @@ operation while leaving deterministic protection active.
 Measured on the shipped prompt against `google/gemma-4-26b-a4b-qat`, across ten
 live steps and forty controlled runs on the same route.
 
-The tier writes `update_status` reliably and `save_knowledge` rarely, and that is
-correct rather than broken. A trajectory step carries the tool name, a bounded
-call description, an outcome, and a result digest. On success the digest is an
-opaque result fingerprint, so a window of successful reads tells the model which
-files were touched and nothing about what is in them. There is no durable fact in
-that input, and a status line is the only faithful thing to write about it.
-
-Three candidate causes were ruled out by controlled runs that changed one
-variable at a time:
+Earlier measurements found that the tier wrote `update_status` reliably and
+`save_knowledge` rarely. At that time a successful trajectory step carried an
+opaque result fingerprint, so a window of successful reads told the model which
+files were touched and nothing about what was in them.
+
+A current trajectory step keeps two fields with different jobs. The operation
+fingerprint identifies repeated calls and remains derived only from the tool name
+and arguments. The result digest is human-readable diagnostic content from the
+canonical result-disposition projection, with explicit source provenance. Secret
+redaction and a 240-byte cap apply before the digest reaches the task bank or the
+background request. A metadata-only disposition contributes outcome facts and no
+captured body. Results without a canonical disposition use a redacted deterministic
+fallback, so older tool producers remain useful without gaining a second model
+summarizer.
+
+Three candidate causes were ruled out in the earlier implementation by
+controlled runs that changed one variable at a time:
 
 - rewriting the prompt's second worked example to carry a `save_knowledge` moved
   nothing, and made the model emit no operations at all in four of five runs;