fix(core): effective-map entries reached through a super-user * carry every bit the server grants, so can(object, 'transfer') agrees with checkObjectPermission (#20134)

[objectstack-fleet]

Fixes #20134

Clause-②: yes (widening)

The effective object-permission map (the objects slot of GET /auth/me/permissions, and what ISecurityService.getEffectiveObjectPermissions hands to current_user.can()) now carries every bit a super-user '*' grants on the server. A super-user wildcard is one carrying viewAllRecords or modifyAllRecords. Before this change, its entries diverged from PermissionEvaluator.checkObjectPermission in three places, all in the refuse direction:

• transfer. The fold put only read, create, edit and delete on an entry, so can(X, 'transfer') was false for admin_full_access on every object, and for the walled organization_admin on every object its own set does not name. The server grants transfer through modifyAllRecords.
• A super-read wildcard's own plain bits. '*': { viewAllRecords, allowEdit } put only the read on an entry.
• A super-user wildcard carrying allowExport. It skipped the super-user seed for every unrestricted object. This is the third location of the family recorded on security: the effective permission map folds a super-user '*' over the same set's narrower explicit entries — a walled org admin gets can('sys_position','edit') true where enforcement refuses #20136, measured at 214 cells by the reviewer of fix(core): the effective object-permission map covers a plain * grant, so current_user.can() agrees with checkObjectPermission for a wall-less org admin (#20083) #20132.

The fix is at the producer, @objectstack/core buildEffectiveObjectPermissions, as triage directed (「seed and fold every bit checkObjectPermission reads」). checkObjectPermission, formula's can(), annotateEffectiveApiOperations and every route and plugin source are untouched.

What changes

packages/core/src/security/effective-object-permissions.ts:

• seedSuperUserRestrictedObjects places an entry for every registered object the merged map lacks, whenever the merged '*' carries a super-user bit. It used to skip an unrestricted object whose export stays allowed, because that object needs no apiOperations. The seed no longer resolves the operation set at all. Its signature and its {allow*: false} initial shape are unchanged.

• foldSuperUserWildcardGrants is new and module-private. It runs right after foldWildcardSuperUser and before the managed-write clamp. For each set whose '*' is a super-user wildcard, it walks every entry that set does not name. On each such entry it sets every grant bit the spec's objectPermissionGrants says that wildcard grants: the one fold checkObjectPermission itself asks. This is resolveObjectPermission's per-set reading:

  • a set that names an object keeps its explicit entry as its whole answer for that object;
  • a private object is covered, as a super-user wildcard covers it on the server;
  • only true bits are set.

  For a super-user wildcard the read cell is always true, so its export cell is exactly its own allowExport, the grant half the evaluator's export conjunction reads. The bits are derived, not listed.

• foldWildcardSuperUser has an unchanged body. Its docblock now says what the merged reading cannot carry, and names its two known over-grants (below). The old line "exactly as broad as real enforcement — never broader" was false for those cells.

No exported name or type changes. Both helpers keep their signatures, and the new step is module-private.

Measurement

The map answer is the real formula current_user.can() over toEvalPermissions(map). It is compared with PermissionEvaluator.checkObjectPermission on all 10 verbs the vocabulary accepts. under means the map refuses a verb the evaluator grants, and over the reverse. As in the #20083 pin, create/edit/delete refused on a guarded managed object is the managed-write clamp and is not counted.

Unit fixture: 63 registered objects × 10 verbs. The objects are 52 from @objectstack/platform-objects, 7 plugin-security objects, and 4 app objects: public, apiMethods-restricted, private, and apiEnabled: false. Base is a08e059c61, with core's dist/ built from base source. Head is 071e3f49fb.

subject (resolved sets)	entries	under	over	map bytes
admin_full_access	64 → 64	63 → 0	0 → 0	changed
admin_full_access + member_default	66 → 66	63 → 0	0 → 0	changed
admin_full_access + organization_admin_no_bypass + member_default	66 → 66	63 → 0	0 → 0	changed
walled organization_admin + member_default	66 → 66	30 → 0	38 → 38 (same cells)	changed
'*': { modifyAllRecords }	64 → 64	63 → 0	36 → 36 (same cells)	changed
'*': { modifyAllRecords, allowCreate, allowRead }	64 → 64	63 → 0	0 → 0	changed
'*': { viewAllRecords, allowEdit }	64 → 64	54 → 0	0 → 0	changed
'*': { viewAllRecords, allowEdit, allowTransfer, allowDelete }	64 → 64	153 → 0	0 → 0	changed
'*': { viewAllRecords }	64 → 64	0 → 0	0 → 0	identical
'*': admin bits + allowExport	53 → 64	214 → 0	0 → 0	changed
'*': { viewAllRecords, allowExport }	53 → 64	74 → 0	0 → 0	changed
'*': admin bits + allowExport, + member_default	56 → 66	206 → 0	0 → 0	changed
explicit crm_account: read beside another set's super-user '*'	54 → 64	136 → 0	0 → 0	changed
ONE set: super-user '*' and a narrower explicit crm_account	64 → 64	62 → 0	7 → 7 (same cells)	changed
super-read '*' beside a plain '*'	64 → 64	0 → 0	0 → 0	identical
admin_full_access beside a plain export-only '*'	53 → 64	161 → 0	0 → 0	changed
member_default	31 → 31	0 → 0	0 → 0	identical
organization_admin_no_bypass + member_default	64 → 64	0 → 0	0 → 0	identical
viewer_readonly + member_default	64 → 64	0 → 0	0 → 0	identical
the four #20083 plain-wildcard shapes	—	0 → 0	0 → 0	identical

• No narrowing, measured entry by entry, base against head over all 23 subjects. No entry is removed, no true bit turns false, and no apiOperations list loses or gains an operation. The head adds 53 entries (the allowExport shapes' unrestricted objects) and true bits: allowTransfer × 688, allowExport × 212, allowEdit × 42, allowDelete × 18.
• The head adds ZERO over-granted cells in any subject. The three pre-existing over-grant sets are the same cells at base and head.

Public door on a booted showcase. bootStack(showcase) in its default composition, with the seeded platform admin (positions platform_admin, everyone; sets showcase_member_default + admin_full_access + member_default). The answer read is the response bytes of GET /auth/me/permissions itself. The comparison covers 78 registered objects × 10 verbs against checkObjectPermission over the same resolved sets.

	base	head
under	78 (all transfer)	0
over	0	0
entries / objects bytes	81 / 16695	81 / 17385
showcase_account	allowTransfer: false, can(…, 'transfer') false; server true	allowTransfer: true, can() true

That is the card's 63 fixture cells and 78 showcase cells, reproduced exactly.

The base leg of this table and of the write-path table is this head with both changes ablated and core's dist/ rebuilt. On the fixture, that leg's maps are byte-identical (sha256) to true base a08e059c61's, with the same under and over counts, in all 23 subjects.

Write path. The real ObjectQL engine, with the real SecurityPlugin member registered as its resolver. crm_case.stage has options gated on current_user.can('crm_account', …), and a boolean field has CEL defaultValue current_user.can('crm_account', 'transfer').

subject	option transfer	option edit	option read	defaultValue
admin_full_access + member_default	refused VALIDATION_FAILED/invalid_option → admitted	admitted → admitted	admitted → admitted	false → true
walled organization_admin + member_default	refused → admitted	admitted → admitted	admitted → admitted	false → true
'*': { viewAllRecords, allowEdit }	refused → refused (server refuses)	refused → admitted	admitted → admitted	false → false
'*': admin bits + allowExport	refused → admitted	refused → admitted	refused → admitted	— → true
member_default	refused → refused	refused → refused	refused → refused	—
organization_admin_no_bypass + member_default	refused → refused	admitted → admitted	admitted → admitted	false → false
viewer_readonly + member_default	refused → refused	refused → refused	admitted → admitted	false → false

Every head cell agrees with checkObjectPermission, and every control cell is unchanged.

The #18990 ruling and the seed's skip

The pins this PR inverts in plugin-hono-server's effective-api-operations.test.ts quote the #18990 ruling (batch #159 item 1, letter A). The ruling's headline is 「/auth/me/permissions owes every object a principal can reach an explicit entry」. The carve-out the pins quote, 「skip only an unrestricted object whose export stays allowed」, is written about annotateEffectiveApiOperations attaching apiOperations.

This PR keeps that carve-out exactly. An entry seeded for an unrestricted, export-allowed object carries no apiOperations, and annotateEffectiveApiOperations is untouched. What changes is that the entry now exists, which is the ruling's headline. current_user.can() reads the entry and reads an absent one as 「no grant」, a reader the ruling predates.

Ruled: Q2 → A (seat amendment 5831894689 on #20134). The #18990 ruling line (5729478681), quoted verbatim:

Ruling: batch #159 item 1 · letter A (/auth/me/permissions owes every object a principal can reach an explicit entry: the seed runs for a wildcard-only viewAllRecords principal too — allowRead folded true, the write bits false, apiOperations annotated by the same predicate as #18931; PR #18984's toBeUndefined pin flips on purpose) · maintainer 「同意」 2026-09-18T11:42Z

The entry is owed. The #18931 skip predicate governs the apiOperations annotation, which this PR keeps byte-identical (0 apiOperations lost or gained across 23 subjects). Seeding the entry for an unrestricted, export-allowed object therefore carries out the ruling's letter; it does not reopen it. The three effective-api-operations.test.ts seed pins that quoted the annotate skip as a seed skip are inverted on purpose, and the amendment adds that file to the claimed surface.

Known divergence, pre-registered and unchanged (#20136)

The fold is broader than the evaluator in two places. Both are OVER-grants and belong to #20136, the family's over-grant card, which remains open. This PR leaves both byte-identical.

• The merged bypass folded into an entry the super-user set itself names narrower. On the 63-object fixture this is the walled organization_admin's 38 cells (create, edit, delete and import on its five read-only RBAC objects, and edit on sys_organization). A one-set authored shape shows 7.
• allowCreate pulled on modifyAllRecords alone. The spec's objectPermissionGrants gives this no create cell. A bare '*': { modifyAllRecords: true } shows 36 create/import cells. No shipped set has this shape, since both shipped super-user wildcards carry allowCreate: true. This second location is not in security: the effective permission map folds a super-user '*' over the same set's narrower explicit entries — a walled org admin gets can('sys_position','edit') true where enforcement refuses #20136's body. The seat has routed it to security: the effective permission map folds a super-user '*' over the same set's narrower explicit entries — a walled org admin gets can('sys_position','edit') true where enforcement refuses #20136's enumeration (amendment 5831894689).

KNOWN_OVER_GRANT in the parity pin lists both, cell for cell, and the pin asserts the observed set EXACTLY. That is the flip trigger: when #20136 lands, those rows go red and their entries are deleted, never widened.

For domain:cli (the route) and domain:services (plugin-security)

No code in plugin-hono-server or plugin-security changes, only their pins. What their readers see:

• GET /auth/me/permissions → objects. For a subject holding a super-user wildcard, entries gain true bits (allowTransfer, and the wildcard's own plain and export bits). Where that subject's wildcards also grant allowExport, the map gains an entry for each registered unrestricted object that had none, and that entry carries no apiOperations. Nothing is removed, and no apiOperations list changes. Shape, keys and route are unchanged.
• ISecurityService.getEffectiveObjectPermissions. The same map, since it is the same function. On the write path, a can()-gated option or defaultValue is admitted for these subjects wherever the server grants.
• Byte-identical for every subject holding no super-user wildcard (the plain-wildcard and member rows above).

There is no non-test requester of /auth/me/permissions in this repo. objectui's can() is UNMEASURED: the sibling repo is not in this container.

Clause-②

• The behavioural accept set widens. can() answers widen to match enforcement, and a can()-gated write for these subjects is now admitted. Nothing narrows (see the entry-level diff above), so @objectstack/core is minor, following the security: the effective object-permission map omits objects covered only by a plain '*' grant, so current_user.can() answers false where enforcement answers true (wall-less org admins) #20083 and [finding] nothing on the server side populates EvalContext.permissions, so can is bound but unwalked in-repo — the nearest call site needs an ISecurityService addition the #18545 ruling does not decide #18783 precedents.
• Public type: no exported name or type changes.
• check-changeset-no-major --base origin/main and check-adr-0087-registration --base origin/main both exit 0.

DELIBERATE CORRECTION: three pending changesets

Each correction changes ONE clause or bullet of a pending release note that this PR makes false or inexact, following the #20083 precedent. Every other line of each file is byte-identical.

• Q1 → A (seat amendment 5831894689 on core: effective-map super-user entries never carry transfer (or a super-read wildcard's plain bits) — current_user.can(obj, 'transfer') is false for admin_full_access where enforcement answers true via modifyAllRecords #20134) covers the [finding] nothing on the server side populates EvalContext.permissions, so can is bound but unwalked in-repo — the nearest call site needs an ISecurityService addition the #18545 ruling does not decide #18783 clause.
• The contract review FAIL 5832348775 (prose only) names the finding(plugin-hono-server): /auth/me/permissions never seeds an unrestricted object for a wildcard-only principal, so the Console renders Export where the server answers 403 EXPORT_NOT_PERMITTED #18931 and [finding] /auth/me/permissions is silent for a wildcard-only viewAllRecords principal too — the class #18931 fixed only for modifyAllRecords #18990 bullets, and seat amendment 2 (5832355884) rules them corrected in this PR.

1. .changeset/18783-server-can-option-visibility.md, line 37 (one clause)

The pending current_user.can() write-path changeset ends its Plain-wildcard coverage, closed in this release. paragraph (the paragraph #20132 corrected) with a clause this PR makes FALSE.

• Before: 「The map still differs from PermissionEvaluator.checkObjectPermission for subjects holding a super-user wildcard: an entry the super-user set itself names narrower can read as granted, and an entry reached through a super-user wildcard carries no transfer.」
• After: 「The map still differs from PermissionEvaluator.checkObjectPermission for subjects holding a super-user wildcard: an entry the super-user set itself names narrower can read as granted. Its missing transfer is closed in this same release (.changeset/20134-super-user-entries-every-bit.md).」

Byte identity. git diff --numstat gives 1 1 on the file, 39 lines before and after. With line 37 removed, the before and after files are identical (diff exit 0). Line 37 is identical up to and including 「…names narrower can read as granted」, and only its tail changes. The blob goes from f357292a to 29a6ba2e.

The new sentences are TRUE at this head (c63f61522c; its code and test blobs are identical to 071e3f49fb, where the measurements above were taken):

• 「an entry the super-user set itself names narrower can read as granted」 holds. These are security: the effective permission map folds a super-user '*' over the same set's narrower explicit entries — a walled org admin gets can('sys_position','edit') true where enforcement refuses #20136's cells: 38 for the walled organization_admin on the 63-object fixture, and 7 for the one-set authored shape. Both are byte-identical at base and head and pre-registered in KNOWN_OVER_GRANT.
• 「Its missing transfer is closed in this same release」 holds. transfer under-grants are 0 in every super-user row of the fixture table and 78 → 0 on the booted showcase.
• The create-on-modifyAllRecords-alone cells are not named there, and do not need to be. The sentence does not claim to list every divergence. That over-grant is disclosed in this release's own .changeset/20134-super-user-entries-every-bit.md (「Still broader than the server, unchanged here」), and no shipped set has the shape. Naming it in the [finding] nothing on the server side populates EvalContext.permissions, so can is bound but unwalked in-repo — the nearest call site needs an ISecurityService addition the #18545 ruling does not decide #18783 entry would widen the correction beyond the one clause Q1 authorizes.

2. .changeset/18931-me-permissions-unrestricted-export-annotation.md, line 13 (one bullet)

• Before: 「The seed now applies annotate's own predicate: resolve with the export slot annotate will read for the entry being seeded, and skip only an object that is unrestricted and keeps export. A seeded entry carries no allowExport of its own and foldWildcardSuperUser does not add one, so annotate's acc.allowExport ?? wildExport resolves to the same wildcard bit the seed read — the two passes cannot diverge again.」
• After: 「The seed and annotate cannot diverge again. Since core: effective-map super-user entries never carry transfer (or a super-read wildcard's plain bits) — current_user.can(obj, 'transfer') is false for admin_full_access where enforcement answers true via modifyAllRecords #20134 the seed places an entry for every registered object a super-user wildcard reaches that the merge left without one, and annotateEffectiveApiOperations alone decides which entries carry apiOperations: an object that is unrestricted and keeps export gets none.」

Why the old bullet is FALSE at this head. The seed skips no registered object for a super-user wildcard any more. Also, the per-set super-user fold puts allowExport on a seeded entry whenever a set's super-user wildcard grants it, so 「a seeded entry carries no allowExport of its own」 no longer holds.

Why the new bullet is TRUE.

• seedSuperUserRestrictedObjects gives an entry to every registered object the merged map lacks, whenever the merged '*' carries a super-user bit. That is what 「…that the merge left without one」 says. The seat's suggested text read 「places an entry for every registered object a super-user wildcard reaches」; an object the merge already carries keeps its own entry, so the clause is narrowed to what the seed actually writes.
• annotateEffectiveApiOperations is untouched, and it is the only pass that writes apiOperations. It skips exactly an object that is unrestricted and whose export bit is true.
• Measured: 0 apiOperations lost or gained across 23 fixture subjects and on the booted showcase.

Byte identity. git diff --numstat gives 1 1, 16 lines before and after. With line 13 removed, the files are identical (diff exit 0). The blob goes from 38bfb50f to 6eac3716.

3. .changeset/18990-viewall-only-permissions-seed.md, line 12 (one bullet)

• Before: 「apiOperations is attached through the predicate already shared with the modify-all class — an unrestricted object whose export stays allowed is still skipped, because for it the client's default-allow path is already right.」
• After: 「apiOperations is attached through the predicate already shared with the modify-all class — an unrestricted object whose export stays allowed still gets no apiOperations (the entry itself is seeded since core: effective-map super-user entries never carry transfer (or a super-read wildcard's plain bits) — current_user.can(obj, 'transfer') is false for admin_full_access where enforcement answers true via modifyAllRecords #20134), because for it the client's default-allow path is already right.」

Why. 「is still skipped」 was true of apiOperations and is false of the entry, which the seed now places. The corrected text states both halves. The ruling's carve-out governs apiOperations only, which this PR keeps byte-identical.

Byte identity. git diff --numstat gives 1 1, 14 lines before and after. With line 12 removed, the files are identical (diff exit 0). The blob goes from 3ed4a3fe to 261e412f.

Check Changeset stays red on this PR by design. check-empty-changeset names exactly these three files, because it treats an edit to another card's pending changeset as a foreign-changeset edit. pr-automation.yml runs it on pull_request only, never on merge_group, as with #20083. Three named files add no new class of red.

Changeset gates at c63f61522c, run against merge base a08e059c61. check-changeset-no-major read this body as its --event payload.

$ node scripts/check-empty-changeset.mjs --base a08e059c61                 -> exit 1 (expected)
✓ No empty-frontmatter changeset introduced by this diff (4 declaring changeset(s) added).
This PR changes a changeset it did not add:
   .changeset/18783-server-can-option-visibility.md
     present on the merge base and CHANGED by this PR -- this is somebody else's release note
   .changeset/18931-me-permissions-unrestricted-export-annotation.md
     present on the merge base and CHANGED by this PR -- this is somebody else's release note
   .changeset/18990-viewall-only-permissions-seed.md
     present on the merge base and CHANGED by this PR -- this is somebody else's release note

$ node scripts/check-changeset-no-major.mjs --base a08e059c61 --event (this body)   -> exit 0
✓ This diff introduces no `major` bump.
✓ LEVEL AXIS: this PR declares clause-② `yes (widening)`, and no package whose `packages/**/src/**` it moves is graded `patch`.

$ node scripts/check-adr-0087-registration.mjs --base a08e059c61          -> exit 0
✓ check-adr-0087-registration: this PR adds no declared-breaking changeset (4 non-breaking changeset(s) seen).

$ node scripts/check-issue-citations.mjs --base a08e059c61                -> exit 0
citations judged: 11 across 1 file(s)
✅ check-issue-citations: every citation this change adds resolves (or is a declared cross-repo reference).

Tests

All at 071e3f49fb, dist/ of the closure rebuilt, each run under the shared verify lock. The head is now c63f61522c, which adds only the three changeset corrections above; every code and test blob is identical to 071e3f49fb:

• pnpm --filter @objectstack/core test: 53 files / 1346 passed. typecheck exit 0 (check:test-typecheck OK, 4 pinned signatures held).
• pnpm --filter @objectstack/plugin-security test: 135 files / 2697 passed. typecheck exit 0.
• pnpm --filter @objectstack/plugin-hono-server test: 27 files / 317 passed. typecheck exit 0.
• Access-security dogfood (the 11 files the checklist area names, plus every dogfood file reading the effective map or current_user.can, plus security: the effective object-permission map omits objects covered only by a plain '*' grant, so current_user.can() answers false where enforcement answers true (wall-less org admins) #20083's permission set): 18 files / 261 passed, 1 skipped.
  • shared-showcase: showcase-anonymous-deny-surfaces, showcase-permission-zoo, showcase-private-owd, two-doors-permission: 4 / 66.
  • isolated: me-apps-and-everyone-baseline, owner-anchor-and-bulk-writes, showcase-client-liaison-fixtures, showcase-crud-persona-matrix, showcase-fls-read-mask-strip, showcase-scope-depth-fallback, showcase-scope-depth-write, showcase-scope-depth, organization-update-door, showcase-permission-projection, showcase-permission-seeding, comments-permission-matrix, attachments-permission-matrix, authz-conformance: 14 / 195 + 1 skipped.

New and changed pins:

• plugin-security get-effective-object-permissions.test.ts: the security: the effective object-permission map omits objects covered only by a plain '*' grant, so current_user.can() answers false where enforcement answers true (wall-less org admins) #20083 parity table gains 9 super-user rows, plus 2 spelled-out cases and a registration-integrity case (31 tests).
• core effective-object-permissions.test.ts: a 5-case [#20134] battery, and one updated key-order assertion (20 tests).
• plugin-hono-server: 3 seed pins inverted, and 2 route assertions added.

Ablation, from the committed head through scripts/ablation-replace.mjs, two nested WRAP legs:

• The per-set call was replaced by a runtime marker: anchor 1 → 0, blob 0955a452 → c8367daf.
• The seed's old skip was re-inserted with its own marker: anchor 1 → 0, blob c8367daf → eb95e485.
• ablation-dist-preflight found both markers in 2 core dist/ files.
• Observed direction: red.
  • plugin-security 11 failed / 20 passed: every super-user row and both spelled-out cases. The 7 plain rows stayed green.
  • core 6 failed / 14 passed.
  • hono 4 failed / 36 passed.
• Restore: blob == HEAD and git diff HEAD empty on both legs. After the rebuild, --absent passes for both markers over 14 dist files, the whole tree is clean, and the pins are green again (31 / 20 / 40).
• The first attempt was refused by the tool before any command ran: the inner replacement contained its own anchor. Nothing was measured on it, and both legs restored and proved clean.

Gates. node scripts/pm/dispatch-gates.mjs --commands --repo objectstack-ai/objectstack (no paths) derives 64 commands at 071e3f49fb; all 64 exit 0.

• pnpm check:dual-build-cjs-loads first answered PREREQUISITE NOT MET (exit 3), because 8 unrelated packages had no dist/. That was NOT MEASURED, not red. After building them it exits 0 (105 entries / 67 packages / 660 CJS files).
• --ran reads 64 derived, 64 run, 0 NOT-MEASURED, 0 UNRUN.
• node scripts/check-issue-citations.mjs --base a08e059c61 exits 0, with 11 citations resolving.
• Lint, as a proven narrowing at 071e3f49fb:
  1. eslint's own config admits all 5 changed .ts files (isPathIgnored false).
  2. --format json counts 5 files, 0 errors, 0 warnings.
  3. The config never enables type-aware linting (no parserOptions.project, no typed rules), so this diff cannot move any untouched file's verdict.
     The repo-wide pnpm lint is CI's.

Acceptance notes

• The three pending release notes this PR made false or inexact (18783, 18931, 18990) are corrected here, one clause or bullet each (see DELIBERATE CORRECTION above).
• transfer on guarded managed objects. The managed-write clamp narrows create, edit and delete, not transfer. The map therefore answers transfer as checkObjectPermission does on a guarded object too. The 63-object fixture registry holds 45 guarded objects: 44 from @objectstack/platform-objects, plus plugin-security's engine-owned sys_audience_binding_suggestion. An earlier count of 44 read the platform objects alone. Of the 45, only sys_metadata has an owner field. Whether its engine-owned guard refuses the owner update that a transfer rides is UNMEASURED here.
• Branch base. The branch sits on a08e059c61. origin/main has moved one commit since (f09d4122bc, driver-sql / driver-turso only), which touches none of this diff's packages.

[github-actions]

📓 Docs Drift Check

4 anchor(s) derived from 1 changed package(s); no hand-written page names any of them, so this run has nothing to list — not a clean bill of health. This check sees only pages that NAME a derived anchor: one that documents this change in prose, or enumerates it in an authoring dialect, names none and stays invisible to it on every run.

What this run could not see

• the SDK route bridge reached 60 of 215 client-bound route-ledger rows — the other 155 have no registrar path: tail to select them, so pages documenting THEIR client methods cannot appear above, on this or any run. Of those 155: 0 are remediable by widening that discovery convention (an in-repo file declares the path; the convention did not scan it); 55 are structural — on a ledger where NOT ONE row is declared in-repo, so no discovery change reaches them at any price; 100 are undecided (no in-repo declaration, on a ledger that has other in-repo registrars — absence and an unreadable spelling are not distinguishable here). The rows themselves: node scripts/docs-audit/affected-docs.mjs --bridge-coverage
• a page that states a rule by its inputs shares no identifier with the emitter that implements the rule, so an emitter-only diff cannot list it — not on this run and not on any run. Measured on fix(driver-sql): emit varchar(maxLength) for a text field a declared index keys on #11430: content/docs/protocol/objectql/types.mdx documents the text-family column mapping by the ObjectQL type names it maps FROM (text / textarea / html) while the diff changed createColumn; it went unlisted, and it was the page that diff falsified, in four places. No shared token exists to detect this on, so a rule your change carries has to be re-read by hand in the pages that restate it.
• a key NAME is not a key, so the hand re-read the line above prescribes can land on the wrong schema. The same spelling is authorable on one governed type and a [REMOVED] tombstone on another for each of active, aria, joins, objects, template, tools and version (censused on [finding] tools is a key on BOTH AgentSchema (tombstoned, dead) and SkillSchema (live, cloud-attested), so a name-based search attributes skill examples to the agent key — it produced a false stop-the-line alarm on PR #19059 #19093 over the liveness ledger's governed types, top-level keys); nothing in a search result distinguishes the two, so a grep hit on a LIVE example reads as evidence about the DEAD key. Measured on fix(spec): the agent.tools liveness row says dead — it claimed live on a key the schema tombstoned #19059: content/docs/ai/agents.mdx was reported as contradicting the agent.tools tombstone over its tools: example at :161, which is inside the defineSkill({ block opened at :155 — the page was already correct. Settle ownership by PARSING the value against both schemas, never by the name: that literal PASSES SkillSchema, and as an AgentSchema it FAILS at tools with the tombstone prescription. ⛔ These names are not the whole class — a key retired through a .strict() guidance map leaves no tombstone in the walked shape and none of them here (tool.category, live as AIToolDefinition.category).

Coarse fallback — 24 page(s) merely mention a changed package (the pre-#9192 predicate, kept for the deliberately-wide backstop): node scripts/docs-audit/affected-docs.mjs --json 949e99bed9352d49a82aa186fffef86468a9d533 → packageMentionDocs.

Which tree this was computed on

This run read content/docs from d6de03d7a23dc84119e30513a657f8faeaab7665 — the merge of head c63f61522c274bc29fb8dc9fb330fd5bc517fe88 into base 949e99bed9352d49a82aa186fffef86468a9d533, which is what actions/checkout gives a pull_request run. Not the PR head.

A worktree cut from an older main holds a different content/docs, so re-deriving there can legitimately return a different list — that is a different tree, not a wrong row. To answer on the same tree:

# while this PR is open — GitHub drops the merge commit once it closes
git fetch origin d6de03d7a23dc84119e30513a657f8faeaab7665 && git checkout d6de03d7a23dc84119e30513a657f8faeaab7665
# afterwards, rebuild it from the two parents, which stay fetchable
git fetch origin 949e99bed9352d49a82aa186fffef86468a9d533 c63f61522c274bc29fb8dc9fb330fd5bc517fe88 && git checkout -B drift-repro 949e99bed9352d49a82aa186fffef86468a9d533 && git merge --no-ff c63f61522c274bc29fb8dc9fb330fd5bc517fe88

node scripts/docs-audit/affected-docs.mjs --json 949e99bed9352d49a82aa186fffef86468a9d533

⚠️ That checkout carried uncommitted changes, so the commit above does not fully identify what was read.

[objectstack-fleet]

Contract review

Served-tier: CONTRACT_REVIEW_TIER
Head-sha: d1d1203a55445b15414bfa84c31bcfbf559aaed1

Scope: 7 files (+368/−55) on merge base a08e059c61:

• packages/core/src/security/effective-object-permissions.ts, the only non-test source;
• its test, plus plugin-security's get-effective-object-permissions.test.ts and plugin-hono-server's effective-api-operations.test.ts and current-user-endpoints-effective-objects.test.ts;
• the new .changeset/20134-super-user-entries-every-bit.md;
• a one-line DELIBERATE CORRECTION of .changeset/18783-server-can-option-visibility.md.

No governed surface and no packages/spec/src is touched. Measured in detached worktrees at head and base, each with its closure built.

① Derived judgments

• Parity, map against enforcement, on the reviewer's own 32 subjects × 63 registered objects × 10 verbs. The map answer is formula can() over toEvalPermissions(buildEffectiveObjectPermissions(...)), and the enforcement answer is checkObjectPermission. Under-granted and over-granted, base → head:
  • admin_full_access, alone and in three combinations: 63 → 0 / 0 → 0.
  • walled organization_admin + member_default: 30 → 0 / 38 → 38, the SAME cells (security: the effective permission map folds a super-user '*' over the same set's narrower explicit entries — a walled org admin gets can('sys_position','edit') true where enforcement refuses #20136). Alone: 30 → 0 / 44 → 44, the same cells.
  • '*': { modifyAllRecords } alone: 63 → 0 / 36 → 36, the same cells (create / import).
  • The '*' admin bits + allowExport shape: 214 → 0 / 0, and 206 → 0 with member_default.
  • super-read plus plain bits: 54 → 0 and 153 → 0. Mixed super and plain shapes: 136 / 161 / 71 → 0.
  • ONE set holding a super '*' AND a narrower explicit entry: 62 → 0 / 7 → 7, the same cells.
  • Every control (member_default, the wall-less org admin, viewer_readonly, the four security: the effective object-permission map omits objects covered only by a plain '*' grant, so current_user.can() answers false where enforcement answers true (wall-less org admins) #20083 plain-wildcard shapes, no sets) is 0 / 0, with byte-identical maps (sha256).
  • The head adds ZERO over-granted cells in any subject. Every pre-existing over-granted set is the identical cell set at base and head.
  • Entry-level diff: 0 entries removed, 0 bits flipped from true to false, and 0 apiOperations lost, gained or changed.
  • KNOWN_OVER_GRANT is exact both ways, so the flip trigger is exact and not green-washed.
• The seed change (Q2): it carries out [finding] /auth/me/permissions is silent for a wildcard-only viewAllRecords principal too — the class #18931 fixed only for modifyAllRecords #18990's headline ("owes every object a principal can reach an explicit entry"). annotateEffectiveApiOperations is byte-identical, and apiOperations changes in 0 cells across 32 subjects and the showcase. The three inverted hono pins pinned the SEED's skip.
• Public door (bootStack(showcase), the seeded platform admin, 78 objects × 10 verbs):
  • under-granted 78 (all transfer) → 0, over-granted 0 → 0;
  • showcase_account.allowTransfer false → true;
  • 0 entries removed and 0 apiOperations change.
• Write path (a real engine with the real SecurityPlugin):
  • a can('crm_account','transfer')-gated option is refused → admitted for admin_full_access and for the walled org admin, and the CEL default goes false → true;
  • the controls are unchanged, and every head admission agrees with checkObjectPermission.
• The pins discriminate. Under the nested ablation: plugin-security 11 failed / 20 passed, core 6 / 14, hono 4 failed over 3 files. Restored by blob.
• Scope: the bodies of annotateEffectiveApiOperations, foldWildcardSuperUser and clampManagedObjectWrites are byte-identical. There is 0 non-test change outside core's producer. merge-tree against 949e99bed9 is clean.
• Changeset 20134-*: no FALSE sentence. The built index.d.ts export list is identical. PR body: inexact, not false: "44 guarded objects" reads 45 on the equivalent registry.
• CI at this head: 41 runs: 34 success, 5 skipped, 2 failure, 0 pending. All seven required contexts are success. Both failures are Check Changeset, naming only the [finding] nothing on the server side populates EvalContext.permissions, so can is bound but unwalked in-repo — the nearest call site needs an ISecurityService addition the #18545 ruling does not decide #18783 file: the expected red.

② Semver level

Clause-②: yes (widening), @objectstack/core minor: RIGHT.

• The map answers widen to match enforcement, and can()-gated writes are admitted.
• There is no new export or type member, and nothing narrows.
• check-changeset-no-major --event <PR body>: "✓ This diff introduces no major bump." and "✓ LEVEL AXIS: … yes (widening) …" (exit 0).
• check-adr-0087-registration: "✓ … no declared-breaking changeset (2 non-breaking changeset(s) seen)." (exit 0).

③ Boundary flags

• DELIBERATE CORRECTION confirmed on d1d1203a55: .changeset/18783-server-can-option-visibility.md, line 37 only; the other 38 lines are byte-identical.
  • The base clause's transfer half ("… and an entry reached through a super-user wildcard carries no transfer.") is FALSE at head.
  • The head sentences ("… names narrower can read as granted." and "Its missing transfer is closed in this same release …") are TRUE at head.
• Two more pending release notes are made FALSE or misleading by this head and are NOT corrected:
  • .changeset/18931-me-permissions-unrestricted-export-annotation.md line 13: "The seed now applies annotate's own predicate … skip only an object that is unrestricted and keeps export. A seeded entry carries no allowExport of its own and foldWildcardSuperUser does not add one …". This is FALSE at head: the seed skips no registered object, and the per-set step puts allowExport on seeded entries.
  • .changeset/18990-viewall-only-permissions-seed.md line 12: "an unrestricted object whose export stays allowed is still skipped". This is true of apiOperations and false of the entry, which is now seeded.
• Out-of-scope findings for security: the effective permission map folds a super-user '*' over the same set's narrower explicit entries — a walled org admin gets can('sys_position','edit') true where enforcement refuses #20136's enumeration, the same at both trees:
  • a walled organization_admin WITHOUT member_default over-grants 44 cells (also edit on sys_user and sys_api_key);
  • an EMPTY explicit entry {} inside a super-user set over-grants read as well (8 cells).

Implemented-by: claude/issue-20134-super-user-seed-bits
Reviewed-by: session_01Bvd69VPa6puiNzzPUroDBx

VERDICT: FAIL

Must-change (prose only; every code and test judgment above PASSES and needs no re-measurement on a head that changes .changeset/* only):

1. A DELIBERATE CORRECTION of .changeset/18931-me-permissions-unrestricted-export-annotation.md line 13, one bullet, every other line byte-identical.
2. The same for .changeset/18990-viewall-only-permissions-seed.md line 12: narrow "is still skipped" to the apiOperations statement.
3. (nit) PR body: "44 guarded objects" → 45.

[objectstack-fleet]

Contract review

Served-tier: CONTRACT_REVIEW_TIER
Head-sha: c63f61522c274bc29fb8dc9fb330fd5bc517fe88

Scope: a DELTA review. It supersedes FAIL 5832348775 (on d1d1203a55). Two prose-only commits (b60ed0d00f, c63f61522c) sit on d1d1203a55, and the PR body was edited.

① Derived judgments

• Blob identity, measured by the reviewer: git diff --stat d1d1203a55 c63f61522c touches exactly .changeset/18931-* and .changeset/18990-*, 1 line each. Every code and test blob, and the 20134-* and 18783-* changesets, are identical. Every reading of 5832348775 therefore stands for this head:
  • parity over 32 subjects;
  • the showcase door, 78 → 0;
  • the write path;
  • the ablation, 11/20, 6/14 and 4/31;
  • the .d.ts surface and the scope.
• The dev's wording departure on 18931 is CORRECT and more exact. The added words are "… that the merge left without one". The seed writes only where objects[name] is absent, so an object the merge already carries keeps its own entry.
• Gates:
  • check-empty-changeset exits 1 as expected, naming exactly the three corrected files.
  • check-changeset-no-major --event <new body> exits 0: "✓ This diff introduces no major bump." and "✓ LEVEL AXIS: … yes (widening) …".
  • check-adr-0087-registration exits 0.
• merge-tree against origin/main 949e99bed9 is clean.
• CI at this head: 41 runs, 34 success, 5 skipped, 2 failure, 0 pending. All seven required contexts are success. Both failures are Check Changeset, naming exactly the three corrected files: the expected red.
• PR body: no NEW false sentence, and the "45 guarded objects" nit is fixed. There is one stale bookkeeping line ("origin/main has moved one commit"; it is now two). It is non-blocking.

② Semver level

Clause-②: yes (widening), @objectstack/core minor: RIGHT, unchanged from 5832348775.

③ Boundary flags

DELIBERATE CORRECTION confirmed on c63f61522c, for three pending release notes. Each changes one clause or bullet, and every other line is byte-identical.

1. .changeset/18783-server-can-option-visibility.md line 37.
   • Base: "… and an entry reached through a super-user wildcard carries no transfer." FALSE at head.
   • Head: "… names narrower can read as granted." and "Its missing transfer is closed in this same release …". TRUE at head.
2. .changeset/18931-me-permissions-unrestricted-export-annotation.md line 13.
   • Base: "The seed now applies annotate's own predicate … skip only an object that is unrestricted and keeps export. A seeded entry carries no allowExport of its own …". FALSE at head.
   • Head: "The seed and annotate cannot diverge again. Since core: effective-map super-user entries never carry transfer (or a super-read wildcard's plain bits) — current_user.can(obj, 'transfer') is false for admin_full_access where enforcement answers true via modifyAllRecords #20134 the seed places an entry for every registered object a super-user wildcard reaches that the merge left without one, and annotateEffectiveApiOperations alone decides which entries carry apiOperations: an object that is unrestricted and keeps export gets none." TRUE at head.
3. .changeset/18990-viewall-only-permissions-seed.md line 12.
   • Base: "… is still skipped …". Misleading at head.
   • Head: "… still gets no apiOperations (the entry itself is seeded since core: effective-map super-user entries never carry transfer (or a super-read wildcard's plain bits) — current_user.can(obj, 'transfer') is false for admin_full_access where enforcement answers true via modifyAllRecords #20134) …". TRUE at head: 53 → 64 entries, and 0 of the new entries carry apiOperations.

Q1 → A, Q2 → A and amendment 2 are carried out as ruled. The out-of-scope rows stand for #20136's enumeration (pointers 5831899863 and 5832366012) and for #20135 (5831905897).

Implemented-by: claude/issue-20134-super-user-seed-bits
Reviewed-by: session_01Bvd69VPa6puiNzzPUroDBx

VERDICT: PASS