@pellux/goodvibes-tui 1.24.2 → 1.26.0

package/CHANGELOG.md

@@ -4,6 +4,38 @@ All notable changes to GoodVibes TUI.
 
 ---
 
+## [1.26.0] - 2026-07-29
+
+### Changes
+
+- Added: a payment card on file for daemon-initiated purchases, entered through /payments card with concealed input. Card material is secret-tier and never rendered or written in plaintext, and the CVV can be stored or requested at purchase time.
+- Added: /profile — what the platform knows about you, kept as one Markdown file you can open and edit by hand at any time. Read the whole thing, trace where any recorded line came from, or forget a single field.
+- Added: goodvibes-daemon send — put a message on a channel straight from the daemon, including --channel telegram, with the message taken from an argument or from stdin.
+- Added: the installer now proves the install you get is the install you reach, and says so when something earlier on your PATH would shadow it.
+- Fixed: a credential configured on a surface now goes to the tier the daemon actually reads. Pairing a Slack bot token or entering a payment card used to report success while the value sat where the daemon never looks.
+- Fixed: inbound webhook surfaces authenticate again. A credential moved into the secret store left a reference behind that the ingress path compared literally, so a correctly configured surface refused every incoming request.
+- Fixed: support bundles no longer carry card material or mailbox passwords in the clear.
+- Fixed: a desktop notification about stopped work now says what stopped and why, in words, instead of naming internal machinery and an identifier you cannot act on.
+- Fixed: test scratch directories no longer accumulate in the system temp directory. The cleanup they relied on never ran at all, which quietly exhausted one host's free inodes.
+
+## [1.25.0] - 2026-07-27
+
+### Changes
+
+- Mail and calendar are surfaces here now: `/mail` and `/calendar`, a Connections category in settings, and sending behind `--confirm`.
+- The daemon this package ships stops carrying its own CalDAV and IMAP/SMTP handlers and lets the platform serve `calendar.*` and `email.*`. Both implementations were bound to the same descriptor ids and the local ones registered later, so they were the ones answering — two implementations behind one path, which is the drift the move exists to end. Nothing was deleted until the platform could do it: generic CalDAV, both spellings of the mail settings with their fallbacks, and address-digested logging were all ported first.
+- The Connections category shows what mail and calendar are actually doing, and never guesses. A row starts as "checking" and only ever changes to something the daemon confirmed; an unconfigured account reports needs-setup naming the exact keys to set, and a daemon that does not serve the surface at all reports unreachable instead. Those two are kept apart deliberately: telling someone to connect an account when the daemon cannot serve mail at all would be a wasted afternoon.
+- Setting a mail or calendar password now works from here. The platform declares the whole mail and CalDAV connection as daemon-owned, so `/secrets set` is relocated into the daemon's own tier rather than filed in this client's store where the daemon never looked. The old guidance said to put it in the daemon's environment and restart, because that was the only thing that actually reached it; that is no longer necessary and the guidance says so.
+
+### Fixes
+
+- `GOODVIBES_HOME` has one meaning and one reader. The client CLI now honours the same home redirection the daemon already did, and an architecture rule covers `scripts/` so a new entry point cannot quietly read it a second way.
+- `--daemon-home` / `GOODVIBES_DAEMON_HOME` reaches the credential store, not just the identity directory. Without it a daemon told to run out of a temp tree still read the real home's daemon secrets, so an "isolated" test daemon held live credentials.
+- A daemon started with an overridden home never adopts the machine's service unit. One did: launched from a scratchpad, it found the unit not running, wrote its own scratchpad command line into the systemd user unit and exited, and systemd then supervised the throwaway as the machine's daemon for five hours while it read real credentials and long-polled a real bot. The check runs before the service-enabled setting deliberately — that setting is client-owned and resolves against the real home, so a test tree's own opt-out was written and never read, and isolation that depends on the isolated process reading its own settings file is not isolation.
+- The review pane declares itself an explicit user request, which is honest there and only there: that path runs because a person is looking at a hunk and pressed a key. It is what lets a confirmation-gated verb tell an authorized action apart from one initiated by content, so scheduled work, triggers and channel-driven work deliberately do not set it.
+- The daemon launcher now says, in the file, that it prefers a prebuilt binary over this source tree. A route added to source answers 404 and every explanation reached for is wrong, because the process answering never contained the code. It cost a round several hours.
+
+
 ## [1.24.2] - 2026-07-27
 
 ### Changes

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.24.2-blue.svg)](https://github.com/mgd34msu/goodvibes-tui)
+[![Version](https://img.shields.io/badge/version-1.26.0-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.
 

package/bin/goodvibes-daemon

@@ -1,4 +1,28 @@
 #!/usr/bin/env bun
+//
+// ── READ THIS BEFORE DEV-TESTING DAEMON ROUTES THROUGH THIS SHIM ──────────
+//
+// This launcher prefers a PREBUILT binary over the source checkout. On a
+// machine with `vendor/goodvibes-daemon-<platform>` staged, `bun bin/goodvibes-daemon`
+// runs THAT binary — compiled against the PUBLISHED SDK — not the source in
+// this repo and not whatever `sdk-dev link` overlaid into node_modules.
+//
+// The consequence is quiet and expensive: a route you just added returns 404
+// and every explanation you reach for is wrong, because the process answering
+// never contained your code. It cost a round several hours.
+//
+// Two further traps in the same area:
+//   - Killing this shim does NOT kill the vendored child. `pkill -f` on the
+//     shim's command line leaves the daemon listening, so the "restart" you
+//     think you performed changed nothing.
+//   - `sdk-dev link` overlays node_modules only. A vendored binary ignores it
+//     completely.
+//
+// To exercise source (and a linked SDK), bypass this launcher:
+//     bun src/daemon/cli.ts --port <port> --hostname 127.0.0.1
+// and isolate it with GOODVIBES_HOME / GOODVIBES_DAEMON_HOME / GOODVIBES_WORKING_DIR
+// so it cannot read the machine's real credentials or claim its service unit.
+//
 import { dirname, join } from 'node:path';
 import { fileURLToPath } from 'node:url';
 import { spawnSync } from 'node:child_process';