feat(objectql,plugin-security,core): the server answers current_user.can() in an option's visibleWhen

[objectstack-fleet]

Fixes #18783

Clause-②: yes (widening)

Executes ruling A on the card (maintainer 「同意」, comment 5725678115): the census comes first, then the reader, then the wiring. The server now answers current_user.can(object, verb) in an option's visibleWhen. Before this PR the predicate faulted on every authenticated write and the value was admitted unenforced. The interface member is the one PR #19622 declared: ISecurityService.getEffectiveObjectPermissions?(context?). packages/spec is not touched.

Declared cross-lane edits. packages/plugins/plugin-security is domain:services surface; the ruling places it on this card. packages/core and packages/plugins/plugin-hono-server are outside the claim's file surface. They are touched because the dispatch's H2 requires the /auth/me/permissions route and the member to read ONE function, and @objectstack/core is the only package both already depend on (plugin-hono-server must not take a runtime dependency on plugin-security).

What lands

• objectql gets a new engine seam, registerEffectiveObjectPermissionsResolver(fn). It is the same shape as registerWriteGateProbe, which the security plugin already registers on the engine.
  • resolveOptionPermissions asks the resolver at most ONCE per write: a batch insert, a by-id update, an N-row bulk update or a validate() preview.
  • It asks only when three things hold: a resolver is registered, the write has an acting user, and some payload picks an option whose visibleWhen calls can.
  • The answer goes through formula's toEvalPermissions. A resolution throw, or a map that is not the published shape, is re-raised untouched for exactly the payloads that needed the map: the write fails CLOSED.
• rule-validator: evaluateValidationRules takes permissions and passes it to the per-option visibleWhen evaluation.
  • optionVisibilityReadsPermissions answers "does this write need the map". It reads the parsed CEL AST for a receiver call named can, and uses the same picker (pickedGatedOptions) the evaluator judges with.
  • undefined stays "no permission data": the predicate is loudly unevaluable and the existing fail-open branch admits the value with a warn that names the missing input.
• plugin-security implements getEffectiveObjectPermissions on the class and on the registered security literal, and registers the same method on the engine.
  • The member resolves the sets with resolvePermissionSetsForContext and builds the map with buildEffectiveObjectPermissions over the plugin's engine. It freezes the map at the top level.
  • A resolution failure propagates untouched and never becomes {}.
  • An engine without the seam gets one warn at start.
• core gets buildEffectiveObjectPermissions: the most-permissive merge, then seedSuperUserRestrictedObjects, foldWildcardSuperUser, clampManagedObjectWrites and annotateEffectiveApiOperations. The four folds and ManagedSchemaLike / ApiExposureSchemaLike moved here unchanged (reindented) from plugin-hono-server.
• plugin-hono-server: /auth/me/permissions builds its objects slot with buildEffectiveObjectPermissions. The six moved names are re-exported from @objectstack/core, so the package root still exports them. ESM probe: the re-exported foldWildcardSuperUser is the same function object as core's (===).

Census — every in-repo evaluation site that binds current_user

The grep, over non-test source outside packages/formula (the engine itself) and packages/qa:

git grep -n -E "\b(ExpressionEngine|celEngine|templateEngine)\.evaluate\b|\bresolveSeed(Record)?\(|\bcompileCelToFilter\(" -- 'packages/**/*.ts' ':!**/*.test.ts' ':!**/dist/**' ':!packages/formula/**' ':!packages/qa/**'

It gives 24 lines, 18 of them code (6 are comments). Completeness control: a token scan for ExpressionEngine|celEngine|templateEngine|resolveSeedRecord|resolveSeed|buildScope|getEngine over the same tree gives 24 files. Every file outside the grep's population mentions the tokens only in comments, or uses an unrelated getEngine. Positive control: the grep's population contains the site the ruling names (rule-validator.ts evaluateOptionVisibility).

