VersionControl:PRs/maybelle-config/267

maybelle-config#267: recovery@hunter: a GitHub issue when someone opens it; the session streamed to an append-only log on maybelle

State	🟣 merged 2026-11-03 15:01:37
Worked on by	magent, justin, blu
Moods	#emergence
Deploy	redeploy maybelle first (the sink), then hunter.
Branch	recovery-alerts → production, by magent-cryptograss
Opened · last pushed	2026-11-02 11:21:45 · 2026-11-02 11:21:26

Until now, opening recovery@hunter produced one line in #general ("who came in, as recovery"). Since the watcher retired, nothing recorded the session anywhere but hunter's own disk. recovery is root on hunter in all but name, so whoever was in the session could also edit the only copy (Justin's ask, #emergence, 2 Nov 11:06–11:17Z).

**What it does now**
- **Loud.** Each login runs `recovery-alert` in the background. It opens a GitHub issue in `recovery_alert_repo` (default `cryptograss/security-and-other-private-things`): "recovery@hunter opened by <who> (<time>), by the <route> route". Everyone watching that repo gets an email and a phone notification, and GitHub keeps the history of every edit to the issue. `<who>` comes from `authorized_keys`, which now runs `magenta-recovery --as <name>` for each key.
- **Kept off hunter.** `recovery-log-ship` is a root system service, not part of any session. Every 2 s it sends new lines from the session transcripts (Claude Code's and Pi's) and from the alert queue to maybelle in one `ssh` call. The key used for that call can only run `append-recovery-log`, which stamps the time each batch arrived and appends it to `/var/log/magenta-recovery/<date>.log`. It can't read, list or rewrite anything. A line only counts as sent once that `ssh` call succeeds, and anything not yet sent waits on hunter. The sink is a new shared role, `recovery-log`, included by maybelle.yml.
- **Honest wording.** The gate's comment and its refusal ("Justin said no.") said Justin was the one answering. Any of the four keys opens recovery, so whoever is at the keyboard is the one answering. The gate's wording now says that, and so does the session's `CLAUDE.md`, which claimed "Only Justin's key opens this login". `$MAGENTA_RECOVERY_WHO` tells the session whose key opened it.

**Known limits, named rather than hidden**
- When maybelle can't be reached, lines wait on hunter. A session holding root can change or drop them before they leave, and it can stop the shipper. Only what reached maybelle while it was happening is safe from the session. The arrival time on each batch shows which lines went late (blu and magent, #emergence 11:08Z).
- The GitHub issue is the only alert that doesn't depend on our own servers. If GitHub is unreachable from hunter too, the only trace of the login is the PAM line in #general.
- This doesn't put the session into the record or a Mood. A #recovery Mood, built on the same queue, is a follow-up.

**Before it does anything, from the vault and the inventory (all optional: without them it installs and stays quiet)**
- `recovery_alert_github_token` (vault): a fine-grained token with Issues read+write on `recovery_alert_repo` and nothing else. Everyone who needs to hear has to watch that repo, so pick a repo all four can see.
- `recovery_log_private_key` (vault) and `recovery_log_public_key` (hunter inventory, public, so the PR or a follow-up can carry it): an ed25519 pair made for this and nothing else.

**Tests:** `test_recovery_log_ship.py` (new, added to CI) has 3 passing tests: whole lines go once, lines wait while maybelle is away and then go, and a partial line goes once it's complete. `test_recovery_gate.mjs` has 5 passing tests. The new and changed scripts pass `py_compile` and `bash -n`.

Deploy: redeploy maybelle first (the sink), then hunter.
Worked on by: magent, Justin and blu, in #emergence