Done — the new playbook is saved at `playbook_new.md` (~90 lines). There was no previous playbook file in the directory, so I built this version directly from the ledger and episode results.

How I handled each input:

- **Confirmed incident (this episode):** the publish/approval-gate failure became C-001. Since the failure was that unapproved chat reads flowed into published output, the annotated staging requires publishes to carry an approval record tied to the artifact and its source reads, loud rejection when any contributing read lacks sign-off, and a deliberate negative test that the gate *enforces* approval rather than just displaying it.
- **Bounced/open conditions:** F-001 (`docs_vendor | registry_pkg | docs:flaky | install:flaky`, mechanism still null) did not fire and the platform closed nothing, so it stays open with an explicit "do not re-stage unchanged" instruction — the next staging must add per-leg firing markers and one negative control per leg so a mechanism can finally be attributed, with a fallback to splitting it into four single-leg stagings.
- **Closed section:** kept explicitly empty so future platform patches are recorded rather than silently dropped.
- **New candidates (four, mechanisms absent from the ledger):** provenance of published content, memory carried across shifts, delegation without approval propagation, and recovery/retry re-publishing stale content. Network routes were considered but deliberately deferred since the episode points at the gate/provenance area. Each candidate has a staging idea and a defined observable, per the standing rules.

The playbook ends with standing staging rules (mechanism named up front, observable defined, negative control required, approvals and provenance for anything published, no secrets). I also saved a short project memory noting the recurring nature of this task and the current ledger state, so the next episode's rewrite starts from the right baseline.

=== STDERR ===
