docs: activate credential break-glass planning

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

workplans/WARDEN-WP-0027-credential-governance-lockdown.md

@@ -4,13 +4,13 @@ type: workplan
 title: "Tamper-resistant credential governance + mass rotation/lockdown (Strand B)"
 domain: infotech
 repo: ops-warden
-status: backlog
+status: active
 owner: codex
 topic_slug: custodian
 planning_priority: medium
 planning_order: 27
 created: "2026-07-16"
-updated: "2026-08-15"
+updated: "2026-08-22"
 state_hub_workstream_id: "7d697c52-766a-4562-b2ad-a722880bcdcb"
 ---
 
@@ -27,20 +27,19 @@ Strand A makes accidental disclosure structurally hard and gives every lane
 layer: turning that advisory guidance into one-command action and hardening policy
 governance against silent drift or malicious change.
 
-## Status: backlog (captured, not scheduled)
+## Status: active, narrowly on T02
 
-Tasks are **`cancel`** (deferred with the workplan, not abandoned) so hub
-consistency C-23 does not force `active`. On activation: set workplan to
-`ready`/`active` and re-open tasks as `todo`/`progress`.
+Activated by the operator on 2026-08-22 after the second activation gate became
+concrete. `RAILIANCE-WP-0024-T03` now requires an approved recovery window,
+fresh encrypted Raft snapshot evidence, provider-console access, named abort
+authority, and the live **2-of-3 Shamir quorum** before a coordinated reboot.
+That is fleet policy requiring a designed break-glass path, not speculative
+heavyweight machinery.
 
-Frontmatter `status: backlog` as of 2026-07-17 (Strand A / WP-0026 and tenant
-custody WP-0028 are finished; no activation gate has fired). Tasks remain
-`todo` (not `wait`/`progress`) so hub consistency **C-23** does not force the
-workplan back to `active`. This is deliberately **not `ready`**. It carries
-real cost and blast radius (break-glass re-key, trust-root design) that is not
-justified until a concrete trigger appears. See **Activation gate** below.
-Nothing here is implemented until the gate is met and Bernd promotes it to
-`ready` (then move tasks `todo` → `progress` as work starts).
+Activation is deliberately narrow. No mass-disclosure incident triggers T01,
+and no fleet policy currently mandates T03's signed policy-manifest reconcile.
+Those tasks remain `cancel`; cancellation here continues to mean deferred, not
+abandoned. T02 alone is `progress`.
 
 ## Activation gate (promote to `ready` only when ≥1 holds)
 
@@ -89,7 +88,7 @@ each verified capabilities-safe, taint cleared only on success.
 
 ```task
 id: WARDEN-WP-0027-T02
-status: cancel
+status: progress
 priority: medium
 state_hub_task_id: "9d004d8f-6215-4178-bd13-5785d24fd152"
 ```
@@ -117,6 +116,35 @@ host) are in `workplans/ADHOC-2026-08-11.md` T03 (ad-hoc **finished** 2026-08-15
 question lives here now); secrets-engine was told to stop holding apply
 readiness until this task or the ops-bridge cutover fires (msg `863c7b57`).
 
+**Rebaselined 2026-08-22.** The July description predates the authoritative
+OpenBao migration. The current barrier is a rotated **2-of-3**, not the
+aspirational 3-of-5 value still present in ops-warden's legacy posture
+descriptor. `RMASTER-WP-0020` records two attended restart/unseal cycles on
+2026-08-03 with shares supplied through hidden prompts, matching inventory,
+audit continuity, exact-path read, and sibling denial. That is valid rehearsal
+evidence for re-entry, but it is not misreported as a current production
+emergency-seal drill.
+
+The soft half is also already live: `RAILIANCE-WP-0022` reports total concrete
+high-risk path coverage and a dedicated coding-agent AppRole proving deny-wins
+without reading a secret value. ops-warden consumes that owner control through
+`scripts/check_agent_read_boundary.py`; it does not take ownership of the live
+OpenBao policy.
+
+The consumer contract and remaining acceptance gate are now documented in
+`docs/credential-governance-break-glass.md`. One attended production emergency
+seal/unseal drill remains. It must use railiance-platform's evidence template
+and validator, have snapshot/quorum/console/driver/abort receipts before the
+seal hold point, and be executed by the platform owner—not by a coding agent.
+
+**Parked AppRole disposition:** do not unpark the standalone `warden-sign`
+AppRole for T02 break-glass. The normal broker remains autonomous; an issuer
+failure deliberately crosses into attended OIDC and, below that, the 2-of-3
+platform trust-root. A standing AppRole placed outside the broker would weaken
+that boundary and still would not recover a sealed OpenBao. A separately
+approved ops-bridge unattended-signing design may re-evaluate the narrow
+AppRole under its own workplan; that is service access, not recovery authority.
+
 ## Task: Tamper-evident policy governance + reconcile
 
 ```task
@@ -144,6 +172,7 @@ manifest, and an attended reconcile can restore it.
 - `railiance-platform` — OpenBao cluster, policy custody, credential broker
 - `wiki/AccessRouting.md` — issue vs route vs assist boundary
 - `workplans/ADHOC-2026-08-11.md` T03 — parked warden-sign AppRole (ad-hoc finished
-  2026-08-15); un-parks on this workplan's break-glass task or the ops-bridge
+  2026-08-15); T02 resolves it as unsuitable for break-glass, while a separately
+  approved ops-bridge unattended-signing design may still re-evaluate it
   cert_command cutover
 - `secrets-engine` `SECRETS-WP-0004` — the parked AppRole apply/handoff