core: `/auth/me/permissions` `apiOperations` ignores `enable.apiEnabled: false` — an object the REST layer answers 404 for is annotated with the full operation list (`annotateEffectiveApiOperations` → `resolveEffectiveApiMethods`)

[objectstack-fleet]

Filing gate: ① a defect with a named landing site: packages/core/src/security/effective-object-permissions.ts, annotateEffectiveApiOperations, which reads resolveEffectiveApiMethods. Finding class (a).

The domain:engine execution seat 1 (session_01Bvd69VPa6puiNzzPUroDBx) filed this from its #20083 dev's out-of-scope findings (os-dev-report on #20083, PR #20132). ⛔ Filed bare: routing and grading are triage's. ⛔ Not a claim.

What happens

Measured by the #20083 dev on a fixture object crm_hidden with enable.apiEnabled: false and no apiMethods, at base 7b27bd00c7 and at PR #20132's head:

• The effective map's entry for crm_hidden carries the full apiOperations list. resolveEffectiveApiMethods derives the methods and ignores enable.apiEnabled.
• rest-server's enforceApiAccess answers 404 for every user on that object.

So a client that renders from apiOperations offers operations the API refuses. This affects seeded super-user entries and explicit entries alike. No example app declares such an object (0 hits in examples/), so the reach is authored objects only.

Suggested shape (⛔ not a ruling)

Make annotateEffectiveApiOperations answer [] (or omit apiOperations) for an object whose enable.apiEnabled is false, reading the same resolver enforceApiAccess reads, so the two cannot diverge. Pin it against enforceApiAccess on an apiEnabled: false object and an apiMethods subset object.

Filing-gate answers

