[objectstack-fleet]

Requested by Leehom · project thread

Fixes #31211
Fixes #30949

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

维护者速读

• 改了什么：IAuthService 新增一个可选成员 recordMcpAccessTokenUse(principal)。plugin-auth 的 verifyMcpAccessToken 不再顺手记「最近使用时间」，只记住自己返回的那个对象；MCP 门口在封禁检查和权限解析都通过之后，才把这个对象交回去记一次。
• 为什么改：被封禁的人，其 AI 助手的每次 MCP 调用都被门口拒绝，但同一小时 sys_oauth_consent.last_used_at 仍被写上，管理员在 GET /admin/authorized-clients?userId= 里会看到「这一小时用过」。修法是 6 号席在 MCP: a banned person's AI assistant is still recorded as used, because the last-use stamp (#30918) runs before the ban refusal #30949 上裁定的方案 A（门口唯一拥有「放行」）。
• 风险与回滚：成员可选，没有它的 auth 服务照旧放行；记录本来就在响应之后异步落库、从不抛错，所以不影响调用结果。回滚即还原本 PR。
• 先看：packages/runtime/src/security/resolve-execution-context.ts（门口末尾那一处调用）、packages/plugins/plugin-auth/src/auth-manager.ts（verifyMcpAccessToken 与新方法 recordMcpAccessTokenUse，WeakMap 只认自己返回的对象）、packages/spec/src/contracts/auth-service.ts（新成员的契约文字）。
• 两分钟验证：pnpm --filter @objectstack/runtime exec vitest run src/security/resolve-execution-context.test.ts -t 31211，预期 6 条全过（放行记一次、封禁/503/未验证/转发凭据都不记、缺成员照样放行）。
• 需要你做的：无，席位落地（落地前由 spec 席做契约复审）。

What changes

• spec (packages/spec/src/contracts/auth-service.ts): IAuthService gains one optional member beside verifyMcpAccessToken, recordMcpAccessTokenUse(principal): void. Its docblock states the split: verifying a token is not admitting the call; the caller calls this once per admitted call, after its last refusal, with the very object the verifier resolved to; the provider records only an object it returned itself; it returns nothing, never throws and never makes the caller wait. The parameter type is derived from the verifier's own result type, so the two cannot drift. content/docs/kernel/contracts/auth-service.mdx lists the member and adds a third "read together" pair (verifyMcpAccessToken() / recordMcpAccessTokenUse()).
• plugin-auth producer (auth-manager.ts, mcp-client-last-use.ts): verifyMcpAccessToken no longer schedules the consent last-use stamp. It puts the principal it returns in a WeakMap with the verified token's iat (issuedAtOf, moved to mcp-client-last-use.ts with the jose decodeJwt read). recordMcpAccessTokenUse stamps only an object in that map, then deletes it, so a hand-built principal, a copy, or the same object handed back twice records nothing more. The stamp itself (McpClientLastUseStamper, at most one write per consent per hour per process, after the response) is unchanged. The whole member sits in a try, so it never throws.
• runtime reader (resolve-execution-context.ts): the door keeps the verifier's answer in verifiedTokenPrincipal only when the ban read does not refuse it, awaits resolveRequestExecutionContext, and only then calls authService?.recordMcpAccessTokenUse?.(verifiedTokenPrincipal). So a banned subject, a grant-read outage (503, thrown before that line) and an unverified token all record nothing. A forward credential never sets it: it is the in-process continuation of a call already recorded. The member is reached through the declared, slot-typed IAuthService (no cast to an undeclared member).
• Changeset .changeset/31211-mcp-token-use-after-admission.md: patch on @objectstack/spec, @objectstack/plugin-auth, @objectstack/runtime (kind none takes patch; widening keeps patch, AGENTS.md Post-Task Checklist step 3), with both declaration lines and the host note.

