Close the KEY-WP-0009 handoff gap and deliver the two blocked admissions

KEY-WP-0009-T04 is done. Re-ran verification on main with an explicit Go 1.23.0
toolchain and a writable build cache: contract validator PASS, build, vet and the
full test suite pass, git diff --check clean. gofmt had drifted on
internal/server/telemetry/events.go and tests/migration/scenario_c_test.go
(comment alignment only, no semantic change); both reformatted so the task's
formatting claim holds. The four handoffs to netkingdom, secrets-engine,
ops-warden and railiance-platform were then actually sent -- the 2026-09-05 audit
had shown the earlier claimed delivery had no receipts -- and each receipt id is
recorded in the workplan and readable back from the hub.

KEY-WP-0013-T02 and KEY-WP-0014-T04 stay in wait. Their remaining work is not
ours to do, so what was owed was the request, and it is now delivered: custody
admission for the two approval clients to railiance-platform, the exact human
client id and callback URI to approval-engine, and the OpenBao-token vs
issuer-JWT split plus Qonto rotation execution authority to ops-warden. Each
message quotes the existing non-secret packet or reviewed sequence and states
what is explicitly not being treated as authorization.

No secret was read, no production resource changed, no route retired.
SCOPE.md updated to match.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016uV8zoCKpA1WRAxsKRYbdH

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 1182213@bnt-lap001
Assistant-Session: 966597b9-ae61-46a4-8b9e-1594ab3ec4ad

SCOPE.md

@@ -103,8 +103,14 @@ Keycloak interchangeability are not established.
   (KEY-WP-0026). Production
   deployment and custody are external; a source implementation or example client
   fragment does not prove live registration or consumer cutover.
-- Approval-client provisioning, coordinated Qonto rotation, native consumer
-  handoffs and notification receipt closure remain open in KEY-WP-0009/0013/0014.
+- Notification receipt closure is done: KEY-WP-0009 is finished, its four handoffs
+  delivered with receipts readable via `GET /messages/?from_agent=key-cape`.
+  Approval-client provisioning (KEY-WP-0013-T02) and coordinated Qonto rotation
+  plus the login-proxy consumer split (KEY-WP-0014-T04) remain open. Both requests
+  are now delivered and both wait on owners outside this repository —
+  railiance-platform for custody admission, approval-engine for the exact human
+  callback, ops-warden for the route contract and a rotation execution/rollback
+  authority. No client is materialized in the deployed image and no route changed.
 
 ## Deliberate exclusions
 

src/internal/server/telemetry/events.go

