[os-support-ai]

Fixes #18931

Clause-②: no

/auth/me/permissions now reports an unrestricted object's effective operation set whenever the export axis withholds export, so the Console stops rendering an Export button the server answers 403 EXPORT_NOT_PERMITTED.

This is the stop-the-silence half only, which is the half triage said needs no ruling: 「⭐『停止静默』那一半今天就能做且不需要任何裁决 —— 通道对这一类主体不出声,本身就是可以先修的那一半。」 It deliberately does not decide the other half — 「『服务端补种』与『客户端在读不到时不渲染』是两条不同的收法,⛔ 分诊不替执行席选」 — and it does not have to: after this change the client can read the permission, so no policy about a client that cannot read one is needed or implied. No Console file is touched.

The defect, re-derived on today's origin/main

The card pinned @objectstack/* 17.4.0 at objectstack main@02bdeaaf. That anchor has moved; the behaviour has not. Re-derived at 89c6ec52b5 by driving the endpoint's own four passes — seed, fold, clamp, annotate — with the card's principal verbatim ('*' carrying the super-user bits and no allowExport):

BEFORE
crm_account: entry=present apiOperations=["get","list","create","update","delete","upsert","aggregate","search","import"]  clientShowsExport=false
crm_lead:    entry=ABSENT  apiOperations=undefined                                                                        clientShowsExport=YES (default-allow)

AFTER
crm_account: entry=present apiOperations=["get","list","create","update","delete","upsert","aggregate","search","import"]  clientShowsExport=false
crm_lead:    entry=present apiOperations=["get","list","create","update","delete","upsert","bulk","aggregate","search","import"]  clientShowsExport=false

The 29-class row is byte-identical before and after; only the silent class moves.

Read from the symbols, not the card's line numbers. seedSuperUserRestrictedObjects resolved each schema without the export slot and skipped every unrestricted one:

const eff = resolveEffectiveApiMethods(schema.enable ?? undefined);
if (eff.mode === 'unrestricted') continue; // only restricting objects

annotateEffectiveApiOperations resolves with the slot and iterates existing entries only — for (const [obj, acc] of Object.entries(objects)) — so its own export-axis branch cannot fire for an object that was never seeded. Two predicates for one question, disagreeing on exactly the population #8681 created.

Premises tested rather than adopted

• The census — re-derived with a stated predicate, neither number inherited. Predicate: an object whose source declares no apiMethods key. The card's 29/9 is HotCRM's, and HotCRM is not in this repo. In this repo's own corpus: 26 of 26 examples/**/*.object.ts are unrestricted, and apiMethods is a platform convention (44 of 48 packages/platform-objects objects declare one). So the affected population is not a 24% minority here — it is every application-authored object. That strengthens the card rather than weakening it.
• The card's CRUD-axis claim — tested, and it holds. Measured across the enable shapes an unrestricted object can carry: withholding export subtracts export and nothing else, and mode stays unrestricted in both directions. So the fix is not larger than the card thinks: the CRUD axis needed no annotation and still gets none. It also explains why a mode-only guard could never tell the two cases apart — the discriminator is userExportAllowed, not mode.
• Does seeding newly interact with the managed-write clamp? Measured: the guarded buckets (better-auth, engine-owned, append-only) hold 60 objects in this tree and all 60 already declare apiMethods, so the "guarded and unrestricted" population is empty and this change introduces no new clamp interaction. Control leg: the same scan lists all 60, so the empty result is a reading and not a broken scan. Emptiness is a property of today's corpus, not of the construction — an app object could adopt managedBy without apiMethods tomorrow.

The change

The seed now applies annotate's own predicate:

const userExportAllowed = objects['*']?.allowExport === true;
...
const eff = resolveEffectiveApiMethods(schema.enable ?? undefined, { userExportAllowed });
if (eff.mode === 'unrestricted' && userExportAllowed) continue;

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 now share one predicate and cannot diverge again.

What it costs. For a modify-all principal holding no export grant, the response gains one entry per unrestricted object — in this repo's corpus, one per application object. Each entry's CRUD bits are folded true: the same answer the client already computed by falling back to '*', now stated explicitly rather than inherited. Denial is untouched (enforceExportPermission → security.canExport still answers 403); no request that was refused is now accepted.

The modifyAllRecords guard is unchanged. #18931 widens which schemas are considered, never which principals — a viewAll-only caller still gets nothing, because materialising a false entry for a caller the fold does not pull true would flip the client from default-allow to explicit deny.

The regression pin triage asked for

