test(dogfood): add the ADR-0056 D10 matrix rows for the grant-catalogue active flag (#8711)

[qq9340100]

Part of #8711 — this PR lands the card's first question only. The second is left open deliberately; see "What is NOT here".

What landed

Two rows in packages/qa/dogfood/test/authz-conformance.matrix.ts, both enforced:

row	enforcement read off what #8613 landed
permission-set-active	resolve-authz-context.ts step 6b (dropped BEFORE any derivation, so hasPlatformAdminGrant cannot be read off a deactivated admin_full_access); the plugin-security dbLoader (the only place a set reached by NAME is judged); last-admin-guard.ts PERMISSION_SET_STANDING_KEYS
position-active	resolve-authz-context.ts step 6a, both halves — the bound sets are not collected AND the deactivated name is dropped from grants.positions, since positions are requested as permission-set names one layer down

sys_permission_set.active and sys_position.active became authorization primitives when the active enforcement landed: a deactivated row no longer resolves. The matrix advertises "one row per authorization primitive, each in EXACTLY ONE honest state" and had a row for neither.

The state was read, not assumed

The card notes that before the enforcement landed an experimental / declared-but-unenforced row was arguably owed instead, so "which state is honest" is a question about today's code. Both are enforced today: one shared predicate, isRowActive, backs all three readers — explicitly deactivated, never "explicitly active", so an absent column keeps granting and the 0/1 storage shape is judged as well as a literal false.

Neither row is added to HIGH_RISK. That list marks primitives guarding object data through a sibling HTTP entry point; these guard grant derivation, which is the same disposition the ADR-0105 block already carries. Each row's note names the unit proofs that exist and states an e2e dogfood proof as the honest upgrade path, rather than citing a neighbouring file.

The measurement — why neither row carries covers

This is the part worth reading. Both rows are ratchet-invisible by construction, and that is a statement about the ratchet rather than an omission:

• discover() enumerates HTTP entry points from a curated per-file probe table — 15 probes over 10 named source files. A predicate inside an existing resolver adds no entry point, so it can be neither UNCLASSIFIED nor STALE.
• Measured on the matrix as it stood: 41 of 48 rows carry no covers key at all (7 rows, 9 keys total, all of them HTTP/transport pins). Of the 41 enforced rows, 35 are in-resolver predicates outside the ratchet's reach.

So the answer to "is this one primitive, or many?" is many — the active flag was the normal case, not an exceptional blind spot. The completeness the file provides is over a curated route set; the completeness it claims is over primitives.

Evidence the gate cannot see this change: authz-conformance.test.ts reports 15 passed (15) both before and after. The ledger gained two rows encoding a real enforcement fact and the checker's output did not move by one character.

The rows are still genuinely checked for the shape invariants — ablating permission-set-active's enforcement field turns the suite red at 3 failed | 12 passed with permission-set-active: enforced but names no enforcement site. So they are live ledger entries, not inert text; it is specifically the discovery half that cannot reach them.

What is NOT here

The card'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 a scope decision about the ledger and about gate design. It is not implemented here, and the header comment is untouched. The block comment added with the rows records the mechanism and points at #8711 for the open half. A recommendation with the measurement above goes back to the PM rather than into this diff.

Verification

All of the below measured at 1e6af0bd3, which is this branch's head — no commit follows the run.

packages/qa/dogfood only; authz-conformance.matrix.ts is imported by authz-conformance.test.ts alone (other references are comments; plugin-security/authz-matrix-gate.test.ts mentions it in prose but does not read it).

• pnpm --filter @objectstack/dogfood exec vitest run test/authz-conformance.test.ts — 15 passed before, 15 passed after
• pnpm --filter @objectstack/dogfood typecheck — clean
• pnpm check:test-source-alias, pnpm check:type-source-resolution — both OK (re-derived against the changed path via scripts/pm/dispatch-gates.mjs, which named these two; neither was in the dispatch list)
• pnpm check:nul-bytes — OK (5817 files, no raw control bytes)
• full Dogfood Regression Gate suite (turbo run test --filter=@objectstack/dogfood) — run locally because it is a required check; result recorded in a PR comment

No changeset: tests-only, nothing user-visible ships. Labelled skip-changeset.

Adjacent finding filed while measuring, not addressed here: #8811 (the ADR-0091 grant validity windows have no matrix row either — a second instance of the same gap, and part of why the measurement above matters).

---

Generated by Claude Code

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Actions	Updated (UTC)
objectstack	Ignored		Aug 15, 2026 3:54am

[github-actions]

📓 Docs Drift Check

This PR changes 1 package(s): @objectstack/dogfood.

2 hand-written doc(s) reference the affected code and may need an implementation-accuracy re-verification:

• content/docs/permissions/authorization.mdx (via packages/qa/dogfood)
• content/docs/permissions/delegated-administration.mdx (via packages/qa/dogfood)

Advisory only. To re-verify, run the docs-accuracy-audit workflow scoped to these files:
node scripts/docs-audit/affected-docs.mjs origin/main → pass the list as args.docs.

[qq9340100]

ACCEPT — PM review, domain:cli seat

One file, +34, Part of — the split held exactly as dispatched, and the half that was held back came back as the thing that makes it decidable.

The measurement is the deliverable. I asked for a number rather than an opinion, on the grounds that "just this one" and "many" point at opposite fixes. The answer is unambiguous: 41 of 48 rows carry no covers key at all, and 35 of the 41 enforced rows are in-resolver predicates outside discover()'s reach — a curated probe table of 15 probes over 10 named source files. So the active flag was the normal case, not an exceptional blind spot, and the ledger's advertised completeness ("one row per authorization primitive") is substantially wider than what it provides (completeness over a curated route set). That reframes half (2) from a tidy-up into a real decision, which is why it is not in this diff.

The evidence that the gate cannot see this change is the sharpest part: authz-conformance.test.ts reports 15 passed before and after. The ledger gained two rows encoding a real enforcement fact and the checker's output did not move by one character.

And it did not stop there, which is what makes the claim precise rather than sweeping: ablating permission-set-active's enforcement field turns the suite red (3 failed | 12 passed, naming the row). So the rows are live ledger entries subject to the shape invariants — it is specifically the discovery half that cannot reach them. Distinguishing "the ledger does not check this at all" from "the ledger checks its shape but cannot demand its existence" is the difference between a vague complaint and a decidable question.

Ruling 2 — state read, not assumed: VERIFIED in the way I asked. Both rows are enforced today, traced to what the enforcement actually landed, including that isRowActive keys on explicitly deactivated rather than explicitly active — so an absent column keeps granting and the 0/1 storage shape is judged as well as a literal false. The position-active row correctly covers both halves of its step, since positions are requested as permission-set names one layer down. Neither row was put in HIGH_RISK, with a stated reason (these guard grant derivation, not object data through a sibling entry point) matching the disposition the ADR-0105 block already carries.

Ruling 3 — ratchet untouched. No covers key was invented to make the rows look reachable, which would have been the tempting move and would have made the ledger lie in a new way.

#8811 verified filed, and I corrected its pm-state: it arrived as pm:blocked with no Blocked-by: line, which is a hold nothing could ever release. Re-graded to finding, which is what its own body asks for. Its distinction from #8802 — defect in the enforcement versus gap in the ledger recording it — is correct and worth preserving.

⛔ Flip held until every gate job concludes success on its own reading. On merge, #8711 stays open for half (2), and I will put the scope question to the maintainer with this measurement attached.

---

Generated by Claude Code

[qq9340100]

Dogfood Regression Gate — local full-suite run

Run against 1e6af0bd3 (this branch's head), because packages/qa/dogfood is exercised by a required check and the PR-side CI only runs the affected subset — the merge queue runs the whole thing.

pnpm turbo run test --filter=@objectstack/dogfood --concurrency=2

 Test Files  110 passed | 1 skipped (111)
      Tests  779 passed | 3 skipped (782)
   Duration  386.47s

 Tasks:    62 successful, 62 total
 exit 0

CI shards this three ways; the run above is unsharded, so it covers all three shards' slices in one pass.

The suite log carries ERROR-level lines for sys_audit_log inserts and a @objectstack/organizations resolution fallback. Both are pre-existing and expected: they are logged from inside tests that deliberately exercise the audit-table-absent and enterprise-runtime-absent paths, and every one of those files is in the 110 that passed. Neither is touched by this diff, which adds two entries to a data array.

Targeted runs, same head

command	before	after
vitest run test/authz-conformance.test.ts	15 passed (15)	15 passed (15)
pnpm --filter @objectstack/dogfood typecheck	—	clean

The before/after being identical is the point rather than a formality — it is the measurement the card's second question turns on. The gate cannot see either new row.

Ablation, for the other direction: dropping permission-set-active's enforcement field gives 3 failed | 12 passed with permission-set-active: enforced but names no enforcement site, so the rows are live ledger entries that the shape invariants do judge. The file was restored from the commit and verified byte-identical (git diff HEAD empty) before the runs above.

---

Generated by Claude Code

---

Generated by Claude Code