maintainlisted

# maintain — a maintainer's circuit for this repo This is a **workflow**, not a rulebook. The rules live in `AGENTS.md` and `docs/RELEASING.md` and are cited here by section, never restated: two copies drift, and drift between rule files is the failure mode this repo exists to kill. Read `AGENTS.md` before the first tool call of a cycle; when it and this file disagree, `AGENTS.md` wins and this file is the thing to fix. The circuit below was run twelve times over two days. The numbers in it are measured on those runs, not estimated. ## 0. Coexistence — before anything Other sessions may be working this same repo. - `ListAgents` first. If another session is live, exchange **file sets** by message before either of you starts: two cycles that touch disjoint files can run at once, two that touch `src/core/facilitator/executors/build.ts` cannot. - **Never merge while another session's release is running** — and since #299 that is a file, not a question: `scripts/release.sh` writes `.RELEASE-IN-PROGRESS` at the repo root for its whole span, and `scripts/merge-wave.sh` WAITS on it the way it waits on its own lock — and the release waits on a running wave's lock before its first edit, exit 14 when it gives up (§2, §6). `scripts/merge-wave.sh --status` says who holds the checkout — a wave (holder, branch, phase), a release (holder, version), or `idle` — so "is it alive?" is a command, not a `ps` reading. The one hint the marker cannot give: a `release: X.Y.Z` comm