@pellux/goodvibes-daemon 1.28.19 → 1.28.21

package/CHANGELOG.md

@@ -2,8 +2,63 @@
 
 All notable changes to the GoodVibes daemon.
 
+## [1.28.21] - 2026-08-21
+
+### Changes
+
+- **The checkout verbs answer.** `payments.checkout.begin` and
+  `payments.checkout.fillCard` attach through sdk 2.0.19's browser-checkout
+  seam: one payments service per registration holds the in-flight checkout
+  registry across both verbs, a second begin on a busy page refuses, and the
+  card-material guard is the engine's own instance end to end. Without a
+  merchant-response reader wired, purchase outcomes record honestly as
+  `submitted-unverified` and the owner report says so. `explicitUserRequest`
+  gates entry to `begin` and is documented as what it is: a caller assertion,
+  no stronger than a confirm flag; the money controls are the budget ledger,
+  the purchase notices and decision windows, and the card-material guard.
+- **The daily budget survives restarts.** Reservations and commits persist
+  atomically to `payments-budget.json` and reload at boot; corrupt or
+  malformed entries (including non-finite or out-of-range amounts and
+  timestamps) are dropped with a warning instead of poisoning the pools; a
+  commit whose disk write fails keeps the in-memory spend, logs the exposure
+  plainly, and retries on the next mutation, so a full disk cannot erase a
+  spend that already happened at the merchant; a failed reserve rolls back
+  rather than holding budget; old spend records prune at boot; loaded
+  reservations are disclosed at startup for reconciliation.
+- **Five payments verbs ride the sdk registrar.** `budget.status`,
+  `cards.list` and `cards.delete` attach through sdk 2.0.19's
+  `registerPaymentsGatewayMethods`; `cards.create` and `purchases.list` keep
+  thin local wrappers over the same service for stricter field-named
+  validation and query-string limits. Wire behavior for all five is pinned
+  byte-identical by the contract suites. Teardown restores all seven
+  descriptors to their pristine builtin state.
+- Platform runtime 2.0.19: the pin rides the checkout-seam and wake-fix
+  cycle; this daemon serves the repaired `voice.wake.model.get`, which fixes
+  wake-word model delivery for every surface that fetches models from it.
+
 ---
 
+## [1.28.20] - 2026-08-21
+
+### Changes
+
+- **The payments surface answers on the standalone daemon** (platform runtime
+  2.0.18): cards list/create/delete, budget status, and the purchase ledger
+  serve external clients (webui, the desktop app) instead of answering 501.
+  Card metadata lives beside the daemon's other control-plane stores and card
+  material sits per field in the daemon secure secret tier; a corrupt card
+  file refuses writes rather than orphaning stored material, a CVV is never
+  supplied while cvvHandling is prompt, and the two checkout verbs keep an
+  honest 501 until the browser-driver seam exists.
+- **Stored remote-peer rows are validated when read**: a corrupt or
+  hand-edited row raises a typed error instead of flowing downstream
+  malformed, and removing such a row still works.
+- **Remote backends sweep their credential directories at construction**, so
+  a crashed daemon no longer leaves plaintext keys on disk across restarts.
+- Config keys are narrowed by a shared type guard instead of casts, and the
+  daemon's CI now gates coverage, architecture, and the sdk pin before any
+  tag exists.
+
 ## [1.28.19] - 2026-08-15
 
 ### Changes
@@ -15,7 +70,7 @@ All notable changes to the GoodVibes daemon.
   records fold in automatically, newest first, legacy files untouched.
 - **A turn through a strict OpenAI-compatible gateway works again** (platform
   runtime 2.0.17): the edit tool's schema declared a union with `oneOf`,
-  which validators like abacus RouteLLM now reject wholesale — every hosted
+  which validators like abacus RouteLLM now reject wholesale, and every hosted
   turn through such a provider failed with "Extra inputs are not permitted".
   The union is `anyOf` now, pinned by a wire-compatibility test.
 
@@ -25,8 +80,8 @@ All notable changes to the GoodVibes daemon.
 
 - **The keep-awake inhibitor can no longer paint an authentication prompt on
   a terminal** (platform runtime 2.0.15): a polkit refusal of the sleep
-  inhibitor — typical for tmux/SSH sessions logind does not count as an
-  active seat — used to register systemd's interactive auth agent on the
+  inhibitor, typical for tmux/SSH sessions logind does not count as an
+  active seat, used to register systemd's interactive auth agent on the
   controlling terminal. The inhibitor is now requested with
   `--no-ask-password`; refusal is silent and the platform runs without it.
 
@@ -36,8 +91,8 @@ All notable changes to the GoodVibes daemon.
 
 - **Post-wake capture ends when the speaker stops, on real microphones**
   (platform runtime 2.0.14): the silence floor now follows the room during