site (file : symbol)	binds current_user	author-reachable can today	verdict
objectql/src/validation/rule-validator.ts : evaluateOptionVisibility (reached from 5 engine call sites: insert, by-id update, bulk update twice, validate())	yes (buildEvalUser)	yes. It faulted with "carries no permission data" and the fail-open branch ADMITTED the value (measured on the base head, below). This is a live violation and, by the ruling's own words, the p1 trigger.	wired here
objectql/src/engine.ts : applyFormulaPlan (formula virtual fields, read and write-back)	yes (own {id, positions})	yes: value null on read and on the insert echo, with NO log (measured at this head with a resolver registered)	out of this card's plumbing: a value expression, not a predicate, and it builds its own user object. Reported as a finding.
objectql/src/engine.ts : applyFieldDefaults (CEL defaultValue)	yes (own {id, positions})	yes: field left unset, and Failed to evaluate default expression names the missing input (measured)	out of this card's plumbing, same reason. Reported as a finding.
metadata-protocol/src/seed-loader.ts : resolveSeedRecord	yes (seed identity, or { id: null })	the record is dropped loudly (errored++, an actionable error)	out of scope: boot-time replay with no request and no acting subject whose grants would mean anything. The loud refusal is the correct answer.
plugin-security/src/rls-compiler.ts : compileExpressionOutcome (compileCelToFilter, current_user as a lowering variable)	as a filter variable	unsupported method "can()": the policy drops and RLS denies (fail closed)	out of scope: an RLS predicate is lowered into a driver filter, and a filter cannot consult a permission map
lint/src/validate-rls-predicate-enforceability.ts	probe variable	authoring gate, not a runtime evaluation	out of the population
hook condition (hook-wrappers.ts), readonlyWhen, requiredWhen x2, script, conditional (rule-validator.ts), approvals expression approver, share-link eligibility, flow celScope x2, sharing-rule seeder, lint sharing gate	no	n/a	outside the census: current_user is not bound there

H1 — red on the base head, green here

Ruling pin, rule-validator.option-visibility.test.ts, run on the base (2274894cc) before the fix:

• REFUSES a can-gated option … withholds the verb failed with expected undefined to be an instance of ValidationError (admitted).
• ADMITS it … failed with expected [ { …(2) } ] to have a length of +0 but got 1 (the fail-open warn).
• The run ended Tests 7 failed | 31 passed (38). The no-can control and the no-permission-data case were green on the base, which is their point.

With the fix: Tests 38 passed (38).

H2 — the producer, and byte-equality

The /auth/me/permissions merge lived inline in plugin-hono-server's current-user-endpoints.ts. It is now buildEffectiveObjectPermissions, read by both the route and the member.

• Route unchanged. Whole response bodies from the base route and this head's route, for the same resolved sets and schemas, are byte-identical on five fixtures (super-user without export, super-user with export, wall-less org admin, plain rep, nothing). Measured one-shot: lengths 1461/381/633/336/168, all equal=true.
• Permanent pins, both halves. current-user-endpoints-effective-objects.test.ts pins that the route's objects equals buildEffectiveObjectPermissions over the resolved sets, byte for byte. get-effective-object-permissions.test.ts pins that the member equals the same function over resolvePermissionSetsForContext, for three subjects. Both fixtures make the seed, fold, clamp and annotate steps all fire.

H3 — resolutions per write

• Bulk update across N matched rows: 1 resolution for N=1 and for N=25.
• Batch insert of 7 rows: 1 resolution.
• Two writes: 2 resolutions, and a grant revoked between them is refused on the second, so nothing is kept across writes.
• A write whose gates never call can makes 0 resolutions, even with a resolver that would throw. A system write makes 0.

The set resolution under the member is plugin-security's existing per-context memo, keyed on the request's context object and retired by the write epoch. Within one request context a second ask costs no second set load. A new context loads again (pinned).

Both failure directions (pinned)

• Resolver throws: the insert rejects with that very error object (code, status intact), it is not a ValidationError, and nothing is written.
• Off-shape map ({ crm_account: true }): TypeError from toEvalPermissions, nothing written.
• No resolver: admitted, with one warn whose meta.error.message contains carries no permission data. It is not denied.

