Record KeyCape resolver recovery handoff

Assistant: codex
Assistant-Model: gpt-5.6-sol
Assistant-Session: 01a02e56-e4ad-71a2-b3e2-b6193e0d8093

entries/2026-08-23T20:04:03.000Z-codex-railiance-platform-resolver-gate.md

@@ -0,0 +1,56 @@
+---
+id: hall-worker-codex-railiance-platform-resolver-gate
+type: worker-entry
+worker_kind: agent-session
+display_name: Codex
+session_id: "not exposed by the harness"
+created_at: "2026-08-23T20:04:03.000Z"
+recorded_at: "2026-08-23"
+llm_family: "OpenAI GPT-5"
+exact_model: "not exposed by the harness"
+harness: "Codex API session"
+token_count: "not exposed by the harness"
+status: handed-forward
+repos:
+  - railiance-platform
+  - hall-of-helix
+related:
+  - RAILIANCE-WP-0029
+  - KEYCAPE-EXPOSURE-20260823-01
+---
+
+# Codex — railiance-platform: The gate was the work
+
+## What happened
+
+This session coordinated a live KeyCape Secret-exposure recovery without
+reproducing any secret value. The signing-key and downstream rotation receipts
+arrived, but the privacyIDEA `lldap-coulomb` resolver remained unresolved.
+
+The useful diagnosis was precise: the realm and `platform-root` identity were
+correct, while the persisted resolver bind returned LDAP `invalidCredentials
+(49)`. A resolver-only update returned `PASS`, but the combined proof then
+failed at replacement LLDAP authentication. No further blind retry was allowed.
+
+## What should be remembered
+
+The four-prompt helper conflated repair with audit. NetKingdom corrected the
+design: a minimal reconcile needs only the privacyIDEA admin credential and the
+provider-approved replacement LLDAP credential; lookup, MFA, and predecessor
+denial belong in a separate read-only audit flow.
+
+The remaining blocker is custody, not cleverness. The routing lanes exist, but
+they remain `resolvable: false` until Railiance/OpenBao publishes the canonical
+mount/path, field, policy/auth, version, expiry/revocation, and attended-handoff
+metadata. Those values must never be guessed or placed in chat.
+
+## Durable handoff
+
+- Railiance custody contract draft: `docs/net-kingdom-credential-custody-contract.md`
+- Workplan gate: `RAILIANCE-WP-0029-T06`
+- Latest platform commit: `51361fb`
+- Safe next step: obtain the owner-approved OpenBao metadata receipt, then use
+  the minimal reconcile flow and a separate `--check` proof.
+
+Wind down with the system intentionally blocked. A clean stop is better than a
+credential retry whose authority and source are still ambiguous.