@iowarp/clio-coder 0.3.4 → 0.3.6

package/docs/release-cut-checklist.md

@@ -1,6 +1,6 @@
-# v0.3.4 Release-Cut Checklist
+# v0.3.6 Release-Cut Checklist
 
-The ordered steps that turn the prepared `v0.3.4` branch into a published
+The ordered steps that turn the prepared `v0.3.6` 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,13 +11,14 @@ state of every step.
 
 | Item | State |
 | --- | --- |
-| Branch | `v0.3.4`; `origin/v0.3.4` exists and is pushed to the reviewed tip before the cut |
-| `package.json` version | `0.3.4`; the top `CHANGELOG.md` heading is `## 0.3.4 - 2026-08-22` |
-| `main` | `8a1c8304`, the published `v0.3.3` commit; it is an ancestor of `v0.3.4` and moves only at Part 4. |
-| `origin/main` | `8a1c8304`, matching the published `v0.3.3` commit |
-| Tags | none for 0.3.4, local or remote |
-| GitHub Release | none for 0.3.4 |
-| npm registry | `@iowarp/clio-coder@0.3.4` absent; `latest` is `0.3.3` |
+| Branch | `v0.3.6`, local only; pushed with the explicit refspec `refs/heads/v0.3.6` when the operator decides, never as a bare name that a tag could shadow |
+| `package.json` version | `0.3.6`; the top `CHANGELOG.md` heading is `## 0.3.6 - 2026-08-23` |
+| `main` | `590fda7d`, which already carries the v0.3.5 content and the CI diet; it is an ancestor of `v0.3.6` and moves only at Part 4. |
+| `origin/main` | `590fda7d`, matching `main` with the v0.3.5 content and the CI diet |
+| Tags | none for 0.3.6, local or remote |
+| GitHub Release | none for 0.3.6 |
+| npm registry | `@iowarp/clio-coder@0.3.6` absent; `latest` is `0.3.4` |
+| npm history | `@iowarp/clio-coder` has published versions 0.3.0 through 0.3.4, with `latest` at 0.3.4. Version 0.3.5 was published and withdrawn, so `@iowarp/clio-coder@0.3.5` can never be reused. |
 | 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. |
 
 ---
@@ -38,8 +39,9 @@ Run against the exact final candidate with `NO_COLOR` unset and
    integrity, version coherence between `package.json` and the top
    `CHANGELOG.md` heading, the forbidden-file list, the required runtime
    resources, and the tarball and unpacked size budgets)
-9. Step 8 again under the other supported Node major. Both Node 22 and
-   Node 24 must be green; the repo is developed against 22.22.3 and 24.9.0.
+9. Optional: step 8 again under Node 24. Hosted CI gates on Node 22 alone,
+   the `engines` floor; the weekly `flake-hunt` workflow carries Node 24.
+   Repeat locally only when the cut touches runtime-sensitive code.
 10. `npm run live:smoke -- --target <id>` for one real headless turn through
     the built binary against a configured target, which is the one release
     check a deterministic suite cannot give. The packaged-install lifecycle
@@ -58,22 +60,22 @@ Run against the exact final candidate with `NO_COLOR` unset and
 ## Part 2: version and notes (repeatable)
 
 13. Files carrying a version reference, to update together if the number
-    changes: `package.json` and `package-lock.json`, the `## 0.3.4 - <date>`
-    heading in `CHANGELOG.md`, the `(Version: 0.3.4)` markers in `docs/*.md`,
-    the `Blueprint (v0.3.4)` titles in `docs/html/*.html`, the `--branch`
+    changes: `package.json` and `package-lock.json`, the `## 0.3.6 - <date>`
+    heading in `CHANGELOG.md`, the `(Version: 0.3.6)` markers in `docs/*.md`,
+    the `Blueprint (v0.3.6)` titles in `docs/html/*.html`, the `--branch`
     pin in the README install block (the hygiene lint checks it), and the
     measured-at figures in `scripts/check-release.mjs` if the package size
     moved materially.
-14. Confirm the `## 0.3.4` section of `CHANGELOG.md` describes every
+14. Confirm the `## 0.3.6` section of `CHANGELOG.md` describes every
     user-visible behavior change, including the ones that alter existing
     behavior, and carries no Workbench release narrative. The release workflow
     uses this section verbatim as the GitHub Release body.
 15. Re-run `npm run ci:release` after any version edit and commit as one
-    commit on `v0.3.4`.
+    commit on `v0.3.6`.
 
 ## Part 3: present the gate
 
-16. Report to the operator before touching `main`: the exact final `v0.3.4`
+16. Report to the operator before touching `main`: the exact final `v0.3.6`
     SHA and clean status, the commits added since the handoff SHA, the gate
     commands with pass/fail totals for both Node majors, the package version
     and changelog heading, the tarball audit, the clean-install results and any
@@ -92,35 +94,36 @@ confirming the exact SHA and the commands.
 ## Part 4: fast-forward `main`
 
 17. `git fetch origin` immediately before integrating; require `origin/main`
-    to be an ancestor of the reviewed `v0.3.4` tip and confirm no other
+    to be an ancestor of the reviewed `v0.3.6` tip and confirm no other
     worktree has `main` checked out.
