Give cbd its own config file, separate from cbd-tui

cbd (server + TUI in one process) and cbd-tui (standalone client) both
read cbd-tui.toml, so pointing that file at a remote server for cbd-tui
also dragged cbds local TUI to the remote while its in-process server
ran unused. cbd now reads its own cbd.toml (same options, same localhost
default that matches its embedded server), so a self-contained cbd and a
remote-pointed cbd-tui coexist on one machine without their address
settings colliding.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

README.md

@@ -49,25 +49,34 @@ directory). Every file is optional; missing providers simply do not
 mount. Files are created/rewritten on first start with their defaults
 filled in.
 
-| File                 | Component | Documentation                          |
-| -------------------- | --------- | -------------------------------------- |
-| `tidaly.toml`        | Tidal     | [tidaldy/README.md](tidaldy/README.md) |
-| `ytdy.toml`          | YouTube   | [ytdy/README.md](ytdy/README.md)       |
-| `fsdy.toml`          | local fs  | [fsdy/README.md](fsdy/README.md)       |
-| `cbd-tui.toml`       | TUI / cbd | below                                  |
-| `crabidy-server.toml`| server    | below (never auto-created)             |
+| File                 | Component  | Documentation                          |
+| -------------------- | ---------- | -------------------------------------- |
+| `tidaly.toml`        | Tidal      | [tidaldy/README.md](tidaldy/README.md) |
+| `ytdy.toml`          | YouTube    | [ytdy/README.md](ytdy/README.md)       |
+| `fsdy.toml`          | local fs   | [fsdy/README.md](fsdy/README.md)       |
+| `cbd-tui.toml`       | `cbd-tui`  | below                                  |
+| `cbd.toml`           | `cbd`      | below (same options as `cbd-tui.toml`) |
+| `crabidy-server.toml`| server     | below (never auto-created)             |
 
 The server-managed folders (`queues/`, `bookmarks/`, `captures/`) also
 live in `~/.config/crabidy/`; they need no configuration and hold plain
 folders of track files in the format documented in
 [fsdy/README.md](fsdy/README.md).
 
-### `cbd-tui.toml`
+### `cbd-tui.toml` and `cbd.toml`
 
-Configuration of the TUI (and the TUI half of `cbd`):
+Client configuration. `cbd-tui` (the standalone terminal client) reads
+`cbd-tui.toml`; `cbd` (server + TUI in one process) reads its own
+`cbd.toml`. They are **separate files with the same options** so the two
+can run side by side on one machine — a common setup is `cbd` playing
+locally against its in-process server while `cbd-tui` points at a remote
+server (e.g. a Raspberry Pi). A shared file would force one to follow
+the other's `address`.
 
 ```toml
-# Where to find the server. Default shown.
+# Where to find the server. Default (both files): localhost, which is
+# what cbd's own in-process server listens on. Point cbd-tui.toml at a
+# remote server to use it as a remote control.
 address = "http://127.0.0.1:50051"
 
 # Credentials, when the server has [auth] configured (see below).
@@ -78,7 +87,7 @@ password = ""
 ```
 
 Every option is also available as a command-line flag
-(`cbd-tui --address ...`).
+(`cbd-tui --address ...`, `cbd --address ...`).
 
 ### `crabidy-server.toml` — roles and rights
 

architecture/cbd-bundle.md

@@ -6,7 +6,9 @@
 runs a long-lived server and attaches TUIs to it. The user wants a
 single binary **`cbd`** for the one-machine case: starting it starts the
 server and connects the TUI to it. Everything else works exactly the
-same — same configs, same gRPC wire, same features.
+same — same config *format*, same gRPC wire, same features. (`cbd` reads
+its own `cbd.toml`, not `cbd-tui.toml`; see the resolved note under
+Risks.)
 
 ## Assumptions (confirmed)
 
@@ -89,10 +91,14 @@ remote -> standalone: "gRPC (remote setup\nkeeps working)"
 
 ## Risks and open questions
 
