SECRETS-WP-0015-T04: record NK49 T40/T18 issuer evidence; consumer continuity still waits on OpenBao recovery

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

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 4384@bnt-lap001
Assistant-Session: 80d1f3da-7a91-4519-9737-9ba128b4da64

workplans/SECRETS-WP-0015-original-keycape-recovery-selector.md

@@ -8,7 +8,7 @@ status: active
 owner: codex
 topic_slug: custodian
 created: "2026-10-17"
-updated: "2026-10-21"
+updated: "2026-10-23"
 flavor: implementation
 depends_on: []
 related: [CUST-WP-0082, NK-WP-0049, SECRETS-WP-0012, SECRETS-WP-0008, SECRETS-WP-0013, SECRETS-WP-0014, GEXEC-WP-0001]
@@ -136,7 +136,7 @@ assignee: codex
 needs_human: true
 decision_id: "d1ab097d-cc79-4612-9c17-bb9b364081ac"
 depends_on: [SECRETS-WP-0015-T03, SECRETS-WP-0015-T05, NK-WP-0049-T33]
-blocking_reason: "Anchor installed on the attempt host 2026-10-23 and NK-WP-0049-T33 done. Await the founder's signed attempt admission for the exact case (NK-WP-0049-T40) and original OpenBao/custody recovery for actual consumer continuity."
+blocking_reason: "Issuer half filled 2026-10-23 (NK49 T40 admission, T18 isolated attempt verified). Still open: consumer claim compatibility (unimplemented NK49 callback) and actual consumer continuity, which waits on an independently recovered original OpenBao/custody graph owned by railiance-platform/rapp-openbao; no isolated OpenBao restore is prepared."
 state_hub_task_id: "aeec6eb0-39e2-5f7c-8f5d-778133edfc73"
 ```
 
@@ -181,3 +181,46 @@ is root:root 0644 with a single entry: principal `bernd`, namespaces=`secrets-en
 `SHA256:NekDABfw8K8IBYznjREg7jPpcK/BzCgO1pH1ebT/FXM`. A self-test signature verified Good. This is not
 the runtime host anchor for SECRETS-WP-0014-T04 (different namespace and host). No selector, service_auth.py or
 check-tool file was edited, so the NK49 pins stand.
+
+2026-10-23 evening, consumer-owner reading of the NK49 attempt (read-only; no live action by this owner).
+Inputs: NK-WP-0049-T40 done (net-kingdom a20dcfe), founder-signed admission sha256 `f8297954…c157`,
+window 2026-10-23T17:00Z to 2026-10-24T05:00Z; selector preflight `--admission` exit 0,
+`founder_admitted_attempt_not_native_acceptance`, principal bernd. NK-WP-0049-T18 attended attempt
+(net-kingdom a09bf20, `docs/evidence/2026-10-23-nk49-t18-keycape-attempt/verifier-output.json`):
+production LE reissue in an isolated namespace (railiance-cluster 88b360b), launcher passed, independent
+verifier `verified` with no findings for receipt sha256 `16d72f7c…1651`. The receipt is retained outside
+Git by founder decision and is not copied here. It records `network_mode` none, `production_contacted` false,
+`downstream_consumer_reconnect_proven` false and `human_mfa_proven` false.
+
+Filled, for this exact selector only (plan claim 1, original issuer). The pinned checker
+`isolated-keycape.py` (sha256 `86f37add…`) selects exactly one archived client `secrets-engine-openbao`
+with `secretRef` env `KEYCAPE_SECRETS_ENGINE_OPENBAO_CLIENT_SECRET`, confidential, client_credentials.
+It then runs native `keycape verify-client` with all eight selector fields:
+- archived registration: `native_service_registration_verified` and
+  `original_config_registry_policy_receipts_equal`. Exchange with the archived secret, exact sub, tenant,
+  roles and scope, and no excess grant.
+- issuer trust: `original_https_issuer_and_trust_preserved` and `original_public_signing_key_in_live_jwks`
+  (SPKI sha256 `e803a3e2…3a3d`), on the reissued chain to ISRG Root X1.
+- native negative checks at the issuer: `denied_scopes_refused` (`openbao:admin`) and
+  `wrong_unrelated_secret_explicitly_refused`.
+- isolation and cleanup: plaintext and container cleanup verified.
+
+Not filled, and not claimed. The verifier's `claims_not_made` (consumer continuity, retained-factor MFA,
+owner acceptance) remain unclaimed here.
+- Plan claim 2, consumer claim compatibility. The callback that hands an original-issuer token to the
+  Secrets claim observer is not implemented, and the observer has never run on real material.
+- Plan claim 3, actual consumer continuity. The secrets-engine client has not authenticated natively
+  against restored dependencies: no OpenBao JWT login, no resource-server negative, no session
+  revocation. This needs an independently recovered original OpenBao, plus its custody, KV
+  registration, OIDC role and operator auth. NK49's identity archive does not carry it
+  (`identity-service-restore-packet.md` excludes OpenBao restoration).
+- MFA stays NK49 T19. Owner acceptance is not given by this note.
+
+2026-10-23 read-only survey. No owner holds a prepared, bounded, isolated OpenBao recovery for this
+consumer. railiance-platform RPF-WP-0036-T03 inventories OpenBao snapshot/isolated restore and waits on
+the activity-core scheduler. Its RPF-WP-0015 Raft snapshot receipt authorizes no restore. rapp-openbao
+WP-0001/0002 contain no restore task.
+Next owner action: railiance-platform, with rapp-openbao, accepts or declines a bounded isolated original
+OpenBao restore with the secrets-engine JWT role and KV path, as a dependency of this task. The
+consumer-continuity run (plan claim 3) stays a separately admitted attempt after that. Status stays `wait`.
+No selector, service_auth.py, checker or founder_admission.py file was edited, so the NK49 pins stand.