-  capture — a headset's automatic gain control ramping up after speech no
-  longer holds the microphone open — and breath ticks shorter than
+  capture, so a headset's automatic gain control ramping up after speech no
+  longer holds the microphone open, and breath ticks shorter than
   `voice.wake.speechRetriggerMs` (new setting, default 150 ms) no longer
   reset the silence clock. A pinned `voice.wake.silenceFloorRms` still
   freezes the floor completely.
@@ -54,7 +109,7 @@ All notable changes to the GoodVibes daemon.
   module scope; under the single-file compiler's nondeterministic module
   order that call could run before the helper exists, killing the binary at
   load. The table is now built on first use. Found by auditing for the same
-  build-order lottery class 1.28.15 fixed — this was the last direct
+  build-order lottery class 1.28.15 fixed. This was the last direct
   module-scope call into the platform runtime in this product.
 
 ## [1.28.15] - 2026-08-07
@@ -66,7 +121,7 @@ All notable changes to the GoodVibes daemon.
   off the SDK's runtime namespace objects at module scope (`export const X =
   ns.X`). Bun's single-file compiler emits module bodies in an order that
   varies build-to-build, and such a read can land before the module that
-  defines the binding — the binary then dies at load with a ReferenceError on
+  defines the binding, and the binary then dies at load with a ReferenceError on
   some builds of identical source. Every one of those reads is now a grouped
   live re-export from the SDK's registered runtime subpaths, resolved by the
   module system instead of read at module scope. The shared post-build smoke
@@ -83,7 +138,7 @@ All notable changes to the GoodVibes daemon.
   fan or steady background noise no longer holds the microphone open to the
   ceiling on every capture. The floor is a real setting
   (`voice.wake.silenceFloorRms`, 0 = adaptive), and
-  `voice.wake.captureMaxSeconds: 0` now genuinely means no hard maximum —
+  `voice.wake.captureMaxSeconds: 0` now genuinely means no hard maximum:
   whisper has no input limit, and capture closes on silence.
 - The exec sandbox's self-description now names the built-in tools a turn
   should use for daemon status and settings, so an assistant inside the
@@ -97,13 +152,13 @@ All notable changes to the GoodVibes daemon.
 - **Fixed: an unnamed transcription or synthesis request goes to the voice
   provider the user actually configured** (platform runtime 2.0.11). The
   daemon's provider picker answered "use whatever this host has configured"
-  with the first name on its internal registration list — a cloud provider —
+  with the first name on its internal registration list, a cloud provider,
   even when that provider had no key and the host carried fully provisioned
   local engines. On a machine set up for local voice, every wake-word
   transcription failed "OpenAI API key missing" while the user's working
   whisper was never asked, and no settings key could override the pick.
   Unnamed requests now prefer providers that report themselves configured,
-  with configured local engines first — free, offline, no key. A named
+  with configured local engines first, free, offline, no key. A named
   provider keeps exactly its previous behavior.
 
 ## [1.28.12] - 2026-08-05
@@ -113,7 +168,7 @@ All notable changes to the GoodVibes daemon.
 - **Fixed: a hosted conversational turn no longer gets the host.** The daemon
   composes hosted sessions through the same `createClientRuntimeServices` a
   terminal runs, so a hosted command already ran inside the same bubblewrap
-  boundary — network, PID, UTS and IPC namespaced, system read-only, /tmp and
+  boundary: network, PID, UTS and IPC namespaced, system read-only, /tmp and
   $HOME masked, `sandbox.egressAllowlist` the one way network comes back. What
   differed was the fallback: with no boundary available the command ran
   directly on the host and only said so afterwards, and a conversational turn
@@ -122,17 +177,18 @@ All notable changes to the GoodVibes daemon.
   `conversational`, which makes the boundary REQUIRED: a command that cannot be
   contained is refused, naming why, and `background: true` is not a spelling
   that gets around it. A hosted workstream that genuinely needs the machine is
-  a per-spawn grant written into this daemon's own composition — nothing on the
+  a per-spawn grant written into this daemon's own composition; nothing on the
   wire and nothing in a tool argument can reach it.
 - **Fixed: the owner's terminal is untouchable.** A command that drives an
-  existing tmux session, window or pane this platform did not create —
-  send-keys, kill, resize, attach, respawn, rename — is refused by the exec
-  guard for a hosted turn, with a refusal that names the rule. Creating and
+  existing tmux session, window or pane this platform did not create is
+  refused by the exec guard for a hosted turn, with a refusal that names the
+  rule. The blocked verbs are send-keys, kill, resize, attach, respawn,
+  rename. Creating and
   driving the platform's own sessions is unchanged, and so is reading tmux
   state (`list-sessions`, `list-panes`, `capture-pane`), which the fleet view
   already does. The frozen catastrophic block is untouched.
 - Changed: this daemon's hosted operator prompt carries the platform's
-  conversational diagnosis contract — report the state and propose, never
+  conversational diagnosis contract: report the state and propose, never
   restart the owner's applications or type into his terminal to "fix" things,
   and a "fixed" claim needs the live evidence it rests on.
 
@@ -151,7 +207,7 @@ All notable changes to the GoodVibes daemon.
   settings unreadable; wake transcription is daemon-first with failure
   evidence in diagnostics; the managed voice installer supersedes stale
   manual paths by name and proves itself with a spoken round trip.
-- Changed: setup flows complete the inferred intent — propose extensions,
+- Changed: setup flows complete the inferred intent: propose extensions,
   ask at genuine forks, never hand the user a command; the Google
   walkthrough accepts pasted values in-conversation and answers with the
   consent link.
@@ -173,7 +229,7 @@ All notable changes to the GoodVibes daemon.
   with receipts, and the legacy directory empties and is removed.
 - **Changed: the daemon hosts conversation turns for the agent.** Hosted
   session event streams are render-grade and session-scoped, so a client
-  rendering from the stream sees what the model said and what it did — and
+  rendering from the stream sees what the model said and what it did, and
   agent conversations become genuinely cross-visible with their messages.
 - Changed: connecting Google is one action, with every needed scope in a
   single consent and a live mail-and-calendar proof at the end; the settings
@@ -185,7 +241,7 @@ All notable changes to the GoodVibes daemon.
 ### Changes
 
 - Changed: a conversational turn is told to understand what it captures, not
-  just file it — an itinerary also means an away-span said back in plain
+  just file it. An itinerary also means an away-span said back in plain
   words, travelers who are people in the owner's life, and durable facts
   about the destination, and the turn uses what it stored: it names
   collisions with existing plans and offers the obviously useful next steps
@@ -199,14 +255,14 @@ All notable changes to the GoodVibes daemon.
 
 - **Fixed: a chat message gets an answer, never workflow paperwork.** The
   conversation gate's decision that a channel message is conversation is now
-  authoritative — the review-wording heuristic that turned "I'll review the
+  authoritative. The review-wording heuristic that turned "I'll review the
   route" in a transcript into a full write-review-fix-confirm chain can no
   longer override it. When a chain does legitimately run, the reply sent back
   over the channel carries what the agent actually found or did; chain status
   lines stay in the operator progress feed. Duplicate replies from the two
   completion reporters are gone (platform runtime 2.0.6).
 - **Added: personal information shared in conversation gets captured.** A
-  conversational channel turn — which previously ran with no tools at all —
+  conversational channel turn, which previously ran with no tools at all,
   now carries the profile capture tool with per-run owner authority: a trip
   itinerary pasted into Telegram lands in the owner profile's Plans section
   with its dates, flights, travelers and confirmation number, and the reply
@@ -231,15 +287,15 @@ All notable changes to the GoodVibes daemon.
 ### Changes
 
 - **Changed: payment limits hold the amount you would say out loud.** The
-  budget settings drop their unit suffix — `payments.budget.perPurchaseCeiling`,
-  `dailyItem`, `dailyOverage`, `overageToleranceDailyAllowance` — and hold
+  budget settings, `payments.budget.perPurchaseCeiling`,
+  `dailyItem`, `dailyOverage`, `overageToleranceDailyAllowance`, drop their unit suffix and hold
   plain amounts in the configured currency, written exactly as you give them:
   `100` is a hundred dollars, `19.99` is nineteen ninety-nine, and `$100`,
   `100.00` and `100` all mean the same hundred. This daemon migrates its
   settings file on load with a receipt; your limits are unchanged, only how
   they are written (platform runtime 2.0.5).
 - Fixed: every platform state store this daemon keeps writes atomically and
-  quarantines a corrupt file with a receipt instead of failing on it — the
+  quarantines a corrupt file with a receipt instead of failing on it. The
   watcher-snapshot fix from 1.28.6 is now the platform-wide rule. The daemon
   settings file itself deliberately keeps its stricter contract: an
   unparseable settings file still refuses the boot loudly, because defaults
@@ -251,7 +307,7 @@ All notable changes to the GoodVibes daemon.
 
 - **Fixed: a corrupt watcher snapshot no longer crash-loops this daemon.**
   A host freeze left the snapshot file as valid JSON followed by NUL bytes,
-  and the daemon died parsing it — once at boot, and once on a periodic tick
+  and the daemon died parsing it, once at boot, and once on a periodic tick
   47 seconds after every restart, so the service never stayed up. The
   platform runtime (2.0.4) now writes that file atomically and quarantines a
   corrupt one with a receipt beside it, rebuilding watcher state from live
@@ -266,7 +322,7 @@ All notable changes to the GoodVibes daemon.
 - Fixed: a client that inherited this daemon's bind host is no longer refused
   as "insecure PUBLIC transport" when that host is a wildcard. The platform
   runtime (2.0.3) classifies `0.0.0.0` and `::` with loopback and the other
-  private-network origins — a wildcard is a listen address, and dialing it
+  private-network origins: a wildcard is a listen address, and dialing it
   reaches the local machine. Until this fix, a daemon deliberately bound to
   `0.0.0.0` for LAN access left local clients unable to call it over plain
   http, profile reads included.
@@ -288,8 +344,8 @@ All notable changes to the GoodVibes daemon.
 
 - Fixed: importing settings that include `display.themeMode` no longer prints
   an "unknown key" warning. The SDK's configuration schema (2.0.1) now declares
-  the key — `auto` probes the terminal background once at startup, `dark` and
-  `light` force a fixed appearance — so every component ingests it as a real,
+  the key: `auto` probes the terminal background once at startup, `dark` and
+  `light` force a fixed appearance, so every component ingests it as a real,
   documented setting.
 
 ## [1.28.2] - 2026-08-01
@@ -312,7 +368,7 @@ All notable changes to the GoodVibes daemon.
 
 - `pair --host <name>` now reaches a DIFFERENT daemon instead of being refused.
   It asks that daemon to mint a brand-new per-device pairing token over
-  `pairing.handoff.create` and prints the pairing block for it — a different
+  `pairing.handoff.create` and prints the pairing block for it, a different
   act than the plain `pair` reprint, which still just reprints this machine's
   existing shared token and never mints. Because it changes state on a daemon
   that may not be this process's own, it states the plan and asks for
@@ -330,7 +386,7 @@ All notable changes to the GoodVibes daemon.
   and the advertised REST path.
 
   What a client gets is one merged timeline, newest first, across every
-  provider — items interleave by arrival rather than being grouped, and each
+  provider, items interleave by arrival rather than being grouped, and each
   carries its own `provider`, so an inbox reads like an inbox. Pages are bounded
   and walked with an opaque `nextCursor`; `cursor` stays what it was, the
   freshness watermark you hand back as `since`. That is a keyset, not an offset:
@@ -338,8 +394,8 @@ All notable changes to the GoodVibes daemon.
   every insert, so a caller walking pages during a poll would see items twice
   and miss others.
 
-  The answer is served from this daemon's SYNCED MIRROR — the sqlite store the
-  Slack, Discord and IMAP adapters already write into on their own cadences —
+  The answer is served from this daemon's SYNCED MIRROR, the sqlite store the
+  Slack, Discord and IMAP adapters already write into on their own cadences,
   and not from a fresh remote fetch per call. Four reasons, all of them about
   what a fetch-per-call would cost: a third-party rate limit would sit behind a
   read verb any client may call at any rate; the cluster hands FETCHING for each
@@ -356,7 +412,7 @@ All notable changes to the GoodVibes daemon.
   state, when it last synced, how much of the mirror is its, and whether this
   node is the one fetching it. `ready`, `empty`, `unconfigured`, `error` and
   `pending` are five different things, and a caller does something different
-  about each — a fresh install with no tokens is not an outage, and a node that
+  about each: a fresh install with no tokens is not an outage, and a node that
   has not looked yet is not a node reporting an empty inbox. A provider whose
   sync failed contributes no items, says why, and sets `partial`, so a short
   list is never mistaken for a quiet week. Nothing configured is an empty list
@@ -368,7 +424,7 @@ All notable changes to the GoodVibes daemon.
   path, the first rename moved it away, and the second failed with ENOENT on a
   file it had just written. Not hypothetical: the inbox poller flushes once per
   provider and polls every provider concurrently, so an ordinary two-provider
-  startup hit it — and once `channels.inbox.list` began reporting per-provider
+  startup hit it, and once `channels.inbox.list` began reporting per-provider
   health, the failure showed up as a provider reporting a filesystem error for
   its feed. The temp name now carries a per-process counter. Every store on
   `HandlerSqliteStore` shared the hazard, so the fix is there.
@@ -376,8 +432,8 @@ All notable changes to the GoodVibes daemon.
 - A gateway invocation that carries no context no longer throws a TypeError out
   of the handler wrapper. `normalizeContext` read `.metadata` off the context
   unconditionally, and an in-process invoke that builds the invocation by hand
-  can omit it; an absent context now reads as the empty one — no principal, no
-  scopes, not admin, nobody claiming a person asked — which can only cost a
+  can omit it; an absent context now reads as the empty one: no principal, no
+  scopes, not admin, nobody claiming a person asked, which can only cost a
   caller an authorization it never proved, never grant one.
 
 - Three config modules the terminal app carried a byte-identical copy of are the
@@ -391,7 +447,7 @@ All notable changes to the GoodVibes daemon.
   `parseConfigValueText`. `src/cli/config-value.ts` held a byte-identical copy
   of that function and its `cli/index.ts` re-export is gone with it. The copy
   existed because the shared one was private; it is exported now, and one
-  implementation is the whole point — `--config x=false` and `config set x
+  implementation is the whole point: `--config x=false` and `config set x
   false` must write the same thing.
 
 - The local `sql.js` ambient declaration is gone. The SDK ships the declaration