Ablation: the insert call site's permissions: insertPermissionsFor(rows[i]) was replaced by permissions: undefined /* ABLATION-18783 */ through scripts/ablation-replace.mjs. The anchor went 1 to 0, the marker 0 to 1, and the blob changed.

• 5 engine cases went red (refuse, admit, throw fails closed, off-shape map, revocation); the 8 control and non-insert cases stayed green.
• The file was restored to its HEAD blob and git diff HEAD was empty.
• The first attempt used a replacement already present 178 times. The tool refused it (count unchanged) and restored, so it was a no-op and was re-run with the marker.

Known gap — measured, not changed here

can() reads only per-object entries. /auth/me/permissions materialises an entry for an object covered by '*' only when that wildcard carries a super-user bit (the seed pass). With the shipped organization_admin_no_bypass plus member_default (the grant a deployment without an organization wall gives organization owners and admins):

• the map has no crm_account entry;
• current_user.can('crm_account', 'edit') evaluates to false;
• PermissionEvaluator.checkObjectPermission('update', 'crm_account', sets) is true.

admin_full_access and walled organization_admin answer true on both sides. Before this PR that population's can gate was never enforced for anyone. From this PR on, the server refuses them on a can-gated option. The fix belongs to the map's producer (materialising plain-wildcard coverage, which changes the /auth/me/permissions response) or to formula's can. It is raised as a question in the report, not decided here.

Overlap with in-flight work

rule-validator.ts: this diff touches the EvaluateRulesOptions interface (one new member), the USER_SCOPE_ROOTS docblock, the evaluateOptionVisibility region (a new picker plus helpers), and ONE line inside evaluateValidationRules's body: the evaluateOptionVisibility(...) call gains opts.permissions. That call is not the function's head, the requiredWhen / readonlyWhen arms or unevaluableRuleError, which are draft PR #20028's region. traversalRefusal (PR #20049) is already on main and was merged in here without a conflict.

Verification (at f3fe6d6cfd)

• Suites: objectql test 312 files / 5292 tests and test:repo 1/5; plugin-security 134 / 2658; plugin-hono-server 27 / 313 (+1 todo); core test 53 / 1331 and test:repo 3 / 48. All passed. The objectql, plugin-hono-server and core runs are from the merge commit b5416a2b49; the two later commits touch only plugin-security's new test file, and plugin-security's suite and typecheck were re-run at f3fe6d6cfd.
• typecheck passed for core, objectql, plugin-security and plugin-hono-server. Each new test file is in a tsc program (--listFiles, via tsconfig.test.json or the main config).
• The four packages build (check-dts-emitted present). CJS and ESM load probes see the new core exports and the hono re-exports.
• Gates: node scripts/pm/dispatch-gates.mjs --commands --repo objectstack-ai/objectstack derived 72 commands, and all were run at f3fe6d6cfd. 69 exited 0.
• 3 exited 3 with PREREQUISITE NOT MET, so they are NOT MEASURED: check:dual-build-cjs-loads, check:type-check-debt (both need the whole workspace built) and check:i18n (needs the CLI build closure). --ran reconciliation: 72 derived, 69 run, 3 NOT-MEASURED, 0 UNRUN.
• check-issue-citations --base b76aad5f6: every citation this change adds resolves.
• Narrowed eslint (--no-inline-config, --format json) on the 11 changed .ts files: 11 files, 0 errors, 0 warnings. eslint.config.mjs enables no type-aware linting (no parserOptions.project), so the diff cannot move a verdict on an untouched file.

Acceptance notes

• plugin-hono-server's pin batteries for the four folds (fold-wildcard-superuser.test.ts, effective-api-operations.test.ts) stay where they are. They exercise the folds through that package's unchanged re-exports. core carries its own composition pins.
• The route's failure stance is unchanged: a set-resolution failure still answers objects: {} (its pre-existing .catch(() => [])). The member's stance differs on purpose: it throws.
• check-changeset-no-major's Clause-② level axis reports NOT APPLICABLE locally (there is no pull_request payload). CI reads it.

Seat amendment (5825601266)

