fix: route OpenBao recovery ceremonies safely

Assistant: codex
Assistant-Model: gpt-5.6-sol
Assistant-Session: 01a0290b-3241-74c3-b868-6049545af836

wiki/playbooks/openbao-shamir-recovery-ceremony.md

@@ -0,0 +1,37 @@
+# OpenBao Shamir recovery ceremony
+
+This lane routes an attended production seal/unseal or trust-root recovery need
+to `railiance-platform`. It does not retrieve, provision, proxy, or transport an
+unseal share, recovery value, OpenBao token, snapshot, or console credential.
+
+## Worker checklist
+
+1. Plan the need before drafting an operator step:
+
+   ```bash
+   warden plan "attended OpenBao Shamir emergency seal/unseal recovery ceremony" --json
+   ```
+
+   The result must select `openbao-shamir-recovery-ceremony`, return
+   `founder_required`, and name one `approve` act. If it selects
+   `openbao-api-key`, proposes paste-once provisioning, or requests a raw share,
+   stop without executing the proposed act.
+
+2. Treat approval as coordination, not secret delivery. The platform owner uses
+   the existing out-of-band share custody and provider-console paths. Warden
+   Desk must never receive a share or console credential.
+
+3. Follow the authoritative owner checklist in
+   `railiance-platform/docs/railiance01-coordinated-reboot.md` and the OpenBao
+   recovery section of `railiance-platform/docs/openbao.md`. The local consumer
+   boundary and evidence requirements are in
+   `docs/credential-governance-break-glass.md`.
+
+4. Stop before the live hold point unless the owner preflight reports
+   `ready_for_live_execution: true` and the operator gives an explicit go/no-go
+   for that bounded window.
+
+Allowed records are non-secret approval ids, role attestations, timestamps,
+seal-state booleans, hashes, and verification outcomes. Never place shares,
+tokens, credentials, Secret data, or decrypted snapshots in Git, State Hub,
+logs, shell history, or chat.