@@ -414,17 +470,17 @@ All notable changes to the GoodVibes daemon.
   installed agents) and `acp.sessions.create` (spawn one as a long-lived
   session) were cataloged and advertised as callable on every build, and
   answered nothing: the composition never constructed the ACP host they are
-  handlers for. `runtime/services.ts` now builds that host — permission asks
+  handlers for. `runtime/services.ts` now builds that host: permission asks
   from a hosted agent route through the same shared approval broker every
   other confirmation rides, and each hosted agent registers onto a shared
-  session so it is attachable and steerable like any native one — and threads
+  session so it is attachable and steerable like any native one, and threads
   it into the gateway registration and the fleet registry, so a hosted agent
   also shows up as a fleet row.
 
 - The command line is the daemon's, and it is an operator surface rather than a
   way to start a process. It shipped carrying the terminal app's parser: a table
-  of two dozen command words — `tui`, `run`, `doctor`, `models`, `providers`,
-  `auth`, `secrets`, `plugin` — against an entry point that dispatched on help,
+  of two dozen command words (`tui`, `run`, `doctor`, `models`, `providers`,
+  `auth`, `secrets`, `plugin`) against an entry point that dispatched on help,
   version and four service verbs. Everything else fell through to "start a
   daemon in the foreground", so `goodvibes-daemon status` served, and so did
   `goodvibes-daemon install-servce`. The parser's own unknown-command error was