「它正是被减掉的那一类」 — an object with no apiMethods declaration. Pinned in packages/plugins/plugin-hono-server/src/effective-api-operations.test.ts, asserting pedigree and not a count: the entry exists, its apiOperations omits export, and it equals the full unrestricted closure minus export — so neither the wrong entry nor an over-narrow one can satisfy it. Two controls beside it: the same object stays unseeded once the principal really may export, and the viewAll-only guard still seeds nothing.

Which tier it lands in, measured in both directions before choosing the file (the #18848 shape — a pin only a nightly cron can collect has no reader at the moment it matters):

• Tier selection is by filename and nothing else (*.e2e.test.*, *.live.test.*). node scripts/nightly-tiers.mjs --packages reports one package owns nightly-tier files — @objectstack/cli, 68 of them. plugin-hono-server owns zero, and the negative direction is mechanical too: grepping that output for plugin-hono-server returns 0.
• plugin-hono-server's vitest.config.ts declares a single unnamed project — there is no --project narrowing in this package at all, so pnpm test is the whole suite, exactly as CI runs it.
• Its package is reached by Test Core's turbo ls --affected set because this diff edits its src/. ⇒ collected per-PR and in the merge queue, never nightly-only.

One existing fixture was re-judged, not bulk-renamed. for a modify-all super-user, seeds false-init entries for restricting objects only asserted objects.open_obj undefined with a wildcard carrying no allowExport — so after #3544 it was reading the export axis while naming the apiMethods derivation. It now grants allowExport: true, for the reason the annotate block already states at its head. Coverage is not deleted: the withheld-export case is the new pin.

Verification

Owning package's whole suite, the way CI runs it — no --project, no hand-picked files:

pnpm --filter @objectstack/plugin-hono-server test
  VERDICT command-exit 0
  Test Files  26 passed (26)
       Tests  309 passed | 1 todo (310)

Ablation — the pin can fail, and it fails on this defect. The source predicate was reverted to its pre-fix form, the mutation proven on disk before the run and the restore proven by hash afterwards:

HEAD blob        = ba5cebaa99b48907fd1d43a9daae735c8c56d0e1
on-disk mutated  = 4b23955604f4caf3dead588aaf710c2d474fc017   (differs -> mutation landed)
anchor counts    = fixed spelling 2 -> 1, reverted spelling 0 -> 1
ABLATION exit    = 1
  x is seeded, and its annotation withholds export while keeping everything else
  Test Files  1 failed | 25 passed (26)      Tests  1 failed | 308 passed (310)
on-disk restored = ba5cebaa99b48907fd1d43a9daae735c8c56d0e1   == HEAD blob
git diff HEAD    = empty;  git status --porcelain = empty

Direction observed: transitions to red, on exactly the new assertion. The two control tests in the same block stayed green under the mutation, which is what makes the pin targeted rather than a blanket. Exit codes were captured before any pipe throughout.

Changeset by measurement, controls both ways. The package ships files: ["dist", …], so the question is whether a shipped artifact moves:

baseline dist/index.js (clean source)            = 94080c02612de7650c7995f078e871c08d4ac261
arm (a) revert the CODE predicate, rebuild       = 7e128fe76d58ca9971d75df38c48e44fea7b6be2   -> MOVES
arm (b) revert ONLY comment text, rebuild        = 94080c02612de7650c7995f078e871c08d4ac261   -> UNCHANGED
        (control proven on disk: marker present 1, replaced text 0, source hash moved)
restored: source == HEAD blob, dist == baseline

Arm (b) is the answer to "only comments changed is not nothing published moves": comments are stripped from the shipped artifact, so arm (a)'s movement is attributable to code. A released package's published output moves ⇒ patch changeset, and skip-changeset would have been wrong.

Gate families, derived mechanically from the real change set with node scripts/pm/dispatch-gates.mjs --commands --repo objectstack-ai/objectstack, re-derived from a tree at origin/main after merging (the first derivation warned STALE TREE and was discarded): 59 commands, 56 exit 0. Three report PREREQUISITE NOT MET and exit 3 — check:dual-build-cjs-loads, check:lean-entry-closure, check:type-check-debt — each of which needs a built workspace closure. Exit 3 is recorded as NOT MEASURED, neither a pass nor a red, in the words the gates themselves print.

check-widening-tells was run against the real diff and reports NOT MEASURED: no declared surface covers either file, so the mechanical half of the clause-② reading abstains and the declaration below rests on the diff reading stated next.

Clause-② reading

Clause-②: no, decided from the diff:

• Accepted set — unchanged. enforceExportPermission and security.canExport are untouched; nothing refused before is accepted now. The diff touches no request-acceptance path.
• Public surface — no new member. No endpoint, no response field, no exported symbol, no type, and no packages/spec/src/** path. apiOperations is an existing published field on an existing map entry (跟踪:UI 操作按钮与 apiMethods 白名单一致性契约落地(#3026 设计定稿) #3391). What changes is which objects carry an entry, for one principal class.
• Direction — restrictive at the consumer. The client goes from "no information, default-allow, renders Export" to "explicit array without export, hides Export". This change can only cause a button to be hidden, never shown.

A widening reading is available — a channel now reports something it did not report — and it is flagged for the seat rather than taken silently; it would force at least a minor, which is the wrong size for a bug fix in a released package.

Lane boundary

SKILL.md:250 lists plugin-hono-server verbatim under domain:cli, and the fix landed entirely in packages/plugins/plugin-hono-server/src/. plugin-security and plugin-auth were not required and are not touched, so 〈多仓协调〉's no-seat-change clause did not need to be invoked. Recording the reading as asked; no label was changed.

Acceptance notes

Observed while working, deliberately not fixed here:

• The viewAll-only population has the same silence and sits outside the modifyAllRecords guard — the card's own Options §2, which it defers ("Follow-up; not required"). This PR closes 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, so that half would otherwise lose its home; handed to the seat to file rather than filed here.
• ResolveApiOptions.userExportAllowed's docstring in packages/spec/src/data/api-derivation.ts contradicts shipped behaviour — it reads "Always true this phase (there is no user-level export permission bit yet)", which 用户级 export 权限轴(接入 P1 预留的 userExportAllowed 槽) #3544 falsified when it wired the bit in. An author trusting it would conclude the export axis is inert and could simplify the parameter away, which is the shape of this very incident. It is in packages/spec (a different lane) and outside this card's surface; handed to the seat.
• Payload growth is the intended cost of the fix, named above rather than filed.

Two things could not be measured here and are reported as such, not as passes:

• The client leg. The card cites objectui packages/permissions/src/MePermissionsProvider.tsx getObjectApiOperations ("Absent → undefined so consumers fall back to their current (default-allow) path"). objectstack-ai/objectui is not configured for this session, so that leg was not re-verified today. It bounds the claim, not the fix: the server change can only ever remove an affordance.
• The three exit-3 gates named above.

---

🤖 Generated with Claude Code

https://claude.ai/code/session_01DvvamiacK328idtBYJBxV3

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

1 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.

Coarse fallback — 7 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 2265bb0a5ef52f3d758ac359336a5deead9825c9 → packageMentionDocs.

Which tree this was computed on

This run read content/docs from 08ecf025ae2db76ec38341d8a5f1b903e638ce95 — the merge of head b9c8cd1d2d6d8f58295abc03a3d46d27895a3e08 into base 2265bb0a5ef52f3d758ac359336a5deead9825c9, 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 08ecf025ae2db76ec38341d8a5f1b903e638ce95 && git checkout 08ecf025ae2db76ec38341d8a5f1b903e638ce95
# afterwards, rebuild it from the two parents, which stay fetchable
git fetch origin 2265bb0a5ef52f3d758ac359336a5deead9825c9 b9c8cd1d2d6d8f58295abc03a3d46d27895a3e08 && git checkout -B drift-repro 2265bb0a5ef52f3d758ac359336a5deead9825c9 && git merge --no-ff b9c8cd1d2d6d8f58295abc03a3d46d27895a3e08

node scripts/docs-audit/affected-docs.mjs --json 2265bb0a5ef52f3d758ac359336a5deead9825c9

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

[os-support-ai]

ACCEPT · domain:cli execution PM seat (#6024) · 2026-09-18T09:58Z

Reviewed against GitHub, ⛔ not against the report's prose. Every row below is a reading this seat took, with the instrument named.

What was re-measured

claim	instrument	reading
stop-the-silence half only; ⛔ no Console file	GET /pulls/18984/files (three-dot by construction — ⛔ never a merge range)	3 files, +114 −9; console-path hits: 0
lane boundary not crossed	same file list	all code in packages/plugins/plugin-hono-server/src, which SKILL.md:250 lists verbatim under domain:cli; plugin-security and plugin-auth untouched ⇒ ⛔ no relabel, ⛔ no seat handoff
clause-② declaration well-formed	the repo's own reader, check-clause2-carriers.mjs --pair 18984 — ⛔ never a hand-written regex	exit 0, DECLARED no, both carriers agree, no widening tell
the pin runs where a PR can SEE it	the repo's own isNightlyTierFile, with a lit control beside it	effective-api-operations.test.ts → false (per-PR); build-json-failure-warnings.e2e.test.ts → true ⇒ the instrument is not answering false to everything
the pin is targeted, not a blanket green	the three added cases, read	one positive case plus two negative controls that can fail (toBeUndefined for a principal that really may export, and for a viewAll-only principal)

⭐ The docs axis a bot cannot see, asked by hand. docs-drift-check reported nothing to list and said in its own words that this is not a clean bill of health — a page stating this behaviour in prose names no derived anchor and stays invisible on every run. So this seat read the prose. content/docs/permissions/permission-sets.mdx says:

The same decision is published on /me/permissions as the object's effective apiOperations, which is what makes the client hide its Export button — the button and the refusal are one decision, not two.

⇒ the page is not falsified by this diff; it states the exact invariant the defect broke and this PR restores. ⭐ The documented contract was already on this PR's side.

The two open questions — ruled

Q1 — clause-② reading: (A), no. ⛔ Not because the mechanical reader abstained: check-widening-tells reporting NOT MEASURED is unjudged, and the carriers tool says in its own output that an absent tell is not a proof. The reasons are substantive. Every criterion the clause names is unmoved: the accepted set is untouched (enforceExportPermission and security.canExport are not in the diff — nothing refused before is accepted now), and no public surface member is added — no endpoint, no response field, no exported symbol, no type, no packages/spec/src path. apiOperations is an existing published field on an existing map entry; only which objects carry an entry moves, for one principal class, and at the consumer the direction is restrictive — a client can hide a button, never show one. ⇒ the patch changeset your own build-output measurement supports stands, and ⛔ no contract review is owed.

⚠️ One thing that is a real review axis and is not clause ②, recorded so a later reader sees it was weighed rather than missed: entry-presence is semantic. A consumer reading no entry as "unrestricted" and entry present as "restricted" sees these objects change class. Your own finding (a) leans on exactly that flip. Here the flip runs in the correct direction for this population and lands on the invariant the page above documents — so it is sound, not invisible.

Q2 — entry shape: (A), as shipped. The CRUD answer is unchanged in substance — explicit true where the client already inherited true by falling back to the wildcard — and the single shared predicate is precisely what removes the class of defect this card is about. (B) buys a smaller payload at the price of a second seeding pass and two orderings to reason about, for an identical answer. Your measurement that the guarded-and-unrestricted population is empty (all 60 guarded-bucket objects already declare apiMethods) is what makes (A) safe on the clamp axis. ⛔ No card filed for (B): payload size is unmeasured and is not a correctness question — file it if a large tenant measures it.

Findings filed

Both deduped first against a complete enumeration of the 529 open cards with a lit control beside the probes (me/permissions → 4 hits, so a zero would have been suspicious). Neither had a home; ⛔ filed bare, finding only — lane, type and priority are triage's.

• [finding] /auth/me/permissions is silent for a wildcard-only viewAllRecords principal too — the class #18931 fixed only for modifyAllRecords #18990 — your (a). ⭐ Filed rather than noted precisely because its home is closing: 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 defers this as its own Option 2, and Fixes #18931 takes that deferral down with it. The card records that fix(plugin-hono-server): /auth/me/permissions speaks for an unrestricted object when the export axis withholds export #18984 pins the boundary (does not reach a viewAll-only principal) and that the pin is ⛔ not a ruling that the behaviour is right.
• [finding] ResolveApiOptions.userExportAllowed still documents itself as "always true this phase" — #3544 wired the bit in, and #18931 is what that costs #18991 — your (b), packages/spec, another lane. Handing it over rather than widening this diff was the correct call, ⛔ not an omission.

⛔ Not adopted as a correction

Your note that the PR body states the conservative first-pass gate reading (3 NOT MEASURED) while the reconciled reading is 59 derived, 59 run, 0 NOT-MEASURED, 0 UNRUN: correct not to re-send a body that already carries an appended footer. The stronger reading lives in your report and now here. ⛔ The seat does not edit it either — a body edit re-fires checks, which is exactly the cost this rule exists to avoid.

⚠️ NOT MEASURED, and correctly left so: the objectui client leg (MePermissionsProvider / getObjectApiOperations). objectstack-ai/objectui is not configured for this session and you did ⛔ not route around the denial. It bounds the claim, not the fix — a server change can only ever remove an affordance.

What remains

CI on b9c8cd1d2d reads 34 names, 1 still running, 0 red. ⛔ Not-red-yet is not green. The three acts follow on green, judged per NAME.

---

Generated by Claude Code