@pellux/goodvibes-tui 1.27.0 → 2.0.1

package/CHANGELOG.md

@@ -4,6 +4,129 @@ All notable changes to GoodVibes TUI.
 
 ---
 
+## [2.0.1] - 2026-08-01
+
+### Changes
+
+- This repository's releases now carry the suite installer; the command at
+  `https://goodvibes.sh/install.sh` is unchanged.
+
+## [2.0.0] - 2026-08-01
+
+### Changes
+
+- **Breaking: this build refuses to attach to a daemon older than `1.28.0`.**
+  1.28.0 is the daemon release where the daemon became its own product and
+  this terminal became a pure client of it — the session register, the
+  inbound steer queue, the fleet needs-input push and the credential writes
+  this build calls are all served there, and an older daemon answers some of
+  those and not others. Rather than run half-working against a peer it has no
+  reason to suspect, this build reads the daemon's version on every attach and
+  refuses one below its floor instead of adopting it. What a user sees: the
+  daemon status reads as an unadopted, incompatible service, and one line
+  names both versions — "`<daemon>` is running build X; this client requires
+  1.28.0 or newer — update the daemon." Refused means local-only, which this
+  app already renders honestly; no second daemon is started on the occupied
+  port. On the ordinary path nothing needs doing: a pre-split daemon (1.27.1
+  or below) is handed over to its own release line once at this app's next
+  launch (see below), and every daemon past the split updates itself hourly
+  from there, so the floor is met without anyone touching anything. If a
+  daemon still answers below 1.28.0 — auto-update turned off, or a fresh
+  manual install of an old release — re-run the suite installer
+  (`curl -fsSL https://goodvibes.sh/install.sh | sh`) to bring the daemon
+  current.
+- The daemon is a separate product and this package stops carrying it. It was
+  built here, released here, shipped inside this npm tarball, vendored into
+  every platform package, and swapped by this app's `/update`. All of that came
+  from one repository holding two programs; the daemon has its own repository,
+  its own release line and its own npm package now. This package builds one
+  binary, ships one `bin` entry, vendors one file, and its releases carry four
+  binaries instead of eight.
+- `npm install @pellux/goodvibes-tui` still brings the whole thing: this package
+  declares `goodvibes-daemon` as a dependency, so one install still puts both
+  commands on your PATH. What changed is that the daemon's own package places
+  the daemon's own binary — two packages each placing a copy of
+  `goodvibes-daemon` is exactly how a machine ends up with two of them.
+- `/update apply` and `/update rollback` no longer touch the daemon binary
+  beside this one. A release of this repository publishes no daemon asset at
+  all, so a swap from here would be looking for a file that does not exist —
+  and, if one ever appeared under that name, would replace a working daemon with
+  a build from a different version line. Both commands say so in their report
+  rather than leaving a reader to wonder where the second line went. A daemon
+  built from the daemon's own repository updates itself, hourly, from its own
+  releases.
+- **New: this app hands a pre-split daemon over to its own release line, once,
+  at launch.** A daemon shipped at 1.27.1 or below cannot do this for itself.
+  Its `update.releasesUrl` default is compiled in, not persisted — no settings
+  file carries it and no migration rewrites it — and it names this repository,
+  which no longer builds daemon binaries. Reconfiguring it to the daemon's
+  repository does not help either: its shipped updater adds the terminal binary
+  beside it to the same all-or-nothing download whenever `goodvibes` sits in the
+  install directory, which the installer guarantees, and the daemon's repository
+  publishes no terminal binary. So this app reads the version of the
+  `goodvibes-daemon` binary installed beside it and, when that binary predates
+  the split, downloads the current daemon from the daemon's own releases,
+  checksum-verifies it, swaps it with the outgoing build kept at
+  `<path>.previous`, and restarts the service — printing a receipt naming both
+  versions. It replaces that one file: not this app's binary, not the sqlite-vec
+  addon the three binaries share. A binary whose version cannot be read is never
+  swapped, a package-manager-managed daemon is never swapped in place, and once
+  the installed daemon is 1.28.0 or newer the path goes quiet permanently. The
+  existing `update.autoUpdateAtLaunch` setting turns it off along with this
+  app's own launch update; no second switch was added for one migration.
+- The suite installer moved to the daemon's repository, where the release lane
+  that publishes it to goodvibes.sh lives. `curl -fsSL https://goodvibes.sh/install.sh | sh`
+  is unchanged and still installs everything — it now also installs the browser
+  operator surface. The `run-goodvibes` GitHub Action fetches that published
+  installer instead of running a committed second copy.
+
+- The Cloudflare Zero Trust Tunnel route now turns on
+  `httpListener.trustCloudflare`. That route already wrote
+  `controlPlane.trustProxy` and `httpListener.trustProxy` so the login
+  rate-limiter keyed on the address the tunnel forwards — but with only
+  trustProxy set, that address comes from `X-Forwarded-For`, which a client
+  reaching the listener directly sets for itself, so it could still choose which
+  rate-limit bucket and audit-log entry it landed in. The stricter read (the
+  address comes from `CF-Connecting-IP`, accepted only from a peer inside a
+  published Cloudflare range) had no setting behind it when the wizard was
+  written and now does. The step's notice says the protection is ON for this
+  route, and still names what is not covered: the control plane has no
+  equivalent setting, so keep it reachable only through the tunnel.
+
+- Crash-restore is the SDK's mechanism now, and this app keeps the ask.
+  `core/session-recovery.ts` is gone; `applyRecoverySnapshot` and the
+  journal-replay helpers it wrapped moved to the SDK
+  (`platform/runtime/recovery-snapshot-apply.ts`, and the
+  `transcript-journal-replay.ts` this repo had a second copy of).
+  `runtime/recovery-prompt.ts` still owns the two-step modal, and
+  `runtime/recovery-offer-wiring.ts` still owns this shell's live objects; what
+  they now hand the SDK is the user's answer. Reading a snapshot and retiring it
+  are one operation there, so this flow can no longer load one and leave it
+  behind — and a snapshot that turns out to be damaged is reported as such
+  instead of being applied as an empty conversation.
+
+- Three config modules the daemon carried a byte-identical copy of are the
+  SDK's: `config/goodvibes-home.ts` (tree-root and daemon-home resolution),
+  `config/provider-model.ts` (`provider:model` parsing) and `config/index.ts`
+  (which was a barrel over the SDK plus two derivation helpers, both of which
+  moved). Every importer reads them from `@pellux/goodvibes-sdk/platform/config`
+  and `.../platform/providers`. One behaviour came with them: an unreadable
+  `provider.systemPromptFile` still degrades to "no configured system prompt"
+  rather than throwing, because the SDK adopted this app's version.
+
+- The local `sql.js` ambient declaration is gone. The SDK ships the declaration
+  now, and the one file that imports `sql.js` picks it up with
+  `/// <reference types="@pellux/goodvibes-sdk/sql-js" />`.
+
+## [1.27.0] - 2026-07-30
+
+### Fixes
+
+- Fixed: the daemon died without saying why. Measured against the released 1.27.0 daemon binary, in a throwaway home whose `.goodvibes/daemon/settings.json` could not be parsed: it exited 1 with zero bytes on stdout, zero bytes on stderr, and no activity log at all. It restarted and failed 77 times overnight and the only sign anything was wrong was that everything had stopped. The cause was not output buffering and not a handler that got skipped — the daemon reported the failure to the activity logger and exited, and the daemon had never given that logger a file to write to, so nothing reached a console, a journal or a log. Writing to a log object is not the same as writing to the terminal. Every place the daemon can exit before its screen is up now writes to the error stream directly, before anything else and before the exit: the startup failure itself, the flag-parse refusal, the config and endpoint override refusals, and the `cluster`, `send`, `provision-wake-model` and service subcommands. Written to the file descriptor rather than through `process.stderr`, because this program replaces `process.stderr` to keep the rendered screen clean, and because a stream write issued immediately before the process exits can still be in flight when the process stops existing. Proven the only way it can be proven — by compiling a binary and running it — against a control that pins the old shape at zero bytes, so nobody can put the silence back without a test failing.
+- Fixed: the daemon now writes an activity log. The standalone daemon never named a log file at boot, so every line it logged for its whole lifetime went nowhere, and the flushes it performs before exiting had nothing to flush.
+- Fixed: the interactive program's startup failure message goes to the error stream directly too, for the same reason: the guard that keeps the screen clean is exactly the thing that could swallow the one line explaining why the screen is blank.
+- Fixed: `--daemon-home` is given the daemon's own state directory — `~/.goodvibes/daemon`, where its operator tokens, its users and its daemon settings live — instead of the home directory above it. The installer's systemd unit, the installer's macOS launch agent, the in-app install-service, and a daemon started in the background by the interactive program all named the home directory, so a daemon filed its identity one level above where every reader of it looks, and the program that started it went on reading an empty file. An already-installed service unit that carries no pinned host or port is still left alone on upgrade, so an existing install keeps the old location until its unit is regenerated.
+
 ## [1.26.0] - 2026-07-29
 
 ### Changes