@@ -434,9 +490,9 @@ All notable changes to the GoodVibes daemon.
   (`src/cli/command-catalog.ts`) that the parser, the help text and the shell
   completions all read. Serving happens on a bare invocation or on `serve`, and
   on nothing else; any other unrecognized word exits 2 with `Unknown command: X`
-  and the help. The terminal app's conversation flags — `--resume`, `--continue`,
+  and the help. The terminal app's conversation flags (`--resume`, `--continue`,
   `--fork`, `--print`, `--prompt`, `-o/--output`, `--open`, `--no-alt-screen`,
-  `--session`, `--strict` — were accepted in silence and read by nothing; each is
+  `--session`, `--strict`) were accepted in silence and read by nothing; each is
   now refused by name and says which surface owns it.
 
 - New commands, all of them things a headless box's operator previously had no
@@ -452,8 +508,8 @@ All notable changes to the GoodVibes daemon.
     with the same operator token.
   - `config list|get|set|unset` reads and writes this machine's settings
     directly, so it works whether or not a daemon is running. Every value it
-    PRINTS goes through the redaction rules first — a token, a password or an API
-    key reads as `<redacted>` — while `config set` still writes the real value.
+    PRINTS goes through the redaction rules first, so a token, a password or an API
+    key reads as `<redacted>`, while `config set` still writes the real value.
   - `pair` prints the pairing link and QR again, from the same renderer the
     daemon uses at startup and carrying the same existing token, so the block is
     no longer lost when the boot banner scrolls away.