-18. `git checkout main && git merge --ff-only v0.3.4`. No merge commit, no
+18. `git checkout main && git merge --ff-only v0.3.6`. No merge commit, no
     rebase, no reset. Verify `main` equals the reviewed SHA and is clean.
 19. `git fetch origin` once more; stop on any unexpected remote movement. Then
     `git push origin main`. Never `--force` or `--force-with-lease`.
 
 ## Part 5: exact-SHA CI, tag, GitHub Release
 
-20. Wait for the `ci` workflow the `main` push triggers. Both the Node 22 and
-    Node 24 jobs must succeed on the exact release SHA. A red or pending run
-    blocks the tag; a flake is rerun only with concrete evidence, never
-    silenced with an unrelated change.
-21. Reconfirm that tag `v0.3.4` and the GitHub Release do not exist, then
-    `git tag -a v0.3.4 -m "Clio Coder 0.3.4"` on the green SHA and
-    `git push origin v0.3.4`.
-22. The tag push triggers `.github/workflows/release.yml`, which requires a
-    successful `ci` run for the tagged SHA, verifies the tag matches
-    `package.json`, builds and audits the artifact, extracts the `## 0.3.4`
-    section of `CHANGELOG.md` as the release body, and attaches the tarball.
+20. The `main` push triggers the `ci` workflow. It is a useful signal but no
+    longer 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 tagging around it, and never silence a flake with an unrelated
+    change.
+21. Reconfirm that tag `v0.3.6` and the GitHub Release do not exist, then
+    `git tag -a v0.3.6 -m "Clio Coder 0.3.6"` on the green SHA and
+    `git push origin refs/tags/v0.3.6`.
+22. 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.6` 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)
 
 23. `npm whoami` and confirm the registry and account; reconfirm
-    `@iowarp/clio-coder@0.3.4` is still absent.
+    `@iowarp/clio-coder@0.3.6` is still absent.
 24. Obtain the operator's explicit dist-tag decision. `latest` makes this the
-    default install for every user; `--tag next` keeps `0.3.3` as the default.
+    default install for every user; `--tag next` keeps `0.3.4` as the default.
 25. Run `npm publish` (or `npm publish --tag next`) once. `prepublishOnly`
     re-runs `ci:release` as a safety net; it is not a substitute for Part 1.
 26. A published version cannot be replaced. `npm unpublish` is restricted and
@@ -128,13 +131,13 @@ confirming the exact SHA and the commands.
 
 ## Part 7: post-publish verification and follow-ups
 
-27. `npm view @iowarp/clio-coder@0.3.4` and the selected dist-tag.
+27. `npm view @iowarp/clio-coder@0.3.6` and the selected dist-tag.
 28. On a clean machine, `npm install -g @iowarp/clio-coder` from the registry
     rather than from a local tarball, then repeat step 12 against it, plus
     `configure` to a real target and one real turn when one is authorized.
     This is the only step that tests what users actually receive.
-29. From an installation of 0.3.3, verify `clio-coder upgrade` finds and
-    applies 0.3.4.
+29. From an installation of 0.3.4, verify `clio-coder upgrade` finds and
+    applies 0.3.6.
 30. Record the SHA, CI URL, tag, GitHub Release URL, npm version and dist-tag,
     tarball evidence, and the post-publish verification in the release report.
 31. Maintainer follow-up, independent of the release: verify the commit

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.4).
+> **Interactive Spec Available:** An interactive dashboard is located at [docs/html/safety_blueprint.html](html/safety_blueprint.html) (Version: 0.3.6).
 
 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.
 
@@ -13,7 +13,7 @@ Source of truth: `src/domains/safety/**`, `src/tools/registry.ts`, `src/tools/bo
 
 The `autonomy` setting (`read-only` | `suggest` | `auto-edit` | `full-auto`) is an enforced dial. It controls exactly one thing: which action classes run immediately, which park for operator approval, and which are auto-denied. The safety net (damage-control rules, path policy, protected artifacts, loop guard, dispatch scope admission) is independent of the dial and identical at every level. When a `[safety-net]` notice appears at full-auto, that is the always-on net working as designed, not a contradiction of the level.
 
-In Clio Coder v0.3.4, effective autonomy resolution is strictly centralized in `src/entry/orchestrator.ts` through `resolveEffectiveAutonomy` and `resolveBaselineAutonomy`. Every admission surface (tool registry admission, dispatch plan provenance, and ACP session snapshots) delegates to this pair of functions so that fallback paths cannot diverge across execution contexts. `resolveBaselineAutonomy` evaluates dispatch settings overrides, headless CLI options, and configuration settings before applying the default `auto-edit` level. `resolveEffectiveAutonomy` combines any active ACP session autonomy level with the baseline resolution.
+In Clio Coder v0.3.6, effective autonomy resolution is strictly centralized in `src/entry/orchestrator.ts` through `resolveEffectiveAutonomy` and `resolveBaselineAutonomy`. Every admission surface (tool registry admission, dispatch plan provenance, and ACP session snapshots) delegates to this pair of functions so that fallback paths cannot diverge across execution contexts. `resolveBaselineAutonomy` evaluates dispatch settings overrides, headless CLI options, and configuration settings before applying the default `auto-edit` level. `resolveEffectiveAutonomy` combines any active ACP session autonomy level with the baseline resolution.
 
 ### Autonomy levels
 
@@ -40,6 +40,27 @@ The `system_modify` confirm is level-invariant, so it is enforced and attributed
 
 The level is persisted as `autonomy` in `settings.yaml`, hot-reloads, and is edited in the `/settings` Autonomy & Safety section.
 
+### Consequence tier is presentation, not authority
+
+Every operator decision also receives one closed consequence tier. The tier explains what the already-required decision can affect. It never decides whether a call runs, never changes the autonomy level, and never overrides a safety-net verdict. Registry admission still follows the enforcement path below before any presentation is built.
+
+| Consequence tier | Trusted facts that select it | Operator-facing meaning |
+| --- | --- | --- |
+| Conversational answer | A local `ask_user` question that records an answer | Records an answer without granting tool authority. |
+| Workspace authority | A main-agent one-shot approval whose bounded scope is the workspace | Authorizes only the presented call. Workspace changes can be reviewed and reverted when the action class supports that. |
+| Outward consequence | Typed `exposure: outward` | The answer concerns a step that can reach people or systems outside the workspace. The interview itself does not publish or send anything. |
+| Safety-net confirmation | An always-on confirm rail | The safety net requires a one-shot operator decision independently of the autonomy level. |
+| System change | `system_modify`, destructive, unknown, or otherwise system-scoped consequences | The effect reaches outside the workspace or cannot be safely bounded, and reversibility is unknown. |
+| Worker escalation | An authenticated dispatched-worker origin | The parked decision belongs to the named worker run and returns only to that exact request. |
+
+The classifier reads the request kind, the enforced safety or autonomy axis, normalized local or outward exposure, derived reversibility and scope, authenticated main-agent or worker origin, and whether the surface records an answer or grants one-shot authority. Model-authored questions, reasons, summaries, option labels, titles, and color names do not enter the classifier. Worker and system facts take conservative precedence, and an unknown action class uses the system tier. An interview that has reached outward exposure keeps that tier for later rounds and durable replay, so a later local declaration cannot visually lower it.
+
+These three concepts answer different questions:
+
+- The autonomy level decides when the registry allows, parks, or denies an action class.
+- The safety-net axis identifies an always-on rule that can block or require confirmation at every autonomy level.
+- The consequence tier explains the scope, reversibility, requester, and effect of a decision that the enforced axes have already produced.
+
 ---
 
 ## Enforcement path
@@ -237,7 +258,7 @@ Prefer typed tools over Bash:
 
 A package-script check and the frontend validator are in the no-prompt set at `auto-edit`: both are bounded by the verification-script family and a fixed argv shape. A project-catalog check is not. The engine resolves the check id against `.clio-coder/verifiers.yaml` on every call and treats the declared argv exactly like a bash command string: the damage-control rules and the zero-access read guard scan it, and it is tagged unrecognized, so `auto-edit` parks it for one confirmation that shows the argv and `full-auto` runs it. `.clio-coder/verifiers.yaml` and `.clio-coder/safety.yaml` are read-only to the model's `write`, `edit`, and bash redirect paths through the default path policy: both files are operator authority, and a model that could author either one could widen its own permissions in two tool calls.
 
-The project verifier catalog is an executable authority supplied by the repository, not by model prose. Its schema rejects unknown fields, shell strings and shell executables, invalid or duplicate IDs, oversized values, absolute or escaping working directories, unsupported versions, and collisions with package-provider IDs. A catalog entry fixes argv, repository-relative cwd, and timeout. Tool-call `args`, `cwd`, timeout, output-cap, or environment-shaped fields cannot widen it. Safe-exec uses `spawn` without a shell, filters the child environment to the Clio allowlist, honors cancellation, and reports exact argv and termination evidence.
+The project verifier catalog is an executable authority supplied by the repository, not by model prose. Its schema rejects unknown fields, shell strings, invalid or duplicate IDs, oversized values, absolute or escaping working directories, unsupported versions, and collisions with package-provider IDs. It also refuses the common shell executables (`sh`, `bash`, `zsh`, and the like) as argv[0], which is a tripwire against the obvious mistake rather than a sandbox: `python3 -c`, `node -e`, and `env bash -c` pass the schema, so the authority boundary is the fact that the catalog file is operator-owned and read-only to the model, and that every catalog check is scanned by the damage-control rules and parked at `auto-edit`. A catalog entry fixes argv, repository-relative cwd, and timeout. Tool-call `args`, `cwd`, timeout, output-cap, or environment-shaped fields cannot widen it. Safe-exec uses `spawn` without a shell, filters the child environment to the Clio allowlist, honors cancellation, and reports exact argv and termination evidence.
 
 `clio-coder verifiers discover` and `clio-coder verifiers author` do not grant authority during inspection. They read only declared package, Cargo, CMake preset, Python runner, Go module, and YAML validation-command signals and render exact argv vectors with provenance. The preview names the catalog path, cwd, timeout, tags, and authority consequence for every check. Toolchain conventions are labeled separately from literal project declarations. Ambiguous validation prose and directory-only hints are rejected with a JSON argv manual-entry path.
 
@@ -286,7 +307,7 @@ Evidence raises a warn-level external-bypass finding for bypassed runs and an in
 
 ## Approvals
 
-An `ask` can come from either axis: a safety-net confirm rail (damage-control `ask` rule, project `requireConfirmation`, `system_modify`) or the autonomy mapping. The permission overlay names the asking axis on its `Asked by:` line, and the transcript carries an `[approval]` notice for every parked call.
+An `ask` can come from either axis: a safety-net confirm rail (damage-control `ask` rule, project `requireConfirmation`, `system_modify`) or the autonomy mapping. The permission overlay names the authenticated requester and asking axis on its `Requested by:` lines, and the transcript carries an `[approval]` notice for every parked call.
 
 Every approvable ask has one canonical identity: a `requestId` minted at the approvals plane. The `PermissionRequested` and `PermissionResolved` bus payloads and the audit permission rows all carry it, along with `origin` (who asked), `axis` (which rail or level), and `decidedBy` (who or what answered), so a request joins its resolution on one key across the bus, the ledger, and receipts, and every request resolves exactly once. Worker escalations forward their full decision provenance (reasons, reason code, rule id, policy source), so the overlay names the real asking rail for a worker exactly as it does for the main agent.
 
@@ -294,9 +315,10 @@ How an ask resolves depends on the context:
 
 ### Interactive TUI Behavior
 
-In interactive mode, a permission request opens a queued overlay prompt immediately in the TUI.
-- **Queued Overlays:** If multiple tools or worker dispatches require permission during a single turn, the TUI queues the requests. Closing one overlay automatically pops the next permission overlay in the queue.
-- **Operator Options:** The operator can grant permission once, which resumes only the parked tool call without changing the overall operating posture; the one-shot grant is scoped to the presented request's `requestId`. Denying rejects only the presented request and advances the queue; the next parked call re-presents. Cancel-all is reserved for shutdown, an aborted turn, headless runs, and transport failure, where no operator can answer.
+In interactive mode, a permission request opens a queued overlay prompt immediately in the TUI, and the composer rail switches to `CONFIRM` with the same keys for as long as the prompt owns the keyboard.
+- **Queued Overlays:** If multiple tools or worker dispatches require permission during a single turn, the TUI queues the requests. Closing one overlay automatically pops the next permission overlay in the queue. Each queued request retains its consequence tier and authenticated requester. A request that arrives while a different overlay (a picker, `/context`, the fleet board) holds the screen is announced with an `[approval]` notice and re-presented the moment that overlay closes.
+- **Operator Options:** `Enter` grants permission once, which resumes only the parked tool call without changing the overall operating posture; the one-shot grant is scoped to the presented request's `requestId`. `Esc` denies only the presented request and advances the queue; the next parked call re-presents. `s` denies it and ends the turn. Cancel-all is reserved for shutdown, an aborted turn, headless runs, and transport failure, where no operator can answer.
+- **Enter never doubles as send:** `Enter` allows only from an empty composer. While the composer holds a draft, `Enter` does nothing, both surfaces say `[Backspace] clear draft` in its place, and only deletion keys reach the editor. An operator who typed a message and pressed the habitual send key cannot approve a parked call by accident; on a safety rail the ambiguous key resolves away from allow.
 
 ### Deterministic Headless Behavior
 

package/docs/scientific-validation.md

@@ -1,11 +1,11 @@
 # 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.4).
+> **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.6).
 
 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. 
 
-Clio Coder recognizes **scientific validation contract files** as an opt-in signal for a higher evidence bar. In v0.3.4, the session rigor resolver does not parse or enforce a scientific contract schema. The presence of `.clio-coder/validation.yaml`, `.clio-coder/validation.yml`, `validation.yaml`, `validation.yml`, or `VALIDATION.md` at the workspace root raises the default rigor level to `high`; the file contents are advisory material for developers, project agents, and external validators.
+Clio Coder recognizes **scientific validation contract files** as an opt-in signal for a higher evidence bar. In v0.3.6, the session rigor resolver does not parse or enforce a scientific contract schema. The presence of `.clio-coder/validation.yaml`, `.clio-coder/validation.yml`, `validation.yaml`, `validation.yml`, or `VALIDATION.md` at the workspace root raises the default rigor level to `high`; the file contents are advisory material for developers, project agents, and external validators.
 
 This advisory convention is separate from the executable project verifier catalog at `.clio-coder/verifiers.yaml`. The verifier catalog has a strict version-1 schema and admits exact argv vectors to the `verify` tool. Scientific validation contracts and handbook expectations do not grant command authority: prose such as `validators: ["python tools/check_grid.py"]` remains guidance until the project owner confirms the equivalent argv, cwd, timeout, and tags in `verifiers.yaml`. The executable catalog does not interpret numerical tolerances or artifact expectations; it only runs the explicitly declared process vector through safe-exec.
 
@@ -95,7 +95,7 @@ Comparing floating-point values in scientific computations must accommodate roun
 
 ## Common Scientific Artifact Families
 
-The following labels are useful project conventions for validation contracts and reports. They are not a closed, core-enforced enum in v0.3.4:
+The following labels are useful project conventions for validation contracts and reports. They are not a closed, core-enforced enum in v0.3.6:
 
 - **`HDF5` / `NetCDF` / `Zarr`:** Multi-dimensional scientific array files.
 - **`FITS`:** Flexible Image Transport System (used in astrophysics).

package/docs/session-lifecycle.md

@@ -1,6 +1,6 @@
 # Session Lifecycle
 
-This document is the authoritative specification for Clio Coder interactive and headless session lifecycles, on-disk ledger structures, tree-based conversation branching, checkpoints, and recovery protocols in `v0.3.4`.
+This document is the authoritative specification for Clio Coder interactive and headless session lifecycles, on-disk ledger structures, tree-based conversation branching, checkpoints, and recovery protocols in `v0.3.6`.
 
 Source implementations: `src/engine/session.ts` and `src/domains/session/`.
 

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.4).
+> **Interactive Spec Available:** An interactive dashboard is located at [docs/html/skills_blueprint.html](html/skills_blueprint.html) (Version: 0.3.6).
 
 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,11 +1,11 @@
 # 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.4).
+> **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.6).
 
 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/`.
 
-In Clio Coder v0.3.4, `src/tools/agent-tools.ts` serves as the single agent-tool adapter across both orchestrator and worker runtimes. Both surfaces resolve their executable tools through the exact same `effectiveToolNames` narrowing, ensuring that attested tool schemas never drift from the tools available at runtime. Tools are keyed strictly by the `ToolName` union with no alias table. Argument leniency for weak-model callers is provided exclusively by per-tool `prepareArguments` normalizers declared on `ToolSpec`.
+In Clio Coder v0.3.6, `src/tools/agent-tools.ts` serves as the single agent-tool adapter across both orchestrator and worker runtimes. Both surfaces resolve their executable tools through the exact same `effectiveToolNames` narrowing, ensuring that attested tool schemas never drift from the tools available at runtime. Tools are keyed strictly by the `ToolName` union with no alias table. Argument leniency for weak-model callers is provided exclusively by per-tool `prepareArguments` normalizers declared on `ToolSpec`.
 
 ## Observation envelope: truncation notices, offload, next hints, and the turn budget
 

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.4).
+> **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.6).
 
 Clio's trace database is a rebuildable, queryable mirror. Receipts, session
 ledgers, gate artifacts, and evidence remain the source of truth. Removing

package/docs/troubleshooting.md

@@ -1,6 +1,6 @@
 # Troubleshooting & Error Remediation
 
-This guide provides concrete, actionable remediation procedures for operational errors, permission denials, target connection failures, and system diagnostics in Clio Coder `v0.3.4`.
+This guide provides concrete, actionable remediation procedures for operational errors, permission denials, target connection failures, and system diagnostics in Clio Coder `v0.3.6`.
 
 ---
 

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.4).
+> **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.6).
 
 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/).
 
@@ -36,7 +36,7 @@ All color styling is defined in [src/interactive/theme/tokens.ts](../src/interac
 - Color is used functionally to indicate state. If removing a color does not lose information, the text is colored using `dim`, `muted`, or left unstyled.
 - `warning` amber is reserved for true warnings. Costs and neutral telemetry numbers use `muted`.
 - `accentDeep` is used only in section tags. Metric values (such as TTFT, tokens-per-second, and autonomy status) use `muted`.
-- `action` neon orange remains scarce and strictly disciplined: only while Clio is acting or a prompt owns the keyboard (e.g. running connect/probe operations, active dispatch/fleet execution, or the keyboard-owning confirmation border / `STEER` mode). It is never used for idle decoration or settled telemetry, and never appears on more than one element per screen region.
+- `action` neon orange remains scarce and strictly disciplined: only while Clio is acting, for workspace-authority and worker-escalation decision frames, or in `STEER` mode. It is never used for idle decoration or settled telemetry, and never appears on more than one element per screen region. Outward, safety-net, and system decision frames use `warning`; conversational answers use `accent`.
 - Per-surface color budgets limit noise: chip strips use at most one non-neutral token per chip, and framed cards use at most one status token alongside neutral colors.
 
 ---
@@ -118,6 +118,8 @@ Overlay frames share the island's top border rules and include keyboard shortcut
 └─ [Tab] mode · [Esc] close ─────────────────┘
 ```
 
+Fleet run cards add two bounded budget rows when native dispatch admission supplies an envelope. The `policy` row shows the recipe default or exact pin, its optional maximum, and the invocation request. The `budget` row shows the effective phase, the operator lifetime cap, and the clamp or retry/revision escalation reason. Historical or external-agent rows without this provenance omit both rows.
+
 ### 4.3 Section Headers
 
 - **Panel Section Tag**: Bold CAPS in `accentDeep`.
@@ -144,6 +146,21 @@ All TUI overlays and cards support compact widths down to 40 columns:
 - Keybinding hints, cards, and markdown detail text wrap fluidly without horizontal clipping.
 - Settings provides a dedicated drill-down stack below 72 columns.
 
+### 4.7 Decision Consequence Frames
+
+Permission confirmation and `ask_user` use one pure consequence presentation classifier while keeping separate input and execution protocols. The classifier supplies the tier title, semantic frame token, consequence and reversibility copy, requester attribution, and display actions. Permission keeps allow-once, deny, and stop behavior. `ask_user` keeps selection, free-text, cancellation, and its compact, panel, or interview layout chosen from question shape.
+
+| Tier | Title | Token | Plain-text identity |
+| --- | --- | --- | --- |
+| Conversation | `Answer a question` | `accent` | `Conversational answer` |
+| Workspace | `Approve workspace action` | `action` | `Workspace authority` |
+| Outward | `Confirm outward consequence` | `warning` | `Outward consequence` |
+| Safety net | `Safety-net confirmation` | `warning` | `Safety-net confirmation` |
+| System | `Approve system change` | `warning` | `System change` |
+| Worker | `Worker needs approval` | `action` | `Worker escalation` |
+
+The words carry the meaning when color is disabled. Permission copy states the exact one-shot authority, whether effects are reversible, the authenticated requester and axis, and what deny and stop do. The classifier never consumes question, reason, summary, option-label, or requested-title prose, so those strings cannot select or lower a tier.
+
 ---
 
 ## 5. Screen Surfaces & State Choreography
@@ -230,6 +247,7 @@ The collapsed form is one composed ledger line:
 - Expanded calls show the primary argument in the signature and every secondary argument as a typed field list. Multiline argument bodies become line and byte facts, nested objects retain structured rendering, and safety-sensitive values remain redacted.
 - Running calls label `live output` and replace the cumulative partial result in place. Settled calls label `output` and show available exit status, result or observation counts, line count, displayed and total byte sizes, truncation, timeout, tool-token usage, dynamically added tools, context exclusion, and the full-output path. A blocked or aborted admission instead labels its `decision` and does not claim that the tool ran.
 - A call parked for one-shot approval replaces its running timer with `awaiting approval` and shows the already-sanitized action class, asking safety axis, and target below the row. These facts are transient UI state: approval, denial, abort, or settlement clears them, and they are never reconstructed from the session ledger.
+- The live permission frame derives its consequence tier from those typed facts and the authenticated origin. It anchors at bottom center with five rows reserved for the composer and footer, and it recomputes that anchor on resize. Each queued frame retains its own tier and requester.
 - Text and image tool results keep their text while rendering images as MIME and byte-size placeholders; base64 image data is never written to the terminal.
 - Successful `edit` and `write` calls render the bounded diff produced by the tool result. Live regular-screen and fullscreen rows color removed and added lines with the `error` and `success` tokens and emphasize changed words; `/resume` replay and `/export` keep the same numbered diff as plain text.
 - Operator `!` and `!!` bash commands use the same running and settled block as model-initiated bash. The block appears before the process starts, streams the throttled cumulative stdout/stderr tail, and settles in place while the existing `bashExecution` session entry remains the durable record. `!!` continues to exclude that record from model context and says so in the block.
@@ -294,13 +312,22 @@ The `/settings` overlay is a full-screen transactional control center:
 - **Scoped Models Checklist**: Settings → `Models` provides a provider-backed checklist subview with target-level and target/model items, checked current selections, `Space` to toggle, and capability details in the inspector. Unresolved model references are preserved under an `Unavailable` group.
 - **Narrow Terminal Drill-Down Navigation**: Below 72 columns, Settings transitions from a split view to a modal drill-down stack (section list → section rows → detail drawer) with a breadcrumb and `Esc` moving up one level before closing. Includes `/` filtering across label, path, and description, narrowing per keystroke like `/model` and `/resume`. Below 60 columns, side margins are removed for full-width presentation.
 
-### 7.2 Task and Decision Boards
+### 7.2 Fleet Runs Board
+
+The `Alt+W` board renders one card per run. The default list is compact: run id, route, task, status, telemetry, retry, tool names, and proof. `Enter` opens the selected run's worker detail, which adds two rows to that card and nothing to any other:
+
+- **`doing`**: the phase (`◐ thinking` in `reason`, `◑ writing` in `accent`, `⚙ tool` in `action`, `◔ waiting` in `info`) followed by the running call as `<tool> <verb> <object>`, or the last finished call as `last <tool> <verb> <object>`. The verb and object come from a descriptor composed at the worker seam; raw arguments never reach the renderer.
+- **`answer`**: the newest rows of the worker's bounded prose on a `│` rail with a hanging indent under the key, then a dim row naming the lines and bytes the bounds refused and the `/view dispatch:<runId>` deep link.
+
+Wrapping happens before the row cap, so the block is at most six rows tall at any width and a streaming answer cannot make the card grow under the operator. Detail follows the cursor rather than pinning to a run, and closing the board closes it. Reasoning text is never rendered; the `thinking` phase word is the whole of what the board says about it.
+
+### 7.3 Task and Decision Boards
 
 - **Composite Tasks Board (`/tasks`, `Alt+B`)**: Presents four sections in one reopenable overlay: the live session board, terminal task history, successful workspace artifacts, and project-scoped operator tasks. Selecting a workspace artifact opens the filtered `/view` path. Operator rows support add, hand, done, and drop actions; refresh is explicit for captured history and artifacts, while lightweight repaint reads the current board snapshot.
 - **Settled Decisions Board (`/decisions`, `Alt+D`)**: Groups completed and cancelled interviews on the active branch, expands source questions and answers, and lets the operator supersede a value or submit a correction. Corrections travel through the ordinary operator-turn path after the durable decision snapshot is updated.
 - **Approved editor overrides**: `Alt+B` and `Alt+D` are deliberate application-input boundary overrides of Pi's editor word-back and word-delete chords. Clio routes them before the editor so the two global boards remain one chord away. They are explicit exceptions to the general rule that Clio app bindings avoid Pi editor reserves, and users may rebind the Clio actions in `settings.yaml`.
 
-### 7.3 Slash Autocomplete Command Palette
+### 7.4 Slash Autocomplete Command Palette
 - **Grouped Palette**: Typing `/` opens a grouped command palette (ordered by `Run`, `Inspect`, `Configure`, `Sessions`) with compact argument hints and formatted descriptions.
 - **One Canonical Spelling**: Autocomplete, help, and parsing expose the same unique slash-command names; no alias rows compete with canonical commands.
 
@@ -330,3 +357,10 @@ Two shapes, both ending at something the user can act on.
 ### 8.2 Memory Step Rows
 
 `/memory` activity rows read `<trigger> <decision> <reason>`, followed by `<N>w` when the step wrote to the bank and `<N> cited` when it cited entries, then the tier and latency. `describeTaskMemoryActivity` is the one place that builds this string.
+
+Knowledge and procedural task-bank rows expose `p` to propose the selected
+entry for the active canonical repository and `g` to propose it globally.
+Global scope requires a second `g` press on the same entry after the warning
+line appears. Status rows are labeled private and neither action can promote
+them. Both actions create unapproved durable proposals, show the resulting
+memory ID, and leave approval to the separate reviewed memory lifecycle.

package/docs/worker-dispatch-mechanics.md

@@ -1,7 +1,7 @@
 # Worker Dispatch Mechanics
 
 > [!TIP]
-> **Interactive Spec Available:** An interactive NDJSON protocol timeline stream and heartbeat watchdog simulator is located at [docs/html/worker_dispatch_blueprint.html](html/worker_dispatch_blueprint.html) (Version: 0.3.4).
+> **Interactive Spec Available:** An interactive NDJSON protocol timeline stream and heartbeat watchdog simulator is located at [docs/html/worker_dispatch_blueprint.html](html/worker_dispatch_blueprint.html) (Version: 0.3.6).
 
 This document describes the design and lifecycle of Clio Coder dispatched workers, focusing on the spawning sequence, execution isolation, the standard input/output NDJSON communication loop, and permission escalation routing.
 

package/package.json

@@ -1,6 +1,6 @@
 {
 	"name": "@iowarp/clio-coder",
-	"version": "0.3.4",
+	"version": "0.3.6",
 	"description": "Coding agent for HPC and scientific-software developers, part of IOWarp's CLIO ecosystem of agentic science.",
 	"keywords": [
 		"ai",
@@ -76,7 +76,6 @@
 		"test:file": "node --import tsx --import ./tests/harness/tmp-root.ts --test",
 		"pretest": "test -f dist/assets/codewiki.json && [ -z \"$(find src -newer dist/assets/codewiki.json -type f -print -quit)\" ] || npm run build",
 		"test": "node scripts/shard-tests.mjs",
-		"test:coverage": "node scripts/test-coverage.mjs --experimental-test-coverage --test-coverage-include='src/**/*.ts' --test-coverage-exclude='src/**/*.d.ts' 'tests/contracts/**/*.test.ts' 'tests/smoke/**/*.test.ts'",
 		"test:repeat": "node scripts/repeat-tests.mjs",
 		"test:trace-viewer": "npm --prefix apps/trace-viewer test",
 		"trace:ui": "node apps/trace-viewer/server.mjs",
