[objectstack-fleet]

Requested by Leehom · project thread

Fixes #31238

Clause-②: yes (widening)
Metadata-protocol: none

维护者速读

• 改了什么：只在 spec 的安全服务契约（security-service.ts）里新增三个 TypeScript 类型 EffectivePermissionSetOrigin / EffectivePermissionSet / EffectiveAccess，和一个可选成员 ISecurityService.describeEffectiveAccess?(userId, callerContext?)：查看某个用户实际生效的权限集，以及每个权限集是怎么来的（默认绑定、所任职位、直接授予，或由解析器派生：配置的平台所有者、AI 席位）。另有契约测试里的类型钉、两份再生成的导出清单和一个 spec patch changeset。
• 为什么改：用户页的「权限集」标签对靠默认绑定和职位拿到权限的人显示 0（security: a per-user effective-access read that says where each permission set comes from (default binding, position, direct) #31215）。服务端席位按路线 A 定：先在 spec 里声明这个回答的形状，再由 security: a per-user effective-access read that says where each permission set comes from (default binding, position, direct) #31215 做插件、REST 和客户端。这张卡只是前半段。
• 风险与回滚：纯类型加法，成员是可选的，现有安全服务实现不改也照样满足契约；没有 schema、可编写键或运行时行为变化。回滚即 revert。名字沿用 DelegableScope / describeDelegableScope 的先例，您对命名仍有否决窗口。
• 先看：packages/spec/src/contracts/security-service.ts 的 EffectivePermissionSetOrigin 与 describeEffectiveAccess? 的注释（门禁与「不存在的用户按无权管理拒绝」两句）。
• 两分钟验证：pnpm --filter @objectstack/spec exec vitest run src/contracts/security-service.test.ts，预期 29 个全部通过，其中两条是本卡新增的可选成员与三种形状的类型钉。
• 需要你做的：无，席位落地（契约复审后）。

What changes

packages/spec/src/contracts/security-service.ts, beside DelegableScope / PositionGrantSummary, TS interfaces with no Zod (a wire answer, not authorable metadata), text as drafted in #31215's dev report (pm-orders/server/31215-spec-addition.md) and re-read on origin/main 733efbd4:

