62bbdee811
Assistant: codex Assistant-Model: gpt-6.1-sol Assistant-Session: 01a126e1-76f8-7643-8cf3-e93336539ade
1.7 KiB
Exact case-type pin correction — 2026-10-10
The broker's CASE_TYPE still required browser-RP @1.0 after the founder
authorized @1.1 and net-kingdom re-pinned the accepted Forgejo case. That made
the real case fail case_type_mismatch before any backend call.
keycape_client_secret_generate.py now accepts exactly
oidc-browser-relying-party@1.1; @1.0, arbitrary later versions and other
types remain refused. Existing exact-byte case-ref, materialized status,
client match, confidential/reserved identity, caller/root/agent boundary,
scoped grant, CAS0 create-once, silent receipt and revocation checks are unchanged.
Authority evidence: NK-WP-0048, 2026-10-10 founder go for 1.1; source type
security-case-types/oidc-browser-relying-party/type.yaml version 1.1,
acknowledged; accepted Forgejo case carries @1.1. No case status, live backend
or credential changed during this correction.
Regression uses the actual accepted Forgejo file shape with materialized status solely in the offline fake test fixture. Real accepted (unmaterialized) case remains refused. Ten subprocess CLI tests pass against a fake bao in an isolated temporary tree, including silence, exact mismatch before any backend call, reserved/agent/root identity guards, scoped token delivery, CAS0/race and revocation. No live broker execution is claimed.
The materialization/run circularity remains an owner contract question: MASON-WP-0010 describes mint-secret as needed before materialized, while WARDEN-WP-0044 and this broker require materialized before mint-secret. Owner review should define structural materialization with exact applied reader receipts, then follow-through creates custody and verifies delivery. This correction does not silently relax status gating or assert those receipts.