diff --git a/workplans/KEY-WP-0013-approval-engine-resource-audience.md b/workplans/KEY-WP-0013-approval-engine-resource-audience.md
index 58cf069..dfa6621 100644
--- a/workplans/KEY-WP-0013-approval-engine-resource-audience.md
+++ b/workplans/KEY-WP-0013-approval-engine-resource-audience.md
@@ -223,6 +223,32 @@ client's tenant against the real fixture so a reintroduced alias fails the build
 Full `go test ./...` and `go vet ./...` pass. Choice only — live provisioning and
 the other admission gates remain with KEY-WP-0013-T02.
 
+2026-09-09 observation, read-only. Custody has been admitted since the
+2026-09-08 record and the deployment now carries the pieces T02 was waiting for:
+`sso/keycape-config` registers `secrets-engine-approval` and
+`approval-engine-operator` alongside the existing clients; the secrets
+`keycape-secrets-engine-approval-client` and
+`keycape-approval-engine-operator-client` exist in the namespace; both
+`KEYCAPE_SECRETS_ENGINE_APPROVAL_CLIENT_SECRET` and
+`KEYCAPE_APPROVAL_ENGINE_OPERATOR_CLIENT_SECRET` are wired into the pod; and the
+image is pinned by digest to
+`sha256:7ff54c54e63ee172ae9e6e7fd2da96e427352f712343d74626ee6fe0f6f82611`, the
+candidate T06 published.
+
+What that does and does not establish. The live issuer passes every conformance
+check that needs no credential — it advertises itself, offers the profile
+authorization surface, publishes usable RS256 keys and advertises no excluded
+grant (`src/tests/conformance`, run against `https://kc.coulomb.social`). It does
+**not** establish the claim contract: subject, tenant, roles, scopes, lifetime
+and excess-scope denial per client are exactly what `keycape verify-client`
+exists to prove, and that needs the client secret in the environment.
+
+Deliberately not done here. Reading either secret to run the verifier is
+client-side retrieval, which the provisioning packet records as **not admitted**
+(`custody_return.scope`: verifier-side copies only). So the remaining proof is an
+attended operator action, not something to take by reading the secret. T02 stays
+`wait` on that run, not on custody.
+
 ## Assign and register the human approver browser client
 
 ```task
diff --git a/workplans/KEY-WP-0028-browser-client-field-validation.md b/workplans/KEY-WP-0028-browser-client-field-validation.md
index 83fc122..2876402 100644
--- a/workplans/KEY-WP-0028-browser-client-field-validation.md
+++ b/workplans/KEY-WP-0028-browser-client-field-validation.md
@@ -9,6 +9,7 @@ owner: claude
 topic_slug: browser-client-field-validation
 created: "2026-09-09"
 updated: "2026-09-09"
+state_hub_workstream_id: "6d0cb4fd-17da-5466-8011-5ade1ac46171"
 ---
 
 `serviceSubject` and `roles` are read only on the `client_credentials` path. On a
@@ -26,6 +27,7 @@ rule exists — it was just incomplete.
 id: KEY-WP-0028-T01
 status: done
 priority: medium
+state_hub_task_id: "e4bce8c7-0e60-55e8-ad32-a3a0c4e46044"
 ```
 
 Config validation now rejects `serviceSubject` and `roles` on any client that
@@ -34,6 +36,16 @@ Nothing in `config/dev-config.yaml`, the example fixture or the live deployment
 sets either field on a browser client, so this breaks no existing configuration —
 checked against all three rather than assumed.
 
+Re-verified against `sso/keycape-config` on 2026-09-09, after a peer raised that
+this validation fails closed at startup and a rollout is imminent, so a stray
+field would surface as KeyCape failing to boot. The deployed config now holds six
+clients: `demo-app`, `netkingdom-bootstrap-console` and `openbao-admin` are
+browser clients carrying neither field, while `rapp-qonto-client`,
+`secrets-engine-approval` and `approval-engine-operator` carry both legitimately
+on the `client_credentials` path. The rule rejects none of them. Kept as errors
+rather than downgraded to warnings on that evidence: a warning for a field that
+does nothing is the state this change exists to end.
+
 **`tenant` is deliberately excluded from the rule**, and a test pins that. A
 browser client may declare a tenant; `humanTenant` resolves it against the
 directory and refuses issuance when the two disagree (KEY-WP-0013-T05). An
@@ -46,6 +58,7 @@ feature unusable.
 id: KEY-WP-0028-T02
 status: done
 priority: medium
+state_hub_task_id: "5ab951f8-2f9c-522c-b6ea-7f6d572cd618"
 ```
 
 This work started from KEY-WP-0013-T05's blocker paragraph, which described a