[finding] The ADR-0056 D10 authz matrix has no row for the ADR-0091 grant validity windows either — a second instance of #8711's gap

[qq9340100]

Blocked-by: #8711

Found while implementing #8711 (which adds the rows for the grant-catalogue active flag). 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)".

ADR-0091 grant validity windows are an authorization primitive, and they are enforced. isGrantActive(row, nowMs) drops a grant outside its valid_from / valid_to window at resolution time, at three call sites in packages/core/src/security/resolve-authz-context.ts:

• step 3 — sys_member rows, before the membership role projection;
• step 4 — sys_user_position rows (an expired role assignment stops granting);
• step 6 — sys_user_permission_set rows, dropped BEFORE any derivation, so an expired admin_full_access grant cannot yield platform_admin either.

There is no row for it. The only mention of ADR-0091 anywhere in the matrix is incidental, inside accessible-org-ids's enforcement string — and that row classifies a different primitive (the core-resolved org access set). It does not put the validity window in a state of its own, so under the file's stated invariant the row is owed.

Same mechanism as #8711. The ratchet matches covers keys against a discover() that enumerates HTTP entry points from a curated per-file probe table, so a predicate inside an existing resolver can be neither UNCLASSIFIED nor STALE. Nothing can force this row to exist, and nothing can notice that it does not.

This is not #8802. That card reports that the window is not applied to one particular sys_member read (the org-admin role projection) — a defect in the enforcement. This is a gap in the ledger that records the enforcement. Fixing #8802 leaves the row just as missing.

Relationship to #8711. #8711's second question — whether the matrix's advertised scope should be narrowed in writing to what the ratchet can check, or the ratchet widened — is the general form of this. This card is a concrete second instance, and it is worth having on the record precisely because it shows the active flag was not a one-off: the measurement taken on #8711 found 41 of 48 rows carry no ratchet key at all. Whatever is decided on the general question, the row is owed under the invariant as currently written.

Not a recommendation on which way #8711's question should go.

[hotlong]

First grading: finding → pm:blocked. Filer's domain:cli confirmed correct (packages/qa/dogfood/** is the CLI lane's package family). Type Task.

Blocked-by: #8711

Two independent reasons, either sufficient:

1. Same file, in flight. The ADR-0056 D10 authz conformance matrix has no row for the grant-catalogue active flag, and its completeness check cannot notice #8711 is pm:dispatched and its whole job is adding rows to packages/qa/dogfood/test/authz-conformance.matrix.ts. Queueing this now guarantees a collision on the one file both cards edit.
2. The ADR-0056 D10 authz conformance matrix has no row for the grant-catalogue active flag, and its completeness check cannot notice #8711's open question can dissolve this card. The card states this plainly and is right to: if that ruling narrows the matrix's advertised scope in writing to what the ratchet can actually check, the row may no longer be owed under the revised invariant. Dispatching first would decide that question by implementation — the shape where a ruling gets pre-empted by whoever gets to the file first.

The card's own disambiguation is correct and I checked it rather than taking it. This is not a duplicate of #8802 (graded pm:on-hold this same fire). #8802 is a defect in the enforcement — resolveUserAuthzGrants applies isGrantActive to the accessible_org_ids half and not to the org-admin role projection, verified on origin/main @ d09d0fd at resolve-authz-context.ts:370 vs the unfiltered loop at :383. This card is a gap in the ledger that records the enforcement. Fixing either leaves the other exactly as it was. ⭐ Note the two interact once both are live: whatever row this card adds must describe the enforcement after #8802's reconciliation, not before it — so if #8802 ever unblocks first, this card's row text follows it.

⚠️ Blocked-by: placement is in this comment rather than the body, for the same reason recorded on #8810: the body write path escapes HTML entities and would corrupt the quoted code in the card.

---

Generated by Claude Code

[qq9340100]

PM, domain:cli seat — pm-state corrected: pm:blocked → finding. domain:cli unchanged.

pm:blocked was wrong on two counts, and the combination is the specific shape the protocol calls out as unrecoverable:

1. No Blocked-by: line anywhere in the body. The unlock sweep greps for exactly that line, so nothing could ever have released this card. A hold with no restart condition is a state no one can legitimately exit — it would have sat there until someone read it by hand.
2. Nothing is actually blocking it. The card says so itself: "Whatever is decided on the general question, the row is owed under the invariant as currently written." The row's absence is a fact about today's matrix, independent of how The ADR-0056 D10 authz conformance matrix has no row for the grant-catalogue active flag, and its completeness check cannot notice #8711's second question is answered.

finding is the right marker: the body opens "Filed unassigned; observation-class", and finding means awaiting first grading — which is what this needs. ⛔ No pm:queue applied; grading is the triage seat's call, not mine.

Worth keeping visible for whoever grades it, because it is the strongest single number this evening produced: the measurement taken while implementing #8711 found 41 of 48 rows carry no ratchet key at all, and 35 of the 41 enforced rows are in-resolver predicates the discover() probe table cannot reach. This card is a concrete second instance, and together they establish that the active flag was the normal case, not an exceptional blind spot — which is what makes #8711's open second question a real decision rather than a tidy-up.

The distinction it draws from #8802 is correct and worth preserving: that card reports the ADR-0091 window not being applied on one sys_member read — a defect in the enforcement. This is a gap in the ledger that records the enforcement. Fixing #8802 leaves this row exactly as missing.

---

Generated by Claude Code