@@ -86,9 +85,12 @@
 		"prepublishOnly": "npm run ci:release",
 		"skills:pin": "node --import tsx scripts/pin-skills.ts",
 		"skills:check": "node --import tsx scripts/pin-skills.ts --check",
+		"benchmark:typecheck": "tsc -p benchmarks/tsconfig.json",
+		"benchmark:check": "npm run benchmark:typecheck && node --import tsx --test benchmarks/internal/tests/*.test.ts",
+		"benchmark:campaign": "node --import tsx benchmarks/internal/campaign.ts",
+		"benchmark:report": "node --import tsx benchmarks/internal/report.ts",
 		"//": "below here: a real model target, chosen with --target <id>; costs money and/or GPU time, never run in CI",
 		"live:smoke": "node --import tsx benchmarks/internal/live-smoke.ts",
-		"live:recon": "node --import tsx benchmarks/internal/live-recon.ts",
 		"live:fleet-dispatch": "node --import tsx benchmarks/internal/live-fleet-dispatch.ts",
 		"live:tui": "node --import tsx benchmarks/internal/pty-drive.ts",
 		"live:home": "node --import tsx benchmarks/internal/live-home.ts"
@@ -100,7 +102,8 @@
 		"@earendil-works/pi-tui": "0.84.0",
 		"@silvia-odwyer/photon-node": "^0.3.4",
 		"grok-mermaid": "0.2.2",