@@ -25,7 +25,7 @@ type Event struct {
 	ClientID    string    `json:"client_id"`
 	Endpoint    string    `json:"endpoint"`
 	Feature     string    `json:"feature,omitempty"`
-	Result      string    `json:"result"`             // "success" | "failure"
+	Result      string    `json:"result"` // "success" | "failure"
 	ErrorType   string    `json:"error_type,omitempty"`
 	Scopes      []string  `json:"scopes,omitempty"`
 	GrantType   string    `json:"grant_type,omitempty"`

src/tests/migration/scenario_c_test.go

@@ -8,8 +8,8 @@ import (
 	"strings"
 	"testing"
 
-	"keycape/internal/migration/toldap"
 	"keycape/internal/migration/tokeycloak"
+	"keycape/internal/migration/toldap"
 	"keycape/internal/server/telemetry"
 )
 

workplans/KEY-WP-0009-provider-capabilities-and-service-identities.md

@@ -4,11 +4,11 @@ type: workplan
 title: "Provider capability declarations and bounded service identities"
 domain: infotech
 repo: key-cape
-status: blocked
+status: finished
 owner: codex
 topic_slug: netkingdom
 created: "2026-08-23"
-updated: "2026-08-23"
+updated: "2026-09-08"
 depends_on:
   - NK-WP-0030
   - KEY-WP-0006
@@ -85,7 +85,7 @@ custody and platform owners and are not implied by this source registration.
 
 ```task
 id: KEY-WP-0009-T04
-status: wait
+status: done
 priority: high
 state_hub_task_id: "6945c0c0-bbb6-552b-8d62-d806d3fd0018"
 ```
@@ -97,8 +97,32 @@ railiance-platform with revision-independent paths and exact ownership status.
 Both declarations pass NetKingdom's canonical validator. The full Go suite,
 vet, build, `gofmt`, YAML parsing, and `git diff --check` pass using an explicit
 Go 1.23 toolchain and writable local cache; the workstation's default Go cache
-is read-only and was not used. The earlier statement that State Hub handoffs were delivered was not supported
-by receipt IDs. The 2026-09-05 audit found no matching handoff receipts in the
-current Hub response; local implementation and validation were complete, but
-notification delivery is unverified. KEY-WP-0014 records the correction and
-remaining consumer handoff. Do not use this task as proof of message delivery.
+is read-only and was not used.
+
+2026-09-05 correction: the earlier statement that State Hub handoffs were
+delivered was not supported by receipt IDs. The audit found no matching handoff
+receipts in the Hub response. KEY-WP-0014-T02 records the correction.
+
+2026-09-08 closure. Verification re-run on `main` with `GOTOOLCHAIN=go1.23.0` and
+a writable `GOCACHE`: `make contract-test` PASS, `go build ./...`, `go vet ./...`
+and `go test ./...` all pass, `git diff --check` clean. `gofmt` had drifted on
+`src/internal/server/telemetry/events.go` and `src/tests/migration/scenario_c_test.go`
+(comment alignment only, no semantic change); both were reformatted so the
+formatting claim now holds.
+
+The four handoffs were then actually sent, and each receipt is readable back via
+`GET /messages/?from_agent=key-cape`:
+
+| Recipient | Receipt id |
+| --- | --- |
+| netkingdom | `692ed0d7-e21b-48e7-8600-5b32b551c627` |
+| secrets-engine | `479a1698-87dc-4ee2-a732-c2dc18bc4e84` |
+| ops-warden | `5bc58847-eed5-4164-bb0f-a0d8455e75b8` |
+| railiance-platform | `9c6a4e70-6bc0-4ad6-8293-35a56e507dfc` |
+
+Each names revision-independent paths, the 2026-09-08 verification result, and
+the same ownership split: KeyCape owns issuance, static registrations, client
+disablement and the claim set; secret custody, OpenBao roles/policies and token
+enforcement, privacyIDEA factor and token lifecycle, resource authorization and
+deployment remain with their named owners. C2a is not claimed. This closes the
+notification gap; it is still not evidence of live deployment or provider cutover.

workplans/KEY-WP-0013-approval-engine-resource-audience.md

@@ -8,7 +8,7 @@ status: blocked
 owner: codex
 topic_slug: approval-engine-resource-audience
 created: "2026-09-05"
-updated: "2026-09-06"
+updated: "2026-09-08"
 state_hub_workstream_id: "6e815d88-b0e3-5ce0-be5d-13ab15917f7f"
 ---
 
@@ -57,6 +57,34 @@ returned founder_required but matched an unrelated generic database lane; that
 mismatch is not authority to provision. Human callback clarification is pending.
 No secrets were read or production resources changed.
 
+2026-09-08: the two blocking requests were sent and their receipts are readable
+back via `GET /messages/?from_agent=key-cape`.
+
+- `278a3ebe-b529-49f6-bd1a-e3ebcf318260` -> railiance-platform. Custody admission
+  for both clients, quoting `docs/approval-engine-provisioning-request.yaml`
+  verbatim: exact OpenBao paths and `client_secret` field, the two Kubernetes
+  delivery references, the two `KEYCAPE_*_CLIENT_SECRET` environment names,
+  `tenant:platform` per decision `5ed3fb35-eca9-413a-82b9-95171ba85bf6`, and the
+  15m lifetime. It asks for four things explicitly: confirm/correct the paths and
+  fields, confirm the delivery references, name the authority for the attended
+  first provision, and agree a rollout window in which registrations and the
+  KeyCape version that reads them deploy together. It restates that the
+  `warden plan` `founder_required` result matched an unrelated generic database
+  lane and is not being treated as authorization.
+- `43fbd997-6e22-4859-8433-58b784c2df6c` -> approval-engine. Requests the two
+  missing human-registration inputs — the exact `client_id` and the full callback
+  URI — noting redirects are matched exactly and a near-miss fails closed at
+  `/authorize`. Restates the human client shape (public, S256 PKCE,
+  `audience: approval-engine`, `allowedScopes: [openid, approval:approve]`,
+  `mfaRequired: true`, no consume grant) and asks approval-engine to confirm it
+  validates the access token, not the ID token, against the deployed `/jwks`.
+
+Deployment state is unchanged from the 2026-09-05 observation: neither approval
+client is materialized. Task remains `wait` — the two admissions are owned by
+railiance-platform and approval-engine respectively, and live provisioning proof
+cannot begin until both land. Still no secret read and no production resource
+changed.
+
 ## Reconcile tenant vocabularies across approval layers
 
 ```task

workplans/KEY-WP-0014-native-credential-lane-handoff.md

@@ -8,7 +8,7 @@ status: blocked
 owner: codex
 topic_slug: native-credential-lane-handoff
 created: "2026-09-05"
-updated: "2026-09-05"
+updated: "2026-09-08"
 state_hub_workstream_id: "0d003df3-f7d3-5063-8ca0-e1e33f7df74a"
 ---
 
@@ -81,4 +81,27 @@ with the platform owner and ops-warden before route changes. No route was change
 NetKingdom, secrets-engine, ops-warden or railiance-platform. Corrected the
 unsupported statement in KEY-WP-0009-T04. This proves only that no receipts
 are present in the current Hub response, not that no message ever existed.
-No replacement outbound messages were sent.
+The 2026-09-05 audit's finding stands as recorded; the replacement outbound
+messages were sent on 2026-09-08 (below).
+
+2026-09-08: `0a6c9d88-cf50-45d8-acdc-99a40747683e` -> ops-warden, readable back
+via `GET /messages/?from_agent=key-cape`. It puts both open questions to the
+route and custody owner in one place:
+
+1. The `key-cape-oidc-login` proxy yields an OpenBao token and `keycape login`
+   yields an issuer JWT — different credential types, different verifiers,
+   different enforcement owners, so not interchangeable. Two admissible options
+   are offered: keep the proxy and run `keycape login` alongside it for JWT
+   consumers, or adapt the route's consumer contract to a JWT and then cut over.
+   Option (a) is recommended until every consumer of the route is enumerated.
+2. Qonto rotation for `rapp-qonto-keycape-client`, quoting the five-step reviewed
+   sequence from `docs/native-authentication.md` and asking who executes the
+   successor generation and CAS update, in which transport, under what authority.
+   It records that `warden route`/`warden plan` returned no exact admitted lane
+   and that a generic match is not being treated as authorization.
+
+The KEY-WP-0009 handoff ops-warden reported missing has also now been delivered
+(`5bc58847-eed5-4164-bb0f-a0d8455e75b8`), closing the KEY-WP-0014-T02 correction.
+
+Task remains `wait` — no route was changed and no rotation command ships until
+ops-warden answers (1) and an execution/rollback authority is admitted for (2).