key-cape/workplans/KEY-WP-0027-rollout-readiness-and-live-state.md

id	type	title	domain	repo	status	owner	topic_slug	created	updated	state_hub_workstream_id
KEY-WP-0027	workplan	Establish the live state and the rollout gap for G10	infotech	key-cape	finished	claude	rollout-readiness-and-live-state	2026-09-08	2026-09-08	2ab60558-ee14-542c-9f19-bb487de8e668

G10 cannot be closed from this repository: it waits on named custody and platform owners. What was doable was to stop guessing about the live state, verify the handoffs actually went out, and find out whether main is safe to roll out. The last question turned up a defect in this repository's own recent work.

Verify the handoff receipts independently

id: KEY-WP-0027-T01
status: done
priority: medium
state_hub_task_id: "00de2bad-04da-5b58-8cde-aaa144272541"

KEY-WP-0009 was reopened once because delivery was claimed without receipts, so the claim that it has now been sent deserved the same scrutiny rather than being taken on trust. GET /messages/?from_agent=key-cape shows all seven present and dated 2026-09-08T08:21Z: the four KEY-WP-0009 handoffs (netkingdom, secrets-engine, ops-warden, railiance-platform) and the three admission requests (railiance-platform custody, approval-engine human callback, ops-warden token split). No replies had arrived at the time of writing, which is expected hours after sending and is not itself a blocker to record.

Record the live state as observed, not as remembered

id: KEY-WP-0027-T02
status: done
priority: medium
state_hub_task_id: "2d513229-1dbd-500e-9100-c0173be7b4de"

Read-only cluster inspection, sso namespace, 2026-09-08:

• image forgejo.coulomb.social/coulomb/key-cape:main-153258b, predating every change from KEY-WP-0016 onward;
• environment carries KEYCAPE_RAPP_QONTO_CLIENT_SECRET only, so the two approval clients are still not materialized — KEY-WP-0013-T02 remains correctly blocked;
• four registered clients: demo-app, netkingdom-bootstrap-console and openbao-admin (public, authorization_code) and rapp-qonto-client (confidential, client_credentials);
• no tenantEngine block, so KEY-WP-0024 is inert on rollout.

Correction to an earlier claim of mine. I reported the ou=people fix (KEY-WP-0023) as a production-relevant correction to human login. The deployed config sets userOU: "ou=people" explicitly, so production was never affected. The fix matters for anyone relying on the default — the dev stack, the scenario scripts, a fresh deployment — not for this one.

Find out whether main is safe to roll out

id: KEY-WP-0027-T03
status: done
priority: high
state_hub_task_id: "23c8d04b-c2b7-5347-80a0-6388c1c41c53"

Defect found in KEY-WP-0019, before it shipped. Upstream verification discovers the expected issuer server-side from authelia.tokenBaseURL. The deployed Authelia derives its advertised issuer from the request Host, confirmed directly:

Host presented	issuer advertised
authelia.sso.svc.cluster.local:9091	http://authelia.sso.svc.cluster.local:9091
auth.coulomb.social	http://auth.coulomb.social

KeyCape fetches over the in-cluster address, so it would expect the first value while tokens minted for the browser-facing host carry the second. Verification fails closed, so if they differ every human login fails after rollout, and it presents as a broken login rather than a configuration error.

Which value the ID token actually carries could not be settled from here without performing a real login against production Authelia, which was not done. The risk is therefore recorded as a rollout precondition, not as a confirmed breakage.

Two mitigations, both in this repository:

• docs/operations.md documents pinning authelia.issuer and authelia.jwksUrl explicitly, with the one-line curl that reveals the value the provider will advertise for a given Host. The overrides already existed; nothing said when they were needed.
• The failure is now diagnosable. The authentication failure event carries a specific reason — id_token_issuer_mismatch, distinct from id_token_signature, provider_keys_unavailable and the rest — so an operator can tell a misconfiguration from an attack. Five cases cover the mapping. The browser still learns nothing.

Record what each owner owes

id: KEY-WP-0027-T04
status: done
priority: medium
state_hub_task_id: "7ba84b61-0458-5820-8ded-c6f59d820303"

G10's status now names the live state, the outstanding requests with their receipt ids, and the issuer precondition that must be checked before main is deployed. The precondition was also sent to railiance-platform as the deployment owner (message c8b1ad10), with the exact curl to settle it, the config keys to pin, and the error_type to look for if it bites — plus a note that the two approval clients remain unprovisioned, confirmed by inspection rather than asserted. G10 stays open: nothing here admits custody, registers the human callback, or reconciles the OpenBao-token boundary, and no repo-local change can.