Close RPF-WP-0015: the post-reboot synthetic E2 passed and the audit chain is intact.

Accepted (202) then duplicate, same pod and restart count, clean cleanup;
verify-chain intact at 2454 events with the 2026-10-14 head matched.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 236506@bnt-lap001
Assistant-Session: 09087018-91e1-48c5-ab2f-acfbb62c92e4

workplans/RPF-WP-0015-audit-core-custody-and-recovery-coordination.md

@@ -4,7 +4,7 @@ type: workplan
 title: "Coordinate audit-core temporary custody and recovery exercises"
 domain: financials
 repo: railiance-platform
-status: active
+status: finished
 flavor: residual
 owner: codex
 topic_slug: railiance
@@ -176,11 +176,8 @@ live window after the Whitehat engagement cleanup.
 
 ```task
 id: RPF-WP-0015-T03
-status: wait
-needs_human: true
+status: done
 decision_id: 2fd5849c-240e-4d0a-bf07-5ebf8dfce3fd
-blocked_on: message-from:railiance-infra
-blocking_reason: "Single-node outage exercise needs operator access and a declared restart order coordinated with railiance-infra, railiance-cluster, audit-core and the OpenBao package owner."
 priority: high
 state_hub_task_id: "ba729d18-f053-539f-86ef-5cb8ad4cce45"
 ```
@@ -581,3 +578,38 @@ accepted→duplicate still holds: the only change is the chain-head selection,
 which is the same on a healthy chain. The `senders.json` registry is
 compatible (optional `emission_cadence`), and lease/readiness behaviour is
 unchanged.
+
+**T03 synthetic E2 completed 2026-11-03.** The founder ran window
+`rpf-wp-0015-t03-e2-20261103t2006z-founder-go` (20:07:24–20:08:00Z) under
+round-12 owner approvals. The hub shows `all_approved` for contract
+`a5e2b55d`; receipts audit-core `f0def1dc`, rapp-postgres `fad65811`,
+railiance-cluster `33ad480b`, railiance-infra `50121aef`, railiance-platform
+`bd01bfa5`. It used the contained `aal2` login and `AUDIT_KUBECONFIG`.
+- The first send was a fresh `accepted` (HTTP 202) and the replay was
+  `duplicate`, so the event was accepted exactly once.
+- The pod UID and restart count did not change during the exercise. The
+  driver cleanup was clean, and the projected sender identity and bearer file
+  were removed. audit-core is back at 1/1.
+- `verify-chain` afterwards: intact, 2454 events, no break. The head is the
+  E2 event, and `--against` the 2026-10-14 post-reboot attestation
+  (`c99426d8…`) matched.
+No secret values were observed.
+Evidence: `docs/evidence/2026-11-03-rpf-wp-0015-t03-e2/`.
+
+Three earlier attempts in this window stopped before any projection:
+- a placeholder `--confirm`;
+- a missing `0700` evidence directory, which the window must find already
+  created;
+- a standing `OPENBAO_TOKEN` exported from the founder's shell profile, which
+  the contained login refuses.
+
+T03 is done, and RPF-WP-0015 is finished.
+
+Follow-ups, not part of this plan:
+- The founder removes the standing `OPENBAO_TOKEN` from the shell profile
+  and revokes it. This is still open from 2026-10-14.
+- The legacy hub alias for RAILIANCE-WP-0024 (`88c4ef7f`) still shows
+  T02/T03 as `wait`. That is RPF-WP-0036-T07 alias disposition.
+- The window could create its evidence directory, or record an early
+  failure somewhere else. That needs a pinned-artifact change and a new
+  owner round.