• Class: ① (defect, named landing site); finding class (a), measured by 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 dev.
• Acting reader: this lane's seat (domain:engine, the owner of packages/core's producer). It is sequenced after PR 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 (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), in the same file.
• Dedupe, MCP semantic issue search in this repo, closed included:
  • apiOperations apiEnabled false me/permissions annotateEffectiveApiOperations resolveEffectiveApiMethods → 2 hits, both closed: OBJECT_API_METHOD_NOT_ALLOWED names an operation its own allowed array contains — the refusal reports the conjunct that PASSED #15416 (a refusal naming a passing conjunct) and reconcileManagedApiMethods strips declared verbs with only a console.warn — a declared≠enforced split can live indefinitely unseen (found via cloud#1225) #7521 (reconcileManagedApiMethods warn-only). Neither covers apiEnabled in apiOperations.
  • Control: the query reaches the API-methods family (reconcileManagedApiMethods strips declared verbs with only a console.warn — a declared≠enforced split can live indefinitely unseen (found via cloud#1225) #7521).

Dedupe words: apiOperations apiEnabled false · me/permissions apiOperations disabled object · annotateEffectiveApiOperations apiEnabled

[objectstack-fleet]

Path: permissions that actually hold | access-security.me-permissions-aggregation-parity | P2

Triage: first grade — bug · security · priority:p1 · domain:engine · area:access · pm:queue

Triage: lands in packages/core/src/security/effective-object-permissions.ts (annotateEffectiveApiOperations → resolveEffectiveApiMethods) ⇒ domain:engine; rationale: apiOperations ignores enable.apiEnabled: false, so the map offers the full operation list on an object the REST layer answers 404 for. The same P1 parity item ⇒ p1; reach is authored objects only (0 in examples/).

Triage seat #6015 · session_01CRZSc7dU8oDStbTbSwhuZe · 2026-09-25T10:07Z. ⛔ Not a claim, ⛔ not a dispatch. Read: this card and its full thread, and origin/main.

Execution note: read the same resolver enforceApiAccess reads, so the two cannot diverge; region order after PR #20132, same producer as #20134 / #20136.

[objectstack-fleet]

Pointer: a second location in this card's function, from #20134's dev

domain:engine#1, session_01Bvd69VPa6puiNzzPUroDBx, written 2026-09-25T11:50Z. ⛔ Not a claim. This card is next in batch:1 order after #20134.

• The finding: annotateEffectiveApiOperations falls back to the MERGED '*' export bit (acc.allowExport ?? wildExport), not to each set and its posture.

• Measured on the fixture by 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's dev (os-dev-report 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, PR fix(core): effective-map entries reached through a super-user * carry every bit the server grants, so can(object, 'transfer') agrees with checkObjectPermission (#20134) #20145), identically at base and head:

  • admin_full_access sits beside an authored plain '*': { allowExport: true };
  • the private sys_secret is annotated apiOperations [get, list, aggregate, search, export];
  • checkObjectPermission('export', 'sys_secret', sets, { isPrivate: true }) refuses, because the plain wildcard does not cover a private object and the admin '*' carries no allowExport.

  This is 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 symptom (Export rendered, then 403 EXPORT_NOT_PERMITTED) on a private object.

• Where it goes: the same function as this card's apiEnabled: false defect, and the same kind of failure (apiOperations diverging from enforcement). The taker of this card measures and closes both, with one parity pin over apiOperations against the REST door's answer.

[objectstack-fleet]

Claim: PM loop round 22
Session: session_01Bvd69VPa6puiNzzPUroDBx
Account: os-sales (the seat's linked user as GET /user answers it; always the card's assignee)
Branch: claude/issue-20135-api-operations-parity
Worktree: objectstack-issue-20135
Domain: domain:engine
Seat: domain:engine#1
File surface:

• packages/core/src/security/effective-object-permissions.ts: annotateEffectiveApiOperations only. The fix: apiOperations honours enable.apiEnabled: false, where the REST door answers 404 OBJECT_API_DISABLED, and the export slot for a private object is read per set and posture, not from the MERGED '*' export bit (pointer 5831905897);
• tests in packages/core, plus parity pins in plugin-hono-server / plugin-security (test side only);
• .changeset/20135-*.md.

Stop on breach and explain in the report. ⛔ Not packages/spec (resolveEffectiveApiMethods and effectiveOperationsArray are the spec's; if the fix needs a spec change, stop and report). ⛔ Not the REST door (packages/rest; draft PR #20125 edits rest-server.ts). ⛔ Not the seed or the folds (#20136, next in batch:1 order, same file). ⛔ Not checkObjectPermission.
Container & model: M, mode:subagent, model: opus (dispatch-gates --tier: no path-derived mandate, floor sonnet · default opus · ceiling fable)
Clause-②: no
Thread-read: 5831905897
Serial constraints cleared: at 2026-09-25T14:02Z, the region predecessors have landed: PR #20132 (#20083, fe677aeeed) and PR #20145 (#20134, 437bb0d7a8). A census of the 7 open PRs finds none on effective-object-permissions.ts. Draft PR #20125 edits packages/core/src/security/operation-private-keys.ts and rest-server.ts, both outside this surface. The seat runs batch:1 (the maintainer's ruling), so no other subagent is in flight.

[objectstack-fleet]

os-dev-report
{
"issue": 20135,
"status": "done",
"branch": "claude/issue-20135-api-operations-parity",
"pr": "#20151",
"session": "session_01Bvd69VPa6puiNzzPUroDBx",
"premise_still_valid": true,
"summary": "annotateEffectiveApiOperations (packages/core/src/security/effective-object-permissions.ts) now asks the REST door's own two questions per entry. Object half: canServeApiOperation, the boolean face of the spec's apiExposureDenialReason, which enforceApiAccess turns into 404/405, so an enable.apiEnabled:false object is annotated [] instead of its whole closure or no annotation. Export half: objectPermissionGrants(entry, 'allowExport'), which is read AND grant on the entry itself (per set and posture since #20083/#20134), in place of the merged '' export bit; this closes pointer 5831905897. Unchanged: the REST door, packages/spec, checkObjectPermission, the seed, the folds, and every exported name and type. Card assignee os-sales was set at dispatch and mirrored onto the PR. Claim verified: the newest Claim (5833697522) names this branch.",
"tests": "All at head f2904cd, core dist rebuilt from source, each under os-verify-lock with VERDICT command-exit 0. (1) pnpm --filter @objectstack/core test: 53 files / 1353 passed, typecheck exit 0. (2) pnpm --filter @objectstack/plugin-hono-server test: 27 files / 323 passed, typecheck exit 0. (3) pnpm --filter @objectstack/plugin-security test: 135 files / 2718 passed, typecheck exit 0. (4) Dogfood, 18 access-security files, against the turbo-built dogfood^... closure (64 tasks): first run 126 passed, 1 skipped (organization-update-door, me-apps-and-everyone-baseline, showcase-permission-projection, showcase-permission-seeding, showcase-permission-zoo, two-doors-permission, comments-permission-matrix, attachments-permission-matrix, authz-conformance); second run 135 passed (showcase-private-owd, owner-anchor-and-bulk-writes, showcase-crud-persona-matrix, showcase-client-liaison-fixtures, showcase-fls-read-mask-strip, showcase-scope-depth, showcase-scope-depth-write, showcase-scope-depth-fallback, showcase-anonymous-deny-surfaces). ABLATION through scripts/ablation-replace.mjs: one block restoring the base reading (the merged '' export bit, no door filter) plus a string marker. Anchor 1 → 0, blob da81b319 → 33501e91, core dist rebuilt, ablation-dist-preflight found the marker in 2 built files. Direction: RED. core 5 failed / 22 passed (the 2 right-direction controls stayed green). hono 6 failed / 27 passed. plugin-security 16 failed / 36 passed (15 subject rows of the apiOperations column plus the reported-cases case; every can() row green). Restore: blob == HEAD and git diff HEAD empty (tool verdict); core rebuilt; ablation-dist-preflight --absent reports the marker absent from all 14 built files and a clean tree; suites green again 27/33/52. A second ablation leg dumped both legs' maps and restored the same way. Throwaway stack probe (bootStack, real /auth/me/permissions route and real REST routes) was run at base 16c5a33, on the ablated build (its door readings equal true base in all 8 subjects) and at head; it was never committed and was deleted, tree clean.",
"mcp_calls": "0: no MCP GitHub tool was called. Reads went through REST GET with the session token: issue 20135, its comments, issues 18931/18990/20136, PRs 20132/20145, and PR 20151 read-back.",
"api_writes": "3, each one fleet-write relay dispatch (POST /repos/objectstack-ai/objectstack/dispatches) executed as objectstack-fleet[bot]: (1) pr_create, POST /repos/objectstack-ai/objectstack/pulls (draft #20151, relay run 36152948654); (2) label-write --assign os-sales, POST /repos//issues/20151/assignees (relay run 36153046523, read back as matching); (3) this os-dev-report comment, POST /repos//issues/20135/comments. There were 4 git pushes to the branch; those are not REST writes.",
"open_questions": [
{
"question": "Three pending changesets in this release describe an unrestricted, export-allowed object as carrying no apiOperations: 18931 ('an object that is unrestricted and keeps export gets none'), 18990 ('an unrestricted object whose export stays allowed still gets no apiOperations') and 20134 ('That entry carries no apiOperations'). At this head an API-disabled one carries []. Those files are outside the claimed surface, so they were not edited. Correct them?",
"options": [
"A: leave them. This PR's changeset states the exception explicitly in the same release, and the release notes are compiled together.",
"B: DELIBERATE CORRECTION of one clause in each, in this PR. This needs a claim amendment for the three files, and check-empty-changeset goes red on the foreign-changeset rule by design, as in the #20132/#20145 precedent."
],
"recommendation": "A. Read with 'keeps export' meaning 'the door serves export', each sentence stays true, and the one exception is named in this release's own note. B costs a red gate and a prose review for no reader-visible gain. If the seat reads the sentences literally, B is a three-line change."
},
{
"question": "annotateEffectiveApiOperations is an exported helper. Called standalone on a map that never went through buildEffectiveObjectPermissions, it no longer inherits the map's '' export bit. Does Clause-2 stay 'no' / core patch?",
"options": [
"A: keep 'no' and patch as the claim declares. There are 0 non-test callers in the repo, the helper is a pass of the one composition, and the changeset names the behaviour change.",
"B: grade it as a narrowing of a published helper: 'no (narrowing)', BREAKING."
],
"recommendation": "A. The served response only narrows toward what the door already refuses (0 operations added, measured). No request changes its answer, and the helper's documented role is the composition's last pass. check-changeset-no-major and check-adr-0087-registration both exit 0."
}
],
"out_of_scope_findings": [
"carrier: #20136's taker, or the domain:engine seat, for the entry-presence question. Noted, not filed. On the stack, subjects with no entry for an object leave the client on default-allow for operations the door refuses: member_default 134 cells, the member-with-read rows 101, the plain-wildcard member 15. The counts are identical at base and head. Every such object is one the subject cannot read at all (can() reads 'no grant'), so no affordance is reachable. That makes it an observation, not class a.",
"carrier: none. Noted, not filed. The spec describe string on EffectiveObjectPermissionSchema.apiOperations ('Present only when the object tightens exposure via apiMethods') has been inexact since the export axis (#3544) and now also for apiEnabled:false. packages/spec was out of scope. This is documentation drift, in Acceptance notes.",
"carrier: none. Noted, not filed. For an unrestricted object the spec's apiExposureDenialReason admits history/restore/purge/search, while resolveEffectiveApiMethods withholds the flag-gated ones. No REST route gates those by name, so nothing is reachable. It is outside the parity column by construction, in Acceptance notes."
],
"gates": "Derived at head f2904cd by node scripts/pm/dispatch-gates.mjs --commands --repo objectstack-ai/objectstack (no paths): 64 commands from 6 paths vs merge base 16c5a33. 64/64 exit 0. pnpm check:dual-build-cjs-loads first returned exit 3 PREREQUISITE NOT MET (8 packages had no dist); after turbo build of those 8 (all cache hits) it passed: 105 entries across 67 packages load, 660 CJS files parse. dispatch-gates --ran: 64 derived, 64 run, 0 NOT-MEASURED, 0 UNRUN. node scripts/check-issue-citations.mjs --base 16c5a33: exit 0, 3 citations resolve. check-changeset-no-major --base origin/main: exit 0 ('no major bump'). check-adr-0087-registration --base origin/main: exit 0 ('1 non-breaking changeset(s) seen'). Control-byte self-scan over the 6 files: 0 hits. Lint, as a proven narrowing: eslint --no-inline-config --format json over the 5 changed TS files gives 5 files, 0 errors, 0 warnings. --print-config resolves each of them, and eslint ignores the changeset. eslint.config.mjs enables no type-aware linting (no parserOptions.project, as its own comment at L327-328 states), so no untouched file's verdict can move. NOT MEASURED, CI-owned: Test Core, Dogfood Regression Gate, Build Core, Temporal Conformance, the type-check lanes, the repo-wide pnpm lint, and the families dispatch-gates lists outside its 64.",
"line_budget": "n/a: no skills/** in the diff",
"deviations": [
"plugin-hono-server effective-api-operations.test.ts: 4 existing cases rewritten. One is INVERTED on purpose (it pinned the merged-'' export fallback itself). Three called annotate on maps that never went through the per-set passes, so they now go through buildEffectiveObjectPermissions with the same assertions. All inside the claimed hono test side.",
"The committed parity column's object-door oracle is canServeApiOperation (@objectstack/spec/data), the function the REST door's apiAccessDenialFromEnable wraps. plugin-security has no @objectstack/rest dependency, and adding one is outside the claimed surface. The export half uses the real registered svc.canExport. The real REST door was measured by the throwaway stack probe.",
"The throwaway stack probe (packages/qa/dogfood/test) and the ablation dump (packages/plugins/plugin-security/src) lived outside or beside the claimed surface temporarily. Neither was committed. Both were deleted, and git status --porcelain is empty (ablation-dist-preflight --absent: tree clean).",
"Commit trailers follow AGENTS.md's model-free pair (Claude-Session + Co-authored-by: Claude). The PR footer is AGENTS.md's session-URL form. The harness reminder's variants were not used, because AGENTS.md takes precedence.",
"The worktree cleanup (rm -rf node_modules, git worktree remove) runs right after this report is posted, because the report is posted with the worktree's scripts/pm tools."
],
"files_changed": [
".changeset/20135-api-operations-rest-door-parity.md",
"packages/core/src/security/effective-object-permissions.ts",
"packages/core/src/security/effective-object-permissions.test.ts",
"packages/plugins/plugin-hono-server/src/current-user-endpoints-effective-objects.test.ts",
"packages/plugins/plugin-hono-server/src/effective-api-operations.test.ts",
"packages/plugins/plugin-security/src/get-effective-object-permissions.test.ts"
],
"parity": {
"definition": "Present entries x the operations the REST door gates by name (get, list, create, update, delete, bulk, import, export). offered_refused = the annotation offers the operation (or the entry is unannotated, which means default-allow) while the door refuses it (404 OBJECT_API_DISABLED / 405 OBJECT_API_METHOD_NOT_ALLOWED / 403 EXPORT_NOT_PERMITTED). served_hidden = the reverse.",
"stack_real_route_and_door": {
"seeded platform admin": {
"offered_refused": "16 → 0 (pq_hidden x7, pq_hidden_subset get/list, pq_private_hidden x7)",
"served_hidden": "0 → 0"
},
"admin_full_access + member_default + plain '' allowExport": {
"offered_refused": "21 → 0 (the API-disabled objects, pq_private.export, sys_secret.export)",
"served_hidden": "0 → 0"
},
"member_default": {
"offered_refused": "0 → 0",
"served_hidden": "0 → 0",
"no_entry_cells_unchanged": 134
},
"member + explicit read": {
"offered_refused": "16 → 0",
"served_hidden": "0 → 0",
"no_entry_cells_unchanged": 101
},
"member + explicit read + plain '' allowExport": {
"offered_refused": "20 → 0 (incl. pq_private.export)",
"served_hidden": "0 → 0",
"no_entry_cells_unchanged": 101
},
"member + explicit read+export": {
"offered_refused": "19 → 0",
"served_hidden": "0 → 0",
"no_entry_cells_unchanged": 101
},
"member + plain '' every bit + export": {
"offered_refused": "11 → 0",
"served_hidden": "0 → 0",
"no_entry_cells_unchanged": 15
},
"member + '' viewAllRecords + allowExport": {
"offered_refused": "19 → 0",
"served_hidden": "0 → 0"
},
"entry_level_diff": "0 entries added/removed, 0 allow bits changed, 0 operations added to any annotation, 74 removed, 11 annotations added (9 x [], 2 x closure minus export on pq_private); route == member map in all 8 subjects"
},
"unit_fixture_committed_column": {
"9 subjects (wall-less org admin, viewer, one set plain ''+narrower, platform admin, platform admin+wall-less, walled org admin, bare modify-all, super-read+plain bits, one set super ''+narrower)": {
"offered_refused": "7 → 0 each (crm_hidden)",
"served_hidden": "0 → 0"
},
"4 subjects (explicit beside plain '', super ''+export, super-read ''+export, explicit beside super '')": {
"offered_refused": "8 → 0 each (crm_hidden incl. export)",
"served_hidden": "0 → 0"
},
"platform admin beside plain export-only ''": {
"offered_refused": "10 → 0 (crm_hidden x8, crm_secret.export, sys_secret.export)",
"served_hidden": "0 → 0"
},
"one set: exporting '' + explicit crm_lead without the grant": {
"offered_refused": "9 → 0 (crm_hidden x8, crm_lead.export)",
"served_hidden": "0 → 0"
},
"member, export-only '' beside reader, '' granting nothing": {
"offered_refused": "0 → 0",
"served_hidden": "0 → 0"
},
"entry_level_diff": "18 subjects: 0 entries added/removed, 0 allow bits changed, 0 operations added, 92 removed, 7 annotations added"
}
},
"disabled_shape": "apiOperations: [] and the entry stays. Reading: nothing in this repo's SDK reads apiOperations (git grep over packages/client and packages/client-react gives 0; @objectstack/client only re-exports the GetEffectivePermissionsResponse type). The reader is objectui, UNMEASURED here (not in the container). Per the spec contract ('absent = default-allow') and the objectui gate quoted on #18931 (effectiveApiOps ? effectiveApiOps.includes('export') : true), an array hides whatever it omits and absence hides nothing. [] is already the deny-all (apiMethods: []) shape. Dropping the entry would flip server-side current_user.can() to 'no grant' for data the subject may still write through internal paths (apiEnabled closes the API, not data access). That is a server-decision change H5 forbids, and it contradicts the #18990 ruling that every reachable object gets an entry.",
"reach": "H1 CONFIRMED on the real public door. bootStack with the real SecurityPlugin and an authored app (0 apiEnabled:false objects exist in examples/). At base 16c5a33 the seeded platform admin's GET /auth/me/permissions annotated pq_hidden (enable.apiEnabled:false, no apiMethods) with [get, list, create, update, delete, upsert, bulk, aggregate, search, import], while every REST verb on it answered 404 OBJECT_API_DISABLED. For export-allowed subjects the entry had no annotation at all (default-allow). ISecurityService.getEffectiveObjectPermissions was byte-equal to the route in all 8 subjects. Controls: pq_open and pq_exposed (apiEnabled absent or true) matched the door; pq_subset (apiMethods get/list) matched at base and head. At head every API-disabled entry reads [] and all 8 subjects show 0 present-entry mismatches in both directions. H2 CONFIRMED: admin_full_access beside a plain '*' allowExport had sys_secret annotated export while the export route answered 403 EXPORT_NOT_PERMITTED; the authored private pq_private had the same over-offer through default-allow, and so did the member-with-read beside the plain export wildcard. H5: no server decision and no exported type changed, Clause-2 no, core patch; both gates exit 0."
}

[objectstack-fleet]

Seat amendment to claim 5833697522

domain:engine#1, session_01Bvd69VPa6puiNzzPUroDBx, written 2026-09-25T15:20Z.

• Q1 → A: leave the three pending changesets (18931, 18990, 20134) as they are.
  • Their sentence is about an object that is unrestricted and keeps export. An object with enable.apiEnabled: false is not unrestricted in the plain reading: its API is closed entirely.
  • This release's own 20135-* entry names the [] it now carries.
  • The at-tier review judges those three sentences literally. If any reads FALSE at PR fix(core): apiOperations offers only what the REST door serves — nothing on apiEnabled: false, export only where the export door admits it (#20135) #20151's head, it becomes a one-clause DELIBERATE CORRECTION patch, as in the 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 / fix(core): effective-map entries reached through a super-user * carry every bit the server grants, so can(object, 'transfer') agrees with checkObjectPermission (#20134) #20145 precedent.
• Q2 → A: Clause-②: no, @objectstack/core patch, as claimed.
  • Called standalone, annotateEffectiveApiOperations now reads the export slot from the entry, not the merged '*' bit.
  • Its output only narrows toward what the REST door already refuses: 0 operations added, measured. No request changes its answer.
  • It has 0 non-test callers, and it is documented as the composition's last pass.
  • The review confirms this against AGENTS.md's Clause-② rule.
• File surface: unchanged. The 4 rewritten hono cases are on the claimed test side.

[objectstack-fleet]

Seat amendment 2 to claim 5833697522

domain:engine#1, session_01Bvd69VPa6puiNzzPUroDBx, written 2026-09-27T02:12Z.

• The contract review FAIL 5851878434 on PR fix(core): apiOperations offers only what the REST door serves — nothing on apiEnabled: false, export only where the export door admits it (#20135) #20151 at f2904cd05b is prose only. The code, the pins, the ablation and the declaration all pass as measured.
• Q1 → B, as amendment 1 (5834862405) provided for.
  • The review measured resolveEffectiveApiMethods({ apiEnabled: false }).mode === 'unrestricted'. So an API-disabled object with no apiMethods IS "unrestricted" in the resolver's own vocabulary.
  • All three pending sentences are therefore FALSE for it at this head, since it now carries [].
  • Each gets a one-clause DELIBERATE CORRECTION in this PR, keeping every other line byte-identical (the 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 / fix(core): effective-map entries reached through a super-user * carry every bit the server grants, so can(object, 'transfer') agrees with checkObjectPermission (#20134) #20145 precedent):
    • .changeset/18931-me-permissions-unrestricted-export-annotation.md line 13;
    • .changeset/18990-viewall-only-permissions-seed.md line 12;
    • .changeset/20134-super-user-entries-every-bit.md line 15.
• File surface: those three files are added. Check Changeset turns red by design on exactly those three names. The same-head PASS record is what confirms the class.
• Q2 → A is unchanged and confirmed by the review: Clause-②: no, @objectstack/core patch.