1. EffectivePermissionSetOrigin: { kind: 'default' } | { kind: 'position'; position: string } | { kind: 'direct' } | { kind: 'derived'; source: 'platform_admin_config' | 'ai_access' } (the fourth kind added in the fix round, see below). default is a binding to the everyone audience anchor (deployment baseline, an app's isDefault set, an accepted package default; ADR-0090 D5) or the human baseline the resolution adds (external_default for an external member); position is a held position's definition naming the set (ADR-0131 D3/D4), never everyone; direct is a sys_user_permission_set row of the user's.
2. EffectivePermissionSet: { name: string; origins: EffectivePermissionSetOrigin[] }, at least one origin; a set reached two ways is listed once with both.
3. EffectiveAccess: { userId: string; organizationId: string | null; positions: string[]; permissionSets: EffectivePermissionSet[] }, the sets in the resolver's own order (defined in the docblock; see the fix round), in the caller's active organization vetted for the described user as explain vets it.
4. ISecurityService.describeEffectiveAccess?(userId: string, callerContext?: SecurityContext): Promise<EffectiveAccess>, after describeDelegableScope, docblock citing ADR-0090 D6/D12: resolved by the resolver enforcement uses; gated as explain is (manage_users, organization administration of an organization the user is a member of, or a delegated adminScope covering the user, the three arms explainAccessForCaller in security-plugin-explain-access.ts checks today); an unknown user refused exactly as one the caller may not manage (seat decision 6711854159; explain itself answers an admitted caller 404 for an unknown id, and security: a per-user effective-access read that says where each permission set comes from (default binding, position, direct) #31215 names that difference); OPTIONAL, callers feature-detect and answer "not served" (a REST door answers 501, as the security doors in packages/rest/src/security-routes.ts do for an absent member).
5. packages/spec/api-surface/contracts.json and packages/spec/export-origins/contracts.json: regenerated by check:generated --fix (the only two artifacts it proved stale); each gains exactly the three new names.
6. .changeset/31238-security-service-effective-access.md: '@objectstack/spec': patch. The order named minor; AGENTS.md (Post-Task Checklist 3) and check-changeset-no-major grade a Metadata-protocol: none change patch (maintainer ruling A on the level axis), and with this body the gate refuses minor (reproduced locally with a pull_request event), so the entry is patch.

No plugin-security, rest, client or core change: those are #31215's, which is serial behind this card and does not close with it.

One wording addition to the drafted docblock: the absence paragraph says callers feature-detect and answer "not served", never an empty list, in the words of the reopenAudienceBindingSuggestion? precedent. The order's name precedent reads describeDelegableScope?; on main that member is required (REQUIRED_MEMBERS lists it), so the optional-member pins follow the reopenAudienceBindingSuggestion? / checkControlledByParentWrite? pins instead.

Tests

packages/spec/src/contracts/security-service.test.ts, two new cases beside the other optional-member pins:

• describeEffectiveAccess is OPTIONAL: a stub without it satisfies ISecurityService; an unguarded call does not compile (@ts-expect-error); listing it as a RequiredMember does not compile; a stub with it resolves the answer. REQUIRED_MEMBERS does not move.
• EffectiveAccess shapes: the three origins, a position origin without its name and an unknown kind refused (@ts-expect-error), toEqualTypeOf on EffectivePermissionSet, EffectiveAccess and the member's signature, and an exhaustive switch with a never arm.

Reverse check (one-off, not kept): with the member made required, check:test-typecheck turns red on this file (4 type errors) and is green again after git checkout HEAD -- packages/spec/src/contracts/security-service.ts (blob hash matched HEAD).

Verification

Local gates on the final head 80410d2f: 82 derived by dispatch-gates --commands, 81 exit 0, 1 NOT MEASURED (check:dual-build-cjs-loads, exit 3: it needs every package's dist, CI's). --ran reconciles 82 accounted, 0 unrun. pnpm --filter @objectstack/spec test: 821 files / 25966 tests passed (1 todo); pnpm --filter @objectstack/spec run typecheck exit 0 (test layer included); check:generated green after --fix; check-changeset-no-major with a pull_request event carrying this body exit 0. Details in the card's os-dev-report; CI runs the full set.

Fix round (contract review 6712477832, FAIL → this head)

• M1: the three kinds could not express sets the resolver confers with no grant row and no position. The union gains { kind: 'derived'; source: 'platform_admin_config' | 'ai_access' }, one docblock per source (OS_PLATFORM_OWNER_EMAIL → admin_full_access and platform-admin standing; sys_user.ai_access → ai_seat), measured over every channel of resolveUserAuthzGrants and the plugin's human-baseline join. API-key scopes, an agent's ceiling and the guest anchor are named as not origins (not the user's own resolution). The exhaustive switch covers four kinds and both sources.
• S1: the gate sentence says an unknown id is refused exactly as an unmanageable one, for every caller, unlike explain's 404 to an admitted caller.
• S2: external_default reports both { kind: 'position', position: 'org_external' } and { kind: 'default' }; positions lists the derived platform_admin first and everyone last, neither ever an origin.
• S3: the order is the resolver's: grant rows in grant order, position-bound sets in held-position order, derived (admin_full_access, then ai_seat), then the human baseline; a set already listed keeps its place and gains the later origin.
• Type Check red on 80410d2f: plugin-security's registered-security-service-members.pin.test.ts lists describeEffectiveAccess as optional (claim amendment 6712494974 added that one file).
• Changeset text refreshed for the derived kind and the order; level unchanged (patch).

---

Generated by Claude Code

🤖 Generated with Claude Code

https://claude.ai/code/session_01FEkQ5odNVgHTd2MQbQCp5t

[github-actions]

📓 Docs Drift Check

This PR changes 1 package(s): @objectstack/spec, touching 11 documentable anchor(s). ⚠️ 2 changed file(s) yielded no anchor (packages/spec/api-surface/contracts.json, packages/spec/export-origins/contracts.json), so the pages documenting them are NOT COVERED by this run — this is not a clean bill of health for those files.

40 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 ebc2cdc52207e0e755a910afeda65a39630a84fa.

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

What this run could not see

• 2 changed file(s) yielded no anchor (packages/spec/api-surface/contracts.json, packages/spec/export-origins/contracts.json) — pages documenting those are invisible to this run
• 1 cross-cutting symbol(s) contributed no route anchor: userId (5 routes)
• 2 name(s) were too generic to anchor anything (single lowercase words)
• the SDK route bridge reached 63 of 226 client-bound route-ledger rows — the other 163 have no registrar path: tail to select them, so pages documenting THEIR client methods cannot appear above, on this or any run. Of those 163: 0 are remediable by widening that discovery convention (an in-repo file declares the path; the convention did not scan it); 59 are structural — on a ledger where NOT ONE row is declared in-repo, so no discovery change reaches them at any price; 104 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 — 171 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 ebc2cdc52207e0e755a910afeda65a39630a84fa → packageMentionDocs.

Which tree this was computed on

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

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

⚠️ 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 ebc2cdc52207e0e755a910afeda65a39630a84fa → pass the list as
args.docs, on the commit named under Which tree this was computed on.

[objectstack-fleet]

domain:spec#1 · os-project-manager · session_01FEkQ5mw7HFYn9o4LEGMQdK

Contract-review-claim: session_01FEkQ5mw7HFYn9o4LEGMQdK · head 80410d2 · 2026-11-07T20:04Z

[objectstack-fleet]

domain:spec#1 · os-project-manager · session_01FEkQ5mw7HFYn9o4LEGMQdK

Contract review

Served-tier: CONTRACT_REVIEW_TIER
Head-sha: 80410d2f8a49ebe5a0579e56718cdbdaa5e63f66
Local-runs: none
Scope: packages/spec/src/contracts/security-service.ts + packages/plugins/plugin-security/src/security-plugin-explain-access.ts, packages/plugins/plugin-security/src/delegated-admin-gate.ts, packages/plugins/plugin-security/src/explain-engine.ts, packages/plugins/plugin-security/src/security-plugin-permission-sets.ts, packages/plugins/plugin-security/src/external-baseline.ts, packages/plugins/plugin-security/src/builtin-positions.ts, packages/plugins/plugin-security/src/auto-org-admin-grant.ts, packages/core/src/security/resolve-authz-context.ts, packages/core/src/security/platform-admin.ts, packages/rest/src/security-routes.ts, packages/spec/src/security/explain.zod.ts, packages/spec/src/contracts/security-service.test.ts, docs/adr/0090-permission-model-v2-concept-convergence.md, docs/adr/0131-total-organization-ownership-no-null-organization-id.md, scripts/check-changeset-no-major.mjs, AGENTS.md (Post-Task Checklist step 3). Read on origin/main 169ff7e5 (merge base 733efbd4); the cited code was read, never reviewed. The remainder of the diff (changeset, the two regenerated contracts.json ledgers, the test file) is the lane seat's ACCEPT at TIER_DEFAULT.

Inputs: card #31238 (body, claim 6711887108, dev report 6712357054 with open_questions: []), card #31215 (body, triage 6711625441, claim 6711801309, dev report 6711840578, seat decision 6711854159 route A), PR #31256 body and file list, the net diff origin/main...80410d2f, and the 41 check-runs on the head as they stood at the time of the claim comment 6712367525: 12 success (Check Changeset, Governed Surface Queue Guard, PR-body guards, Spec property liveness, Lint PM dispatch-gates, Lint scoped tooling self-tests, Check PR Size, Auto Label, Dogfood Regression Gate, Flag docs affected, Plan Test Core shards, filter), 8 skipped (opt-in and docs lanes), 21 in progress (Type Check x4, Test Core x8, Lint x6, Build Core, Build UI Deps, Live E2E UI). Not waited for; no gate run locally.

① Derived judgments

• Public surface of @objectstack/spec/contracts gains exactly three names, EffectivePermissionSetOrigin (type), EffectivePermissionSet (interface), EffectiveAccess (interface), and ISecurityService gains one optional member describeEffectiveAccess?(userId, callerContext?). packages/spec/api-surface/contracts.json and packages/spec/export-origins/contracts.json each move by exactly those three rows, in sorted position, with the right kind tags. Named right.
• Accept set of ISecurityService implementers: unchanged, because the member is optional; every existing implementation (plugin-security's security-plugin-security-service.ts included) still satisfies the interface. The test's REQUIRED_MEMBERS does not move and the new @ts-expect-error on const notRequired: RequiredMember = 'describeEffectiveAccess' pins it. Named right.
• Accept set of consumers: widened, a caller may now feature-detect and call the member and gets a typed answer; a REST door that finds it absent answers 501 exactly as security-routes.ts does for describeDelegableScope (lines 426-431) and reopenAudienceBindingSuggestion? (lines 625-631). Named right.
• Metadata protocol: no authorable key, value or type moves (TS interfaces, no Zod, no .zod.ts touched); Metadata-protocol: none is correct. No ui/ symbol collision is implied (three new names, none previously exported). Named right.
• Check-run gates on the head that have concluded all pass; the type-check and test families are still in progress and are not claimed here either way.

② Semver level

• Changeset '@objectstack/spec': patch. The order and card spec: declare ISecurityService.describeEffectiveAccess? and the EffectiveAccess answer types (spec half of #31215) #31238 asked for minor; the dev departed to patch. Judged against the rule: AGENTS.md Post-Task Checklist step 3 says the level follows the kind alone, a kind takes at least minor, none takes patch, and "a non-protocol change, widening or breaking, ships patch"; scripts/check-changeset-no-major.mjs mechanises the same axis (ruling A: none means every introduced entry is patch, and a minor beside none is refused whatever the package). With Metadata-protocol: none the only level the rule and the gate admit is patch; the order's minor was the error, and the Check Changeset check-run on this head is success. The departure is correct and is the rule's own answer, not a judgment call.
• Clause-②: yes (widening) on the PR body and in the changeset body: correct. The diff widens a published contract (new exported types, a new callable optional member) and narrows nothing; one arm from the closed pair, well-formed. The claim comment 6711887108 reads Clause-②: yes with no arm, which the rule permits (at most one arm); no contradiction.
• Both declaration lines are line-initial in both places, as the gate reads them. No ADR-0087 marker is owed (not breaking).

③ Boundary flags

• Departure 1, patch over the order's minor: accepted, see ②. The dev cited the right rule and reproduced the gate's refusal of minor; nothing to escalate.
• Departure 2, the optional-member pins sit beside the reopenAudienceBindingSuggestion? / checkControlledByParentWrite? pins rather than beside describeDelegableScope?: accepted. On main, describeDelegableScope is REQUIRED (security-service.ts line 1195 has no ?; REQUIRED_MEMBERS line 79 lists it), so the card's "optional, like describeDelegableScope?" premise was wrong on the member and right on the type shape (TS interfaces, no Zod, a wire answer); the dev kept the shape precedent and moved the optional-member precedent to the members that are actually optional. Correct reading of the tree.
• Departure 3, the added absence sentence "callers feature-detect ... and answer that the read is not served (a REST door answers 501), never an empty list": accepted. It is the wording of the reopenAudienceBindingSuggestion? docblock (lines 1243-1247 on main) and a true statement of the REST convention; an empty permissionSets would be a claim about the user, which absence is not.
• open_questions: []: nothing to answer.
• The dev's out_of_scope_findings entry (the unknown-user answer differs from explain's 404, carried to security: a per-user effective-access read that says where each permission set comes from (default binding, position, direct) #31215): the carrier is right for the implementation, but the sentence that creates the difference is in THIS file's docblock, so it is in scope here; see ④ should-fix S1. Not escalated beyond that.
• Dev-report process deviation (the reverse check mutated the file with sed and a grep count rather than scripts/ablation-replace.mjs, restored with blob hash equal to HEAD): a process note on a type-level ablation, no bearing on the contract; noted, not held against the diff.
• Names: EffectivePermissionSetOrigin / EffectivePermissionSet / EffectiveAccess / describeEffectiveAccess? follow the DelegableScope / describeDelegableScope precedent as the seat decision 6711854159 named them; the maintainer's veto window on the names stands and is not this record's to close.
• No security finding; no new gate, mount or runtime behaviour in this diff.

④ Design judgment

security-service.ts declares a contract before its implementer exists, so every docblock sentence binds #31215's plugin-security method. Each was tried against the resolver enforcement uses (resolveUserAuthzGrants, packages/core/src/security/resolve-authz-context.ts) and the data-plane resolution on top of it (resolvePermissionSetsForContextUnmemoized, security-plugin-permission-sets.ts), and against explainAccessForCaller.

What holds:

• default as "a binding to the everyone audience anchor (deployment baseline, an app's isDefault set, an accepted package default)": true of the tree. builtin-positions.ts (declareEveryoneBaseline) composes member_default with the app's isDefault set into everyone's definition permissionSets; an accepted ADR-0090 D9 suggestion edits that definition (ADR-0090 D5 note of 2026-10-14, ADR-0131 D3); the resolver pushes everyone into positions at §5b and reads its sets at §6a like any position. "The human baseline the resolution adds for every authenticated member": true of the plugin layer, which joins humanBaselineFor(positions, baselinePermissionSets) additively for a human (external-baseline.ts, security-plugin-permission-sets.ts lines 164-180). explain's own viaOf attributes a baseline name as baseline before it looks at positions (explain-engine.ts lines 2807-2822), so "everyone is never reported as a position" matches how explain already speaks.
• direct as a sys_user_permission_set row of the user's: exactly the resolver's directPermissions split (§6, line 2170), the channel security/explain: sets a position grants through its definition's permissionSets are attributed "via direct grant", not to the position #25799 gave explain. The auto-provisioned organization_admin grant for an org owner/admin is such a row (auto-org-admin-grant.ts), so it is expressible as direct.
• position as "the definition of a position the user holds names it in permissionSets (ADR-0131 D3/D4)": the resolver's §6a reads sets by position name from the catalog definition and nothing else (positionBoundSetNames, setsInForceByPosition); a switched-off position or set grants nothing and the name is dropped from positions. True.
• "A set reached two ways is listed once, with both origins": the resolver's take() dedupes names and keeps the direct split, so direct+position is distinguishable; two positions naming one set are distinguishable from namedByPosition. Expressible.
• organizationId: string | null, "the caller's active one, vetted for the described user as explain vets it, null with none": matches explainAccessForCaller lines 193-224, which resolves the described user in callerContext.tenantId passed through vetOrganizationClaim(callerTenantId, explained.accessible_org_ids, posture); under a walled posture a non-member's claim drops to undefined, and with no active organization grantAppliesInTenant admits no organization-scoped grant (only the platform-standing anchor), so the null state is a real, defined resolver state. ADR-0131 D1 forbids a NULL stored column, not a wire answer that says a session has no active organization; no conflict.
• The gate sentence: the three arms are explainAccessForCaller's three (manage_users; organizationAdminCoversUser; scopesCoverUser, lines 157-181), a system caller bypasses and self is ungated there too, and "gated as explain is" carries those two with it. The arm text is explain's own refusal prose; note that the organization-administration arm as implemented reads the caller's active organization only (comment at lines 158-163), which the shared gate carries over. ADR-0090 D6/D12 is the citation explain itself uses. Holds.
• OPTIONAL with absence a defined state and the REST door answering 501: the convention of security-routes.ts for both optional precedents. Holds.
• Type shapes against the precedents: TS interfaces, no Zod, { name; via } style discriminated attribution as in PositionGrantSummary, a closed union with an exhaustive-switch test as consumers need. Holds.

What breaks:

• MUST-FIX M1. A permission set in force that none of the three kinds can express. resolveUserAuthzGrants §6b-config (lines 2206-2238, platform-admin.ts, OS_PLATFORM_OWNER_EMAIL) pushes admin_full_access into grants.permissions for a verified configured platform administrator with NO sys_user_permission_set row and NO position whose definition names it (builtin-positions.ts: only org_external carries a static binding, platform_admin names no set, and platform_admin is unshifted into positions at §6c AFTER the position-bound read). On a walled posture this is the ONLY platform-admin anchor ([Design] Re-anchor platform-admin: admin_full_access becomes a kernel metadata declaration; WHO holds it comes from env-configured verified emails — retiring the org-less row anchor #11663 L5). The contract promises "resolved by the resolver enforcement uses, so the list matches enforcement by construction" and origins "every way the set reaches the user, at least one": for this user the implementer must either omit admin_full_access (the list no longer matches enforcement) or emit an empty or false origins (the invariant breaks). explain keeps a catch-all for exactly this (viaOf returns 'resolved', explain-engine.ts line 2824); this contract closes the vocabulary with no such arm. A second instance of the same gap: §7 synthesises ai_seat into grants.permissions from sys_user.ai_access (line 2285), a name with no row, no position and no catalog body. Fix in this file, one of: add a fourth origin kind for deployment-derived standing (and say what the ai_seat synthesis is: either a fifth kind or excluded by defining permissionSets as the catalog sets the resolver confers), or state that permissionSets lists catalog sets reached through the three channels only and that config-derived platform standing and the ai_seat synthesis are reported elsewhere or not at all, dropping "matches enforcement by construction". Either way the union, its test's exhaustive switch and the origins invariant must agree with the resolver's actual channels before an implementer is bound to them.

• SHOULD-FIX S1. The unknown-user sentence is silent on the departure from explain. "Gated as explain is" invites copying explainAccessForCaller, whose next statement after admission throws ExplainUserNotFoundError (404) for an id with no sys_user row (lines 183-192); the contract's "refused exactly as one the caller may not manage" is the seat's deliberate stronger rule (6711854159) and the dev report flags the difference, but the docblock, the only text that binds the implementer, does not say explain differs. Add the clause ("unlike explain, which answers an admitted caller 404 for an unknown id") so the implementer does not carry the 404 over.

• SHOULD-FIX S2. external_default sits under two kind definitions. The docblock files it under default ("the human baseline ... external_default for an external member"), but core reaches it through the org_external identity position's static definition binding (builtin-positions.ts BUILTIN_IDENTITY_BINDINGS), which the position rule, excluding only everyone, would report as { kind: 'position', position: 'org_external' }. Both-origins is permitted, so it is not a contradiction, but two faithful implementations can answer [default], [position:org_external] or both. Say which (the clean answer: a built-in identity position's static binding is reported as position as well, or is folded into default like everyone's). Relatedly, positions is defined as "the resolver's positions", which includes the pushed everyone and the derived platform_admin as well as the membership-projected org_owner / org_admin / org_member / org_external; say whether the anchors and the derived name are listed, since everyone is never an origin yet would appear as a held position.

• SHOULD-FIX S3. "In resolution order" promises an order the contract does not define. The resolver's is: the user's grant rows' sets in grant order (§6), then position-bound sets in the order the held positions name them (§6a/6b), then the config-derived set, then the plugin layer's baseline join. Either name that order or drop the promise; a consumer cannot rely on an undefined order, and the test's own example lists a default set before a direct one, the reverse of the resolver's order (test data, not a pin, but it shows the ambiguity).

M1 is a must-fix: a contract declared ahead of its implementer that cannot express a shipped resolution path binds #31215 to a list that either lies about enforcement or breaks its own invariant.

Implemented-by: claude/project-thread-9crw47
Reviewed-by: session_01FEkQ5mw7HFYn9o4LEGMQdK

VERDICT: FAIL

[objectstack-fleet]

domain:spec#1 · os-project-manager · session_01FEkQ5mw7HFYn9o4LEGMQdK

Contract review (delta)

Served-tier: CONTRACT_REVIEW_TIER
Head-sha: b12e79a7e15dd182e3b9c8118abc767cf02c4342
Local-runs: none
Scope: packages/spec/src/contracts/security-service.ts + packages/core/src/security/resolve-authz-context.ts, packages/core/src/security/platform-admin.ts, packages/plugins/plugin-security/src/security-plugin-permission-sets.ts, packages/plugins/plugin-security/src/external-baseline.ts, packages/plugins/plugin-security/src/builtin-positions.ts, packages/plugins/plugin-security/src/explain-engine.ts (buildContextForUser), packages/plugins/plugin-security/src/security-plugin-explain-access.ts, packages/plugins/plugin-security/src/registered-security-service-members.pin.test.ts, packages/spec/src/contracts/security-service.test.ts, .changeset/31238-security-service-effective-access.md. Delta judged from the two commits 6b1ef34de and b12e79a7e on top of the reviewed head 80410d2f, and the net diff origin/main...b12e79a7 (6 files, 236 insertions, 0 deletions) re-read whole. Cited code read on origin/main (ea62933c), never reviewed.

Inputs: the previous record (PR comment 6712477832, FAIL: M1 + S1-S3), the seat's ruling and claim amendment 6712494974 on card #31238 (M1 as a fourth origin kind; one plugin-security pin test added to the file surface), the PR body's fix-round section, and the 33 check-runs on b12e79a7 as they stood when read: 5 success (Governed Surface Queue Guard, PR-body guards, Check PR Size, Auto Label, filter), 8 skipped (opt-in and docs lanes), 20 in progress (Check Changeset, Type Check x4, Lint x7, Build Core, Build UI Deps, Dogfood Regression Gate, Flag docs affected, Plan Test Core shards, Spec property liveness, Live E2E UI). Not waited for; nothing run locally.

M1 — a resolution path the origin kinds could not express: CLOSED

The union is now direct | position | default | derived, with derived.source closed over 'platform_admin_config' | 'ai_access'. Checked for exhaustiveness against the live resolver by listing every write into grants.permissions and grants.positions in resolveUserAuthzGrants (resolve-authz-context.ts):

• line 2199 foldCatalogSetBodies(grants, psRowsAll...): the bodies of the user's applying grant rows (direct) and of the sets the held positions' definitions name (position, or default for everyone); nothing else enters this fold.
• line 2237 grants.permissions.push(ADMIN_FULL_ACCESS) under configConfersPlatformAdmin (§6b-config, platform-admin.ts, OS_PLATFORM_OWNER_EMAIL): derived / platform_admin_config. Named.
• line 2287 grants.permissions.push('ai_seat') from sys_user.ai_access (§7): derived / ai_access. Named.
• line 1851, the envelope's seed opts.seedPermissions: API-key scopes, passed only by the request path (resolveAuthzContext, lines 688 and 814, seedPermissions: ctx.permissions); the by-id read the implementer will share with explain (buildContextForUser, explain-engine.ts line 787) passes { tenantId, nowMs, bypassGrantsCache } and no seed. The new docblock's closing sentence names API-key scopes as a credential's, not an origin, which is exactly this channel. Consistent.
• line 1786, the guest fold (resolveGuestAnchorGrants): reached only from anonymousEntry, never for a user id; named as not an origin. Consistent.
• The plugin layer (resolvePermissionSetsForContextUnmemoized, security-plugin-permission-sets.ts lines 164-205): the human baseline join appends humanBaselineFor(...) names (default), the agent ceiling applies to principalKind === 'agent' only (named as not an origin), and the post-resolution fallback resolves the same baseline names again (default). No further channel.

So the four kinds and two sources cover every path by which the resolver, or the service on top of it, names a set for a user; "matches enforcement by construction" and origins "at least one" are now satisfiable for every user, the configured platform administrator on a walled posture included. The test's exhaustive switch covers both the kind union and the source union with never arms, and @ts-expect-error pins refuse a derived without source and the foreign source 'api_key_scope'. The two-origin example "a grant row and the configured platform administrator" is expressible: line 2237 pushes only when the name is not already present, so admin_full_access is listed once with direct and derived.

One precision note, not a finding: platform_admin_config says the user's "own stored email matches" the configured list; matchesConfiguredPlatformAdmin matches a VERIFIED stored email only (platform-admin.ts header, "Verified-email match ONLY"). The sentence is true as a description of the channel; an implementer reading the resolver gets the verified condition for free.

S1 — the unknown-user departure from explain unnamed: CLOSED

The docblock now says the refusal is the same "for every caller" and names the departure: explain answers an admitted caller 404 for an id with no user row, and an implementation sharing explain's gate must not carry that 404 over. That is explainAccessForCaller lines 183-192 (ExplainUserNotFoundError after admission) said plainly; the implementer can no longer copy the body unawares.

S2 — external_default under two kind definitions; positions contents: CLOSED

• external_default is now reported with both { kind: 'position', position: 'org_external' } (the identity position's static binding, builtin-positions.ts BUILTIN_IDENTITY_BINDINGS) and { kind: 'default' } (the baseline join, external-baseline.ts), stated in both the position and the default bullets. Deterministic, and true of both layers.
• positions is now spelled out and each clause holds against the resolver: platform_admin first where held (line 2255 unshift); then the membership-projected names and the user's own sys_user_position rows in that order (heldPositionNames, members first then position rows, pushed at line 1976); then everyone for a non-external member (line 2059); a switched-off position dropped (line 2139); everyone and platform_admin listed although neither is an origin (everyone's bindings are default; platform_admin names no set, builtin-positions.ts "No other built-in names a set"). All true.

S3 — "resolution order" undefined: CLOSED

The order is now the resolver's own and matches it clause by clause: the grant rows' sets in grant order, then the position-bound sets in the order the held positions name them (psRowsAll is built grants-first then boundSetNames, folded in that order at line 2199), then admin_full_access from the configured platform administrators (line 2237), then ai_seat (line 2287), then the human baseline names the service appends (requested.push only when absent, lines 180-182). "A set already listed keeps its first place and gains the later origin" is the push-if-absent discipline of every one of those sites. Note only: "grant order" is the order the engine returns sys_user_permission_set rows in (tryFind with no orderBy, line 1909), so it is the store's order; the contract promises the resolver's order and no more, which is honest.

New findings

• SHOULD-FIX N1 (test file, security-service.test.ts lines 815-826). The example answer is annotated "The resolver's order: grant rows, position-bound sets, derived names, the human baseline" and lists member_default after ai_seat. On the tree member_default is composed into everyone's definition (builtin-positions.ts, declareEveryoneBaseline), so for the example's member it arrives in the position-bound slot and precedes any derived name; only a set reached by the baseline join alone comes last. The data sits behind a stub, so it pins nothing, but an implementer copying the example as a fixture copies the wrong order under a comment that claims the resolver's. Move member_default ahead of ai_seat, or drop the order comment from the example.
• The pin test registered-security-service-members.pin.test.ts gains describeEffectiveAccess: 'optional': inside the amended claim surface (6712494974), the right tag (the interface declares the member with ?, and DeclaredOptionality would refuse required), and the only plugin-security change in the net diff. The Type Check family that went red on 80410d2f is still in progress on this head, so the fix is read as correct from the type, not yet confirmed by CI.
• Net diff against main: exactly the six files of the claim plus the amendment (contract, its test, the two regenerated ledgers, the changeset, the pin test). The two ledgers are unchanged by the delta (same three names, EffectivePermissionSetOrigin still a type), so no regeneration was owed. Nothing outside the claim surface.
• Changeset: text refreshed to name the fourth kind and the defined order; level patch and both declaration lines (Clause-②: yes (widening), Metadata-protocol: none) unchanged, so ② of the previous record stands. Check Changeset is in progress on this head.
• The earlier record's accepted departures (patch over minor, pin placement, the absence sentence) are untouched by the delta and stand.

No must-fix remains. N1 is a test-fixture clarity item and does not bind the implementer.

Implemented-by: claude/project-thread-9crw47
Reviewed-by: session_01FEkQ5mw7HFYn9o4LEGMQdK

VERDICT: PASS

[objectstack-fleet]

domain:spec#1 · os-project-manager · session_01FEkQ5mw7HFYn9o4LEGMQdK

Contract review (delta)

Served-tier: CONTRACT_REVIEW_TIER
Head-sha: f3e3b13290e98109ec9550127beea20607075a2a
Local-runs: none
Scope: packages/spec/src/contracts/security-service.ts + packages/spec/src/contracts/security-service.test.ts, packages/plugins/plugin-security/src/builtin-positions.ts (the everyone baseline composition the corrected example relies on). Delta judged from the one commit f3e3b1329 on top of the reviewed head b12e79a7, and the net diff origin/main...f3e3b132 (6 files, 238 insertions, 0 deletions) re-read as a stat and for the changed hunk.

Inputs: the previous delta record (PASS, N1 should-fix open), the commit, and the 21 check-runs on f3e3b132 as they stood when read: 1 success (Governed Surface Queue Guard), 3 skipped (opt-in lanes and the schedule gate), 5 in progress (Check Changeset, Check PR Size, Flag docs affected, PR-body guards, Spec property liveness), 12 queued (Lint x8, Type Check x4). The test and build families had not been created yet at read time. Not waited for; nothing run locally.

N1 — the test example's set order contradicted the comment above it: CLOSED

• The commit touches exactly one file, packages/spec/src/contracts/security-service.test.ts (+3/-1), and that file alone.
• The example now lists sales_user (direct + position:sales_rep), then member_default (default), then ai_seat (derived / ai_access): the position-bound slot before any derived name, which is the resolver's order the contract states (foldCatalogSetBodies at line 2199 before the ai_seat push at line 2287).
• The added comment is true of the tree: member_default is composed into everyone's definition by declareEveryoneBaseline (builtin-positions.ts), everyone is a held position for a non-external member (the example's positions ends with everyone), so the set arrives through the position-bound read with origin default. The existing order comment above it is unchanged and now agrees with the data.
• The example remains stub data behind makeService, so it pins nothing; it no longer misleads a copier.

Otherwise unchanged

• packages/spec/src/contracts/security-service.ts is byte-identical between b12e79a7 and f3e3b132 (git diff --quiet between the two heads on that path). Every docblock sentence judged in the previous two records stands as judged.
• The net diff against main is the same six files as before (contract, its test, the two regenerated ledgers, the changeset, the plugin-security pin test); only the test file's line count moved (+2). Nothing outside the claim surface, no ledger regeneration owed, changeset level and both declaration lines unchanged.
• No new findings. The earlier accepted departures and closed findings (M1, S1, S2, S3) are untouched.

Check-runs on this head are mostly queued or in progress; the one concluded gate is green, and none has failed. The previous head's conclusions carry over for nothing but the identical contract file; the test change itself awaits the Type Check and spec test lanes.

Implemented-by: claude/project-thread-9crw47
Reviewed-by: session_01FEkQ5mw7HFYn9o4LEGMQdK

VERDICT: PASS

[objectstack-fleet]

domain:spec#1 · os-project-manager · session_01FEkQ5mw7HFYn9o4LEGMQdK

Test Core (2/8) red on f3e3b132: the one failing test is @objectstack/scenarios test/runner/external-driver.test.ts ("a full crm run through the command…"), cause Test timed out in 5000ms (5019 ms). This PR changes TS types and a test in packages/spec plus one plugin-security pin test; nothing in packages/qa/scenarios or any runtime path. The same test timed out the same way in the merge-queue build for PR #31247 (run 42414930416) an hour earlier. Re-running the failed job ONCE; a second red is read as real.

[objectstack-fleet]

domain:spec#1 · os-project-manager · session_01FEkQ5mw7HFYn9o4LEGMQdK

Contract review (delta)

Served-tier: CONTRACT_REVIEW_TIER
Head-sha: 84a719f5d16889cb592562e25d1f067335cd15ec
Local-runs: none
Scope: packages/spec/src/contracts/security-service.ts + packages/spec/src/contracts/security-service.test.ts, packages/plugins/plugin-security/src/registered-security-service-members.pin.test.ts, packages/spec/api-surface/contracts.json, packages/spec/export-origins/contracts.json, .changeset/31238-security-service-effective-access.md, and on origin/main the 25 commits the merge brought in, read as a file list against the cited resolver code (packages/core/src/security/resolve-authz-context.ts, packages/core/src/security/platform-admin.ts, packages/plugins/plugin-security/**, packages/rest/src/security-routes.ts) and packages/qa/scenarios/test/runner/external-driver.test.ts (the test behind the previous head's one red). Merge-only delta: 84a719f5 is Merge branch 'main' into claude/project-thread-9crw47, first parent the reviewed head f3e3b132, second parent origin/main ebc2cdc5.

Inputs: the three earlier records (PR comments 6712477832 FAIL, 6713231084 PASS, 6713288167 PASS on f3e3b132), the seat's note 6713452741 on the Test Core (2/8) red, the PR body and file list, git diff origin/main...84a719f5 against git diff of the old merge base 733efbd4 to f3e3b132, and the 41 check-runs on 84a719f5 as they stood when read. Not waited for; nothing built, run or re-run locally; the one job log cited was read from GitHub.

① The PR's surface is unchanged by the merge

• Net diff at the old head (733efbd4..f3e3b132) and at the new head (ebc2cdc5..84a719f5): the same six files, 238 insertions, 0 deletions, and the two patches are byte-identical once the index lines are dropped (every file header, hunk header and hunk body the same). git diff ebc2cdc5 84a719f5 names those six files and nothing else, so the new head is origin/main plus exactly the reviewed diff: the merge carried main whole and added nothing to the PR's own surface. No conflict resolution touched a PR file.
• Of the 25 commits main brought in (733efbd4..ebc2cdc5, among them 59d9815 test(scenarios): give the external-driver crm run a measured 30s budget and a lighter stand-in #31284, ea053b4 fix(cli): os build leaves devPlugins out of the artifact; os validate --target stops reading it as code #31276, c0f88b9 feat(scenarios)!: cards declare user-handle fields and persona records; seed dependence is decided per turn #31275, b3bd75d fix(mcp): a coded sandboxed hook refusal answers the body's sentence, not the wrapper naming the hook #31268, 2f369cd fix(plugin-auth): a correct-password sign-in refused by an organization IP list no longer counts toward the account lockout #31262, 07559ce fix(cli): os serve refuses to boot when a plugins entry that may provide the crypto provider does not load #31263, ebc2cdc fix(pm): dispatch-gates derives fifteen whole-root lint gates from the diffs that can move them #31291), none touches packages/spec/src/** (the only packages/spec path main moved is packages/spec/llms.txt), packages/spec/api-surface/**, packages/spec/export-origins/**, packages/plugins/plugin-security/**, packages/core/src/security/**, packages/rest/src/security-routes.ts, scripts/check-changeset-no-major.mjs, scripts/check-api-surface.mjs, scripts/check-export-origins.mjs, AGENTS.md, scripts/pm/check-governed-queue-guard.mjs, scripts/pm/check-governed-merges.mjs or scripts/pm/record-recognisers.mjs (zero changed files under each, checked path by path). The two plugin-auth commits (2f369cd, ea62933) are sign-in and audit paths, not the authz resolver. So describeEffectiveAccess?, EffectiveAccess, EffectivePermissionSet and EffectivePermissionSetOrigin bind against the same resolver, the same explainAccessForCaller, the same builtin-positions.ts and the same REST convention the three earlier records judged them against; every sentence judged there describes the same tree on this head.
• Ledgers: main changed nothing under packages/spec/src, and packages/spec/api-surface/contracts.json and packages/spec/export-origins/contracts.json are identical between 733efbd4 and ebc2cdc5. The PR's three rows (EffectiveAccess (interface), EffectivePermissionSet (interface), EffectivePermissionSetOrigin (type), each with its src/contracts/security-service.ts#... origin) remain the only delta against main in both files and sit in sorted position (after EMBEDDER_SERVICE, before EmailAddress). A regeneration on this head could differ from the committed ledgers only if main had moved the spec's exported surface; it did not. No regeneration owed; none run.
• .changeset/config.json on main gained @objectstack/scenarios in one package list; the PR's changeset names @objectstack/spec alone, and Check Changeset is success on this head.
• The pin test registered-security-service-members.pin.test.ts gains the same one line (describeEffectiveAccess: 'optional') and plugin-security is untouched by main, so the pin reads the same interface.

② Semver and Clause-② — unchanged, still right

• .changeset/31238-security-service-effective-access.md is byte-identical between f3e3b132 and 84a719f5: '@objectstack/spec': patch, Clause-②: yes (widening), Metadata-protocol: none, both lines line-initial. The PR body carries the same two lines (lines 6 and 7). With Metadata-protocol: none the level the rule and check-changeset-no-major.mjs admit is patch; one arm from the closed pair, well-formed; no ADR-0087 marker owed. The judgment of record 6712477832 ② stands, and the gate agrees on this head (Check Changeset success).

③ Check-runs on 84a719f5 as they stood when read

• 41 check-runs: 13 success (Governed Surface Queue Guard, Check Changeset, Check PR Size, PR-body guards, Spec property liveness, Type Check · source gates, Lint · PM dispatch-gates, Lint · scoped · tooling self-tests, Plan Test Core shards, Dogfood Regression Gate, Flag docs affected by code changes, Auto Label, filter); 8 skipped (opt-in lanes, Build Docs, UI Published Artifacts, Temporal Conformance, the schedule gate, Dogfood Verify CLI and the sharded dogfood matrix); 20 in_progress (Type Check · workspace / consumer gates / debt ledger, Lint x6, Build Core, Build UI Deps, Test Core 1/8 to 8/8, Live E2E UI). No failure, no commit status. Of main's required contexts (TypeScript Type Check, Test Core, Build Core, Lint & Repo Gates, Governed Surface Queue Guard, Lint UI, Build & E2E UI, Type Check UI, Test UI, Live E2E UI), Governed Surface Queue Guard is green; Build Core and Live E2E UI are in progress; the aggregate contexts have not been created yet. Not claimed either way.
• The previous head f3e3b132 finished 53 success, 9 skipped, 2 failure: Test Core (2/8) and its aggregate Test Core. Read from the job log of run 42416214837 job 128540808803: the single failing test is @objectstack/scenarios test/runner/external-driver.test.ts, "a full crm run through the command: each key reached it in a 0600 file only, and no written artifact holds any", Test timed out in 5000ms; the same shard reports @objectstack/spec 820 passed, 1 skipped. Not attributed to the diff: the PR touches no scenarios path, and main's 59d9815 (test(scenarios): give the external-driver crm run a measured 30s budget and a lighter stand-in #31284) rewrites exactly that test and its fake driver with a measured 30 s budget (}, 30_000) at line 237 of the file on 84a719f5), which this merge carries. The seat's attribution in 6713452741 matches the log. On f3e3b132 every other gate the identical diff faces was green: Type Check x4 and the TypeScript Type Check aggregate, Type Check UI, the whole Lint family, Build Core, Build & E2E UI, Check Changeset, Spec property liveness, Governed Surface Queue Guard, and Test Core shards 1 and 3 to 8. Those conclusions carry over as evidence only; the gates on this head decide the landing.
• PR state: open, draft, 7 commits, head repo is the base repo (not a fork), auto-merge not armed. Tier S landing stays the owning seat's through the queue once every check is green.

④ Design judgment — unchanged

The contract file and every file its docblock cites are byte-identical to what records 6712477832, 6713231084 and 6713288167 judged (the file through the PR's unchanged hunks, the cited code through main's untouched paths). M1, S1, S2, S3 and N1 stay closed; the accepted departures (patch over minor, pin placement, the absence sentence) stand. No new findings.

Implemented-by: claude/project-thread-9crw47
Reviewed-by: session_01FEkQ5mw7HFYn9o4LEGMQdK

VERDICT: PASS

[objectstack-fleet]

domain:spec#1 · os-project-manager · session_01FEkQ5mw7HFYn9o4LEGMQdK

维护者速读

• 改了什么：在 ISecurityService 上新增可选成员 describeEffectiveAccess?(userId, callerContext?)，同时新增它的答复类型 EffectiveAccess / EffectivePermissionSet / EffectivePermissionSetOrigin。来源有四种：default、position、direct，以及 derived（platform_admin_config 或 ai_access）。这次只声明契约，不包含实现。
• 为什么改：这是 spec: declare ISecurityService.describeEffectiveAccess? and the EffectiveAccess answer types (spec half of #31215) #31238 的 spec 半，security: a per-user effective-access read that says where each permission set comes from (default binding, position, direct) #31215（某用户实际生效的权限集及其来源）的 server 半要靠它落地。
• 风险与回滚：成员是可选的，没有实现方时行为不变。改动只加不删（+238/-0），回滚即 revert。
• 先看：packages/spec/src/contracts/security-service.ts。
• 两分钟验证：读 6 个文件。plugin-security 的成员钉子测试把新成员钉为 optional；api-surface 与 export-origins 两本账各多 3 行。
• 需要你做的：无，由席位落地。合并前你仍可否决。
• 席位意见：ACCEPT。Fable 契约复审首轮 FAIL（6712477832，M1：resolver 的配置派生平台管理员和 ai_seat 合成两条路径在来源类型里无法表达）。修复后 delta PASS（6713231084、6713288167）；合入 main 后再 delta PASS（6714582644）。

席位核对

Verdict: ACCEPT · head 84a719f5d16889cb592562e25d1f067335cd15ec · card #31238 · claim 6711887108 (amended 6712494974) · report 6712357054

1. Shape: draft, base main. Fixes #31238 is on its own line, with no other closing keyword. The server half (security: a per-user effective-access read that says where each permission set comes from (default binding, position, direct) #31215) stays open for server seat 5. 6 files, +238/-0.
2. Premise measured: the four origin kinds come from reading the resolver's actual channels (resolve-authz-context.ts §6, §6a/6b, the config path and §7). Review M1 is closed by the derived kind. The S1 to S3 docblock items are closed too: the unknown-user departure from explain is stated, the external_default placement is ruled, and the resolution order is named.
3. Gates: every check-run on this head is success (55) or skipped by its own path filter (9). TypeScript Type Check, Lint & Repo Gates and Test Core all succeeded. mergeable_state: clean. check-governed-merges --pr 31256: NOT governed, 238 changed lines.
4. Accepted deviations:
   • The changeset is patch, not minor. With Metadata-protocol: none, patch is the level the rule gives; review ② confirmed it.
   • The member pin lives in plugin-security's pin test. Type Check · workspace was red on 80410d2f; the claim amendment 6712494974 covered it, and the fix-round push fixed it.
   • Test Core (2/8) was red on f3e3b132 from the scenarios external-driver timeout, which main fixed in test(scenarios): give the external-driver crm run a measured 30s budget and a lighter stand-in #31284. The seat updated the branch (pr_update_branch). The merge is pure and the net diff is unchanged (delta 6714582644).
5. Out of scope and where it went: the implementation and the REST door belong to security: a per-user effective-access read that says where each permission set comes from (default binding, position, direct) #31215, under server seat 5, which will be told on merge. Nothing filed.
6. Landing: Clause-②: yes (widening) / Metadata-protocol: none, patch on @objectstack/spec. CONTRACT_REVIEW_TIER PASS 6713231084 and 6713288167, plus a delta PASS 6714582644 on this head.

Ruling-ref: the maintainer, 2026-11-07T16:00Z: 「你有 fable ，车道契约复审可以自己做」; 2026-11-07T16:59Z: 「你应该使用 pm-dispatch 技能审核和落地pr」; standing landing authorisation 2026-10-25T11:35Z: 「按照 pm-dispatch 规则复核过的都授权」.

[github-actions]

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

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

分类：failure —— 按下面的日志分诊。

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

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

  @objectstack/example-todo:test:  FAIL  test/loop-body-iteration.test.ts > #19206 — the loop body runs and binds `currentTask` > ESCALATION: the run reaches `notify_owner` and the notice renders the re
    ↳ 失败原因: @objectstack/example-todo:test: Error: Test timed out in 5000ms.
  @objectstack/example-todo:test:  FAIL  test/loop-body-iteration.test.ts > #19206 — the loop body runs and binds `currentTask` > EVERY item is processed, and each one carries its own values
    ↳ 失败原因: @objectstack/example-todo:test: Error: Test timed out in 5000ms.
  @objectstack/example-todo:test:  FAIL  test/overdue-escalation-days-overdue.test.ts > #18584 — the overdue escalation projection carries a day count > every `{{ currentTask.… }}` hole in the escalatio
    ↳ 失败原因: @objectstack/example-todo:test: Error: Test timed out in 5000ms.
  @objectstack/example-todo:test:  FAIL  test/overdue-escalation-days-overdue.test.ts > #18584 — the overdue escalation projection carries a day count > 0 when the task is not overdue, and 0 when `due_d
    ↳ 失败原因: @objectstack/example-todo:test: Error: Test timed out in 5000ms.
  

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

  @objectstack/platform-objects:test:  FAIL  src/apps/translations/setup-nav-dead-key-tombstone.test.ts > conditionally-contributed Setup nav ids stay labelled (#6659) > fr carries a label for every con
    ↳ 失败原因: @objectstack/platform-objects:test: AssertionError: Setup nav ids with no label — no boot-time gate can see these; see this file header: expected [ 'nav_scim_credentials' ] to deeply equal []
  @objectstack/spec:test:      ✓ inverts the card's measured control: the three bogus keys now FAIL parse instead of adding zero warnings  318ms
    ↳ 失败原因: (这条 FAIL 之后 12 行内没有可识别的原因行 —— 点进 job 看)
  

↳ 失败原因 是判读的关键：超时（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，按失败测试文件聚合）：

• test/loop-body-iteration.test.ts — 24h 内已弹出 5 个 PR（i18n(platform-objects): ship the platform objects, Setup, Studio and Account in French #31233、fix(auth): record an MCP access token as used only after the MCP door admits the call #31247、feat(plugin-auth, plugin-audit): a sign-in the IP allow-list refuses writes one login_failed row, bounded per address #31249、feat(spec): declare the optional ISecurityService.describeEffectiveAccess and its EffectiveAccess answer types #31256、feat(plugin-auth)!: an organization administrator reads their judged client address; the console's retired MFA notices are gone #31258），分属 3 条投机栈 ⇒ 3 次独立命中。汇总 issue：Queue-flake anchor: test/loop-body-iteration.test.ts #31294（已刷新）
• src/apps/translations/setup-nav-dead-key-tombstone.test.ts — 24h 内已弹出 3 个 PR（i18n(platform-objects): ship the platform objects, Setup, Studio and Account in French #31233、feat(spec): declare the optional ISecurityService.describeEffectiveAccess and its EffectiveAccess answer types #31256、fix(lint)!: refuse a flow node no edge path from the start node reaches #31287），但它们同属 1 条投机栈 ⇒ 1 次独立命中。汇总 issue：Queue-flake anchor: src/apps/translations/setup-nav-dead-key-tombstone.test.ts #31306（已刷新）
• test/overdue-escalation-days-overdue.test.ts — 24h 窗口内只有本 PR 撞到过，暂不汇总（再有一个不同 PR 撞到就会自动开汇总 issue）。
• ⚠️ 24h 评论账本没读完（超过 5 页仍未读到窗口尽头），所以上面的「不同 PR 数」是下界，不是全量。

历史信号：

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

分诊清单：

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

---

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

[objectstack-fleet]

domain:spec#1 · os-project-manager · session_01FEkQ5mw7HFYn9o4LEGMQdK

Queue build 42428161519 failed two Test Core shards, and neither failure comes from this PR:

• Test Core (2/8): @objectstack/platform-objects setup-nav-dead-key-tombstone.test.ts fails because fr has no label for nav_scim_credentials. The fr bundle is the one i18n(platform-objects): ship the platform objects, Setup, Studio and Account in French #31233 adds.
• Test Core (6/8): examples/app-todo loop-body-iteration and overdue-escalation-days-overdue hit Test timed out in 5000ms. That is tracked by example-todo: loop-body-iteration.test.ts "ESCALATION" times out at the 5 s default in the merge queue (2 independent hits since #31230 landed) #31298.

This PR touches only packages/spec contract types, the plugin-security pin test and two spec ledgers. It touches nothing in platform-objects, translations or app-todo.

Both anchors list this PR as S1 · inherited: #31306 and #31294 name #31233 as the S1 root. That makes this PR a bystander to the break, not its cause. The seat has re-queued it once, on the same head (84a719f5). The ACCEPT is 6714804600.

[github-actions]

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

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

分类：failure —— 按下面的日志分诊。

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

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

  @objectstack/platform-objects:test:  FAIL  src/apps/translations/setup-nav-dead-key-tombstone.test.ts > conditionally-contributed Setup nav ids stay labelled (#6659) > fr carries a label for every con
    ↳ 失败原因: @objectstack/platform-objects:test: AssertionError: Setup nav ids with no label — no boot-time gate can see these; see this file header: expected [ 'nav_scim_credentials' ] to deeply equal []
  @objectstack/spec:test:      ✓ inverts the card's measured control: the three bogus keys now FAIL parse instead of adding zero warnings  301ms
    ↳ 失败原因: (这条 FAIL 之后 12 行内没有可识别的原因行 —— 点进 job 看)
  

↳ 失败原因 是判读的关键：超时（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，按失败测试文件聚合）：

• src/apps/translations/setup-nav-dead-key-tombstone.test.ts — 24h 内已弹出 3 个 PR（i18n(platform-objects): ship the platform objects, Setup, Studio and Account in French #31233、feat(spec): declare the optional ISecurityService.describeEffectiveAccess and its EffectiveAccess answer types #31256、fix(lint)!: refuse a flow node no edge path from the start node reaches #31287），但它们同属 1 条投机栈 ⇒ 1 次独立命中。汇总 issue：Queue-flake anchor: src/apps/translations/setup-nav-dead-key-tombstone.test.ts #31306（已刷新）
• ⚠️ 24h 评论账本没读完（超过 5 页仍未读到窗口尽头），所以上面的「不同 PR 数」是下界，不是全量。

历史信号：

• ⚠️ 本 PR 过去 24h 已在队列失败 1 次（不含本次）。 内容未变而反复失败 ⇒ 高度怀疑 flaky 测试或与同组 PR 的语义冲突，重排不解决。
• 过去 24h 队列共有 28 个失败构建（不含本次）。

分诊清单：

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

---

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

[objectstack-fleet]

domain:spec#1 · os-project-manager · session_01FEkQ5mw7HFYn9o4LEGMQdK

Queue build 42429369356 failed on the same deterministic root as before. That build stacked on the queue chain behind #31233, whose fr bundle has no label for nav_scim_credentials (anchor #31306). #31233 has now been ejected from the queue three times on that assertion, and it is out of the queue again.

This PR touches no platform-objects or translation file. The seat has re-queued it on the same head (84a719f5), and has asked for #31233 to stay out of the queue until it carries the fr label fix.

[github-actions]

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

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

分类：failure —— 按下面的日志分诊。

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

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

  @objectstack/platform-objects:test:  FAIL  src/apps/translations/setup-nav-dead-key-tombstone.test.ts > conditionally-contributed Setup nav ids stay labelled (#6659) > fr carries a label for every con
    ↳ 失败原因: @objectstack/platform-objects:test: AssertionError: Setup nav ids with no label — no boot-time gate can see these; see this file header: expected [ 'nav_scim_credentials' ] to deeply equal []
  @objectstack/spec:test:      ✓ inverts the card's measured control: the three bogus keys now FAIL parse instead of adding zero warnings  312ms
    ↳ 失败原因: (这条 FAIL 之后 12 行内没有可识别的原因行 —— 点进 job 看)
  

↳ 失败原因 是判读的关键：超时（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，按失败测试文件聚合）：

• src/apps/translations/setup-nav-dead-key-tombstone.test.ts — 24h 内已弹出 5 个 PR（i18n(platform-objects): ship the platform objects, Setup, Studio and Account in French #31233、feat(cloud-connection)!: refuse a managed upgrade that renames or retypes a stored field until it is declared or confirmed #31243、fix(plugin-security): a refused grant holder the caller cannot read is answered as a holder that does not exist #31244、feat(spec): declare the optional ISecurityService.describeEffectiveAccess and its EffectiveAccess answer types #31256、fix(lint)!: refuse a flow node no edge path from the start node reaches #31287），但它们同属 1 条投机栈 ⇒ 1 次独立命中。汇总 issue：Queue-flake anchor: src/apps/translations/setup-nav-dead-key-tombstone.test.ts #31306（已刷新）
• ⚠️ 24h 评论账本没读完（超过 5 页仍未读到窗口尽头），所以上面的「不同 PR 数」是下界，不是全量。

历史信号：

• ⚠️ 本 PR 过去 24h 已在队列失败 2 次（不含本次）。 内容未变而反复失败 ⇒ 高度怀疑 flaky 测试或与同组 PR 的语义冲突，重排不解决。
• 过去 24h 队列共有 35 个失败构建（不含本次）。

分诊清单：

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

---

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

[objectstack-fleet]

domain:spec#1 · os-project-manager · session_01FEkQ5mw7HFYn9o4LEGMQdK

Queue build 42430896312 failed on the same stack root as build 42430895501 on #31287. Both were built on #31233's older queue entry, before #31233's fr fix for nav_scim_credentials (e7071478) reached the queue.

#31233 has since re-entered the queue on the fixed head. The seat has re-queued this PR on the same head (84a719f5).