@@ -468,14 +524,14 @@ All notable changes to the GoodVibes daemon.
   - `completion bash|zsh|fish`, generated from the catalog, and `help <command>`
     for any command's own arguments and flags.
 
-- `service-status` answers with an exit code — 0 installed and running, 3
-  installed but not running, 4 not installed — and takes `--json`. A script no
+- `service-status` answers with an exit code: 0 installed and running, 3
+  installed but not running, 4 not installed, and takes `--json`. A script no
   longer has to read the prose to find out.
 
 - The help text describes the binary that exists: every command, the flags that
   work, `-y/--yes`, `--config`, `--enable`/`--disable`, `--json`, the exit codes,
   and a systemd user service, a launchd agent or a Scheduled Task depending on
-  the platform it is printed on — it used to say systemd on every platform,
+  the platform it is printed on. It used to say systemd on every platform,
   including macOS, where `install-service` writes a launchd agent.
 
 - `status` reads the daemon's identity, health and channel routes with the
@@ -492,7 +548,7 @@ All notable changes to the GoodVibes daemon.
   floor is built (`DaemonConfig.hostedSessions`, wired in
   `runtime/hosted-session-composition.ts`) turns on the SDK's hosted-session
   engine and its `sessions.hosted.create/attach/detach/kill/list` verbs: a full