@@ -203,7 +326,7 @@ Updated: @pellux/goodvibes-sdk and @pellux/goodvibes-terminal-shell to 1.11.3 (q
 - 366560a0 daemon: honest startup identity and unattended legacy-unit reconcile
 - 615d60aa installer: unify the daemon service on the canonical goodvibes.service unit
 
-## [Unreleased]
+## [2.0.0] - 2026-08-01
 
 ### Fixed
 - Installer now creates one daemon service unit that matches the app. The curl
@@ -1135,7 +1258,7 @@ First release of the best-in-class program: a full UX-first review of the codeba
 - 7ff4ab69 fix installed daemon service home
 - 8303819d docs: document Bun global trust setup
 
-## [Unreleased]
+## [2.0.0] - 2026-08-01
 
 ---
 

package/README.md

@@ -2,7 +2,7 @@
 
 [![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-1.27.0-blue.svg)](https://github.com/mgd34msu/goodvibes-tui)
+[![Version](https://img.shields.io/badge/version-2.0.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 it finds on startup), keeps its settings, sessions, and secrets on your own machine, and shows you the token count and running cost of every turn. Alongside the conversation, panels turn background work — running agents, git state, diffs, tokens, cost — into live control rooms.
 
@@ -23,11 +23,11 @@ Or install from the npm registry with [Bun](https://bun.sh):
 
 ```sh
 bun add -g @pellux/goodvibes-tui
-bun pm trust -g @pellux/goodvibes-tui
+bun pm trust -g @pellux/goodvibes-tui goodvibes-daemon
 goodvibes
 ```
 
-Bun blocks lifecycle scripts for untrusted global packages, so the second line lets the package's postinstall place the matching TUI and daemon binaries. Only `@pellux/goodvibes-tui` itself needs trusting — no dependency does. If you skip that step, the `goodvibes` launcher still self-heals on first run by fetching and checksum-verifying the binaries. `npm install -g @pellux/goodvibes-tui` also works when `bun` is already on `PATH`.
+Bun blocks lifecycle scripts for untrusted global packages, so the second line lets both postinstalls run: `@pellux/goodvibes-tui`'s own, which places the TUI binary, and `goodvibes-daemon`'s — a real dependency of this package, so one install brings both commands — which places the daemon binary. No other dependency needs trusting. If you skip that step, the `goodvibes` launcher still self-heals on first run by fetching and checksum-verifying its own binary. `npm install -g @pellux/goodvibes-tui` also works when `bun` is already on `PATH`.
 
 Then point it at a model — an environment variable is the fastest path:
 
@@ -120,7 +120,7 @@ Each row links to the page that documents it. The product's own `?` overlay and
 | Session durability | Post-turn snapshots plus an fsync-per-record transcript journal replayed at every resume | [session-durability.md](docs/session-durability.md) |
 | Planning | Conversational planning loop, project-scoped knowledge spaces, readiness evaluation, the Planning panel | [project-planning.md](docs/project-planning.md) |
 | Sharing and export | `/share` to HTML, JSON, or Markdown with redaction, upload, and clipboard options | [share-command.md](docs/share-command.md) |
-| Daemon and services | TUI-only or in-process daemon, headless daemon/API host, browser operator surface, background service and autostart, inbound TLS, outbound trust | [deployment-and-services.md](docs/deployment-and-services.md) |
+| Daemon and services | Connecting to the standalone GoodVibes daemon, browser operator surface, background service and autostart, inbound TLS, outbound trust | [deployment-and-services.md](docs/deployment-and-services.md) |
 | Remote access | A worked home-server setup: always-on daemon, browser access, TUI over SSH, reachability and TLS | [remote-access.md](docs/remote-access.md) |
 | Channels and API | Slack, Discord, Telegram, Matrix, webhook and other surfaces; the shared reply pipeline; remote peers and node hosts; the control-plane HTTP and streaming API | [channels-remote-and-api.md](docs/channels-remote-and-api.md) |
 | Voice | Live `/tts` playback, TTS and STT providers, streaming voice API | [voice-and-live-tts.md](docs/voice-and-live-tts.md) |
@@ -154,7 +154,7 @@ Edit them live with `/settings` or the fullscreen `/config` workspace rather tha
 | `display.showThinking` | `false` | Show model thinking traces |
 | `behavior.autoCompactThreshold` | `80` | Context percentage before auto-compact runs |
 | `helper.enabled` | `false` | Route grunt work to a cheaper helper model |
-| `daemon.enabled` | `true` | Run the local session daemon, bound to loopback |
+| `daemon.enabled` | `true` | Spawn or adopt a detached local session daemon, bound to loopback |
 
 The wider key table, the permission modes, and the hand-edited TUI namespaces (checkpoint root guard, scriptable statusline, session behavior, launch-time self-update) are in [docs/configuration.md](docs/configuration.md).
 
@@ -193,11 +193,10 @@ bun run dev
 | Command | Does |
 | --- | --- |
 | `bun run dev` | Run the TUI from source |
-| `bun run daemon` | Run the headless daemon/API host from source |
 | `bun test` | Run the suite through the parallel per-file runner |
 | `bun run build` | Compile `src/main.ts` into `dist/goodvibes` |
 
-The compiled binary is the TUI entrypoint; it also hosts the daemon in-process (`daemon.enabled`, on by default, loopback-bound) and the HTTP listener when `danger.httpListener` is enabled.
+The compiled binary is the TUI entrypoint; it adopts a running standalone GoodVibes daemon, or starts one already installed as a stopped service — it never spawns a new daemon process itself (`daemon.enabled`, on by default, loopback-bound) — and hosts the HTTP listener when `danger.httpListener` is enabled.
 
 Tests live under `src/test/`, mirroring the source tree, and cover contract, security, release-gate, runtime, renderer, panel, 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`).
 
@@ -208,7 +207,7 @@ Some decisions worth knowing before you read the source:
 - **In-process agents** — agents run in the same process rather than over IPC, staying isolated through scoped tool registries and namespaced state.
 - **Typed runtime store** — a plain `zustand/vanilla` store with typed selectors and dispatch paths, reachable from agents, tools, renderer, hooks, channels, and daemon surfaces alike.
 - **Tree-sitter and bundled language servers** — grammars for structural analysis, outlines, and AST-level edits, several embedded as WASM for instant startup; TypeScript, Python, Bash, CSS, HTML, and JSON language servers ship as dependencies, while `rust-analyzer` and `gopls` are fetched on first use with checksum verification.
-- **Backend-first external surface** — the daemon and control plane expose typed HTTP and gateway methods, so other clients do not reimplement runtime logic.
+- **Backend-first external surface** — the daemon product exposes typed HTTP and gateway methods, so other clients do not reimplement runtime logic.
 - **Crash recovery** — periodic snapshots plus an fsync-per-record append-only transcript journal, replayed at every resume seam.
 - **Render coalescing and a per-message line cache** — same-tick render requests collapse into one composite frame, and transcript growth re-renders only the appended message instead of rebuilding the whole conversation.
 
@@ -227,7 +226,6 @@ src/
 ├── config/                 settings layering, surface roots, secrets, credential availability
 ├── permissions/            approval cards, hunk selection, sandbox exec gate
 ├── cli/                    flag parsing, management verbs, doctor, launch-time self-update
-├── daemon/                 daemon CLI, lifecycle, request handlers, service commands
 ├── tools/, mcp/, plugins/  TUI-local tool guards, MCP hot reload, plugin loader
 ├── audio/, export/         turn playback and speech routing, cost pricing and gist upload
 ├── verification/, work-plans/, widget/    live verifier and ledger, work-plan store, widget module

package/bin/goodvibes

@@ -21,7 +21,7 @@ if (process.platform === 'win32') {
   process.exit(1);
 }
 
-const artifactName = resolveArtifactName('app', process.platform, process.arch);
+const artifactName = resolveArtifactName(process.platform, process.arch);
 const localPlatformBuild = artifactName ? join(packageRoot, 'dist', artifactName) : null;
 const localBuild = join(packageRoot, 'dist', 'goodvibes');
 const vendoredBinary = artifactName ? join(packageRoot, 'vendor', artifactName) : null;
@@ -38,7 +38,7 @@ if (vendoredBinary && isExecutable(vendoredBinary)) {
   run(vendoredBinary, process.argv.slice(2));
 }
 
-const platformPackageBinary = resolvePlatformPackageBinary('app', process.platform, process.arch, packageRoot);
+const platformPackageBinary = resolvePlatformPackageBinary(process.platform, process.arch, packageRoot);
 if (platformPackageBinary) {
   run(platformPackageBinary, process.argv.slice(2));
 }

package/bin/launcher-support.js

@@ -23,8 +23,8 @@ const PLATFORM_PACKAGE_NAMES = {
  * trust step and no post-install download. Returns null when the package is not
  * installed (e.g. an unsupported platform, or optional-dep resolution skipped).
  */
-export function resolvePlatformPackageBinary(kind, platform, arch, fromDir) {
-  const artifactName = resolveArtifactName(kind, platform, arch);
+export function resolvePlatformPackageBinary(platform, arch, fromDir) {
+  const artifactName = resolveArtifactName(platform, arch);
   if (!artifactName) return null;
   const pkgName = PLATFORM_PACKAGE_NAMES[`${platform}-${arch}`];
   if (!pkgName) return null;
@@ -65,8 +65,12 @@ export function supportedTargetsText() {
   return SUPPORTED_TARGETS.join(', ');
 }
 
-export function resolveArtifactName(kind, platform, arch) {
-  const prefix = kind === 'daemon' ? 'goodvibes-daemon' : 'goodvibes';
+// One binary, so no artifact KIND to choose between any more: this package
+// shipped `goodvibes-daemon` alongside `goodvibes` while one repository built
+// both, and the daemon is its own product with its own package and its own
+// launcher now.
+export function resolveArtifactName(platform, arch) {
+  const prefix = 'goodvibes';
   if (platform === 'linux' && arch === 'x64') return `${prefix}-linux-x64`;
   if (platform === 'linux' && arch === 'arm64') return `${prefix}-linux-arm64`;
   if (platform === 'darwin' && arch === 'x64') return `${prefix}-macos-x64`;

package/docs/README.md

@@ -11,7 +11,7 @@ This directory contains the current product documentation for `goodvibes-tui`.
   The layered settings model, the key-settings table, permission modes and the policy/trust system, plus the TUI-owned namespaces you add by hand to settings.json: checkpoint root guard, the scriptable statusline, session behavior, and launch-time self-update.
 
 - [Deployment and services](deployment-and-services.md)
-  TUI-only mode, compiled binary behavior, in-process daemon/listener hosting, source-run daemon mode, inbound TLS, outbound trust configuration, control-plane entrypoints, the service registry and secret references, profiles and setup transfer, and integration helpers.
+  TUI-only mode, compiled binary behavior, adopting or autostarting the daemon, the in-process HTTP listener, inbound TLS, outbound trust configuration, control-plane entrypoints, the service registry and secret references, profiles and setup transfer, and integration helpers.
 
 - [Remote access: a home server setup](remote-access.md)
   Step-by-step continuity setup: daemon on an always-on box, webui from any browser, TUI over SSH, Tailscale for reachability and TLS, validated by `goodvibes doctor`.
@@ -44,7 +44,13 @@ This directory contains the current product documentation for `goodvibes-tui`.
   `/share` session export to HTML/JSON/Markdown with redaction, upload, clipboard, and open options.
 
 - [CLI flags](cli-flags.md)
-  Global flags reference: session lifecycle (`--continue`, `--resume`, `--fork`), confirmation bypass (`-y`/`--non-interactive`), output format consolidation, `--host` alias, and all other startup flags.
+  Global flags reference: session lifecycle (`--continue`, `--resume`, `--fork`), confirmation bypass (`-y`/`--non-interactive`), output format consolidation, `--host` alias, and all other startup and command-specific flags.
+
+- [Commands reference](commands-reference.md)
+  The generated, categorized list of every slash command, its arguments, and its description — the same list `?` renders in the product.
+
+- [Windows support](windows.md)
+  WSL2 as the supported path today, what the native Windows beta binary can and cannot do yet, and the POSIX-assumption blockers ahead of promotion.
 
 - [Tools and commands](tools-and-commands.md)
   Built-in tool families and a per-tool reference, slash-command families, the full keyboard-binding reference, the agent/archetype and hook systems, MCP and plugin extensibility, and the operator, diagnostics, and workflow surfaces that tie them together.
@@ -66,3 +72,6 @@ This directory contains the current product documentation for `goodvibes-tui`.
 
 - [Foundation artifacts](foundation-artifacts/README.md)
   Checked-in operator and peer contract manifests plus canonical knowledge GraphQL and SQL artifacts for release-gate and SDK extraction work.
+
+- [GitHub Action](github-action.md)
+  The `run-goodvibes` composite action: installing a pinned, checksum-verified release in CI and running a non-interactive command or prompt against a workspace.