ops-warden/docs/evidence/WARDEN-WP-0027-T02-drill-scenario-2026-08-22.md

WARDEN-WP-0027-T02 attended drill scenario

Status: preparing — live execution is prohibited.

Window

• Scenario/window id: WARDEN-WP-0027-T02-DRILL-20260822-01
• Preparation approval: Warden Desk approve recorded at 2026-08-22T19:22:28Z (metadata only)
• Approval expires: 2026-08-23T20:00:00Z
• Live window opens only when the operator gives the exact final go/no-go for this scenario after the owner preflight reports ready_for_live_execution: true
• Maximum live-window duration after GO: 45 minutes
• A NO-GO, missing gate, changed cluster identity, or expired approval closes this scenario without mutation

Assigned roles

Responsibility	Assigned owner	Acceptance
Preparation coordinator and hold-point enforcement	ops-warden	accepted
OpenBao snapshot, seal/unseal driver, post-unseal verification	railiance-platform	pending owner receipt
Independent provider console and distinct abort authority	railiance-infra	pending owner receipt
Two distinct 2-of-3 share custodians available out of band	railiance-master custody authority	pending quorum receipt
Final live GO or NO-GO	human operator	deliberately not requested yet

Owner procedure approval is already complete for audit-core, rapp-postgres, railiance-platform, railiance-cluster, and railiance-infra under the RAILIANCE-WP-0024 contract. Those receipts approve the procedure, not this live window.

Current value-safe baseline

The railiance-platform node-reboot preflight at 2026-08-22T19:23:55Z reported:

• automated_checks_passed: true
• one Ready node with active k3s
• platform-pg healthy 1/1 with continuous archiving and a successful backup 17.15 hours old
• OpenBao initialized and unsealed, Shamir shares=3, threshold=2
• required ExternalSecret stores Valid and projections SecretSynced
• audit-core at the reviewed digest, 1/1 Ready, zero restarts
• secret_values_observed: false

This baseline is not reusable as the final hold-point result. The platform owner must rerun it against the current state and fresh snapshot receipt.

Fail-closed preparation probes

• The OpenBao pod token helper and the current workstation caller token both receive 403 permission denied for a capabilities check on sys/storage/raft/snapshot. No snapshot command was attempted after that denial. The platform driver must use its attended owner identity; the agent will not widen a workload token or substitute root.
• Warden has no autonomous provider-console catalog lane. Independent console access therefore remains an explicit railiance-infra owner attestation, not an inferred result from SSH reachability.
• The live barrier reports three shares and threshold two, but state metadata cannot prove two custodians are currently present. Availability must arrive through the out-of-band custody authority without identities or values.

Pending receipts

• railiance-platform: fresh encrypted, verified, off-host OpenBao Raft snapshot receipt matching the live cluster id and possible applied index; acceptance of the driver role
• railiance-infra: independent provider-console access verified; acceptance of the distinct abort role
• railiance-master: two distinct share custodians explicitly available through the approved out-of-band custody paths; no identities or share values in the receipt
• Fully parameterized read-only owner preflight returns ready_for_live_execution: true and secret_values_observed: false

Final hold point

Once all pending receipts validate, ops-warden presents only the scenario id, bounded duration, owner roles, current preflight result, and stop conditions to the human operator. The live step requires an explicit GO for this exact scenario. Any other response is NO-GO.

No unseal share, token, provider credential, Secret data, decrypted snapshot, or value-derived fingerprint belongs in Git, State Hub, shell history, logs, or chat.