key-cape/workplans/KEY-WP-0030-tenant-precondition-guard.md

id	type	title	domain	repo	status	owner	topic_slug	created	updated	state_hub_workstream_id
KEY-WP-0030	workplan	Make the static-registration precondition a checked condition	infotech	key-cape	finished	claude	tenant-precondition-guard	2026-09-09	2026-09-09	9ed8f851-080a-5d15-8642-f799c2e3295c

informed-decision replied on KEY-WP-0013-T05 and asked for one thing that is ours to do: the caveat under which a registration-bound human tenant is safe should be "a condition of the capability, so a future change to registration policy has to confront it", not reasoning left in a message.

They are right that it was only prose. docs/tenant-claim-contract.md states it, and a separate test asserted registration_endpoint is absent — but nothing connected the two, so a future session adding dynamic registration would see a test about discovery metadata, not a warning about relabelling users.

Tie the exclusion to the capability it protects

id: KEY-WP-0030-T01
status: done
priority: medium
state_hub_task_id: "4729d591-39d4-5f33-bef8-db8057090913"

TestRegistrationBoundTenantRequiresStaticRegistration asserts both halves together: that a client-declared tenant is issued, and that dynamic client registration is not advertised. Whichever is removed first, the failure points at the other.

The failure message carries the reasoning rather than the observation. Adding dynamic registration while a registration may declare its users' tenant means anyone able to register a client can relabel the users who log in through it into a zone of their choosing; the message says that and names the two ways out, drop the capability or gate it to statically configured registrations.

Verified in both directions rather than assumed: advertising a registration_endpoint fails it with the escalation message, and neutering humanTenant fails it with the message saying to remove the guard along with the capability it protects.

This is deliberately not a vote on the tenant question. It makes the precondition of one option checkable; it does not choose between them, and if option 1 lands the capability and this guard are removed together.

Carry the tenant claim's provenance

id: KEY-WP-0030-T03
status: done
priority: high

gate-house ruled on GH-DEC-2026-013 while this was in flight. Section 5 is a finding nobody asked for and is ours to implement: tenant is a bare string, so a consumer cannot tell a zone the directory asserted about the person from one a registration supplied about the client they came through. approval-engine exact-matches that string while its contract reads as though it relies on the first — the check is sound and the property a reader infers from it is absent.

Every token now carries tenant_source beside tenant: directory, registration, or default. It is advertised in claims_supported and asserted on both grants at the token level, not only in the resolution function, because the claim a consumer reads is the thing under obligation.

Three values where the ruling names two, and that is the substantive judgement here. Labelling an unasserted profile default as directory would reproduce the same defect one level down — a consumer reading an assertion the identity layer never made. The ruling cites GH-DEC-2026-011 §3 on unknown versus absent for the case it examined; the same rule applies to our own fallback, so the fallback is named rather than folded into the strongest neighbouring value.

The agreement case resolves to directory deliberately: if a registration declares the zone the directory also assigned, the directory did assert it, and reporting the weaker source would understate what is known.

Condition (b) corrected a message I had just shipped

id: KEY-WP-0030-T04
status: done
priority: high

The guard committed in 5f516a0 told a future reader that adding dynamic registration could be resolved by dropping the capability or gating it to statically configured registrations. Condition (b) voids the second: admitting dynamic registration voids the registration-bound shape that day, and the directory becomes the only source whatever state the adapter is in. gate-house strengthened our own "must be revisited" on the grounds that revisited implies the answer might survive review, and it would not.

So the message offered a way out the ruling forbids, in the exact place someone would read it while making that change. Corrected the same day. Worth recording rather than quietly editing: the guard was written to force a confrontation, and a guard that suggests an inadmissible resolution is worse than none.

What stays with the owners

id: KEY-WP-0030-T02
status: done
priority: medium
state_hub_task_id: "32b10327-f55d-5a0e-a4bc-be92929469dc"

informed-decision prefers option 2 and explicitly declines to treat that as the answer, flagging it to gate-house on GH-DEC-2026-012 and naming approval-engine's stake. KeyCape leans the same way, which is a reason for more care rather than less: the code already implements option 2 (329e48f), so the doctrine question is being decided against a working implementation. That is worth saying out loud to everyone waiting on it, and was.

Their scope set [openid, approval:read, approval:approve] is confirmed and already published. client_id and callback follow at their T07, deliberately not before the tenant question resolves — registering a client that fails closed at first use is the failure this exchange existed to avoid.