@pellux/goodvibes-tui 2.1.0 → 2.1.1

package/CHANGELOG.md

@@ -4,6 +4,12 @@ All notable changes to GoodVibes TUI.
 
 ---
 
+## [2.1.1] - 2026-11-02
+
+### Fixed
+
+- Restore local llama.cpp replies, including DeepSeek responses after tool calls, by excluding the active assistant rendering block from model requests. This release uses SDK 2.1.1 and daemon 1.29.1 and adds a terminal regression check for the outgoing conversation.
+
 ## [2.1.0] - 2026-09-30
 
 ### Added
@@ -1754,7 +1760,7 @@ First release of the best-in-class program: a full UX-first review of the codeba
 - `bun run tsc --noEmit --pretty false`
 - `bun run smoke:daemon`
 - local `npm pack` install smoke with `GOODVIBES_ASSET_SOURCE_DIR=dist`
-- `/home/buzzkill/Projects/goodvibes-tui/dist/goodvibes-linux-x64 --version` from `/home/buzzkill/Projects/ttest1`
+- The compiled `goodvibes-linux-x64 --version` command from a separate test workspace.
 
 ---
 

package/README.md

@@ -2,13 +2,13 @@
 
 [![CI](https://github.com/mgd34msu/goodvibes-tui/actions/workflows/ci.yml/badge.svg)](https://github.com/mgd34msu/goodvibes-tui/actions/workflows/ci.yml)
 [![License: MIT](https://img.shields.io/badge/License-MIT-yellow.svg)](https://opensource.org/licenses/MIT)
-[![Version](https://img.shields.io/badge/version-2.1.0-blue.svg)](https://github.com/mgd34msu/goodvibes-tui)
+[![Version](https://img.shields.io/badge/version-2.1.1-blue.svg)](https://github.com/mgd34msu/goodvibes-tui)
 
 GoodVibes is a terminal console for coding and operations work with an AI model. You run `goodvibes` in a project directory and get a full-screen terminal app where you talk to a model that can read and edit your files, run shell commands, search the web, and hand work off to background agents, asking your permission before anything that writes or executes.
 
 It talks to many model providers (OpenAI, Anthropic, Gemini, Bedrock, Copilot, OpenRouter and other OpenAI-compatible gateways, plus local servers like Ollama and LM Studio that `/scan` finds on your machine and LAN), keeps its settings, sessions, and secrets on your own machine, and shows you the token count and running cost of every turn. Background work opens in large modals over the conversation: running agents, changed files and diffs, tokens and cost.
 
-<img src="docs/assets/splash.png" alt="GoodVibes starting up in a terminal: a glitch-art GOODVIBES wordmark in cyan-to-magenta gradient, the version and tagline beneath it, the active model and tool count, the working directory, a line offering to resume the last session, and a hint line reading Ctrl+P panels / ? help / F2 fleet. A status footer shows mode, token usage, context usage, and the daemon and web listener addresses." width="900">
+<img src="docs/assets/splash.png" alt="GoodVibes 2.1.0 starting up in a terminal. A thin header reads GoodVibes 2.1.0 on the left and the git branch main with a changes dot and the model gpt-6.1-sol on the right. Centered below is a block-letter GOODVIBES wordmark in a cyan-to-violet gradient between two rules, the tagline, the version v2.1.0 with terminal AI assistant, the active model openai:gpt-6.1-sol with 29 tools, the working directory /tmp/orbit-watch, and a hint line reading Ctrl+P commands / ? help / F2 agents. At the bottom is an empty input box reading Ask anything, or type / for commands and @ for files, and a status line showing the normal permission mode, the directory and branch, a cost of zero dollars, an empty context bar at 0 percent of 1.1M, and ctrl+p menu." width="900">
 
 ---
 
@@ -47,21 +47,21 @@ Deeper install notes are in [docs/getting-started.md](docs/getting-started.md):
 
 ### The conversation loop
 
-<img src="docs/assets/conversation.png" alt="Two conversation turns in the terminal. The tail of an earlier answer describes the project as a minimal ISS pass tracker whose calculation is still a stub. Below it the user asks the model to grep for nextPass and list every file that references it; an assistant block shows one find tool call with a green checkmark, and its result is expanded as syntax-highlighted JSON with line numbers listing the two matching file paths and a count of 2. The final answer names src/passes.ts and src/index.ts as a bulleted list. The footer reads Token Usage: Input em dash, Output 264, Cache Read 0, Cache Write 0, Total 264, approximately 0.0040 dollars, above a green context usage bar at 4 percent." width="900">
+<img src="docs/assets/conversation.png" alt="Two conversation turns. The user asks the model to search for nextPass and list every file that references it; the reply shows one collapsed find nextPass tool row with a green checkmark and the summary 2 matches in 2 files, then the answer listing src/index.ts and src/passes.ts. In the second turn the user asks, without running anything, for three things the tracker still needs, and the model answers with three short bullets about orbital-data refresh, pass-prediction validation, and alerts before upcoming passes. Each user message sits in a shaded block and each reply carries a small header with the model name, tool count, and elapsed time. The status line below the input shows the normal mode, the directory /tmp/orbit-watch, an estimated cost of about 3 cents, and the context bar at 1 percent, 14.4k of 1.1M tokens." width="900">
 
 Tool calls stream inline as the model makes them, then their results fold into a collapsible group so a long working session stays readable. Expand any group to see what actually came back. Assistant messages render markdown, syntax-highlighted code, and inline diffs, and any block can be collapsed, bookmarked, copied, or saved to a file.
 
-The footer keeps an honest running total: fresh input tokens separated from cache reads, output tokens, the estimated cost so far, and how much of the context window is used. When a model's price is not in the catalog, the cost is reported as unavailable rather than guessed.
+The status line under the input keeps a running total: the estimated cost so far and how much of the context window is used. `/usage` breaks that down into fresh input tokens, cache reads, and output tokens. When a model's price is not in the catalog, the cost is reported as unavailable rather than guessed.
 
 ### Permissions and workspace trust
 
-<img src="docs/assets/workspace-trust.png" alt="A modal titled New workspace, choose a trust level, offering two options: Trust this workspace, full capability, all tools may run; and Keep restricted, read-only, explore safely, writes and commands are denied until trusted. Navigation hints read Up/Down Navigate, Enter Choose, Esc Close." width="820">
+<img src="docs/assets/workspace-trust.png" alt="A modal over the dimmed conversation, titled New workspace: choose a trust level, with an esc key on its right. Two options are listed: Trust this workspace, full capability, all tools may run, which is highlighted; and Keep restricted (read-only), explore safely, writes and commands are denied until trusted. The hint row reads up and down to move, Enter to choose. Behind it, the transcript shows the model starting exec mkdir -p build and waiting." width="820">
 
-The first time you open a directory, GoodVibes asks how much it is allowed to do there. Restricted is read-only. The model can look around, but writes and commands are refused until you trust the workspace.
+The first time the model wants to write or run something in a new directory, GoodVibes asks how much it is allowed to do there. Restricted is read-only. The model can look around, but writes and commands are refused until you trust the workspace.
 
-<img src="docs/assets/permission-prompt.png" alt="An execution approval prompt. A header reads EXECUTE, Shell Execution Approval, one more waiting. Fields list the requesting session, the tool exec, the full command mkdir -p build, the working directory, a Risk line reading HIGH write in red, the surface and radius, a summary, the decision class, the effects: process execution, filesystem mutation, possible network access, a reviewer checklist, and the raw tool arguments. Below, four numbered remember options scope an approval to this exact command, to every mkdir command, to every exec call in this project, or to the rest of the session in memory only. The action line reads: Y Allow once, 1-4 Allow and remember, N Deny, or type a reason to deny." width="900">
+<img src="docs/assets/permission-prompt.png" alt="A Shell Execution Approval modal with an amber top edge over the dimmed conversation. The header reads EXECUTE and the session id. A shaded row shows the command mkdir -p build, followed by a red high risk tag beside Execute shell command. Three choices sit in a row, Allow once highlighted, Allow for session, and Deny, with d details on the right. The hint row reads: arrows to choose, Enter to confirm, y allow once, 1-4 remember, n deny, or type a reason to deny. Behind the modal the transcript line reads Waiting for your approval, exec, mkdir -p build." width="900">
 
-After that, the default permission mode is `prompt`: writes, edits, shell commands, network fetches, agent spawns, and MCP calls each stop and ask. The prompt shows what will run, in which directory, its assessed risk, and what it can affect. You can allow it once, deny it (optionally typing a reason the model sees), or remember the decision at whichever scope fits: this exact command, this command shape, this tool for the whole project, or just for the rest of the session.
+After that, the default permission mode is `prompt`: writes, edits, shell commands, network fetches, agent spawns, and MCP calls each stop and ask. The prompt shows what will run and its assessed risk; `d` expands the details, including the working directory, what it can affect, and the raw arguments. You can allow it once, deny it (optionally typing a reason the model sees), or remember the decision at whichever scope fits: this exact command, this command shape, this tool for the whole project, or just for the rest of the session.
 
 Four other modes are available when prompting is not what you want:
 
@@ -74,7 +74,7 @@ Four other modes are available when prompting is not what you want:
 
 ### Models and providers
 
-<img src="docs/assets/model-picker.png" alt="A fullscreen model workspace. A left column lists routing targets: Main Chat set, Helper Model off, Tool LLM off, TTS LLM inherit, and Embeddings set. The right pane shows the selected target with its current model and a filter row for search, price, capability, grouping, and availability. Below, a table of models lists model key, display name, provider, context window, tier, and capability flags across 2030 catalogued entries, with a footer of list shortcuts." width="900">
+<img src="docs/assets/model-picker.png" alt="The Models modal opened with /model. Tabs across the top name the routing targets: Main Chat, selected, then Helper (off), Tool LLM (off), TTS, and Embeddings. Below is a search field and a count reading available only, 2,574 of 3,214. The left column lists models grouped by provider, here abacusai, with each model's context window; the right pane describes the highlighted model, its provider, the current Main Chat model openai:gpt-6.1-sol, its status configured, its context window and capability tags, and the filter shortcuts for price, capability, availability, benchmark sort, and grouping. The footer reads Enter use for Main Chat, tab next target, ctrl+f pin, ctrl+r refresh catalog, and 2550 more." width="900">
 
 Models come from a live catalog, so the picker lists far more than a hardcoded set, filterable by search, price, capability, and availability. Separate roles route independently: your main chat model, a cheaper helper model for grunt work, a tool model, a TTS model, and an embeddings model can each point somewhere different.
 
@@ -82,13 +82,13 @@ The `synthetic` provider groups the same model across every backend that serves
 
 ### The Agents control room
 
-<img src="docs/assets/fleet-panel.png" alt="The Fleet panel open beside the conversation. It lists background work as rows with a kind, a name, elapsed time, token count, and cost: a CI watch poller and a runtime heartbeat watcher at 4 minutes 23 seconds each, and an idle code indexer. The detail region below shows the selected watcher's id, state idle, elapsed time, model, tokens, cost, a headline reading CI watch poller, healthy, an activity phase, and an approvals line. The action hints read j/k navigate, Enter attach, K kill, A archive finished, v archived, n host agent." width="900">
+<img src="docs/assets/fleet-panel.png" alt="The Agents modal opened with F2, headed 0 running, the session's own cost, and the fleet cost. The filter field holds the word healthy and shows 3 of 8 rows. Under a running heading the list shows three watchers, CI watch poller, Daemon heartbeat, and Runtime heartbeat, each marked healthy with its elapsed time. The detail pane on the right describes the selected CI watch poller: watcher id ci-watch-poller, state idle, elapsed time, model unknown, tokens not applicable, cost unpriced, the headline CI watch poller, healthy, its activity phase, and approvals. The hint row reads Enter open full screen, s steer, ctrl+x stop, n new agent, v archive, a archive one, f follow." width="900">
 
-Work that is not conversation opens in modals instead of scrolling past in the transcript. Agents, reached with `F2`, is the live control room for agents, WRFC chains, workstreams, watchers, scheduled jobs and hosted sessions: what is running, for how long, at what token cost, and what it is waiting on. You can open a running agent to watch its live tail or steer it, back out with `Esc` without stopping it, stop it with `Ctrl+X` (it asks first), pause and resume, and archive finished work. Usage (`/usage`) shows context pressure, tokens and cost; Changes (`/changes`) shows changed files with a tinted diff, a semantic summary, hunk staging and review comments; Notifications (`/notifications`) keeps the history. The screenshot above predates the modal redesign.
+Work that is not conversation opens in modals instead of scrolling past in the transcript. Agents, reached with `F2`, is the live control room for agents, WRFC chains, workstreams, watchers, scheduled jobs and hosted sessions: what is running, for how long, at what token cost, and what it is waiting on. You can open a running agent to watch its live tail or steer it, back out with `Esc` without stopping it, stop it with `Ctrl+X` (it asks first), pause and resume, and archive finished work. Usage (`/usage`) shows context pressure, tokens and cost; Changes (`/changes`) shows changed files with a tinted diff, a semantic summary, hunk staging and review comments; Notifications (`/notifications`) keeps the history.
 
 ### Everything else is a command
 
-<img src="docs/assets/help-overlay.png" alt="A searchable help overlay titled Help, Commands, with a search field and results grouped by category. Under Provider Accounts is the /accounts command with review, panel, show, routes, and repair subcommands and a one-line description. Under Fleet is /agents, described as hosting third-party coding agents as fleet rows over ACP. Under Experience is /approval, for reviewing action-specific approval classes. A line reads 147 below, and the hints read Up/Down Navigate, Enter Run, / Search, Esc Close." width="820">
+<img src="docs/assets/help-overlay.png" alt="The Help: Commands modal opened with the question-mark key, with a Type to filter field and a count of 160 items. Commands are grouped under category headings: provider accounts with /accounts and its review, panel, show, routes, and repair subcommands, highlighted; agents with /agents, which opens Agents and lists or hosts third-party coding agents over ACP; experience with /approval; platform access with /auth and its long list of subcommands; local runtime with /bookmarks; experience with /bootstrap; and branches with /branch. The hint row reads up and down to move, Enter to run, and 153 more." width="820">
 
 Press `?` for a searchable, categorized list of every slash command with its arguments and description. The same list is generated into [docs/commands-reference.md](docs/commands-reference.md).
 
@@ -109,7 +109,7 @@ Press `?` for a searchable, categorized list of every slash command with its arg
 | `Ctrl+X` | Inside an agent or process view: stop it (press twice to confirm) |
 | `Ctrl+C` | Clear input, cancel a running turn. Press twice to quit |
 
-Most bindings are customizable in `~/.goodvibes/tui/keybindings.json`, and `/keybindings` shows what is currently bound. Five keys are fixed and stay out of that file: `F2` (Fleet), `Shift+Tab` (permission-mode cycle), `Esc` (leave the current mode), `?` (help), and `@` (file picker). The full reference is in [docs/tools-and-commands.md](docs/tools-and-commands.md).
+Most bindings are customizable in `~/.goodvibes/tui/keybindings.json`, and `/keybindings` shows what is currently bound. Five keys are fixed and stay out of that file: `F2` (Agents), `Shift+Tab` (permission-mode cycle), `Esc` (leave the current mode), `?` (help), and `@` (file picker). The full reference is in [docs/tools-and-commands.md](docs/tools-and-commands.md).
 
 ---
 
@@ -213,12 +213,13 @@ bun run dev
 | Command | Does |
 | --- | --- |
 | `bun run dev` | Run the TUI from source |
-| `bun run test` | Run the suite through the parallel per-file runner |
+| `bun run test:changed` | Run the test files your change affects (since `origin/main`) |
+| `bun run test` | Run the whole suite through the parallel per-file runner (CI runs it on every push) |
 | `bun run build` | Compile `src/main.ts` into `dist/goodvibes` |
 
 The compiled binary is the TUI entrypoint. With `daemon.enabled` on (the default) it adopts a running standalone GoodVibes daemon over loopback, and when a daemon is installed as a service but stopped, it starts that service once and waits for it to come online. It never embeds or constructs a daemon of its own. The control plane, HTTP listener (`danger.httpListener`), and web surface are all hosted by the daemon; the TUI configures them and reports their bindings.
 
-Tests live under `src/test/`, mirroring the source tree, and cover contract, security, release-gate, runtime, renderer, view, integration, and anti-regression cases. Several gates run alongside them in CI: byte-exact golden renderer frames, performance budgets for startup and frame composition and line production (`scripts/perf-baseline.json`), and architecture rules for import cycles, layer boundaries, source-file size, and unused renderer exports (`scripts/check-architecture.ts`).
+Tests live under `src/test/`, mirroring the source tree; byte-exact golden renderer frames are part of that suite. End-to-end tests under `src/test/e2e/` drive the compiled binary in a real terminal against a scripted model. CI also checks import cycles and layer boundaries (`scripts/check-architecture.ts`), and the release gates hold the performance budgets (`scripts/perf-baseline.json`). [Testing and validation](docs/testing-and-validation.md) says what runs where.
 
 Some decisions worth knowing before you read the source:
 
@@ -248,7 +249,7 @@ src/
 ├── cli/                    flag parsing, management verbs, doctor, launch-time self-update
 ├── tools/, mcp/            TUI-local tool guards, MCP runtime reload
 ├── audio/, export/         voice capture, wake word, playback and speech routing; gist upload
-├── verification/, widget/  live verifier and its ledger, the terminal widget module
+├── verification/, widget/  live verifier, the terminal widget module
 ├── utils/, scripts/        formatting and clipboard helpers, message processing script
 └── test/                   the suite, mirroring the tree above
 ```

package/docs/README.md

@@ -64,8 +64,11 @@ This directory contains the current product documentation for `goodvibes-tui`.
 - [Release and publishing](release-and-publishing.md)
   Release validation, GitHub CD, compiled binary releases, npm distribution, and the GitHub Packages mirror.
 
+- [Testing and validation](testing-and-validation.md)
+  What runs while you work, on every push, and before a release; the test layers; the end-to-end tests against the built binary.
+
 - [Local verification](verification/local-verification.md)
-  Inventory coverage, GoodVibes home audits, compiled CLI probes, authenticated daemon probes, and release-oriented local gates.
+  GoodVibes home audits, compiled CLI probes, and authenticated daemon probes against your own machine.
 
 - [Changelog](../CHANGELOG.md)
   Current release history. Older per-version release-note files remain under `docs/releases/` for historical releases, but `CHANGELOG.md` is the canonical current stream.

package/docs/foundation-artifacts/operator-contract.json

@@ -3,7 +3,7 @@
   "product": {
     "id": "goodvibes",
     "surface": "operator",
-    "version": "2.1.0"
+    "version": "2.1.1"
   },
   "auth": {
     "modes": [

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@pellux/goodvibes-tui",
-  "version": "2.1.0",
+  "version": "2.1.1",
   "description": "Terminal-native GoodVibes client for coding, operations, knowledge and channel workflows; a pure client of the GoodVibes daemon.",
   "type": "module",
   "main": "src/main.ts",
@@ -36,10 +36,13 @@
     "build:all-shell": "bun run build:linux-x64 && bun run build:linux-arm64 && bun run build:macos-x64 && bun run build:macos-arm64 && bun run build:windows",
     "typecheck": "bunx tsc --noEmit",
     "typecheck:test": "bunx tsc --noEmit -p tsconfig.test.json",
-    "typecheck:coverage": "bun run scripts/typecheck-coverage-rule.ts",
     "test": "bun run scripts/run-tests.ts",
-    "test:coverage": "bun run scripts/coverage-gate.ts",
-    "version": "bun run scripts/prebuild.ts",
+    "test:changed": "bun run scripts/run-tests.ts --changed=origin/main",
+    "test:e2e": "bun test --timeout=300000 src/test/e2e",
+    "test:e2e:fast": "bun test --timeout=120000 src/test/e2e/startup.e2e.test.ts src/test/e2e/first-turn.e2e.test.ts",
+    "test:e2e:release": "bun test --timeout=300000 src/test/e2e/daemon-adoption.e2e.test.ts src/test/e2e/wrfc-chain.e2e.test.ts src/test/e2e/turn-notification.e2e.test.ts src/test/e2e/resize.e2e.test.ts",
+    "version": "bun run scripts/release-prepare.ts --no-bump",
+    "release:prepare": "bun run scripts/release-prepare.ts",
     "preinstall": "sh scripts/check-bun.sh",
     "postinstall": "bun scripts/postinstall.js",
     "postbuild": "bun scripts/postinstall.js --no-download",
@@ -63,11 +66,7 @@
     "audit:home": "bun run scripts/audit-goodvibes-home.ts",
     "foundation:artifacts": "bun run scripts/export-foundation-artifacts.ts",
     "docs:commands": "bun run scripts/generate-command-reference.ts",
-    "verification:ledger": "bun run scripts/verification-ledger.ts",
-    "verification:live": "bun run scripts/verify-live.ts",
-    "eval:gate": "bun run scripts/eval-gate.ts",
-    "eval:gate:verbose": "bun run scripts/eval-gate.ts --verbose",
-    "eval:baseline": "bun run scripts/eval-gate.ts --save-baseline"
+    "verification:live": "bun run scripts/verify-live.ts"
   },
   "license": "MIT",
   "repository": {
@@ -96,18 +95,18 @@
     "@anthropic-ai/bedrock-sdk": "^0.29.1",
     "@anthropic-ai/sdk": "^0.92.0",
     "@ast-grep/napi": "^0.42.0",
-    "@pellux/goodvibes-sdk": "2.1.0",
-    "@pellux/goodvibes-terminal-shell": "2.1.0",
+    "@pellux/goodvibes-sdk": "2.1.1",
+    "@pellux/goodvibes-terminal-shell": "2.1.1",
     "bash-language-server": "^5.6.0",
     "fuse.js": "^7.1.0",
-    "@pellux/goodvibes-daemon": "1.29.0",
+    "@pellux/goodvibes-daemon": "1.29.1",
     "graphql": "^16.13.2",
     "jszip": "^3.10.1",
     "node-edge-tts": "^1.2.10",
     "onnxruntime-web": "^1.27.0",
     "openai": "6.46.0",
     "pyright": "^1.1.408",
-    "simple-git": "^3.33.0",
+    "simple-git": "^4.0.2",
     "sql.js": "^1.14.1",
     "sqlite-vec": "^0.1.9",
     "tree-sitter-css": "^0.25.0",
@@ -121,15 +120,15 @@
     "zustand": "^5.0.12"
   },
   "devDependencies": {
-    "@pellux/goodvibes-toolchain": "2.1.0",
+    "@pellux/goodvibes-toolchain": "2.1.1",
     "@types/bun": "^1.3.10",
     "typescript": "^5.9.3"
   },
   "optionalDependencies": {
-    "@pellux/goodvibes-tui-linux-x64": "2.0.6",
-    "@pellux/goodvibes-tui-linux-arm64": "2.0.6",
-    "@pellux/goodvibes-tui-darwin-x64": "2.0.6",
-    "@pellux/goodvibes-tui-darwin-arm64": "2.0.6"
+    "@pellux/goodvibes-tui-linux-x64": "2.1.1",
+    "@pellux/goodvibes-tui-linux-arm64": "2.1.1",
+    "@pellux/goodvibes-tui-darwin-x64": "2.1.1",
+    "@pellux/goodvibes-tui-darwin-arm64": "2.1.1"
   },
   "trustedDependencies": [],
   "overrides": {

package/src/input/command-reference.ts

@@ -53,8 +53,8 @@ export function renderCommandReferenceMarkdown(entries: readonly CategorizedComm
   lines.push('<!-- GENERATED FILE: DO NOT EDIT BY HAND.');
   lines.push('     Regenerate with `bun run docs:commands`.');
   lines.push('     Source of truth: the slash-command registry (src/input/commands.ts).');
-  lines.push('     A drift check (src/test/release-gates/command-reference-gate.test.ts)');
-  lines.push('     fails CI if this file is stale. -->');
+  lines.push('     Every build (scripts/prebuild.ts) and `bun run release:prepare`');
+  lines.push('     rewrite it, so it is current at each version bump. -->');
   lines.push('');
   lines.push('# Command Reference');
   lines.push('');

package/src/verification/live-verifier.ts

@@ -2,7 +2,6 @@ import { existsSync, mkdirSync, readFileSync, writeFileSync } from 'node:fs';
 import { join, resolve } from 'node:path';
 import { spawn } from 'node:child_process';
 import { auditGoodVibesHome } from '../config/goodvibes-home-audit.ts';
-import { buildVerificationLedger } from './verification-ledger.ts';
 import { summarizeError } from '@pellux/goodvibes-sdk/platform/utils';
 
 export type LiveVerificationStatus = 'pass' | 'warn' | 'fail' | 'skip';
@@ -232,15 +231,6 @@ export async function buildLiveVerificationReport(options: LiveVerificationOptio
   const token = options.token ?? readDaemonToken(homeDir);
   const checks: LiveVerificationCheck[] = [];
 
-  const ledger = buildVerificationLedger(projectRoot);
-  checks.push({
-    id: 'verification-ledger',
-    title: 'Verification inventory ledger',
-    status: ledger.totals.localSignalPercent >= 90 ? 'pass' : 'fail',
-    summary: `${ledger.totals.localSignalPercent}% local verification signal across ${ledger.totals.total} inventory items.`,
-    detail: `${ledger.totals.localBehaviorPercent}% local behavior verified; ${ledger.totals.externalOutcomeRequired} item(s) require external outcomes.`,
-  });
-
   const audit = await auditGoodVibesHome({ homeDir });
   const staleCandidates = audit.settings?.staleCandidates?.length ?? 0;
   checks.push({

package/src/version.ts

@@ -6,7 +6,7 @@ import { join } from 'node:path';
 // The prebuild script updates the fallback value before compilation.
 // Uses import.meta.dir (Bun) to locate package.json relative to this file,
 // which is correct regardless of the process working directory.
-let _version = '2.0.15';
+let _version = '2.1.1';
 try {
   const pkg = JSON.parse(readFileSync(join(import.meta.dir, '..', 'package.json'), 'utf-8'));
   // Only trust a version read from OUR OWN package.json. A Bun single-file

package/src/verification/verification-ledger.ts

@@ -1,709 +0,0 @@
-import { readFileSync } from 'node:fs';
-import { join } from 'node:path';
-import { CONFIG_SCHEMA } from '@pellux/goodvibes-sdk/platform/config';
-import { FEATURE_SETTINGS } from '@pellux/goodvibes-sdk/platform/runtime/state';
-import { featureEnablementWrite, GOODVIBES_CLI_CATALOG } from '@pellux/goodvibes-terminal-shell';
-import { CommandRegistry } from '../input/command-registry.ts';
-import { registerBuiltinCommands } from '../input/commands.ts';
-
-export interface VerificationLedgerArea {
-  readonly area: string;
-  readonly total: number;
-  readonly localSignalVerified: number;
-  readonly localBehaviorVerified: number;
-  readonly externalOutcomeRequired: number;
-  readonly notes: string;
-}
-
-export interface VerificationLedger {
-  readonly generatedAt: string;
-  readonly areas: readonly VerificationLedgerArea[];
-  readonly totals: {
-    readonly total: number;
-    readonly localSignalVerified: number;
-    readonly localBehaviorVerified: number;
-    readonly externalOutcomeRequired: number;
-    readonly localSignalPercent: number;
-    readonly localBehaviorPercent: number;
-  };
-}
-
-/**
- * Baseline count of `Settings schema and persistence` items with real local
- * behavior verification, as measured when this ledger was first authored. New
- * schema keys added since then are accounted for explicitly (see
- * FEATURE_KNOB_LOCAL_SETTINGS) rather than folded into this number, so the
- * baseline stays an auditable fixed point.
- */
-const SETTINGS_BEHAVIOR_BASELINE = 184;
-
-/**
- * Config keys promoted into CONFIG_SCHEMA for the flag-gated feature knobs
- * (SDK commit f5c4af31, "config: add schema keys for flag-gated feature
- * knobs"). Adding these 28 keys raised the settings inventory `total` without a
- * matching rise in behavior-verified coverage, which dropped
- * `localBehaviorPercent` below its floor. Each key is a local, non-external
- * setting whose full persistence behavior, schema default, set → write →
- * reload round-trip, and reset-to-default, is exercised by
- * `src/test/verification/feature-knob-settings-persistence.test.ts`. They are
- * therefore genuinely behavior-verified locally and counted as such here.
- */
-/**
- * The daemon's own mailbox and calendar keys (`surfaces.email.*`,
- * `surfaces.calendar.*`), promoted into CONFIG_SCHEMA so the settings modal,
- * which renders from that schema, can actually show them. Before, the
- * daemon's handlers named these keys in their own error messages
- * ("Set surfaces.calendar.caldavUrl and surfaces.calendar.caldavUser") while
- * the UI that told an operator to set them could not display one of them.
- *
- * Declaring 25 keys raised the settings inventory `total` with no matching
- * behavior coverage, which dropped `localBehaviorPercent` below its floor,
- * the same arrival shape as the two lists above.
- *
- * THIS CONSTANT IS NOT A DIAL. Every key below is counted because
- * `src/test/verification/daemon-mailbox-settings-persistence.test.ts` runs the
- * same four-part persistence contract the other counted sets are counted for:
- * schema default exposure, `set()` through the key's own validator to disk,
- * reload into a fresh ConfigManager with read-back equality, and
- * reset-to-default that also survives reload. That test also asserts this list
- * is exactly the `surfaces.email.*` + `surfaces.calendar.*` schema key set and
- * overlaps neither other counted set, so nothing is double-counted and nothing
- * drifts in uncounted.
- *
- * PER-KEY EVIDENCE. All 42 are read by a LIVE consumer, which is why they were
- * declared at all: the SDK's mail and calendar gateway compositions
- * (platform/email/surface-config.ts and platform/calendar/caldav-gateway-config.ts)
- * resolve every one of them when the daemon serves `email.*` and `calendar.*`,
- * and the `surfaces.email.inbound.*` block is read by the daemon's inbound mail
- * reader, the poller/IDLE path that makes incoming mail visible at all.
- * The five password keys (email.password, email.imapPassword,
- * email.imap.password, email.smtp.password, calendar.caldavPassword)
- * additionally resolve through the daemon secret tier rather than from config,
- * and carry no secret value in config themselves. That is now enforced on the
- * write side too: all five are in `config/secret-config.ts`'s
- * SECRET_CONFIG_KEYS, so the settings modal and `/config set` route an entered
- * value into the secret store and leave only a `goodvibes://` reference in
- * config, rather than writing the password itself into a settings file.
- */
-export const DAEMON_MAILBOX_LOCAL_SETTINGS = [
-  'surfaces.email.host',
-  'surfaces.email.user',
-  'surfaces.email.username',
-  'surfaces.email.from',
-  'surfaces.email.password',
-  'surfaces.email.imapHost',
-  'surfaces.email.imapPort',
-  'surfaces.email.imapUser',
-  'surfaces.email.imapPassword',
-  'surfaces.email.imap.host',
-  'surfaces.email.imap.port',
-  'surfaces.email.imap.user',
-  'surfaces.email.imap.password',
-  'surfaces.email.imap.secure',
-  'surfaces.email.imap.mailbox',
-  'surfaces.email.imap.draftsMailbox',
-  'surfaces.email.smtp.host',
-  'surfaces.email.smtp.port',
-  'surfaces.email.smtp.password',
-  'surfaces.email.smtp.secure',
-  // Inbound mail, the poller/IDLE reader the daemon runs to actually READ mail,
-  // which arrived with the platform runtime. These are counted for exactly the
-  // reason the keys above are: the same four-part persistence contract runs over
-  // every one of them in
-  // src/test/verification/daemon-mailbox-settings-persistence.test.ts, and the
-  // list is asserted there to be the complete surfaces.email.*/surfaces.calendar.*
-  // schema set. Arriving uncounted is what dropped localBehaviorPercent through
-  // its floor when the schema grew.
-  'surfaces.email.inbound.enabled',
-  'surfaces.email.inbound.accounts',
-  'surfaces.email.inbound.source',
-  'surfaces.email.inbound.gmailPollSecondsExpecting',
-  'surfaces.email.inbound.gmailPollSecondsIdle',
-  'surfaces.email.inbound.mode',
-  'surfaces.email.inbound.pollIntervalSeconds',
-  'surfaces.email.inbound.idleReissueMinutes',
-  'surfaces.email.inbound.reconnect.maxBackoffSeconds',
-  'surfaces.email.inbound.notice.route',
-  'surfaces.email.inbound.notice.mode',
-  'surfaces.email.inbound.expectationWindowMinutes',
-  'surfaces.email.inbound.dedupTtlMinutes',
-  'surfaces.email.inbound.retentionDays',
-  'surfaces.email.inbound.maxRecords',
-  'surfaces.email.inbound.capabilityRecheckMinutes',
-  'surfaces.email.inbound.onInsufficientCapability',
-  'surfaces.calendar.caldavUrl',
-  'surfaces.calendar.caldavUser',
-  'surfaces.calendar.caldavPassword',
-  'surfaces.calendar.defaultCalendarId',
-  'surfaces.calendar.calendars',
-] as const;
-
-export const FEATURE_KNOB_LOCAL_SETTINGS = [
-  'provider.optimizerMode',
-  'provider.optimizerPinnedModel',
-  'permissions.divergenceThreshold',
-  'permissions.maxDivergenceRecords',
-  'tools.overflowSpillBackend',
-  'notifications.burstWindowMs',
-  'notifications.burstThreshold',
-  'notifications.burstCooldownMs',
-  'fetch.sanitizeMode',
-  'fetch.trustedHosts',
-  'fetch.blockedHosts',
-  'security.tokenAudit.rotationCadenceDays',
-  'security.tokenAudit.rotationWarningDays',
-  'security.tokenAudit.managed',
-  'integrations.delivery.maxRetries',
-  'integrations.delivery.initialDelayMs',
-  'integrations.delivery.maxDelayMs',
-  'integrations.delivery.maxDlqSize',
-  'integrations.delivery.sloEnforced',
-  'policy.bundleSource',
-  'policy.bundlePath',
-  'agents.passiveInjection.budgetTokens',
-  'agents.passiveInjection.relevanceFloor',
-  'agents.passiveInjection.codeLimit',
-  'agents.contextCompactThreshold',
-  'runtime.toolBudget.maxMs',
-  'runtime.toolBudget.maxTokens',
-  'runtime.toolBudget.maxCostUsd',
-] as const;
-
-/**
- * Config keys added by the paired-device and trigger-family domains in SDK
- * 1.14.0. Like FEATURE_KNOB_LOCAL_SETTINGS above, these arrived as new
- * CONFIG_SCHEMA entries that raised the settings inventory `total` with no
- * matching behavior coverage, dropping `localBehaviorPercent` below its floor.
- *
- * THIS CONSTANT IS NOT A DIAL. Each key below is counted because a test that
- * exercises it was actually written:
- * `src/test/verification/device-and-trigger-settings-persistence.test.ts` runs,
- * for every key in this list, the same four-part persistence contract the
- * feature-knob keys are counted for, schema default exposure, `set()` through
- * the key's own validator to disk, reload into a fresh ConfigManager with
- * read-back equality, and reset-to-default that also survives reload. That test
- * additionally asserts this list is exactly the non-enablement key set of both
- * domains and overlaps neither of the other counted sets, so nothing here is
- * double-counted and nothing drifts in uncounted.
- *
- * PER-KEY EVIDENCE, what is verified, and how live the key is TODAY.
- * "persistence" below means the four-part contract above; the second column
- * records whether anything in this tree (TUI or the pinned SDK) reads the key,
- * audited by tracing each key to its consumers.
- *
- *   watchers.triggers.backoffLadderMs        persistence · live (trigger supervisor retry ladder)
- *   watchers.triggers.breakerStrikes         persistence · live (strike breaker)
- *   watchers.triggers.defaultCheckIntervalMs persistence · live (condition-check scheduler)
- *   watchers.triggers.probeTimeoutMs         persistence · live (probe execution)
- *   watchers.triggers.maxConcurrentChecks    persistence · live (check concurrency cap)
- *   watchers.triggers.observationRingSize    persistence · live (observation ring)
- *   watchers.triggers.runHistoryLimit        persistence · live (run history retention)
- *   watchers.triggers.runHistoryTtlHours     persistence · live (run history sweep)
- *   watchers.triggers.eventLogLimit          persistence · live (event log retention)
- *   watchers.triggers.eventLogTtlHours       persistence · live (event log sweep)
- *   watchers.triggers.sweepIntervalMs        persistence · live (housekeeping cadence)
- *   watchers.triggers.supervisionTickMs      persistence · live (supervision loop tick)
- *   watchers.triggers.streamQueueLimit       persistence · live (stream watcher queue)
- *   watchers.triggers.streamBatchLines       persistence · live (stream batching)
- *   watchers.triggers.streamBatchIntervalMs  persistence · live (stream batching)
- *   watchers.triggers.onExitMaxDurationMs    persistence · live (on-exit trigger duration cap)
- *   watchers.triggers.onExitStdin            persistence · live (on-exit stdin posture)
- *   watchers.triggers.outputTailBytes        persistence · live (captured output tail)
- *   device.capabilities.allowAlwaysOffer     persistence · behavior (durable-grant offer by sensitivity)
- *   device.capabilities.requestTimeoutSeconds persistence · behavior (dispatch, wire payload and prompt deadline)
- *   device.location.precision                persistence · behavior (precise fix refused / never granted)
- *   device.clipboard.readMode                persistence · behavior (clipboard read refused / never granted)
- *   device.capture.retentionHours            persistence · behavior (capture TTL, swept off disk at expiry)
- *   device.capture.maxArtifacts              persistence · behavior (capture count cap at the sweep)
- *   device.capture.sweepIntervalMinutes      persistence · behavior (period of the sweep that reaps)
- *   device.grants.expiryDays                 persistence · behavior (grant TTL, then asks again)
- *   device.grants.maxPerNode                 persistence · behavior (per-node grant cap at the sweep)
- *   device.grants.auditRetentionDays         persistence · behavior (grant ledger retention)
- *   device.nodes.maxPaired                   persistence · live (enforced at the pairing path)
- *
- * On `device.nodes.maxPaired`: the SDK enforces it where a device pairs,
- * PairingTokenManager.mint refuses a NEW node at the cap with
- * PairingLimitReachedError (code DEVICE_NODES_MAX_PAIRED, carrying the setting
- * name, the cap and the live count), mapped to HTTP 409 by the pairing and
- * pairing-handoff routes. An already-paired node supersedes its own record
- * instead of being refused, migration mints off the legacy shared token are
- * deliberately exempt, lowering the cap unpairs nobody, and a non-positive or
- * non-finite value reads as no cap so a broken setting cannot lock the owner
- * out. The cap is read per mint, so a change applies without a restart. What is
- * counted HERE is still only the persistence contract this repo's test
- * exercises, the enforcement itself is SDK-side and SDK-tested, and is recorded
- * in this column so the "how live is it" audit stays accurate, not to claim
- * coverage this repo did not write.
- *
- * On the other ten `device.*` rows: they are live now. This app composes the
- * platform's device posture runtime (src/runtime/device-posture-composition.ts)
- * on the same distributed runtime phones pair onto and the same approval broker
- * every other confirmation rides, registers the `phone` tool on it, and binds the
- * devices.* verbs to it, so each of these keys is read, per request and per
- * sweep, by the DeviceCapabilityService / DeviceGrantStore /
- * DeviceCaptureArtifactStore / DeviceHousekeeper that serve them. They were dark
- * before that: the policy struct carried matching defaults and named the keys in
- * its refusal messages, but nothing mapped configuration into it in either tree.
- * The mapping now lives in the SDK, so every daemon host honours it rather than
- * only whichever consumer had written its own.
- *
- * The second column above is upgraded to "behavior" on the strength of
- * `src/test/verification/device-posture-behavior.test.ts`, which drives THIS
- * app's composition with a real ConfigManager over a temp home and the platform's
- * real stores, stubs only the peer transport and the approval bridge, and asserts
- * per key at two values that the observable outcome differs, refusal code, how
- * authority was established, what reached the transport, what the prompt was
- * given, and what survives on disk after a sweep. It also invokes the `phone`
- * tool and the devices.* verbs off the composed runtime graph, because a mapping
- * nothing composes is the same defect in a different place.
- *
- * STILL NOT COUNTED, FOR A DIFFERENT REASON NOW: the 24 non-enablement
- * `voice.wake.*` keys from the same release. When this list was written they were
- * excluded because nothing captured audio at all. That is no longer true, this
- * terminal opens a recorder subprocess (src/audio/capture.ts), runs the SDK
- * detector over it through onnxruntime-web (src/audio/wake-inference.ts), and
- * hands both a confirmed wake's utterance and a push-to-talk recording to the
- * daemon's `voice.stt` verb. Every one of those rows is read by
- * resolveWakeRuntimeSettings and reaches this surface's runtime.
- *
- * They stay out of the NUMERATOR here because this constant counts exactly one
- * thing, keys whose four-part PERSISTENCE contract is exercised by
- * device-and-trigger-settings-persistence.test.ts, and that test does not cover
- * them. The behaviour they now drive is covered instead by the capture and wake
- * tests under src/test/audio/, which assert the frame path, the detection
- * chain, the disabled-means-no-capture rule, the supervisor's restart and latch,
- * and the recorder argv. Counting them in both places would double-count; adding
- * them here without writing their persistence round-trip would overclaim. So the
- * number this list raises coverage by is unchanged, and the reason it excludes
- * them is recorded above rather than left reading as "the feature does nothing".
- *
- * Every wake row is now in force on this surface, with one condition stated at
- * every surfacing: `voice.wake.vadThreshold` above 0 needs the speech gate's own
- * pinned artifact provisioned (`/voice wake setup` fetches it with the models),
- * and until it is, startup BLOCKS with that reason rather than scoring frames
- * ungated behind a row that says they are screened. `voice.wake.noiseSuppression:
- * speex` runs here: the filter is a WebAssembly module the SDK carries, applied
- * by the wrapper the listener and the push-to-talk session put around this
- * surface's capture opener.
- */
-export const DEVICE_AND_TRIGGER_LOCAL_SETTINGS = [
-  'watchers.triggers.backoffLadderMs',
-  'watchers.triggers.breakerStrikes',
-  'watchers.triggers.defaultCheckIntervalMs',
-  'watchers.triggers.probeTimeoutMs',
-  'watchers.triggers.maxConcurrentChecks',
-  'watchers.triggers.observationRingSize',
-  'watchers.triggers.runHistoryLimit',
-  'watchers.triggers.runHistoryTtlHours',
-  'watchers.triggers.eventLogLimit',
-  'watchers.triggers.eventLogTtlHours',
-  'watchers.triggers.sweepIntervalMs',
-  'watchers.triggers.supervisionTickMs',
-  'watchers.triggers.streamQueueLimit',
-  'watchers.triggers.streamBatchLines',
-  'watchers.triggers.streamBatchIntervalMs',
-  'watchers.triggers.onExitMaxDurationMs',
-  'watchers.triggers.onExitStdin',
-  'watchers.triggers.outputTailBytes',
-  'device.capabilities.allowAlwaysOffer',
-  'device.capabilities.requestTimeoutSeconds',
-  'device.location.precision',
-  'device.clipboard.readMode',
-  'device.capture.retentionHours',
-  'device.capture.maxArtifacts',
-  'device.capture.sweepIntervalMinutes',
-  'device.grants.expiryDays',
-  'device.grants.maxPerNode',
-  'device.grants.auditRetentionDays',
-  'device.nodes.maxPaired',
-] as const;
-
-/**
- * Every feature's enablement settings key whose on/off writes round-trip
- * through a REAL on-disk ConfigManager in
- * `src/test/verification/../input/settings-modal-flag-persistence.test.ts`
- * ("every feature with an off position round-trips both directions"). These
- * are first-class schema keys under the dissolved feature model, so they are
- * genuinely behavior-verified locally. Keys already counted in the
- * feature-knob list are excluded to keep the sum honest.
- */
-const ENABLEMENT_KEYS_BEHAVIOR_VERIFIED = new Set(
-  FEATURE_SETTINGS
-    .filter((feature) => featureEnablementWrite(feature.id, true) !== null && featureEnablementWrite(feature.id, false) !== null)
-    .map((feature) => feature.enablement.key)
-    .filter((key) => !(FEATURE_KNOB_LOCAL_SETTINGS as readonly string[]).includes(key)),
-).size;
-
-/** Settings with real local behavior verification: the authored baseline plus the persistence-tested feature-knob, device/trigger, and enablement keys. */
-/**
- * Config keys added by the LAN group-key layer: the automatic group-key
- * rotation interval, the dual-generation acceptance window around a rotation,
- * the discovery beacon interval, and the roster gossip interval.
- *
- * THIS CONSTANT IS NOT A DIAL, for the same reason as the two above. Each key
- * is counted because a test that exercises it was actually written:
- * `src/test/verification/cluster-group-settings-persistence.test.ts` runs the
- * same four-part persistence contract, schema default exposure, `set()`
- * through the key's own validator to disk, reload into a fresh ConfigManager
- * with read-back equality, and reset-to-default that survives reload.
- *
- * PER-KEY EVIDENCE. All four have a LIVE consumer in this build, which is more
- * than several of the keys counted above can claim:
- *   cluster.keyRotationHours       , read by resolveClusterGroupSettings and
- *                                     compared against the current key's age in
- *                                     the group runtime's rotation check.
- *   cluster.keyRotationGraceMinutes, sets how long the previous generation
- *                                     stays accepted after a scheduled
- *                                     rotation; drives the keyring's accepted
- *                                     generation set.
- *   cluster.beaconSeconds          , the discovery beacon timer interval, and
- *                                     the basis of the "recently heard from"
- *                                     window that decides which member mints a
- *                                     rotation.
- *   cluster.rosterGossipSeconds    , how often the member list is shared.
- *
- * `cluster.enabled` is NOT here: it is a feature enablement key and the ledger
- * counts those in its own set.
- */
-export const CLUSTER_GROUP_LOCAL_SETTINGS = [
-  'cluster.keyRotationHours',
-  'cluster.keyRotationGraceMinutes',
-  'cluster.beaconSeconds',
-  'cluster.rosterGossipSeconds',
-] as const;
-
-/**
- * Config keys for the daemon's payment capability: the master switch, which
- * card to use by default, the settlement currency, CVV handling, the six
- * budget knobs, the shipping-tier preference, the fourteen billing/shipping
- * address sub-fields, the two approval/veto windows, and the notify-channel
- * list. Card MATERIAL (number, expiry, CVV, cardholder name) is intentionally
- * NOT here, see the SDK's schema-domain-payments.ts header and this repo's
- * own input/payments-config.ts: that material lives write-only in the daemon
- * secret store, never in CONFIG_SCHEMA, so there is nothing for a persistence
- * contract to count.
- *
- * THIS CONSTANT IS NOT A DIAL, for the same reason as the sets above. Every
- * key below is counted because
- * `src/test/verification/payments-settings-persistence.test.ts` runs the same
- * four-part persistence contract the other counted sets are counted for:
- * schema default exposure, `set()` through the key's own validator to disk,
- * reload into a fresh ConfigManager with read-back equality, and
- * reset-to-default that also survives reload. That test also asserts this
- * list is exactly the CONFIG_SCHEMA's `payments.*` key set, so a future SDK
- * addition under this domain is caught (fails the inventory-integrity test)
- * rather than silently uncounted.
- *
- * PER-KEY EVIDENCE. All 28 are read by the daemon's own payment capability
- * (platform/payments, platform/control-plane/routes/payments.ts): the budget
- * keys size the daily/overage/tolerance pools, the window keys size the
- * veto/approval timers, cvvHandling and shipping.preferredTier select the
- * enum behaviors `platform/payments` documents, and the address sub-fields
- * are read directly by the daemon's shipping-address-required refusal and the
- * card-issuer address-verification path. `enabled` and `defaultCardId` gate
- * and select, respectively, whether/which card a purchase uses.
- */
-export const PAYMENTS_LOCAL_SETTINGS = [
-  'payments.enabled',
-  'payments.defaultCardId',
-  'payments.currency',
-  'payments.cvvHandling',
-  'payments.budget.dailyItem',
-  'payments.budget.dailyOverage',
-  'payments.budget.perPurchaseCeilingEnabled',
-  'payments.budget.perPurchaseCeiling',
-  'payments.budget.overageToleranceEnabled',
-  'payments.budget.overageToleranceDailyAllowance',
-  'payments.shipping.preferredTier',
-  'payments.billingAddress.name',
-  'payments.billingAddress.line1',
-  'payments.billingAddress.line2',
-  'payments.billingAddress.city',
-  'payments.billingAddress.region',
-  'payments.billingAddress.postalCode',
-  'payments.billingAddress.country',
-  'payments.shippingAddress.name',
-  'payments.shippingAddress.line1',
-  'payments.shippingAddress.line2',
-  'payments.shippingAddress.city',
-  'payments.shippingAddress.region',
-  'payments.shippingAddress.postalCode',
-  'payments.shippingAddress.country',
-  'payments.windows.vetoMinutes',
-  'payments.windows.approvalMinutes',
-  'payments.majorRetailersAdditional',
-  'payments.majorRetailersExcluded',
-  'payments.ebayMinSellerFeedbackCount',
-  'payments.ebayMinSellerPositivePercent',
-  'payments.notifyChannels',
-] as const;
-
-/**
- * Connector settings, the daemon's Google-backed mail/calendar keys plus the
- * connected-host dial switch and the hosted-turn routing switch, declared as
- * described schema rows by platform runtime 2.0.8 (before that the connector
- * keys were cast onto the live config invisibly and the settings surface
- * answered "Unknown setting" for keys the daemon really reads). Counted for
- * exactly the reason DAEMON_MAILBOX_LOCAL_SETTINGS is: the same four-part
- * persistence contract runs over every one of them in
- * src/test/verification/connector-settings-persistence.test.ts, and that test
- * asserts this list is the complete schema set for the email, calendar and
- * google prefixes
- * plus the two switches. Arriving uncounted is what dropped
- * localBehaviorPercent through its floor when the schema grew. The three
- * secret-valued keys hold goodvibes://secrets/ references, never values,
- * same note as the mailbox passwords above.
- */
-export const CONNECTOR_LOCAL_SETTINGS = [
-  'email.enabled',
-  'email.imapHost',
-  'email.imapPort',
-  'email.imapSecurity',
-  'email.smtpHost',
-  'email.smtpPort',
-  'email.smtpSecurity',
-  'email.username',
-  'email.passwordRef',
-  'email.smtpPasswordRef',
-  'email.fromAddress',
-  'email.mailbox',
-  'email.draftsMailbox',
-  'calendar.google.clientId',
-  'calendar.google.clientSecretRef',
-  'calendar.google.icsUrl',
-  'calendar.microsoft.clientId',
-  'calendar.microsoft.clientSecretRef',
-  'google.oauth.projectId',
-  'google.oauth.publishingStatus',
-  'google.oauth.refreshToken',
-  'google.credentials.migratedFrom',
-  'daemon.connectedHost.enabled',
-  'hostedSessions.routeConversationTurns',
-] as const;
-
-const SETTINGS_BEHAVIOR_VERIFIED = SETTINGS_BEHAVIOR_BASELINE
-  + FEATURE_KNOB_LOCAL_SETTINGS.length
-  + DEVICE_AND_TRIGGER_LOCAL_SETTINGS.length
-  + CLUSTER_GROUP_LOCAL_SETTINGS.length
-  + DAEMON_MAILBOX_LOCAL_SETTINGS.length
-  + PAYMENTS_LOCAL_SETTINGS.length
-  + CONNECTOR_LOCAL_SETTINGS.length
-  + ENABLEMENT_KEYS_BEHAVIOR_VERIFIED;
-
-const EXTERNAL_SLASH_COMMANDS = new Set([
-  'auth',
-  'bridge',
-  'cloudflare',
-  'health',
-  'listener',
-  'login',
-  'logout',
-  'mcp',
-  'notify',
-  'pair',
-  'qrcode',
-  'remote',
-  'remote-env',
-  'remote-setup',
-  'runner-pool',
-  'scan',
-  'secrets',
-  'services',
-  'subscription',
-  'teleport',
-  'tts',
-  'tunnel',
-  'voice',
-]);
-
-const EXTERNAL_CLI_COMMANDS = new Set([
-  'bridge',
-  'listener',
-  'pair',
-  'remote',
-  'run',
-  'serve',
-  'service',
-  'tui',
-  'web',
-]);
-
-const ONBOARDING_CAPABILITIES = [
-  'local-tui-only',
-  'browser-access',
-  'network-access',
-  'webhook-events',
-  'external-integrations',
-  'cloudflare-batch',
-] as const;
-
-const EXTERNAL_SURFACES = [
-  'bluebubbles',
-  'discord',
-  'googleChat',
-  'homeassistant',
-  'imessage',
-  'matrix',
-  'mattermost',
-  'msteams',
-  'ntfy',
-  'signal',
-  'slack',
-  'telegram',
-  'webhook',
-  'whatsapp',
-] as const;
-
-function percent(numerator: number, denominator: number): number {
-  return denominator === 0 ? 0 : Math.round((numerator / denominator) * 1000) / 10;
-}
-
-function listSlashCommands(): string[] {
-  const registry = new CommandRegistry();
-  registerBuiltinCommands(registry);
-  return registry.getAll().map((command) => command.name);
-}
-
-/**
- * Built-in modals and views: every config-modal surface builtin-modals.ts
- * registers, plus every kit view modal the shell's view openers construct
- * (Agents, Usage, Changes, Notifications, the masked password prompt).
- */
-function countBuiltinModals(root: string): number {
-  const surfaces = readFileSync(join(root, 'src', 'views', 'builtin-modals.ts'), 'utf8');
-  const openers = readFileSync(join(root, 'src', 'shell', 'view-openers.ts'), 'utf8');
-  const surfaceCount = [...surfaces.matchAll(/registerModalSurface\(/g)].length;
-  const viewModals = new Set([...openers.matchAll(/new ([A-Za-z]+Modal)\(/g)].map((m) => m[1]));
-  return surfaceCount + viewModals.size;
-}
-
-/**
- * The CLI command words this terminal actually accepts, read off the catalog
- * the parser is driven by rather than scraped out of a source file, the
- * ledger counts what ships, and a catalog entry IS what ships.
- */
-function listCliCommands(): string[] {
-  return GOODVIBES_CLI_CATALOG.commands
-    .map((spec) => spec.name as string)
-    .filter((command) => command !== 'unknown');
-}
-
-export function buildVerificationLedger(root: string): VerificationLedger {
-  const slashCommandNames = listSlashCommands();
-  const cliCommandNames = listCliCommands();
-  const slashCommands = slashCommandNames.length;
-  const modals = countBuiltinModals(root);
-  const cliCommands = cliCommandNames.length;
-  const featureFlags = FEATURE_SETTINGS.length;
-  const settings = CONFIG_SCHEMA.length;
-  const externalSlashCommands = slashCommandNames.filter((command) => EXTERNAL_SLASH_COMMANDS.has(command)).length;
-  const externalCliCommands = cliCommandNames.filter((command) => EXTERNAL_CLI_COMMANDS.has(command)).length;
-
-  const areas: VerificationLedgerArea[] = [
-    {
-      area: 'Settings schema and persistence',
-      total: settings,
-      localSignalVerified: settings,
-      localBehaviorVerified: SETTINGS_BEHAVIOR_VERIFIED,
-      externalOutcomeRequired: settings - SETTINGS_BEHAVIOR_VERIFIED,
-      notes: 'Every schema setting can be validated for schema/default/load/write/location; external side effects remain separate.',
-    },
-    {
-      area: 'Feature flags',
-      total: featureFlags,
-      localSignalVerified: featureFlags,
-      localBehaviorVerified: featureFlags - 4,
-      externalOutcomeRequired: 4,
-      notes: 'All flags can be loaded/toggled; a small surface/service subset still requires live external behavior.',
-    },
-    {
-      area: 'Slash commands',
-      total: slashCommands,
-      localSignalVerified: slashCommands,
-      localBehaviorVerified: slashCommands - externalSlashCommands,
-      externalOutcomeRequired: externalSlashCommands,
-      notes: 'Every command can be routed and invoked with a fake context; external/provider/device commands need live outcome checks.',
-    },
-    {
-      area: 'Built-in modals and views',
-      total: modals,
-      localSignalVerified: modals,
-      localBehaviorVerified: modals,
-      externalOutcomeRequired: 0,
-      notes: 'Modals and views can be rendered and input-tested against fake read models and real cached state.',
-    },
-    {
-      area: 'Top-level CLI commands',
-      total: cliCommands,
-      localSignalVerified: cliCommands,
-      localBehaviorVerified: cliCommands - externalCliCommands,
-      externalOutcomeRequired: externalCliCommands,
-      notes: 'Parser/help/status/package behavior is local; long-running TUI/service/remote flows require process or external checks.',
-    },
-    {
-      area: 'External surfaces',
-      total: EXTERNAL_SURFACES.length,
-      localSignalVerified: EXTERNAL_SURFACES.length,
-      localBehaviorVerified: 2,
-      externalOutcomeRequired: EXTERNAL_SURFACES.length - 2,
-      notes: 'Config/readiness can be local for all surfaces; real message delivery is external for most surfaces.',
-    },
-    {
-      area: 'Onboarding capability bundles',
-      total: ONBOARDING_CAPABILITIES.length,
-      localSignalVerified: ONBOARDING_CAPABILITIES.length,
-      localBehaviorVerified: 5,
-      externalOutcomeRequired: 1,
-      notes: 'Wizard state derivation/apply can be local; Cloudflare provisioning remains external.',
-    },
-  ];
-
-  const total = areas.reduce((sum, area) => sum + area.total, 0);
-  const localSignalVerified = areas.reduce((sum, area) => sum + area.localSignalVerified, 0);
-  const localBehaviorVerified = areas.reduce((sum, area) => sum + area.localBehaviorVerified, 0);
-  const externalOutcomeRequired = areas.reduce((sum, area) => sum + area.externalOutcomeRequired, 0);
-
-  return {
-    generatedAt: new Date().toISOString(),
-    areas,
-    totals: {
-      total,
-      localSignalVerified,
-      localBehaviorVerified,
-      externalOutcomeRequired,
-      localSignalPercent: percent(localSignalVerified, total),
-      localBehaviorPercent: percent(localBehaviorVerified, total),
-    },
-  };
-}
-
-export function renderVerificationLedgerMarkdown(ledger: VerificationLedger): string {
-  const lines = [
-    '# GoodVibes Verification Ledger',
-    '',
-    `Generated: ${ledger.generatedAt}`,
-    '',
-    '| Area | Total | Local verification signal | Local behavior | External outcome required | Notes |',
-    '|---|---:|---:|---:|---:|---|',
-    ...ledger.areas.map((area) => [
-      `| ${area.area}`,
-      area.total,
-      area.localSignalVerified,
-      area.localBehaviorVerified,
-      area.externalOutcomeRequired,
-      area.notes,
-    ].join(' | ') + ' |'),
-    '',
-    '## Totals',
-    '',
-    `- Total inventory items: ${ledger.totals.total}`,
-    `- Local verification signal: ${ledger.totals.localSignalVerified} (${ledger.totals.localSignalPercent}%)`,
-    `- Local behavior verified: ${ledger.totals.localBehaviorVerified} (${ledger.totals.localBehaviorPercent}%)`,
-    `- External outcome required: ${ledger.totals.externalOutcomeRequired}`,
-    '',
-    'Local verification signal means the item can be exercised through schema, routing, persistence, render, readiness, daemon, CLI, or real-state checks without relying on an external SaaS/device outcome.',
-    'Local behavior verified means the behavior can be completed locally with in-process, CLI, daemon, tmux, or real persisted state.',
-    '',
-  ];
-  return `${lines.join('\n')}\n`;
-}