-- **Port constant**: the server listens on `0.0.0.0:50051` and the TUI
-  config defaults to localhost; if the user points `cbd-tui.toml` at a
-  remote server, `cbd` still starts a local one (and connects to the
-  configured, remote one). Accepted: `cbd` is the one-machine tool.
+- **Separate client configs (resolved 2026-07-21)**: originally `cbd`
+  and `cbd-tui` both read `cbd-tui.toml`, so pointing that file at a
+  remote server (the standalone `cbd-tui`'s job) also dragged `cbd`'s
+  own TUI to the remote while it started an unused local server. `cbd`
+  now reads its own `cbd.toml` (same option set, defaulting to
+  localhost — matching its in-process server), so the self-contained
+  `cbd` and a remote-pointed `cbd-tui` coexist on one machine. See
+  `architecture/client-configs.md`.
 - **Two log producers, one file**: server and TUI layers share the
   bundled tracing subscriber; targets distinguish them.
 - Open (future): a `--no-server` flag; graceful server shutdown (flush

architecture/client-configs.md

@@ -0,0 +1,51 @@
+# Client configs: `cbd.toml` vs `cbd-tui.toml`
+
+## Problem
+
+`cbd` (server + TUI in one process) and `cbd-tui` (standalone terminal
+client) both originally loaded `cbd-tui.toml`. On a single machine the
+common setup is:
+
+- `cbd` — self-contained, playing on this laptop against its own
+  in-process server (localhost);
+- `cbd-tui` — a remote control pointed at another server (e.g. a
+  Raspberry Pi).
+
+With one shared config file these two uses fight over a single
+`address`: point it at the Pi for `cbd-tui`, and `cbd`'s TUI half also
+connects to the Pi while its local server runs unused.
+
+## Decision
+
+Give each binary its own client config file, with the **same option
+set** (`address`, `user`, `password` — the `ServerConfig` type is
+shared):
+
+- `cbd` reads `cbd.toml`.
+- `cbd-tui` reads `cbd-tui.toml`.
+
+Both default `address` to `http://127.0.0.1:50051`. For `cbd` that
+default is the right permanent value — it matches the in-process
+server's listen address — so `cbd` needs no config at all. `cbd-tui`'s
+default is a starting point the user overrides to point at a remote
+server. The files being separate is the whole point: editing one never
+moves the other.
+
+The server-side `crabidy-server.toml` (the `[auth]` roles) is unrelated
+and unchanged; this split is purely about the client `address`/creds.
+
+## Alternatives considered
+
+- **One file, add a `cbd`-only override section**: still one file to
+  reason about, and the override semantics (which wins?) are murkier
+  than two files with identical shape. Rejected.
+- **A CLI flag only for `cbd`**: does not persist; the user wants a
+  laptop that "just works" on every start. Rejected (the flag still
+  exists as an override, as for `cbd-tui`).
+
+## Migration
+
+Existing users keep their `cbd-tui.toml` for `cbd-tui`. On first run
+after the change, `cbd` writes a fresh `cbd.toml` with localhost
+defaults; anyone who had customized `cbd-tui.toml` *for `cbd`'s* sake
+(unusual — the default already fit) copies the value across once.

cbd/src/main.rs

@@ -28,7 +28,13 @@ async fn main() -> Result<(), Box<dyn Error>> {
     // Both halves share one file-based subscriber: the terminal belongs
     // to the TUI, so the server's usual stderr logging would corrupt it.
     let _log_guard = init_tracing();
-    let config = CONFIG.get_or_init(|| crabidy_core::init_config("cbd-tui.toml"));
+    // `cbd` reads its OWN config (`cbd.toml`), separate from the
+    // standalone `cbd-tui`'s `cbd-tui.toml`. The two run side by side on
+    // one machine — `cbd` self-contained against its in-process server,
+    // `cbd-tui` pointed at a remote (e.g. a Raspberry Pi) — so a single
+    // shared `address` would force one to follow the other. `cbd`
+    // defaults to localhost, which matches its embedded server.
+    let config = CONFIG.get_or_init(|| crabidy_core::init_config("cbd.toml"));
 
     let addr: std::net::SocketAddr = crabidy_server::LISTEN_ADDR.parse()?;
     let mut server = tokio::spawn(crabidy_server::serve(addr));

plan/summary.md

@@ -727,3 +727,13 @@ targeting, dive-clears-filter). 67 cbd-tui tests green; clippy clean.
 
 Scope: TUI only, per the request; web-client parity noted as a
 follow-up.
+
+## client-configs (2026-07-21)
+
+`cbd` now reads its own `cbd.toml` instead of sharing `cbd-tui.toml`
+(`architecture/client-configs.md`, resolving the open risk in
+`architecture/cbd-bundle.md`). One-line change in `cbd/src/main.rs`
+(`init_config("cbd.toml")`); same `ServerConfig` type and localhost
+default, so `cbd` (local, self-contained) and a remote-pointed
+`cbd-tui` coexist on one machine without their `address` settings
+colliding. README config table + client-config section updated.