-		"ollama": "0.6.3"
+		"ollama": "0.6.3",
+		"smol-toml": "1.8.0"
 	},
 	"overrides": {
 		"@anthropic-ai/sdk": "0.105.0",

package/src/cli/agents.ts

@@ -53,8 +53,7 @@ export async function runAgentsCommand(args: ReadonlyArray<string>): Promise<num
 function renderLine(spec: AgentSpec): void {
 	const shape = `${spec.audience}/${spec.category}/${spec.capabilityClass}/${spec.latencyClass}`;
 	const skills = spec.skills.length > 0 ? ` skills=${spec.skills.join(",")}` : "";
-	const budget = spec.budget
-		? `${spec.budget.toolCalls}/${spec.budget.readReserve}/${spec.budget.synthesis ? "synthesize" : "stop"}`
-		: "operator-default";
+	const maximum = spec.budget.maximum ? `..${spec.budget.maximum.toolCalls}/${spec.budget.maximum.readReserve}` : "";
+	const budget = `${spec.budget.toolCalls}/${spec.budget.readReserve}${maximum}/${spec.budget.synthesis ? "synthesize" : "stop"}`;
 	process.stdout.write(`${spec.id.padEnd(20)} ${shape.padEnd(48)} ${spec.description}${skills} budget=${budget}\n`);
 }

package/src/cli/argv.ts

@@ -102,6 +102,19 @@ export function globalFlagPositionHint(arg: string, command: string): string | n
  * for the command boundary, so `--skill path --api-key SECRET paths` treated
  * SECRET as a subcommand and printed it in an error.
  */
+/**
+ * Sessions are resumed from the interactive picker, not from a flag, and the
+ * flag every other agent CLI spells `--resume` or `--continue` fails closed
+ * here. The failure names the picker so the habit lands somewhere (#191).
+ */
+function unknownGlobalOptionError(arg: string): string {
+	const bare = arg.replace(/=.*$/u, "");
+	if (bare === "--resume" || bare === "--continue" || bare === "-r" || bare === "-c") {
+		return `unknown global option: ${arg}. Sessions are resumed from inside the app: start clio-coder, then type /resume to pick one.`;
+	}
+	return `unknown global option: ${arg}`;
+}
+
 export function extractGlobalFlags(
 	argv: ReadonlyArray<string>,
 	isSubcommand: (token: string) => boolean = () => false,
@@ -156,7 +169,7 @@ export function extractGlobalFlags(
 			noSkills,
 			skillPaths,
 			rest,
-			error: `unknown global option: ${arg}`,
+			error: unknownGlobalOptionError(arg),
 			...(apiKey === undefined ? {} : { apiKey }),
 		};
 	}

package/src/cli/fleet.ts

@@ -37,6 +37,13 @@ import {
 import type { ConfigContract } from "../domains/config/contract.js";
 import { ConfigDomainModule } from "../domains/config/index.js";
 import { ContextDomainModule } from "../domains/context/runtime.js";
+import {
+	formatBudgetPolicy,
+	formatBudgetReasons,
+	formatBudgetRequest,
+	formatEffectiveBudget,
+	type RunToolBudgetEnvelope,
+} from "../domains/dispatch/budget-envelope.js";
 import { type CapacityDrain, capacityDrain, setCapacityDraining } from "../domains/dispatch/capacity-lease.js";
 import { runCodeStep } from "../domains/dispatch/code-step.js";
 import { codeStepDir, writeCodeStepRecord } from "../domains/dispatch/code-step-store.js";
@@ -740,6 +747,7 @@ export function statusSnapshot(): {
 			return {
 				runId: row.id,
 				agentId: row.agentId,
+				budget: row.budget ?? null,
 				runtimeKind: row.runtimeKind,
 				outcomePhase: row.status,
 				heartbeat: rowHeartbeat(row),
@@ -798,6 +806,13 @@ function runStatus(args: ReadonlyArray<string>): number {
 			process.stdout.write(
 				`  ${row.runId}  ${row.agentId}  node=${row.node}  ${row.heartbeat}  attempt=${lineage.attempt} depth=${lineage.depth}  ${Math.round((row.elapsedMs as number) / 1000)}s  $${(row.costUsd as number).toFixed(4)}\n`,
 			);
+			const budget = row.budget as RunToolBudgetEnvelope | null;
+			if (budget !== null) {
+				process.stdout.write(`    recipe policy: ${formatBudgetPolicy(budget)}\n`);
+				process.stdout.write(`    requested envelope: ${formatBudgetRequest(budget)}\n`);
+				process.stdout.write(`    effective envelope: ${formatEffectiveBudget(budget)}\n`);
+				process.stdout.write(`    clamp or escalation reason: ${formatBudgetReasons(budget)}\n`);
+			}
 		}
 	}
 	if (snapshot.retrying.length === 0) {

package/src/cli/index.ts

@@ -60,7 +60,7 @@ Usage:
   clio-coder fleet list|run|status|drain|resume  fleet contracts, status, and admission control
   clio-coder evidence             build, list, or inspect evidence artifacts
   clio-coder eval                 run, report, or compare local eval task files
-  clio-coder memory               list, propose, approve, reject, or prune memory
+  clio-coder memory               list, propose, promote, approve, reject, or prune memory
   clio-coder usage report         cross-session usage facts and opportunities (experimental)
   clio-coder trace                query or view the durable dispatch trace mirror
   clio-coder extensions           install, list, enable, disable, or remove extension packages