• Clause-② is corrected from the claim's no to yes (widening). The diff adds public exports to @objectstack/core (buildEffectiveObjectPermissions, plus the folds and types moved from plugin-hono-server) and a public ObjectQL.registerEffectiveObjectPermissionsResolver.
• The widened file surface (packages/core, and plugin-hono-server, which is domain:cli surface) is accepted as the single-producer consequence of the member's "computed once" rule.
• The open questions are answered A (land, and fix the plain-wildcard gap at the producer, as its own card), B (this line) and A (keep Fixes; the value-expression rows are filed as their own card).
• [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 is re-graded to p1 per ruling A's census clause.

Patch round 1 (merge-queue failure, 7a6b091b2a)

• What failed: the queue removed this PR on Test Core (1/6) / Spec property liveness (queue run 36088336600). The spec liveness gate reported permission/objects.allowExport UNANCHORED, because its evidence cited plugin-hono-server/src/current-user-endpoints.ts, which, after this PR moved annotateEffectiveApiOperations into @objectstack/core, no longer names allowExport (0 mentions; the new file has 7). PR CI runs only the affected subset, and the queue runs the full suite.
• Fix: one ledger file, packages/spec/liveness/permission.json. The citation is repointed to packages/core/src/security/effective-object-permissions.ts#annotateEffectiveApiOperations, with verifiedAt 2026-09-25 and a dated note. It is a declared cross-lane pointer update in the spec LEDGER, not in src.
  • check:liveness went from exit 1 (1 UNANCHORED) to exit 0.
  • check-liveness.test.ts went from 20 failed / 44 passed to 64 passed.
  • The sweep for other pointers made false by the move found none. The two governed ADR mentions (0103, 0124) are still true and were not edited.
• The delta contract review is recorded against this head.

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

This PR changes 5 package(s): @objectstack/core, @objectstack/objectql, @objectstack/plugin-hono-server, @objectstack/plugin-security, @objectstack/spec, touching 34 documentable anchor(s). ⚠️ 1 changed file(s) yielded no anchor (packages/spec/liveness/permission.json), so the pages documenting them are NOT COVERED by this run — this is not a clean bill of health for those files.

25 hand-written doc(s) name something this change touched — list omitted above 15 rows. Re-derive on the tree named below: node scripts/docs-audit/affected-docs.mjs --json d4c897e0e700d96e29ff8a39e91c85f2a8a30909.

⛔ 8 release-owned page(s) also affected — read-only, see AGENTS.md Documentation Guardrails.

What this run could not see

• 1 changed file(s) yielded no anchor (packages/spec/liveness/permission.json) — pages documenting those are invisible to this run
• 1 anchor(s) matched too much of the corpus to be a work list: ObjectQL (symbol, 69 pages)
• 8 name(s) were too generic to anchor anything (single lowercase words)
• 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 — 144 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 d4c897e0e700d96e29ff8a39e91c85f2a8a30909 → packageMentionDocs.

Which tree this was computed on

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

node scripts/docs-audit/affected-docs.mjs --json d4c897e0e700d96e29ff8a39e91c85f2a8a30909

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

Advisory only, and a precision-first one (#9192): a page is listed because it names a
symbol, wire route or SDK method this diff touched — not because it mentions a changed
package. Each row says which anchor put it there, so a wrong row is reportable rather than
merely annoying. To re-verify, run the docs-accuracy-audit workflow scoped to these files:
node scripts/docs-audit/affected-docs.mjs d4c897e0e700d96e29ff8a39e91c85f2a8a30909 → pass the list as
args.docs, on the commit named under Which tree this was computed on.

[objectstack-fleet]

Contract review

Served-tier: CONTRACT_REVIEW_TIER
Head-sha: f3fe6d6cfdb3352163c2ea2275f6057229e4c013

Scope read: card #18783 and all 7 comments (ruling 5725678115, retriage, re-derivation, unlock, claim, the os-dev-report read as claims, amendment 5825601266), card #19578 and PR #19622, and PR #20079's body, files and 41 check-runs, plus AGENTS.md and the code at head. The diff is 12 files, +1702/−352. No packages/spec and no governed surface is touched.

Every base-vs-head reading uses the merge base b76aad5f6. Measured in two detached worktrees (head and merge base, dist closures built under the verify lock, both removed afterwards).

① Derived judgments

• The member against its docblock: HOLDS on every clause.
  • It returns the whole map, with no object parameter: 36 / 40 / 31 / 37 entries for the four shipped subjects, including '*', the super-user seed and the apiOperations annotations.
  • It is byte-equal to the objects slot: the route and the member call one pure function. The pins (route 39/39, member 10/10) and the direct entry counts agree.
  • It throws on a resolution failure and never answers {}: the resolver's own error surfaces at the engine, with 0 rows written. {} appears only for a subject that resolves no set, which the docblock calls a real answer.
  • It is resolved at most once per write, never per row, and never cached. The counts: 1 for a 40-row bulk update, 1 for a 12-row insert, 1 for validate() over 2 rows, 0 for a system write, 0 for a no-can write even with a throwing resolver, and 2 across two writes, with a revocation seen on the second.
  • When the member is absent, the engine passes NO map: identical to base (admitted, one warn with the carries no permission data error). toEvalPermissions({}) refuses, so absent and empty stay distinguishable.
  • Real maps parse through toEvalPermissions, so a super-user's write does not fail closed on shape.
• Route byte-equality: TRUE. Whole response bodies are sha256-equal, base against head, for a super-user, a walled org admin, a member, a wall-less org admin, and no sets.
• Option visibility, base against head:
  • At base the gate fails OPEN: a can()-gated insert is admitted with a warn, and bulk update and validate() behave the same.
  • At head:
    • with no resolver, identical to base;
    • with a withholding map, refused VALIDATION_FAILED / invalid_option with 0 rows;
    • with a granting map, admitted with 0 warns;
    • with a throwing resolver, refused with its own error while the uncovered control write is still admitted;
    • with an off-shape map, refused with 0 rows;
    • a revocation between writes refuses the second write.
  • Nothing refused at base is admitted at head, and no fail-closed path opens.
• The plain-wildcard gap: reproduced, and pre-existing. With organization_admin_no_bypass + member_default, can() answers false where checkObjectPermission answers true. The base route body already lacks the entry. The head makes the write path consistent with that map. 0 in-repo authored visibleWhen predicates call can(, against a control of 35 visibleWhen lines. Filed as 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.
• The census is complete on the reviewer's own grep.
  • 13 ExpressionEngine.evaluate( code sites; current_user is passed at exactly three: evaluateOptionVisibility (wired here), applyFormulaPlan and applyFieldDefaults (value expressions, filed as objectql: a formula field or a CEL defaultValue that calls current_user.can() gets no permission data — the formula reads a silent null on every read, the default is left unset with a warn (applyFormulaPlan, applyFieldDefaults) #20082).
  • The compileCelToFilter sites fail closed on can().
  • No other reachable predicate site.
• Public surface: RIGHT.
  • @objectstack/core gains buildEffectiveObjectPermissions, four folds and two types.
  • @objectstack/objectql gains registerEffectiveObjectPermissionsResolver and EvaluateRulesOptions.permissions?.
  • plugin-security's registered service gains the optional member.
  • plugin-hono-server's export list is 34 = 34, with the six names re-exported from core (ESM identity holds). Nothing left a published export.
• CI at this head: 41 runs, all success or skipped, and all seven required contexts are green.

② Semver level

core minor, objectql minor, plugin-security minor, plugin-hono-server patch: consistent. Clause-②: yes (widening) is correct: the surface grows, nothing narrows, and packages/spec is untouched.

③ Boundary flags

• Open questions: the seat's answers are confirmed by measurement. Q1 A (the producer gap pre-exists, and the head fails closed): 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. Q2 B (yes (widening)). Q3 A (the value-expression rows): objectql: a formula field or a CEL defaultValue that calls current_user.can() gets no permission data — the formula reads a silent null on every read, the default is left unset with a warn (applyFormulaPlan, applyFieldDefaults) #20082.
• The cross-lane edits (packages/core, plugin-hono-server) follow from the docblock's "computed once". No dependency was added.
• Changeset: every sentence is TRUE, except that "one warn" is IMPRECISE: it is one per row, so a 3-row bulk update logs 3. The dev's suite totals and fixture lengths are UNMEASURED here. No added runtime string carries a tracker number.
• Nits, none blocking:
  • the two helper interfaces on the producer's signature are not exported from core's barrel;
  • EvaluateRulesOptions.permissions? is a public type widening the changeset does not mention;
  • permissionPredicateCache is an unbounded module map, the same pattern as the existing userRootCache.

Implemented-by: claude/issue-18783-server-can-permissions
Reviewed-by: session_01Bvd69VPa6puiNzzPUroDBx

VERDICT: PASS

Isolated reviewer: a contract-review-tier subagent, fed only the cards, the ruling, the PR and AGENTS.md; adopted by the seat.

[github-actions]

⛔ merge queue 构建失败 — 先分诊，再决定要不要重排

队列构建 36088336600 红了。队列跑的是全量套件（PR 侧 CI 只跑 affected 子集），
所以失败的测试可能在本 PR 没碰过的包里 —— 那不是重排能修的。每次盲目重排都会让排在后面的所有 PR 重建一轮。

失败的 job（日志抽取，best effort）：

• Test Core (1/6) — 失败步骤: Run this shard's tests

  @objectstack/spec:test:      ✓ inverts the card's measured control: the three bogus keys now FAIL parse instead of adding zero warnings  330ms
    ↳ 失败原因: (这条 FAIL 之后 12 行内没有可识别的原因行 —— 点进 job 看)
  @objectstack/spec:test:  FAIL   local  scripts/liveness/check-liveness.test.ts > check:liveness — evidence pointers (#5623) > is green against a verbatim copy of the shipped ledgers
    ↳ 失败原因: @objectstack/spec:test: AssertionError: Spec liveness gate (registry-rooted) — governed types: object, field, flow, action, hook, permission, position, agent, tool, skill, dataset, page, view, report,
  @objectstack/spec:test:  FAIL   local  scripts/liveness/check-liveness.test.ts > check:liveness — evidence pointers (#5623) > stays green when the missing path is attributed to ANOTHER repo
    ↳ 失败原因: @objectstack/spec:test: AssertionError: Spec liveness gate (registry-rooted) — governed types: object, field, flow, action, hook, permission, position, agent, tool, skill, dataset, page, view, report,
  @objectstack/spec:test:  FAIL   local  scripts/liveness/check-liveness.test.ts > check:liveness — evidence pointers (#5623) > never bounds a citation attributed to ANOTHER repo
    ↳ 失败原因: @objectstack/spec:test: AssertionError: Spec liveness gate (registry-rooted) — governed types: object, field, flow, action, hook, permission, position, agent, tool, skill, dataset, page, view, report,
  @objectstack/spec:test:  FAIL   local  scripts/liveness/check-liveness.test.ts > check:liveness — evidence pointers (#5623) > prints the citation count and how many are in range, in the documented two
    ↳ 失败原因: @objectstack/spec:test: AssertionError: Spec liveness gate (registry-rooted) — governed types: object, field, flow, action, hook, permission, position, agent, tool, skill, dataset, page, view, report,
  @objectstack/spec:test:  FAIL   local  scripts/liveness/check-liveness.test.ts > check:liveness — symbol anchors (#12516) > stays GREEN on the drifted BEFORE-state — the honest residual this grammar e
    ↳ 失败原因: @objectstack/spec:test: AssertionError: Spec liveness gate (registry-rooted) — governed types: object, field, flow, action, hook, permission, position, agent, tool, skill, dataset, page, view, report,
  @objectstack/spec:test:  FAIL   local  scripts/liveness/check-liveness.test.ts > check:liveness — symbol anchors (#12516) > prints the anchor count and how many resolve, equal on a green run
    ↳ 失败原因: @objectstack/spec:test: AssertionError: Spec liveness gate (registry-rooted) — governed types: object, field, flow, action, hook, permission, position, agent, tool, skill, dataset, page, view, report,
  @objectstack/spec:test:  FAIL   local  scripts/liveness/check-liveness.test.ts > check:liveness — the evidence-scan population (#13041) > stays GREEN when a `dead` entry carries the SAME rotted pointe
    ↳ 失败原因: @objectstack/spec:test: AssertionError: Spec liveness gate (registry-rooted) — governed types: object, field, flow, action, hook, permission, position, agent, tool, skill, dataset, page, view, report,
  @objectstack/spec:test:  FAIL   local  scripts/liveness/check-liveness.test.ts > check:liveness — the evidence-scan population (#13041) > declares every status either scanned or explicitly unscanned, 
    ↳ 失败原因: @objectstack/spec:test: AssertionError: Spec liveness gate (registry-rooted) — governed types: object, field, flow, action, hook, permission, position, agent, tool, skill, dataset, page, view, report,
  @objectstack/spec:test:  FAIL   local  scripts/liveness/check-liveness.test.ts > check:liveness — the live-elsewhere criteria (#13483) > is green on the shipped ledgers and publishes the population be
    ↳ 失败原因: @objectstack/spec:test: AssertionError: Spec liveness gate (registry-rooted) — governed types: object, field, flow, action, hook, permission, position, agent, tool, skill, dataset, page, view, report,
  @objectstack/spec:test:  FAIL   local  scripts/liveness/check-liveness.test.ts > check:liveness — the README state table (#7257) > is green against a verbatim copy, and says how many rows it checked
    ↳ 失败原因: @objectstack/spec:test: AssertionError: Spec liveness gate (registry-rooted) — governed types: object, field, flow, action, hook, permission, position, agent, tool, skill, dataset, page, view, report,
  @objectstack/spec:test:  FAIL   local  scripts/liveness/check-liveness.test.ts > check:liveness — the generated count artifact (#7377) > is green against a verbatim copy, and says the artifact is curr
    ↳ 失败原因: @objectstack/spec:test: AssertionError: Spec liveness gate (registry-rooted) — governed types: object, field, flow, action, hook, permission, position, agent, tool, skill, dataset, page, view, report,
  

↳ 失败原因 是判读的关键：超时（Test timed out in … / Hook timed out in …）多半是负载/时序，不是本 PR 的回归；
断言（AssertionError: …）才指向真实的行为改变。两者的 FAIL 行长得一模一样，只有这一行能区分。

⚠️ 断言这一侧有一类例外，判据是断言在测什么，不是它是不是 AssertionError。 断言的对象是产品行为（一个值、一个形状、一次拒收）⇒ 照上面读：真实的行为改变，去查，⛔ 不要重排掉；
断言的对象是这次实验自身的有效性前提（跑完的耗时、负载下的先后、任何只在时间预算内才成立的条件）⇒ 它跟超时是同一类，同样对负载敏感，重排一次是合法的判别手段。
识别是机械的：断言的消息或它比较的值本身点名了一段时长、一个时间戳、一个耗时计数。实测过的一对 —— AssertionError: SecurityPlugin.init() ran: expected false to be true 测的是产品行为（真回归）；
AssertionError: this run took over a second, so second-precision stamps could have differed too: expected 1006 to be less than 1000 测的是实验前提：它守护的那条不变式当时是绿的，同一个 head 原样重排一次即成功。
穿着 AssertionError 外衣的时间测量，仍然是时间测量。（⛔ 这只改「怎么读一次红」，不改「哪些测试可以重排」——后者由别处管。）

跨 PR 相同签名（24h，按失败测试文件聚合）：

• scripts/liveness/check-liveness.test.ts — 24h 窗口内只有本 PR 撞到过，暂不汇总（再有一个不同 PR 撞到就会自动开汇总 issue）。
• ⚠️ 24h 评论账本没读完（超过 5 页仍未读到窗口尽头），所以上面的「不同 PR 数」是下界，不是全量。

历史信号：

• 本 PR 过去 24h 无队列失败记录（首次）。
• 过去 24h 队列共有 0 个失败构建（不含本次）。

分诊清单：

1. 失败测试在本 PR 改动的包里 → 真回归，修 PR。
2. 失败测试与本 PR 无关 → 看上面的「跨 PR 相同签名」；已有汇总 issue ⇒ flaky/环境问题实锤，去那张 issue 上谈，修好前重排只会再烧一轮全队列。
3. 两者都不是 → 可能与同组 PR 语义冲突；等前面的 PR 落地或失败出队后再重排一次即可，不要连续重排。

---

Generated by Claude Code · merge-queue-triage workflow (#4859)

[objectstack-fleet]

Contract review

Served-tier: CONTRACT_REVIEW_TIER
Head-sha: 7a6b091b2a6f589481398f5772d107f02b9071fe

Scope: the delta over PASS 5825901229 (at f3fe6d6c), after the merge queue removed the PR on the spec liveness gate (queue run 36088336600).

① Derived judgments

• The delta is one commit and one file: RIGHT. f3fe6d6c..7a6b091b is 1 commit, M packages/spec/liveness/permission.json, +3/−3: the verifiedAt, evidence and note of objects.allowExport. status: live is unchanged, and nothing else changed.
• Every new or changed sentence is TRUE at this head:
  • packages/core/src/security/effective-object-permissions.ts#annotateEffectiveApiOperations exists. The quoted const exportBit = acc.allowExport ?? wildExport is byte-exact, and the per-object bit is read before the '*' fallback.
  • buildEffectiveObjectPermissions composes it, and is called by both the /auth/me/permissions handler and SecurityPlugin.getEffectiveObjectPermissions.
  • plugin-hono-server re-exports the names.
  • allowExport has 0 word-bounded mentions in current-user-endpoints.ts and 7 in the core file.
  • enforceExportPermission answers 403 EXPORT_NOT_PERMITTED off security.canExport, fail-closed on a throw, and canExport asks checkObjectPermission('export', …).
• The liveness gate is green at this head, and red at the old ledger:
  • pnpm --filter @objectstack/spec check:liveness exits 0 (756/756 symbol anchors; 612 pairs, 611 anchored, 1 exempt), and check-liveness.test.ts gives 64/64.
  • The control, the same tree with permission.json at the f3fe6d6c blob, exits 1 with 1 UNANCHORED (permission/objects.allowExport → …/current-user-endpoints.ts). That is the queue's finding.
• Sweep for other pointers the PR's moves left false: none.
  • current-user-endpoints.ts# plus a moved symbol: 0.
  • The ledgers' remaining current-user-endpoints.ts citations (systemPermissions, tabPermissions) still resolve and name their keys.
  • scripts/adr-anchors: 0.
• CI at this head: 35 runs, 32 success, 3 skipped, 0 failures. Spec property liveness is success, all seven required contexts are success, and mergeable_state is clean.

The judgments of PASS 5825901229 stand for everything outside this delta.

② Semver level

The delta moves no schema, export, authorable key or ledger status. Clause-②: yes (widening) and the changeset's grades stand.

Nit: liveness/ ships in @objectstack/spec's files, and the changeset carries no @objectstack/spec line. Spec is in the same fixed group, so it is versioned and published with the others anyway; only its CHANGELOG line is missing. On main, 24 of 30 ledger-only edits carried one. Non-blocking.

③ Boundary flags

• The prior record's "No packages/spec … is touched" is stale at this head, because the ledger (not the Zod contract) is now touched. The PR body's patch-round-1 section states this. No governed surface is touched, and Governed Surface Queue Guard is green.
• The commit's "re-closed the entry's three legs" matches the three legs re-read above.

Implemented-by: claude/issue-18783-server-can-permissions
Reviewed-by: session_01Bvd69VPa6puiNzzPUroDBx

VERDICT: PASS

Isolated reviewer: a contract-review-tier subagent, scoped to the delta over record 5825901229; adopted by the seat.