# 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.