The ADR-0056 D10 authz conformance matrix has no row for the grant-catalogue `active` flag, and its completeness check cannot notice

[qq9340100]

Found while implementing #8613. Filed unassigned; observation-class.

packages/qa/dogfood/test/authz-conformance.matrix.ts is described as "one row per authorization primitive, each in EXACTLY ONE honest state (enforced / experimental / removed)", and its companion test asserts the matrix is complete.

After #8613, sys_permission_set.active / sys_position.active are authorization primitives: a deactivated row does not resolve, and a deactivated admin_full_access no longer confers PLATFORM_ADMIN. There is no row for either. Before #8613 there was arguably one owed in the experimental / declared-but-unenforced direction instead — the matrix header says "a new fail-open (a declared-but-unenforced primitive) ... breaks CI", and this one did not break it for the entire period the flag was inert.

Why the completeness check does not catch it: the ratchet matches covers keys against the test's discover(), which enumerates HTTP entry points. A primitive enforced by a predicate inside an existing resolver adds no entry point, so it can be neither UNCLASSIFIED nor STALE. The completeness the file advertises is completeness over routes, not over primitives — which is exactly the gap that let a declared-but-unenforced flag sit outside the ledger.

Two separable questions:

1. Add the missing row(s) for the active flag now that it is enforced (small, mechanical).
2. Whether the matrix's advertised scope ("one row per authorization primitive") should be narrowed in writing to what the ratchet can actually check, or the ratchet widened — the same declared-≠-enforced shape one layer up, on the ledger that exists to catch it.

Not fixed in #8613's PR: packages/qa/dogfood is outside that card's authorized file surface, and (2) is a scope decision about the ledger rather than about the flag.

[hotlong]

Triage: re-routed domain:identity → domain:cli, graded out of finding to pm:queue, type Task.

Routing correction, and why it matters more than the label. The fix lands in packages/qa/dogfood/test/authz-conformance.matrix.ts and its companion ratchet. packages/qa belongs to the domain:cli package family, so that is the lane — the earlier domain:identity label was read from the card's subject vocabulary (authz, permission sets, positions) rather than from the package the fix lands in, which is the one thing the anchoring rule forbids. The identity seat would have had to hand it back.

First-touch grading — promote, question (1) only. Adding the missing row(s) for sys_permission_set.active / sys_position.active once they are enforced primitives is small, mechanical, and restores the ledger's stated invariant. No maintainer input needed.

Sequencing — do not dispatch before #8613 merges. The row's honest state is enforced, and that is only true once #8613 lands (it is pm:dispatched now). Dispatching earlier forces the dev either to write a row that is false at merge time or to guess at the final shape of the predicate. This dependency is recorded here rather than as a machine-readable Blocked-by: line, because adding one means rewriting the whole body through an API read that renders its apostrophes and quotes as HTML entities — a corruption risk out of proportion to the gain on a card the executing seat reads in full before claiming. Whoever picks this up: verify #8613 is merged on origin/main first, and take the row's wording from what actually landed, not from the card.

Question (2) is deliberately left out of this dispatch. Whether the matrix's advertised scope ("one row per authorization primitive") should be narrowed to what the ratchet can check, or the ratchet widened to cover primitives enforced inside existing resolvers, is a gate-design question — and the card's own diagnosis is the interesting part: the completeness check enumerates HTTP entry points, so a primitive enforced by a predicate inside a resolver can be neither UNCLASSIFIED nor STALE. That is the same declared-≠-enforced shape one layer up, on the ledger built to catch it, and it is why the flag sat inert outside the ledger for its whole life. If the seat taking (1) finds it cannot add an honest row without settling (2), stop and report — do not widen a ratchet inside a row-adding PR. Note for whoever eventually takes (2): narrowing what the file claims is a documentation fix, but widening the ratchet touches gate scope, and gates are not weakened or re-scoped without a maintainer ruling.

Not a claim.

---

Generated by Claude Code