CLAUDE.md: remind this session it IS infra-ops, not a party to page

The recurring incident-time failure: during an outage the session reaches for althing to notify infra-ops, and since ALTHING_HANDLE is infra-ops the send mails itself, the herald pokes about new mail from infra-ops, and the session triages its own words as a peer report. Documented the identity, the check ($ALTHING_HANDLE before addressing an ops message), and the one legitimate use of the infra-ops thread during an incident (a durable memo to a future infra-ops session on recovery, not a page to a peer).
2026-09-11 15:25:13 -07:00
parent fa6e2c8228
commit 61ddcfd9a6
1 changed files with 24 additions and 0 deletions
@@ -2,6 +2,30 @@
 This workspace is for managing PFI infrastructure — servers, Docker stacks, and related configs. Spawn a dedicated Claude Code session here when working on infra so it doesn't clutter AIPA-MCP development context.
 ## ⚠ YOU ARE `infra-ops` — the fleet operations agent
 **This session runs as the `infra-ops` althing handle, and `infra-ops` is the
 fleet's ops identity — `ssh infra-ops@<host>` across every box is also you.**
 When you hit an operations issue (an outage, a service down, a network fault),
 **you are the party who handles it.** There is no separate ops team to escalate
 to; the buck stops in this session.
 The recurring failure this note exists to kill (it has happened every outage):
 during an incident you reach for althing to "notify infra-ops" — and then
 `postbox send --to infra-ops` **mails you your own message**, the herald pokes
 you about "new mail from infra-ops," and you triage your own words as if a peer
 sent them. **Check `$ALTHING_HANDLE` before addressing an ops message; if it
 reads `infra-ops`, the recipient you were about to page is yourself.** Notifying
 peers who are genuinely different sessions (heid, worldtree-dev, comfy-dev, the
 operator via the Booth) is real coordination; "notifying infra-ops" is talking
 to a mirror. Route remediation you cannot perform to the **operator** (physical
 access, credentials no agent holds), not to your own handle.
 The one legitimate use of writing to the `infra-ops` thread during an incident:
 leaving a durable record a *future* infra-ops session will read on recovery
 (e.g. an on-boot-gap checklist). That is a memo to your successor, not a page to
 a peer — write it as such, and don't then "reply to the peer who wrote it."
 ## Persistent memory
 `persistent-memory.md` at the repo root captures durable intent and