Audit of 3f4e4d5

docs/macos.md

@@ -16,7 +16,7 @@ The project is a Swift package built with `swift build`, not an Xcode project. I
 
 `mac/bundle.sh` builds in one directory shared by every worktree, `~/Library/Caches/byre/build`, under a lock: SwiftPM keys a build on the package's absolute path, so a build in a fresh worktree recompiles every dependency. It copies sources in with `rsync --checksum`, which leaves unchanged files' modification times alone. It passes `--no-color-diagnostics` because `COLOR_DIAGNOSTICS` otherwise follows whether output is a terminal and is part of the build request, so agents whose shells differ would each rebuild every target in turn; `build-request.json` under `.build/out/Intermediates.noindex/XCBuildData/` shows what a build was keyed on. The server and helpers go in `Contents/Helpers`, not beside `Byre` in `Contents/MacOS`: the default APFS volume ignores case, so `byre` and `Byre` would be one file.
 
-Only the release configuration is built. A debug build stops at an `#error` in `ByreApp.swift`, and even a failed one leaves the next release build in the same build directory recompiling every target, since the two configurations share it. Release targets build whole-module, so a one-file change to `Byre` recompiles the whole target; the generated API client is its own target so it isn't part of that.
+Only the release configuration is built. A debug build stops at an `#error` in `ByreApp.swift`, and even a failed one leaves the next release build in the same build directory recompiling every target, since the two configurations share it. Release targets build whole-module, so a one-file change to `Byre` recompiles the whole target.
 
 `mac/bundle.sh` builds TailscaleKit from `github.com/tailscale/libtailscale` at the commit pinned in the script (`libtailscale=`), once per commit, and bundles it in `Contents/Frameworks` like Sparkle's. To move to a newer libtailscale, change the pinned commit.
 

docs/operations.md

@@ -100,13 +100,13 @@ Merge coordination must decide from the database's current state, never from whi
 
 byre never signs with a key on the machine it runs on. When a project checkout's `commit.gpgsign` is true (`git -C <checkout> config --type=bool --get commit.gpgsign` prints it), the squash commit of a merge is signed on the merging user's most recently active Mac, so a key that never leaves that Mac's Secure Enclave and needs a fingerprint works. The Mac runs its own git signing config, as git does: `gpg.format` (`openpgp` or `x509`; `ssh` is not supported), the program when it isn't `gpg`/`gpgsm`, and `user.signingkey` when the program can't find the key from the user's byre git identity (not the Mac's `user.email`). The program must print `[GNUPG:] SIG_CREATED ` on its status fd, as git requires. A Touch ID prompt left unanswered for 2 minutes fails the merge. The notes commit is not signed.
 
-`byre signing <checkout>` turns it on for a project; agents learn it from the `signing` knowledge-base article. It sets `commit.gpgsign` true in the checkout and false for its task worktrees, which share that config and would otherwise try to sign end-of-turn commits on the server, and fail. It does this with an `includeIf.gitdir:<common dir>/worktrees/**.path` of an `unsigned.gitconfig`. `extensions.worktreeConfig` wouldn't do it, since `git worktree add` copies the checkout's `config.worktree` into each new worktree, nor would the server's global config, which is read before the checkout's. It refuses a checkout that is itself a linked worktree, since the include would turn signing off for it too. No restart is needed; `git -C <checkout> cat-file commit HEAD` shows the `gpgsig` header.
+`byre signing <checkout>` turns it on for a project; agents learn it from the `signing` knowledge-base article. It sets `commit.gpgsign` true in the checkout and false for its task worktrees, which share that config and would otherwise try to sign end-of-turn commits on the server, and fail. `extensions.worktreeConfig` wouldn't do it, since `git worktree add` copies the checkout's `config.worktree` into each new worktree, nor would the server's global config, which is read before the checkout's. It refuses a checkout that is itself a linked worktree, since the task-worktree exception would turn signing off for it too. No restart is needed; `git -C <checkout> cat-file commit HEAD` shows the `gpgsig` header.
 
 ## Client Macs
 
 - The app pings every 10s and reconnects after 25s with no pong. That catches a socket byre dropped while the Mac slept: the close never reached the Mac, and without something sent on it the app would wait on it indefinitely.
 - `log show --info --last 10m --predicate 'subsystem == "run.fc.byre.mac"'` on a client shows `client request <id>: <op>` lines and `byre-hands` starts and exits, which are info level and kept only in memory, so they cover the last few minutes at most; connection drops (`client connection closed`, `client connection got no pong`) are notices, kept on disk, so `log show --start` reaches much further back for them. byre's log shows `client connected` and `client disconnected`.
-- `byre client-exec` (how to use it, and `byre screen`, is the `client-exec` knowledge-base article) calls `POST /api/clients/exec` on the loopback address with the loopback token, which byre exports as `BYRE_TOKEN` to everything it starts. byre's log has a `client exec` line per call with the client, command, exit status and duration, never the output, since it may hold credentials.
+- `byre client-exec` (how to use it, and `byre screen`, is the `client-exec` knowledge-base article) uses the loopback token, which byre exports as `BYRE_TOKEN` to everything it starts. byre's log has a `client exec` line per call with the client, command, exit status and duration, never the output, since it may hold credentials.
 
 ## Screen and app control