Complete KeyCape service-token rollout

workplans/KEY-WP-0006-client-credentials-service-tokens.md

@@ -4,7 +4,7 @@ type: workplan
 title: "Client credentials and service-token issuance"
 domain: infotech
 repo: key-cape
-status: active
+status: finished
 owner: codex
 topic_slug: netkingdom
 created: "2026-07-27"
@@ -79,7 +79,7 @@ module.
 
 ```task
 id: KEY-WP-0006-T04
-status: wait
+status: done
 priority: high
 state_hub_task_id: "ba65d39f-63b8-42aa-87bb-99ec26821a8e"
 ```
@@ -89,13 +89,28 @@ OpenBao lane, register the static `rapp-qonto` client, deploy KeyCape, and
 verify a real exchange yields only the documented Binky service claims.
 Publish non-secret evidence to `KEY-WP-0004-T03` through T05.
 
+2026-07-27: Provisioned the confidential client secret at
+`platform/workloads/rapp-qonto/keycape-client`, injected it into
+`sso/keycape-rapp-qonto-client`, registered `rapp-qonto-client`, and deployed
+image `main-e877d27-2` on railiance01. A real exchange produced only
+`sub=rapp-qonto`, `tenant=tenant:friendly:binky`, `principal_type=service`,
+`roles=[qonto-reader]`, empty groups, and `scope=qonto:read`; excessive scope
+and a wrong secret were denied. Public DNS still resolves
+`kc.coulomb.social` to the older CoulombCore endpoint, so the deployment proof
+used TLS-preserving direct resolution to railiance01 (`92.205.62.239`).
+
 ## T05 - Closure review
 
 ```task
 id: KEY-WP-0006-T05
-status: wait
+status: done
 priority: low
 state_hub_task_id: "7c9cdac6-c53f-4a32-81d2-8d2e73de0039"
 ```
 
 Close after T01-T04 pass and the repeatable verification path is documented.
+
+2026-07-27: Closure review passed. Build, vet, unit/profile tests, live
+positive claims, negative authentication/scope checks, and discovery metadata
+all passed. The stale public DNS target is handed off as routing work rather
+than weakening the service-token contract.