-  loop composed inside this process — the same orchestrator, the same tool
+  loop composed inside this process: the same orchestrator, the same tool
   registry rooted at the named workspace, the same permission machinery a
   terminal runs. Driving one uses the verbs that already existed
   (`sessions.steer`, `sessions.followUp`, `sessions.toolCalls.cancel`,
@@ -508,7 +564,7 @@ All notable changes to the GoodVibes daemon.
   directories asks three separate questions.
 
   Detaching is governed by `hostedSessions.detachPolicy`, which defaults to
-  `kill` — closing a client has always ended its work. `survive` opts into
+  `kill`. Closing a client has always ended its work. `survive` opts into
   sessions that outlive both the client and a restart of this daemon; a single
   session may override the setting when it is created. `hostedSessions.maxSessions`
   caps how many loops this machine holds at once, and the transcript bound and
@@ -532,13 +588,13 @@ All notable changes to the GoodVibes daemon.
   by id. The runtime is handed over whole, deliberately: the verbs and the `phone`
   tool must reach the same service, because a second path to a phone would be a second
   place the confirmation prompt and the durable grants could be decided differently.
-  Nothing about the gates moved — the prompt still rides this daemon's shared approval
+  Nothing about the gates moved. The prompt still rides this daemon's shared approval
   seam and appears wherever the person is looking.
 
 - Conversation-scope rewind stopped answering for sessions it holds nothing for.
   `conversation-rewind-port.ts` resolves a session's conversation from an in-process
   registry, and while the conversation loops run in the surfaces that registry is
-  empty here. It reported "0 messages to drop" — the same answer a conversation
+  empty here. It reported "0 messages to drop", the same answer a conversation
   already at the anchor gives, so a caller could not tell a rewind that found nothing
   from one that reached nobody. It now reports the anchor as unavailable with the
   reason, which `rewind.plan` surfaces as a warning and `rewind.apply` records instead
@@ -555,8 +611,8 @@ All notable changes to the GoodVibes daemon.
   rode a terminal-app release. It now has its own repository, its own release line and its own
   binary, and the terminal app and the agent become clients of it.
 
-- The suite installer lives here now. `scripts/install.sh` — the script behind
-  `curl -fsSL https://goodvibes.sh/install.sh | sh` — moved out of the terminal app's
+- The suite installer lives here now. `scripts/install.sh` (the script behind
+  `curl -fsSL https://goodvibes.sh/install.sh | sh`) moved out of the terminal app's
   repository into this one, because the daemon is the product everything else is
   installed alongside and this repository's release lane is the one that publishes it.
   There is exactly one copy: two installers in two repositories is how two installers
@@ -585,7 +641,7 @@ All notable changes to the GoodVibes daemon.
   act, and the install receipt prints both the URL and the one command that does it.
 
 - **New: `goodvibes-daemon webui enable | disable | status`.** The command that owns
-  serving the web UI — which directory, whether it is served at all, and the honest
+  serving the web UI: which directory, whether it is served at all, and the honest
   answer to "what URL do I open and who can reach it". `enable --bundle-dir <dir>`
   refuses a directory with no index.html rather than pointing the daemon at something it
   cannot serve; `--lan` is the one act that widens exposure and `--loopback` takes it
@@ -594,7 +650,7 @@ All notable changes to the GoodVibes daemon.
   The URL it reports is the control-plane origin, because that is the listener serving
   the bundle. `web.port` is the surface's declared endpoint and nothing binds it, so
   `enable` also replaces the shipped `web.publicBaseUrl` placeholder (`http://127.0.0.1:3423`)
-  with the origin that actually answers — leaving any value an operator chose alone, and
+  with the origin that actually answers, leaving any value an operator chose alone, and
   saying so when the two differ.
 
 - The daemon updates itself from this repository. The platform default for
@@ -610,7 +666,7 @@ All notable changes to the GoodVibes daemon.
   settings file carries it and no migration rewrites it. The terminal repository no
   longer builds daemon binaries, so those daemons resolve a release with no
   `goodvibes-daemon-<os>-<arch>` asset and fail. Pointing them at this repository
-  instead does not rescue them either — their shipped updater adds the terminal binary
+  instead does not rescue them either. Their shipped updater adds the terminal binary
   beside them to the same all-or-nothing download whenever `goodvibes` sits in the
   install directory, which `scripts/install.sh` guarantees, and this repository
   deliberately publishes no terminal binary. There is also no remote write path to
@@ -629,7 +685,7 @@ All notable changes to the GoodVibes daemon.
   Named rather than implied away: the SDK's `resolveDaemonInstalledFiles` still adds
   the terminal binary to the daemon's OWN update target set when one sits beside it, so
   on a three-binary install a daemon from this repository cannot yet complete an
-  unattended self-update either — it asks for a `goodvibes-<os>-<arch>` asset this
+  unattended self-update either. It asks for a `goodvibes-<os>-<arch>` asset this
   repository does not publish and takes the 404. Making each product update strictly
   its own files is an SDK change, not one this repository can make.
 
@@ -650,7 +706,7 @@ All notable changes to the GoodVibes daemon.
 
   Nothing about where this daemon keeps its state changed. The hoisted modules
   that used to spell the storage scope now take it as a parameter, and every
-  call site here passes the daemon's own — the work plan, the session surface,
+  call site here passes the daemon's own: the work plan, the session surface,
   the workspace trust file, the code-index database and the operator-token
   pruning candidates all resolve to exactly the paths they resolved to before.
 
@@ -663,13 +719,13 @@ All notable changes to the GoodVibes daemon.
   which the shared override path only does for whole `key=value` strings.
 
 - The command line is parsed by the shared argument engine, driven by this
-  binary's catalog. `src/cli/parser.ts` was a full engine — the command-word
-  pre-scan, arity skipping, `--`, inline `=value`, per-kind application — with
+  binary's catalog. `src/cli/parser.ts` was a full engine: the command-word
+  pre-scan, arity skipping, `--`, inline `=value`, per-kind application, with
   a switch over one product's flag field names. The engine is now
   `parseWithCatalog`, and `src/cli/command-catalog.ts` is the vocabulary it
   reads: the same commands, the same aliases, the same flags per command, the
   same refusal that an unrecognized word exits 2 rather than starting a daemon.
-  One sentence reads differently — a conversation flag this binary does not
+  One sentence reads differently. A conversation flag this binary does not
   have is now refused as "`--resume` is not a goodvibes-daemon flag — resuming
   a conversation, a terminal app concern that belongs to another surface."
 
@@ -681,5 +737,5 @@ All notable changes to the GoodVibes daemon.
   its tools when an optional install quietly fails. They are declared here at
   the ranges the platform states, and a dependency check makes a missing one
   fail at build time instead of at the first hosted turn. `@anthropic-ai/vertex-sdk`
-  and `@aws/bedrock-token-generator` are removed — nothing in this repository or
+  and `@aws/bedrock-token-generator` are removed. Nothing in this repository or
   the platform imports either.

package/README.md

@@ -2,14 +2,19 @@
 
 [![CI](https://github.com/mgd34msu/goodvibes-daemon/actions/workflows/ci.yml/badge.svg)](https://github.com/mgd34msu/goodvibes-daemon/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-1.28.14-blue.svg)](https://github.com/mgd34msu/goodvibes-daemon)
+[![Version](https://img.shields.io/badge/version-1.28.20-blue.svg)](https://github.com/mgd34msu/goodvibes-daemon)
 
 The GoodVibes daemon: one long-running process per machine that holds the control plane every
-GoodVibes client talks to. It answers the operator verb families over HTTP, reads and replies on
-your channels, elects a leader among the machines you have grouped together so only one of them
-answers a shared inbox, runs scheduled and triggered work, keeps the session, memory, knowledge
-and code-index stores, provisions the local voice and wake-word models, and updates itself at an
-idle moment with a rollback if the new binary will not start.
+GoodVibes client talks to. It:
+
+- answers the operator verb families over HTTP
+- reads and replies on your channels
+- elects a leader among the machines you have grouped together, so only one of them answers a
+  shared inbox
+- runs scheduled and triggered work
+- keeps the session, memory, knowledge and code-index stores
+- provisions the local voice and wake-word models
+- updates itself at an idle moment, with a rollback if the new binary will not start
 
 The terminal app (`goodvibes`), the conversational agent (`goodvibes-agent`) and the web app are
 clients of this process. They render, they capture input, and they call verbs; the work happens
@@ -25,8 +30,8 @@ A **product** over `@pellux/goodvibes-sdk`, exactly like the TUI and the agent a
 - the CLI (`send`, `cluster`, `webui`, `provision-wake-model`, `install-service` and friends),
 - packaging: the compiled `goodvibes-daemon-<os>-<arch>` binaries.
 
-Every engine — the facade, the routes, the brokers, the updater, the channel adapters, the
-schedulers — lives in the SDK and is consumed from the published package. Nothing was moved out of
+Every engine (the facade, the routes, the brokers, the updater, the channel adapters, the
+schedulers) lives in the SDK and is consumed from the published package. Nothing was moved out of
 the SDK to build this repository, and nothing should be: a capability that both a client and the
 daemon need belongs in the SDK, not here.
 
@@ -34,7 +39,7 @@ daemon need belongs in the SDK, not here.
 
 The daemon's version is **1.28.0**. Live installs already carry a settings reader-floor
 (`$goodvibes.minReaderVersion`), the update handover compares versions monotonically, and the
-rejected-version record is keyed by version — those three mechanics all depend on the version
+rejected-version record is keyed by version. Those three mechanics all depend on the version
 line staying continuous and monotonically increasing.
 
 ## Install
@@ -43,14 +48,14 @@ line staying continuous and monotonically increasing.
 curl -fsSL https://goodvibes.sh/install.sh | sh
 ```
 
-This installs the whole GoodVibes suite — the daemon, the terminal app, the
-agent, and the browser operator surface — from checksum-verified binaries,
+This installs the whole GoodVibes suite (the daemon, the terminal app, the
+agent, and the browser operator surface) from checksum-verified binaries,
 with no package manager involved.
 
 The browser surface is not a fourth binary and not a fourth service: the bundle
 unpacks to `<install dir>/webui/<version>` and this daemon serves it on its own
 listener, same origin as the API. Installing it exposes nothing new to your
-network — the shipped binding is loopback and the installer does not change it.
+network. The shipped binding is loopback and the installer does not change it.
 `goodvibes-daemon webui --lan` is the deliberate act that widens it, and
 `goodvibes-daemon webui status` says which posture is in force.
 
@@ -101,13 +106,13 @@ goodvibes-daemon provision-wake-model
 
 ## Documentation
 
-- [Getting Started](docs/getting-started.md) — install, first boot, pairing, where state lives, health checks
-- [Command Reference](docs/commands-reference.md) — every command, its flags, and its exit codes
-- [Configuration](docs/configuration.md) — the settings this daemon reads, by key
-- [Service and Deployment](docs/service-and-deployment.md) — the host service, migration from an older install, `--daemon-home` vs the data home
-- [Updates and Rollback](docs/updates-and-rollback.md) — the hourly self-update loop, automatic crash-loop rollback, `.previous`
-- [Daemon-Hosted Sessions](docs/hosted-sessions.md) — conversations that run inside the daemon and outlive any one client
-- [Troubleshooting](docs/troubleshooting.md) — startup failures, log locations, port conflicts, service-status oddities
+- [Getting started](docs/getting-started.md): install, first boot, pairing, where state lives, health checks
+- [Command reference](docs/commands-reference.md): every command, its flags, and its exit codes
+- [Configuration](docs/configuration.md): the settings this daemon reads, by key
+- [Service and deployment](docs/service-and-deployment.md): the host service, migration from an older install, `--daemon-home` vs the data home
+- [Updates and rollback](docs/updates-and-rollback.md): the hourly self-update loop, automatic crash-loop rollback, `.previous`
+- [Daemon-hosted sessions](docs/hosted-sessions.md): conversations that run inside the daemon and outlive any one client
+- [Troubleshooting](docs/troubleshooting.md): startup failures, log locations, port conflicts, service-status oddities
 
 ## License
 

package/bin/launcher-support.js

@@ -14,8 +14,8 @@
  *
  * The sqlite-vec native addon gets the same self-heal: `resolveSqliteVecPath()`
  * (platform/state/sqlite-vec-loader.ts, reached from a compiled binary) expects
- * it at `<execDir>/lib/sqlite-vec-<platform>-<arch>/vec0.<suffix>` —
- * `vendor/lib/...` once the binary above is placed there — and a blocked
+ * it at `<execDir>/lib/sqlite-vec-<platform>-<arch>/vec0.<suffix>`,
+ * `vendor/lib/...` once the binary above is placed there, and a blocked
  * postinstall never staged it either. Without this, a self-healed install
  * would get the daemon binary back but stay on lexical-only search forever.
  */
@@ -26,7 +26,7 @@ import { join } from 'node:path';
 
 const SUPPORTED_TARGETS = ['linux-x64', 'linux-arm64', 'darwin-x64', 'darwin-arm64'];
 
-/** Names the sqlite-vec addon for a platform/arch — mirrors resolveSqliteVecAsset
+/** Names the sqlite-vec addon for a platform/arch, mirrors resolveSqliteVecAsset
  * in the SDK's platform/runtime/self-update module. Reimplemented (rather than
  * imported) so this launcher never depends on that package resolving: it must
  * keep working from the packaged bin/ directory alone, with no bundler step
@@ -120,11 +120,11 @@ export async function ensureVendoredBinary({ packageRoot, artifactName }) {
  * Self-heal counterpart to `ensureVendoredBinary` for the sqlite-vec native
  * addon. Same shape, same verification posture (a missing manifest entry does
  * not block the install, matching `ensureVendoredBinary` above), same
- * vendor/ destination — placed at `vendor/lib/sqlite-vec-<platform>-<arch>/
+ * vendor/ destination, placed at `vendor/lib/sqlite-vec-<platform>-<arch>/
  * vec0.<suffix>`, which is exactly where `resolveSqliteVecPath()` looks
  * relative to the vendored binary this module also places. A platform/arch
  * with no addon (`resolveSqliteVecAddonName` returns null) is a no-op, not an
- * error — same as an unsupported binary target.
+ * error, same as an unsupported binary target.
  */
 export async function ensureVendoredSqliteVecAddon({ packageRoot, platform, arch }) {
   const asset = resolveSqliteVecAddonName(platform, arch);