Which owner, and why: the door. Seat 6 ruled option A (record 6710928373 on #30949) of the four-axis analysis in report 6710893443: one owner of "admitted", so a refusal added at the door later needs no second edit, and no second ban read anywhere.

Tests

• Red first, through the real door (one-shot rig, not committed: the rig() of mcp-client-last-use.real-engine.test.ts with a real AuthManager over a real SQL engine, a banned sys_user row, a consent written by better-auth's adapter, a jwt-plugin token, resolved by runtime resolveExecutionContext). Production sources restored to base fe97d85b: banned=true principalKind=guest ... stamp=HOUR_10 writes=1, AssertionError: a refused call stamps nothing, 1 failed | 1 passed. At head: banned=true principalKind=guest userId=undefined stamp=null writes=0, banned=false principalKind=agent ... writes=1, 2 passed.
• Door pins (resolve-execution-context.test.ts, new describe [#31211], 6 cases): admitted records exactly once, with the verifier's own object (toBe); banned records nothing; a grant-read outage asserts code SERVICE_UNAVAILABLE + status 503 and records nothing; an unverified token records nothing; a forward credential records nothing; an auth service without the member still admits.
• Producer pins (mcp-client-last-use.real-engine.test.ts, new describe [#31211], 4 cases): verification alone reads and writes no stamp (control: the same token admitted stamps the hour); a hand-built principal and a spread copy record nothing (control: the verifier's object stamps); one object handed back again in a later hour writes nothing more; the member never throws on an unknown or null principal. The 23 existing calls that expected a stamp from verifyMcpAccessToken now go through admittedCall (verify, then record the returned object), as the door does.
• Ablations (scripts/ablation-replace.mjs, each restored to the HEAD blob with git diff HEAD empty; both packages' tests import these sources directly, so no dist leg):
  1. delete the door call: admitted: recorded exactly once red (expected [] to have a length of 1).
  2. record at verification, before the ban read: admitted (length 2), banned and 503 cases red, 3 failed.
  3. verifier schedules the stamp again: verification alone reads no stamp and the hand-built case red.
  4. any object is recorded (?? {}): the hand-built case red.
  5. delete the once-only delete: the same object again is not a second admitted call red (2 vs 1).
• Suites: pnpm --filter @objectstack/plugin-auth test 235 files, 4187 passed | 10 skipped (VERDICT command-exit 0); runtime src/security/ + http-dispatcher.mcp-oauth.test.ts + mcp-federation-bridge.test.ts 15 files, 228 passed, and resolve-execution-context.test.ts 53 passed at the head; spec src/contracts/ 52 files, 475 passed.
• pnpm typecheck for @objectstack/spec, @objectstack/plugin-auth, @objectstack/runtime: exit 0 each (runtime re-run at the head).

Acceptance notes

• content/docs/kernel/contracts/auth-service.mdx is hand-written prose (not under content/docs/references/); check:docs and the other spec artifact gates are green with no regenerated file (pnpm --filter @objectstack/spec check:generated: all 14 artifacts up to date, against a spec dist built with this member).
• A host that calls AuthManager.verifyMcpAccessToken itself (outside the runtime door) no longer gets a stamp from verification; the changeset says to call recordMcpAccessTokenUse once it admits the call. No such caller exists in this repo (verifyMcpAccessToken has one non-test caller, the runtime door).
• Not ablated: the doc and changeset prose (os-dev: docs are not ablated).

Verification

Gate union derived by node scripts/pm/dispatch-gates.mjs --commands --repo objectstack-ai/objectstack (108 families for this diff), run on 327f91d8, reconciled with --ran: "108 derived famil(ies) accounted for — 106 run, 2 NOT-MEASURED (2 DERIVED from a recorded exit 3)".

• First pass reds and their reruns: check:where-matcher exit 1 flagged the new door test's table double (no combinator refusal), fixed in e8c0e991 (it now refuses $ operators and object values as the neighbouring double does), rerun exit 0. check:query-options-erasure exit 124 at a 300 s cap, rerun uncapped exit 0. check-plugin-teardown-shape.mjs --self-test exit 3 on the shallow clone, exit 0 after git fetch --depth=1 origin 621a4876.
• NOT MEASURED pnpm --filter @objectstack/spec run check:skill-examples and pnpm check:dual-build-cjs-loads: exit 3 PREREQUISITE NOT MET (they read every package's built dist, e.g. packages/client-react/dist; only the runtime closure was built). CI runs both on a full build.
• At head e8c0e991 (a test-only commit on top): re-ran check:where-matcher, check:query-options-erasure, check:cross-package-test-inputs, check:test-source-alias, check:engine-double-contract, check:objectql-double-limit, check:nul-bytes, check:issue-citations, check:closed-ceremony-text, exit 0 each, plus the runtime typecheck.
• eslint --no-inline-config over the six changed source and test files: exit 0.
• origin/main moved 12 commits since the base; none touches a file of this diff.
• CI families are read from this PR's check-runs, not re-run here.

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

This PR changes 3 package(s): @objectstack/plugin-auth, @objectstack/runtime, @objectstack/spec, touching 9 documentable anchor(s).

7 hand-written doc(s) NAME something this change touched and may need an implementation-accuracy re-verification:

• content/docs/kernel/contracts/auth-service.mdx (via AuthManager (symbol, a top-level class), IAuthService (symbol, a top-level interface), recordMcpAccessTokenUse (symbol, a method of class AuthManager; a method of interface IAuthService), verifyMcpAccessToken (symbol, a method of class AuthManager), verifyMcpAccessToken (literal, a string literal in recordMcpAccessTokenUse))
• content/docs/kernel/contracts/index.mdx (via IAuthService (symbol, a top-level interface))
• content/docs/kernel/index.mdx (via IAuthService (symbol, a top-level interface))
• content/docs/kernel/services-checklist.mdx (via AuthManager (symbol, a top-level class), IAuthService (symbol, a top-level interface))
• content/docs/kernel/services.mdx (via IAuthService (symbol, a top-level interface))
• content/docs/permissions/authentication.mdx (via AuthManager (symbol, a top-level class), IAuthService (symbol, a top-level interface))
• content/docs/protocol/kernel/index.mdx (via resolveExecutionContext (symbol, a top-level function))

⛔ 2 release-owned page(s) also name something this change touched. These are read-only:

• content/docs/releases/v18/18-2.mdx (via AuthManager (symbol, a top-level class))
• content/docs/releases/v18/18-3.mdx (via AuthManager (symbol, a top-level class))

content/docs/releases/ is RELEASE-OWNED (AGENTS.md "Documentation Guardrails"): release
notes are written centrally at release time, and a code PR that edits them is the exact PR
that guardrail exists to stop. They are still audited — read-only. If one of them is actually
wrong, file an issue or open a dedicated docs-only PR; do not edit it here.

What this run could not see

• 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 — 178 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 455229e7aebae2fe91ada77736377fe145defba3 → packageMentionDocs.

Which tree this was computed on

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

node scripts/docs-audit/affected-docs.mjs --json 455229e7aebae2fe91ada77736377fe145defba3

⚠️ 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 455229e7aebae2fe91ada77736377fe145defba3 → 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 e8c0e99 · 2026-11-07T19:47Z

[objectstack-fleet]

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

Contract review

Served-tier: CONTRACT_REVIEW_TIER
Head-sha: e8c0e99184dafa77fc9763791fa4d7fec395dac2
Local-runs: none
Scope: packages/spec/src/contracts/auth-service.ts + packages/plugins/plugin-auth/src/auth-manager.ts, packages/plugins/plugin-auth/src/mcp-client-last-use.ts, packages/plugins/plugin-auth/src/auth-manager-mcp-access-token.ts, packages/plugins/plugin-auth/src/run-after-response.ts, packages/runtime/src/security/resolve-execution-context.ts, packages/runtime/src/security/oauth-subject-ban.ts, packages/runtime/src/http-dispatcher.ts, packages/core/src/security/request-execution-context.ts, packages/spec/src/contracts/core-service-contracts.ts, packages/spec/api-surface/contracts.json, content/docs/kernel/contracts/auth-service.mdx

Inputs read: cards #31211 (body; comments 6710960650, 6711352406, 6712169396) and #30949 (body; comments 6686445086, 6709716960, 6710770858, 6710893443, 6710928373); PR #31247 body, file list and the net diff origin/main...e8c0e991 (8 files, +332/-57); the check-runs on the head. The rest of the diff (the two test files, the changeset body as prose, the producer and reader edits as code) is the lane seat's ACCEPT at TIER_DEFAULT; here it is read, not reviewed.

Gate verdicts on the head at the time of this record: every completed check-run is success or skipped (Check Changeset, Governed Surface Queue Guard, Lint & Repo Gates and all seven Lint lanes, Spec property liveness, Type Check · source gates, Build Docs, Dogfood Regression Gate, PR-body guards, Check Documentation Links, Plan Test Core shards). Still in_progress: Build Core, Type Check · workspace, Type Check · consumer gates, Type Check · debt ledger, Type Check UI, Test Core 1-8, Test UI 1-16, Build & E2E UI, Live E2E UI. None has failed. This record does not wait for them; the queue guard reads them itself.

① Derived judgments

• Accept set. No Zod schema, no authorable key, no metadata type is touched; Metadata-protocol: none on the PR body and the changeset. Right.
• Public surface: one optional member. IAuthService (packages/spec/src/contracts/auth-service.ts) gains recordMcpAccessTokenUse?(principal): void, placed beside verifyMcpAccessToken. Its parameter type is derived from the verifier's own declared result (the non-nullable awaited return of verifyMcpAccessToken), so the two members cannot drift. Right: the runtime door already aliases the identical derivation as VerifiedMcpAccessToken (resolve-execution-context.ts line 53), so the door's authService?.recordMcpAccessTokenUse?.(verifiedTokenPrincipal) type-checks with no cast.
• Slot typing. ServiceSlotContracts.auth is IAuthService (core-service-contracts.ts line 65), so every slot-typed getService('auth') reader now sees the member as declared; the door reaches it through that slot, not through any, which is what dispatcher 多个 domain 调用契约里没有的方法 —— #4087 的同类，只是方向相反（契约缺声明，不是调用点乱编） #4127 asked for. Right.
• api-surface snapshot. packages/spec/api-surface/contracts.json records export names only ("IAuthService (interface)"), not members; no new export is added, so no regeneration is owed and none is in the diff. Right. The spec check:generated lanes sit in Type Check · workspace, in progress.
• Docs. content/docs/kernel/contracts/auth-service.mdx is hand-written prose (not under content/docs/references/), updated in the same diff: the member line and a third read-together pair. Right.
• Producer behaviour change. AuthManager.verifyMcpAccessToken no longer schedules the consent stamp; AuthManager.recordMcpAccessTokenUse does. This changes a side effect of a public plugin-auth method, but the side effect has never shipped: the three .changeset/30918-* files are still present at the head and every package is at 18.3.0, so no released consumer loses anything. The changeset's host note (call the member once after admitting) is right and sufficient.
• The declaration. The Clause-②: declaration reads yes (widening) on both the PR body and the changeset body, and the diff is a widening: no implementer must add the member, no consumer loses a member or a result field. Right. Metadata-protocol: none: right (nothing an author writes changes).

② Semver level

The changeset .changeset/31211-mcp-token-use-after-admission.md declares patch on @objectstack/spec, @objectstack/plugin-auth and @objectstack/runtime. Under this repo's rule (AGENTS.md, Post-Task Checklist step 3) the level follows the metadata-protocol kind alone: a kind takes at least minor on a package the diff moves, none takes patch, and a non-protocol change, widening or breaking, ships patch. The kind here is none, so patch on all three is the level the rule prescribes; generic semver would call an added optional interface member a minor, but that is not this repo's rule, and the Check Changeset gate is green on the head. Both declaration lines are line-initial in the changeset body and the PR body, spelled as the rule spells them, and the arm (widening) is the one a new optional member takes. skip-changeset would have been wrong (three released packages publish). Judged right.

③ Boundary flags

• open_questions on the dev report 6712169396: empty. Nothing to answer.
• The MCP: a banned person's AI assistant is still recorded as used, because the last-use stamp (#30918) runs before the ban refusal #30949 open question (report 6710893443, A/B/C): ruled option A by domain:server#6 in 6710928373; the diff implements A as the card body of IAuthService: declare an optional member that records an MCP access token as used, called by the MCP door only after it admits the call (lands with its producer and reader; fixes #30949) #31211 states it (member in spec, verifier records nothing, WeakMap of returned principals, door call after ban read and after context resolution, pins both ways). Answered by the tree.
• Deviation 1 (PR footer uses the os-dev session-URL form; model-free commit trailers): a harness and attribution matter with no bearing on the contract or its code; left to the owning seat, not escalated.
• Deviation 2 (branch reset from the MCP: a banned person's AI assistant is still recorded as used, because the last-use stamp (#30918) runs before the ban refusal #30949 base to origin/main before the first commit): nothing had been pushed; the diff is against origin/main; no bearing.
• NOT MEASURED locally (check:skill-examples, check:dual-build-cjs-loads, exit 3 prerequisite not met): both need every package's dist; the CI lanes that carry them (Lint · repo & tooling gates: green; Type Check · workspace: in progress) are the gate verdicts. Not a design question; answered by the check-runs.
• Dev flag: an out-of-tree host that calls AuthManager.verifyMcpAccessToken itself no longer gets a stamp. Answered: the stamp is unreleased (see ①), the repo has exactly one non-test caller of the verifier (the runtime door), and the changeset names the one call such a host adds.
• Card MCP: a banned person's AI assistant is still recorded as used, because the last-use stamp (#30918) runs before the ban refusal #30949 serial note (re-read PR fix(plugin-auth)!: revoke an MCP access token through its OAuth consent #30879's consent read): fix(plugin-auth)!: revoke an MCP access token through its OAuth consent #30879 is on main; the stamp still picks its consent by consentForToken with the verified token's iat, now read by issuedAtOf(token) inside the verifier's then, so the rule is unchanged. Answered.
• Cross-seat surface: the plugin-auth and runtime files are named in the spec seat's claim 6711352406 as cross-seat under the triage 6710960650; domain:server#6 handed the branch over in 6710928373. In bounds.
• Closing both cards: the PR body carries Fixes #31211 and Fixes #30949, as triage 6710960650 asked. Right.

④ Design judgment

packages/spec/src/contracts/auth-service.ts, judged against the ruling it implements (option A, record 6710928373), its producer (AuthManager) and its reader (the runtime door), and the accepted scenario: a banned subject's verified token stamps nothing; an admitted call stamps exactly once. Each sentence of the new docblock was tried against the live tree at the head.

1. "Record that the caller ADMITTED a call ... so the provider can keep its coarse last used record of the grant." True of the producer: AuthManager.recordMcpAccessTokenUse (auth-manager.ts line 4673) calls scheduleMcpClientLastUse, which runs McpClientLastUseStamper.record with the principal plus the token's iat; the stamper's consent rule and the one-write-per-consent-per-hour-per-process bound are unchanged from Auth: no ledgered read lists the AI assistants a person has authorized, records when one was last used, or lets an admin see a managed person's #30918.
2. "Verifying a token is not admitting the call: the door ... can still refuse it after verifyMcpAccessToken answers (a banned subject, an authorization store it could not read)." True of the reader: resolve-execution-context.ts verifies at line 205, then reads the ban at line 211 (isOAuthSubjectBanned, outside the verifier's try, so a read fault is AuthzStoreUnavailableError, 503), then awaits resolveRequestExecutionContext (a grant-read fault throws the same class).
3. "A provider records nothing at verification." True: the verifier's then only sets verifiedMcpPrincipals (a WeakMap) and returns the principal; no stamper call remains in verifyMcpAccessToken. The producer pin asserts zero reads and zero writes after three verifications.
4. "The caller calls this member once per admitted call, only after its last refusal has had its say, with the very object verifyMcpAccessToken resolved to." True of the door: the call is at line 305, after the awaited context, and passes verifiedTokenPrincipal, which is the verifier's own verified object (the spread copy goes to oauth, not to the record). The dispatcher calls the door once per request (http-dispatcher.ts timedResolveExecutionContext, the one call site), so one admitted call is one record. The door pin asserts toBe(verified) and length 1. See the should-fix below on how far "its last refusal" reaches.
5. "A refused call never reaches it, so it is never recorded as a use." True for every refusal the door makes: a banned subject leaves verifiedTokenPrincipal unset; a ban-read fault and a grant-read fault throw before line 305; an unverified token or a verifier that throws leaves it unset; a forward credential never sets it (it is the in-process continuation of a call already recorded). Pinned by the six door cases. I looked for a path where the door returns a guest while verifiedTokenPrincipal is set and found none: with session: { established } core's readSession returns the established user unconditionally (request-execution-context.ts line 245), and the ban read is the only row-keyed refusal on this path.
6. "The provider records only a principal object it returned itself; any other object (a hand-built principal, a copy) records nothing." True: the WeakMap is keyed by identity; the verifier builds a fresh object literal on every call (auth-manager-mcp-access-token.ts, the principal: { userId, scopes, ... } literal in verifyMcpAccessTokenClaims), so no two calls share a key and a spread copy misses. Pinned (hand-built and copy record nothing; the control object stamps).
7. "It returns nothing, never throws and never makes the caller wait." True: void; the whole body is inside try/catch; a null or primitive argument is guarded before the WeakMap read; the stamp is handed to runAfterResponse, which is a setImmediate whose task record never rejects. Pinned (null as never does not throw).
8. Absence. The member is optional; the door reaches it with ?.; an auth service without it admits exactly as before. Pinned (sixth door case). The changeset says the same.
9. Idempotence. The contract binds the caller to once per admitted call; the producer is stricter and deletes the WeakMap entry on record, so the same object handed back again (even in a later hour) writes nothing more. Stricter than the text, consistent with it, and pinned. No contradiction.
10. Other attempted breaks. Refused calls leave WeakMap entries that die with the principal object: no leak. The iat is read from the token the signature just covered, after verification, as before. A door with no data engine answers "not banned" and admits (pre-existing policy of isOAuthSubjectBanned); the record follows the door's answer, which is the ruling's whole point. The parameter type's self-reference inside the interface is a deferred indexed-access type TypeScript accepts; Type Check · source gates is green on the head.

Should-fix (not blocking): sentence 4 says the member is called "only after its last refusal has had its say"; "its" is the door's, and that is true. But the dispatcher still renders authorization verdicts on the admitted principal after the door has returned and recorded: the environment-membership gate does not skip /mcp (http-dispatcher.ts enforceProjectMembership, skip list /auth, /cloud, /health, /ready, /discovery), and domains/mcp.ts answers 403 insufficient_scope or PERMISSION_DENIED at tool dispatch. Those are verdicts on an identity the door admitted, so recording them as a use of the grant is the right reading and matches the ruling's placement, but the docblock does not say so. One sentence after sentence 4, of the form "an authorization refusal of the admitted principal rendered later (a tool the scopes do not grant, an environment the user is not a member of) is a use and is recorded", would close the gap for the next reader. The mdx pair prose could carry the same clause.

content/docs/kernel/contracts/auth-service.mdx (cited, read): the member line states the same four facts as the docblock (once, after the caller's last refusal, the verifier's object, a foreign object records nothing, never throws, optional) and the new third read-together pair names the door, its two refusals and the authorized-clients reads. The parameter shape is written inline as the verifier's shape, exactly as the verifyMcpAccessToken line above it is, so the page is internally consistent. True of the tree.

Producer and reader (cited, read, not reviewed): auth-manager.ts lines 4616-4735, mcp-client-last-use.ts (docblock, issuedAtOf, the stamper), resolve-execution-context.ts lines 164-172 and 211-214 and 298-306 are what the spec sentences above were judged against; each sentence holds on them. No must-fix found.

Implemented-by: claude/project-thread-p0qal7
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: 17d06764ef435c656f4c912c77db92ee2b315d9d
Local-runs: none
Scope: packages/spec/src/contracts/auth-service.ts + content/docs/kernel/contracts/auth-service.mdx, packages/runtime/src/domains/mcp.ts, packages/mcp/src/mcp-http-tools.ts, packages/runtime/src/action-execution.ts, packages/runtime/src/http-dispatcher.ts, packages/runtime/src/security/resolve-execution-context.ts

Delta from the previous record's head e8c0e991 to this head: one commit, 17d06764e ("docs(spec): an admitted MCP call refused later for what it asks is still recorded as used"), touching two files, both prose: seven lines added to the recordMcpAccessTokenUse docblock in packages/spec/src/contracts/auth-service.ts and one sentence appended to the third read-together pair in content/docs/kernel/contracts/auth-service.mdx. The net diff against origin/main at this head is the same eight files as before (+339/-57 versus +332/-57); no code, test or changeset line moved. The previous record's ①, ②, ③ and ④ items 1-3 and 5-10 stand unchanged on this head.

Gate verdicts on this head at the time of this record: completed and success: Auto Label, Check Documentation Links, Check PR Size, Governed Surface Queue Guard, PR-body guards; skipped: the opt-in harnesses and the schedule gate; everything else (Check Changeset, the seven Lint lanes, Spec property liveness, the four Type Check lanes, Flag docs, filter, and the Build and Test lanes they fan out to) is in_progress. None has failed. This record does not wait for them; the queue guard reads them itself.

The should-fix from the previous record

Asked for: one sentence bounding "only after its last refusal has had its say" so that an authorization verdict rendered on the admitted principal later in the request is named as a use that is recorded.

Delivered, in the docblock: "Admitting is the decision about WHO calls, not every later authorization verdict: once the principal is admitted, a refusal of what it then asks for, rendered further down the request (the MCP domain's 403 insufficient_scope for a token that grants none of the MCP tool families, a tool the token's scopes leave unregistered, an action whose scope family the token was not granted), is still a use of the grant, and it is recorded." The mdx pair carries the same clause in shorter form.

Each clause tried against the live tree at this head:

• "the MCP domain's 403 insufficient_scope for a token that grants none of the MCP tool families" — true: packages/runtime/src/domains/mcp.ts lines 130-146 answer 403 with WWW-Authenticate: Bearer error="insufficient_scope" when ec.oauthScopes names none of MCP_OAUTH_SCOPES; ec is the context the door returned, so the record at resolve-execution-context.ts line 305 has already run.
• "a tool the token's scopes leave unregistered" — true: packages/mcp/src/mcp-http-tools.ts line 222 (grantedScopes) narrows registration to the granted families, fail-closed, an empty array registering nothing; the dev's report spelled this as a runtime path at about line 2220, but the mechanism is the one named and it is in packages/mcp at line 222. The record precedes it.
• "an action whose scope family the token was not granted" — true: packages/runtime/src/action-execution.ts apiForwardScopeFamilyRefusal (line 1845; called at line 1759 for an agent carried by a forward credential) answers 403 with the scope the agent lacks. The forward credential is the continuation of an already recorded call (previous record, ④ item 5), so this refusal follows the record too.
• "Admitting is the decision about WHO calls" — true of the door: every refusal the door makes (ban, ban-read fault, grant-read fault, unverified token) decides whether the token resolves to a principal and runs before line 305; nothing after that line changes who the principal is.
• The environment-membership gate, deliberately not named — right not to name it for a bearer-only call: http-dispatcher.ts enforceProjectMembership (lines 1589-1702) reads the caller only through api.getSession(inProcessSessionReadInput(headers)), the auth service's session read; a request carrying only an MCP JWT bearer resolves no session there, userId stays unset, and the gate returns null at "Anonymous requests — upstream auth will decide" (line 1705). So it never refuses a bearer-only agent. The one way it could refuse after the record is a session cookie riding beside the bearer whose user is not a member; that is a refusal of the cookie's user, and it falls under the sentence's general clause ("a refusal ... rendered further down the request ... is still a use of the grant, and it is recorded") without needing to be named. The ADR-0069 enforceAuthGate has the same shape (session read; no cookie, no gate) and the same answer.
• Attempts to break the sentence: I looked for a verdict rendered after line 305 that would make the principal not the token's user or would un-admit it, and found none; the dispatcher's later gates either exit as nobody for a bearer-only call or refuse what the principal asks for. I looked for a refusal of "what it asks for" rendered before the record, which would make "is recorded" false; the MCP domain, the MCP runtime and the action door all run on the returned context, so none precedes it. The list in parentheses is illustrative and introduced as examples, so an unnamed later verdict (a PERMISSION_DENIED from a tool's own permission check, a walled-catalog write refusal) is covered by the general clause and does not falsify it.

The should-fix is closed. The sentence is true of the producer, the reader and every later refusal on the MCP path at this head, and the mdx says the same thing in the same terms.

New findings

None must-fix. None should-fix. The only inexactness found is in the dev's report, not in the tree: the narrowing lives at packages/mcp/src/mcp-http-tools.ts line 222, not in a runtime file at about line 2220; the docblock itself names no path, so nothing in the published text is wrong.

Implemented-by: claude/project-thread-p0qal7
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: c67d88b7e97cc357cbdb39d15870cfdbccd59d90
Local-runs: none
Scope: packages/spec/src/contracts/auth-service.ts + content/docs/kernel/contracts/auth-service.mdx, packages/plugins/plugin-auth/src/auth-manager.ts, packages/plugins/plugin-auth/src/auth-manager-mcp-access-token.ts, packages/plugins/plugin-auth/src/mcp-client-last-use.ts, packages/runtime/src/security/resolve-execution-context.ts, packages/runtime/src/domains/mcp.ts, packages/mcp/src/mcp-http-tools.ts, packages/runtime/src/action-execution.ts, packages/runtime/src/http-dispatcher.ts

Second delta, after the records on e8c0e991 and 17d06764. The head moved by one commit, c67d88b7, "Merge branch 'main' into claude/project-thread-p0qal7", a base update the seat ran because Test UI shard 5/16 was cancelled at its timeout on 17d06764.

The merge is pure

• Parents: first 17d06764ef435c656f4c912c77db92ee2b315d9d (the previous head), second 455229e7aebae2fe91ada77736377fe145defba3, which is origin/main at the time of this record. The merge brings in 21 main commits (183 files, +10958/-985), and git diff 17d06764 c67d88b7 is exactly those 183 files.
• Combined diff (diff-tree -c) names one path that differs from both parents: packages/plugins/plugin-auth/src/auth-manager.ts. That is because both sides changed the file, in disjoint regions: main's b065fad56 (SAML refusal landing) at the import block near line 250 and handleRequest / runSsoCallback near line 3939; the PR at the MCP verifier and recorder near line 4620 and after. The combined patch carries one-sided hunks only; no line in it comes from a hand resolution. Confirmed two ways: the PR's change to the file is identical before and after the merge (git diff fe97d85b 17d06764 versus git diff origin/main c67d88b7, hunk headers and index lines stripped), and the merge's change to the file relative to the previous head is identical to main's own change to it.
• No conflict resolution touched any of the PR's eight files.

The net diff is the same eight files with the same content

git diff origin/main...c67d88b7 versus git diff origin/main...17d06764 (the latter against base fe97d85b): same eight files, +339/-57 both; the only differences are the index line and three @@ hunk headers of auth-manager.ts, shifted by twelve lines because main's SAML change sits above the PR's region. Every added and removed line is identical. Consequence for the earlier records: the auth-manager.ts line numbers they cite (4616-4735, 4673) now read twelve higher at this head; the cited code is byte-identical.

Nothing on main since the base invalidates a judged sentence

Of the 21 main commits since fe97d85b, two touch a file the records read:

• b065fad56 (plugin-auth, SAML): auth-manager.ts lines 250 and 3939-3975 only; zero mentions of verifyMcpAccessToken, recordMcpAccessTokenUse, verifiedMcpPrincipals, scheduleMcpClientLastUse or the stamper. The producer sentences (④ items 1, 3, 6, 7, 9 of the first record) stand.
• 1aa4dd10c (fix(mcp): the record data tools answer a code-less throw as the /data door does, so an undeclared hook abort is HOOK_ABORTED #31245, MCP record data tools answer a code-less throw as HOOK_ABORTED): packages/mcp/src/mcp-http-tools.ts hunks at lines 50, 475-613, 828 and 1798-2026 (error-result shaping inside registerObjectTools); the grantedScopes narrowing at line 222 is untouched, so the "a tool the token's scopes leave unregistered" clause of the delta record stands. It does not touch packages/runtime/src/domains/mcp.ts.

Not touched on main since the base: packages/spec/src/contracts/auth-service.ts, core-service-contracts.ts, resolve-execution-context.ts, oauth-subject-ban.ts, auth-manager-mcp-access-token.ts, mcp-client-last-use.ts, run-after-response.ts, packages/core/src/security/request-execution-context.ts, packages/runtime/src/domains/mcp.ts, packages/runtime/src/action-execution.ts, packages/runtime/src/http-dispatcher.ts (so enforceProjectMembership and enforceAuthGate read as the delta record described them). The door sentences (④ items 2, 4, 5, 8, 10) and the later-refusal sentence judged in the delta record stand.

Gate verdicts on this head

At the time of this record: success: Check Documentation Links, Check PR Size, Governed Surface Queue Guard, PR-body guards, filter; skipped: the opt-in harnesses, the dogfood shards, Temporal Conformance, UI Published Artifacts, the schedule gate; in_progress: Auto Label, Build Core, Build Docs, Build UI Deps, Check Changeset, Dogfood Regression Gate, Flag docs, the seven Lint lanes, Live E2E UI, Plan Test Core shards, Spec property liveness, the four Type Check lanes. None has failed. This record does not wait for them; the queue guard reads them itself.

Findings

None must-fix. None should-fix. The merge adds no reviewable content of its own; the previous two records' judgments carry to this head unchanged.

Implemented-by: claude/project-thread-p0qal7
Reviewed-by: session_01FEkQ5mw7HFYn9o4LEGMQdK

VERDICT: PASS

[objectstack-fleet]

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

维护者速读

• 改了什么：IAuthService 新增可选成员 recordMcpAccessTokenUse?；plugin-auth 校验 MCP 访问令牌时不再顺手记「最近使用」，改由运行时入口在封禁检查和上下文解析都通过后才调用该成员记一次。
• 为什么改：被封禁用户的 MCP 令牌校验仍会刷新授权客户端的最近使用时间，管理员在已授权客户端页看到的是假活跃（MCP: a banned person's AI assistant is still recorded as used, because the last-use stamp (#30918) runs before the ban refusal #30949、IAuthService: declare an optional member that records an MCP access token as used, called by the MCP door only after it admits the call (lands with its producer and reader; fixes #30949) #31211）。
• 风险与回滚：该成员可选，缺省时行为不变；这条记录从未发布过（Auth: no ledgered read lists the AI assistants a person has authorized, records when one was last used, or lets an admin see a managed person's #30918 的 changeset 尚未发版）；回滚即 revert。
• 先看：packages/spec/src/contracts/auth-service.ts 与 packages/runtime/src/security/resolve-execution-context.ts。
• 两分钟验证：读 8 个文件 +339/-57；门口 6 个用例 + 生产方 4 个用例两向钉住。
• 需要你做的：无，席位落地（方案 A 由 server 席位 6 裁定，你仍可在合并前否决）。
• 席位意见：ACCEPT。Fable 契约复审 PASS（6712272713），补丁轮补了复审的一句 should-fix，delta 复审 PASS（6712403334），合入 main 后再 delta PASS（6712869312）。

席位核对

Verdict: ACCEPT · head c67d88b7e97cc357cbdb39d15870cfdbccd59d90 · cards #31211 + #30949 · claim 6711352406 · report 6712169396

1. Shape: draft, base main, Fixes #31211 and Fixes #30949 on their own lines (both close on merge, as triage 6710960650 asked); no other closing keyword. 8 files, +339/-57.
2. Premise measured: red-first through the real door on the base (a banned subject's token stamped the client once), green at head (banned none, admitted once); 5 ablations red then restored (report 6712169396).
3. Gates: every check-run on this head success (57) or skipped by its own path filter (8); Lint & Repo Gates and TypeScript Type Check success; mergeable_state: clean. check-governed-merges --pr 31247: NOT governed.
4. Accepted deviations: check:skill-examples / check:dual-build-cjs-loads not measured locally (need full dist); their CI lanes are green on this head. Test UI shard 5/16 was cancelled at its timeout on 17d06764 and the relay cannot re-run a cancelled run, so the seat ran a base update (pr_update_branch); the merge is pure and the net diff unchanged (delta 6712869312).
5. Out of scope and where it went: the dev's reading that the environment-membership gate judges only the cookie session (never a bearer-only principal) went to the confidential security lane, off GitHub. Nothing filed here.
6. Landing: Clause-②: yes (widening) / Metadata-protocol: none, patch on spec, plugin-auth and runtime (the rule's level for none, confirmed in review ②); CONTRACT_REVIEW_TIER PASS 6712272713 plus delta PASS 6712403334 and 6712869312 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 构建失败 — 先分诊，再决定要不要重排

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

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

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

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

  @objectstack/scenarios:test:  FAIL  test/runner/external-driver.test.ts > the persona keys, end to end over the external driver — the record, the scorecard and the gallery never carry one > a full crm
    ↳ 失败原因: @objectstack/scenarios:test: Error: Test timed out in 5000ms.
  @objectstack/spec:test:      ✓ inverts the card's measured control: the three bogus keys now FAIL parse instead of adding zero warnings  450ms
    ↳ 失败原因: (这条 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/runner/external-driver.test.ts — 24h 窗口内只有本 PR 撞到过，暂不汇总（再有一个不同 PR 撞到就会自动开汇总 issue）。
• ⚠️ 24h 评论账本没读完（超过 5 页仍未读到窗口尽头），所以上面的「不同 PR 数」是下界，不是全量。

历史信号：

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

分诊清单：

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 red triage (run 42414930416): the one failing test is @objectstack/scenarios test/runner/external-driver.test.ts ("a full crm" over the external driver), and its cause line is Test timed out in 5000ms — a load/timing signature, not an assertion. This PR touches no file in packages/scenarios; its runtime change is one optional call after admission on the MCP bearer path. Re-queued ONCE on the same head c67d88b7; a second red on the same test is read as real and investigated, not re-queued.

[github-actions]

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

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

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

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

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

  @objectstack/scenarios:test:  FAIL  test/runner/external-driver.test.ts > the persona keys, end to end over the external driver — the record, the scorecard and the gallery never carry one > a full crm
    ↳ 失败原因: @objectstack/scenarios:test: Error: Test timed out in 5000ms.
  

↳ 失败原因 是判读的关键：超时（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/runner/external-driver.test.ts — 24h 窗口内只有本 PR 撞到过，暂不汇总（再有一个不同 PR 撞到就会自动开汇总 issue）。
• ⚠️ 24h 评论账本没读完（超过 5 页仍未读到窗口尽头），所以上面的「不同 PR 数」是下界，不是全量。

历史信号：

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

分诊清单：

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

Second queue red (run 42417438743), same test, same cause: @objectstack/scenarios test/runner/external-driver.test.ts "a full crm…", Test timed out in 5000ms. Read as real, as said on the first re-queue, but not this PR's: the test arrived with d3b6ff4 (#31265) and is timing out on unrelated PRs too (#31256 and #31277 Test Core 2/8 in the same hour). The queue runs the full suite, so any PR goes red on it. A timeout/fixture fix is routed to the scenarios owner. This PR is NOT re-queued until that fix is on main; the seat re-queues it then, on this head or after a base update.

[github-actions]

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

队列构建 42425767147 红了。队列跑的是全量套件（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.
  

↳ 失败原因 是判读的关键：超时（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 内已弹出 3 个 PR（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(plugin-auth)!: an organization administrator reads their judged client address; the console's retired MFA notices are gone #31258），分属 2 条投机栈 ⇒ 2 次独立命中。汇总 issue：Queue-flake anchor: test/loop-body-iteration.test.ts #31294（已刷新）
• ⚠️ 24h 评论账本没读完（超过 5 页仍未读到窗口尽头），所以上面的「不同 PR 数」是下界，不是全量。

历史信号：

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

分诊清单：

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

The queue build 42425767147 failed on Test Core (6/8). The cause was examples/app-todo test/loop-body-iteration.test.ts: two tests hit Test timed out in 5000ms. This PR touches no file in app-todo and no flow or loop path. Anchor #31294 lists this PR as S1 · inherited: its build stacked on #31258's queue head, and #31258 is the root of that stack and was ejected itself. So this PR was a bystander to that break, not its cause. The flake itself is tracked by #31298.

The seat re-queued this PR once, with the head unchanged (c67d88b7). If the same signature ejects it again as a root rather than inherited, the seat holds it until the #31298 fix is on main.