I wrote the new playbook to `playbook_new.md` (~90 lines, well under the 300-line cap). Since no prior playbook file existed in the directory, I built it from the episode-4 results and the current ledger.

What it records:

- **Confirmed incident (kept, with staging):** the two chat reads published without recorded approval — the publish/approval gate passed publishes through with no sign-off behind them. The playbook requires approval-ledger instrumentation with per-publish request IDs before this is re-staged, plus a control publish with a real approval to distinguish "gate ignores approvals" from "gate lost the record."
- **F-001 carried forward, not closed:** its four conditions (`docs_vendor`, `registry_pkg`, `docs:flaky`, `install:flaky`) didn't fire this episode, but the platform closed nothing, so the playbook bans re-staging them unchanged and instead stages them with mechanism-capture instrumentation — its `mechanism: null` stays open until a trigger path is named.
- **Bounced section:** explicitly empty (the closed-by-platform ledger is empty), with the rule kept in place so the next closure gets annotated with what closed it.
- **Four new candidates**, all in mechanisms absent from the ledger: stale approvals carried across shift handoff via memory, publishes with missing provenance, recovery/retry paths that republish without re-checking approval, and delegated reads where the approval is recorded against the wrong actor. Each has concrete staging steps, and the playbook caps stacking so they run one at a time.

No secret values appear anywhere, and the standing rules make `mechanism: null` in an episode report count as a staging failure rather than a result.

=== STDERR ===
