[os-steve]

Fixes #19578

Clause-②: yes (widening)

Executes the maintainer's ruling (decision batch 156, item 5, letter A, 2026-09-18): 「ISecurityService gains an effective-object-permission reader, threaded through the engine so evaluateOptionVisibility populates EvalContext.permissions; a census of every current_user-bound predicate evaluation site comes first」.

This PR is the packages/spec half only — the declaration. The engine-side threading, evaluateOptionVisibility and the packages/objectql / plugin-security wiring stay on the engine card (#18783), which is pm:blocked on this one, together with the census the ruling orders first.

What lands

ISecurityService.getEffectiveObjectPermissions?(context?), returning a promise of a readonly Record keyed by object name whose values are EffectiveObjectPermission, declared in packages/spec/src/contracts/security-service.ts, plus five contract pins in its test file. One optional member on a published interface; nothing renamed, narrowed or removed.

The return type is the published one, not a new parallel shape. EffectiveObjectPermission (@objectstack/spec/security) is the entry type of the objects map that GetEffectivePermissionsResponseSchema already serves, and @objectstack/formula's EvalPermissions — the type of EvalContext.permissions, the slot the ruling names — is that same readonly Record, verbatim. So the engine half hands the reader's answer straight into that slot with no reshaping, which is the whole point of single-sourcing it.

Why the shape is settled WITHOUT the census

The claim comment flagged that this card must return needs_decision if the reader's shape cannot be settled before the census. It can, and here is the measurement rather than the assertion — three shape questions, each closed by a published contract:

• Return type — fixed by EvalPermissions in packages/formula/src/types.ts:40, which is the declared type of the ruling's own target slot.
• Whole map vs. a per-object reader — fixed by the permission predicate's own documented semantics: "an object the effective map does not mention is an object with no grant, and answers false" (packages/formula/src/stdlib.ts). A narrowed map is therefore indistinguishable from a measured denial, and the objects a predicate names live in the predicate's source, not at the site assembling the context. The map cannot be narrowed by the caller, so the reader takes no object parameter.
• Failure stance — fixed by the same door's "Absent is not empty" rule (packages/formula/src/types.ts): with no map at all can() throws; an EMPTY map is a real answer evaluating to false. So the reader must throw rather than degrade to an empty map — degrading would publish "this subject holds nothing" as a measured fact — and an absent METHOD must leave the caller passing no permission data at all, never an empty map.

What the census decides is which sites get threaded and what context each holds. Neither moves any of the three above: the context parameter is already a Partial of ExecutionContext, and narrowing for cost is refused by the second bullet. ⛔ No census was run here.

Why a reader on the service, not a merge in the engine

resolvePermissionSetsForContext deliberately leaves the merge to the caller, "because two consumers legitimately project different subsets of the same sets". This map is the projection two consumers need to be identical — /auth/me/permissions serves it, and the permission predicate reads it — and the second consumer cannot tell a wrong map from a right one. toEvalPermissions already names the hazard at its own door: a hand-built permission map "has no shape of its own to be wrong against: it parses, can() answers from it, and the answer is a confident silent denial". One producer removes the second copy before it is written.

The two constraints the card carried over hold as read: ExecutionContext.permissions carries permission-set NAMES, so this is a new reader and not a re-projection of something already threaded; and the hard serial pair in rule-validator.ts is not this diff's surface — this diff touches no file in packages/objectql.

Verification

Commands, with each exit code captured before any pipe and the gate's own verdict line read rather than a bare status:

• pnpm --filter @objectstack/spec build — exit 0 (check-dts-emitted: 34/34 declared declaration file(s) present).
• pnpm --filter @objectstack/spec typecheck — exit 0 (tsc --noEmit, check:scripts-typecheck, check:test-typecheck). This test file carries no test-typecheck-debt.json entry, so its budget is zero: the file’s seven @ts-expect-error pins compile as errors-that-must-exist, and an unused one would red this. ⚠️ This diff adds one of those seven — six are pre-existing at the base. An earlier revision of this sentence said 「three」, which was wrong; the mechanism is unchanged, because a zero debt budget makes every pin in the file self-falsifying.
• pnpm --filter @objectstack/spec exec vitest run --maxWorkers=2 src/contracts/security-service.test.ts — exit 0, 19 passed (14 before this diff).
• pnpm --filter @objectstack/spec test and pnpm --filter @objectstack/spec check:generated — results in the report comment on the card.
• The gate families were derived from the diff by node scripts/pm/dispatch-gates.mjs --commands --repo objectstack-ai/objectstack, ⛔ not from a hand-rolled list. Per-family verdicts, and everything that derivation itself marks NOT MEASURED, are in the report.

Consumer sweep, narrowed and declared. A new OPTIONAL member can break a downstream implementor in exactly one way: a pre-existing getEffectiveObjectPermissions carrying an incompatible signature. git grep for that identifier across this repo and the pinned ../objectui checkout returns this declaration and its pins and nothing else, so there is no implementor to conflict with — which is why the downstream consumer closure was not rebuilt. The counts and the lit control are in the report.

Acceptance notes

• /auth/me/permissions in packages/plugins/plugin-hono-server/src/current-user-endpoints.ts builds this exact map inline today (the most-permissive merge, seedSuperUserRestrictedObjects, foldWildcardSuperUser, clampManagedObjectWrites, annotateEffectiveApiOperations). Moving it behind this reader is the natural second consumer and would make the endpoint and the engine provably one answer — but it is runtime work in another package, outside this card and outside the engine card as split. Noted, not filed: no carrier is in flight for that file.

---

_{⚠️ The pin-count sentence above was corrected by the dispatching seat after the at-tier contract review measured it, under the standing rule that the dev writes this body once at PR-open and the seat writes any later change. Re-verified first-hand before writing, not adopted: the diff adds 1 @ts-expect-error line, the base file carries 6, the head carries 7. Nothing else in this body was touched.}

Authored in Claude Code session session_01AmH9bKvGoLjiY86Q4Z3og2 (https://claude.ai/code/session_01AmH9bKvGoLjiY86Q4Z3og2).

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

This PR changes 1 package(s): @objectstack/spec, touching 2 documentable anchor(s).

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

• content/docs/kernel/contracts/index.mdx (via ISecurityService (symbol, a top-level interface))
• content/docs/kernel/runtime-services/index.mdx (via ISecurityService (symbol, a top-level interface))

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

• content/docs/releases/v17/17-0.mdx (via ISecurityService (symbol, a top-level interface))

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 60 of 215 client-bound route-ledger rows — the other 155 have no registrar path: tail to select them, so pages documenting THEIR client methods cannot appear above, on this or any run. Of those 155: 0 are remediable by widening that discovery convention (an in-repo file declares the path; the convention did not scan it); 55 are structural — on a ledger where NOT ONE row is declared in-repo, so no discovery change reaches them at any price; 100 are undecided (no in-repo declaration, on a ledger that has other in-repo registrars — absence and an unreadable spelling are not distinguishable here). The rows themselves: node scripts/docs-audit/affected-docs.mjs --bridge-coverage
• a page that states a rule by its inputs shares no identifier with the emitter that implements the rule, so an emitter-only diff cannot list it — not on this run and not on any run. Measured on fix(driver-sql): emit varchar(maxLength) for a text field a declared index keys on #11430: content/docs/protocol/objectql/types.mdx documents the text-family column mapping by the ObjectQL type names it maps FROM (text / textarea / html) while the diff changed createColumn; it went unlisted, and it was the page that diff falsified, in four places. No shared token exists to detect this on, so a rule your change carries has to be re-read by hand in the pages that restate it.
• a key NAME is not a key, so the hand re-read the line above prescribes can land on the wrong schema. The same spelling is authorable on one governed type and a [REMOVED] tombstone on another for each of active, aria, joins, objects, template, tools and version (censused on [finding] tools is a key on BOTH AgentSchema (tombstoned, dead) and SkillSchema (live, cloud-attested), so a name-based search attributes skill examples to the agent key — it produced a false stop-the-line alarm on PR #19059 #19093 over the liveness ledger's governed types, top-level keys); nothing in a search result distinguishes the two, so a grep hit on a LIVE example reads as evidence about the DEAD key. Measured on fix(spec): the agent.tools liveness row says dead — it claimed live on a key the schema tombstoned #19059: content/docs/ai/agents.mdx was reported as contradicting the agent.tools tombstone over its tools: example at :161, which is inside the defineSkill({ block opened at :155 — the page was already correct. Settle ownership by PARSING the value against both schemas, never by the name: that literal PASSES SkillSchema, and as an AgentSchema it FAILS at tools with the tombstone prescription. ⛔ These names are not the whole class — a key retired through a .strict() guidance map leaves no tombstone in the walked shape and none of them here (tool.category, live as AIToolDefinition.category).

Coarse fallback — 136 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 9cc5010c708c55d9a0d0c58d955e4b0293cef904 → packageMentionDocs.

Which tree this was computed on

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

node scripts/docs-audit/affected-docs.mjs --json 9cc5010c708c55d9a0d0c58d955e4b0293cef904

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

[os-steve]

Contract review

_{read 2026-09-21T20:42Z}

Served-tier: CONTRACT_REVIEW_TIER
Head-sha: 52f0330d9781b1ef3e1dbdadfc78a68f47f35755

① Derived judgments

Declared member, as it stands at this head:

getEffectiveObjectPermissions?(context?: SecurityContext): Promise<Readonly<Record<string, EffectiveObjectPermission>>>

Is the declared shape RIGHT — the three anchors, each read from the tree rather than taken from the body.

• EvalContext.permissions. packages/formula/src/types.ts:120 declares it EvalPermissions; :40 declares EvalPermissions = Readonly<Record<string, EffectiveObjectPermission>>, over EffectiveObjectPermission imported from @objectstack/spec/security (:16). The declared return is that construction verbatim, over the same element type. This is the ruling's own named target slot, so the engine half hands the answer straight in with no reshaping.
• GetEffectivePermissionsResponse.objects. packages/spec/src/api/protocol.zod.ts:2569 — z.record(z.string(), EffectiveObjectPermissionSchema). A Record is assignable into a Readonly<Record> return, so the endpoint's map flows through unchanged. readonly on a return position constrains the caller, not the implementer, so it is the safe direction and not a narrowing.
• EffectiveObjectPermissionSchema. packages/spec/src/security/permission.zod.ts:595, type at :617 (z.input<…>). Confirmed not declared in protocol.zod.ts, which only imports it at :28 — the seat's corrected reading is the right one.

Parameter, optionality, and the absent context. context?: SecurityContext is character-for-character the sibling spelling at security-service.ts:397 (resolvePermissionSetsForContext?(context?: SecurityContext)), and SecurityContext = Partial<ExecutionContext> is all-optional by construction with the type's own docblock covering partial callers. An absent context therefore needs no separate clause on this member, and the answer it yields — an empty map — is already a defined real answer under the member's own doc rather than an undefined state. No gap, and the optional ? is what a widening requires.

The three shape questions really are closed by published contracts; I read the closures, not the argument for them. packages/formula/src/stdlib.ts:160-162 states that "an object the effective map does not mention is an object with no grant, and answers false" — so a caller may not narrow the map, and the reader correctly takes no object parameter. stdlib.ts:198-207 is the failure stance in the consumer's own runtime code: with binding.permissions === undefined, can() throws, and its message names the shape outright — "the objects map of the published /auth/me/permissions response, object name -> EffectiveObjectPermission". No map is a loud throw, an empty map is a quiet real answer, so a reader that degraded to {} would publish a denial of everything as measured fact. The declared contract matches on all three.

Was the published type reused rather than duplicated? Yes. EffectiveObjectPermission is imported from ../security/permission.zod.js; no parallel entry shape is declared anywhere in the diff. The only thing restated is the Readonly<Record<string, …>> wrapper, and it must be restated: packages/spec/package.json carries no @objectstack/formula dependency in dependencies, devDependencies or peerDependencies, while packages/formula/package.json depends on @objectstack/spec (workspace:*). Importing EvalPermissions would invert that direction, so restating the wrapper over the imported element type is the only available spelling. Not a duplicate shape.

The census question — done is the right call, and needs_decision would have been wrong. The ground is the ruling text, not the author's argument for it. Comment 5725678115 does not merely order a census. Under Interface it directs: 「the claimant files the spec sub-card for the member (Clause-②: yes, the spec lane's at-tier review, changeset @objectstack/spec minor) and this card carries the wiring (packages/objectql + packages/plugins/plugin-security), Blocked-by: that sub-card」. The ruling pre-specified this PR's clause, its review tier, its semver level and its shape (「the caller's effective object permissions in the /auth/me/permissions shape (the map can already reads)」). The Census first bullet defines its own rows as "populates permissions, or is out of scope with a reason" — rows about evaluation SITES, carried by the wiring card. The board agrees: #19578 is titled as the packages/spec half and #18783 is pm:blocked / domain:engine, so the split is recorded rather than asserted. A census over sites cannot move a return type pinned at both ends by already-published contracts, and the body declares 「⛔ No census was run here」 outright rather than implying one. The contract was not declared prematurely.

Do the pins pin the contract, or merely the syntax? Mostly the contract.

• The @ts-expect-error on the unguarded call pins OPTIONALITY, and it is self-falsifying: security-service.test.ts has no entry in packages/spec/test-typecheck-debt.json (53 entries, none matching; control — src/ai/conversation.test.ts is one of them), so its budget is zero and an unused directive reds check:test-typecheck.
• Optionality is closed from the other direction too, by the file's pre-existing RequiredMember / UnlistedRequiredMember / satisfies readonly RequiredMember[] machinery: making the member required would make UnlistedRequiredMember non-empty and stop the file compiling.
• The RETURN TYPE is genuinely pinned, because makeService(overrides: Partial<ISecurityService>) type-checks every override literal against the declared signature. apiOperations: ['get', 'list'] is the real discriminator: apiOperations exists only on the response-side EffectiveObjectPermissionSchema and deliberately not on the authoring ObjectPermissionSchema, and both values are members of API_OPERATION_ORDER (packages/spec/src/data/object.zod.ts:65). Swapping the element type to the authoring one would fail excess-property checking, so the test pins the effective-vs-authored distinction it claims to pin.

⚠️ Two nits, neither a FAIL ground. (a) The body states "the three @ts-expect-error pins"; this diff adds one. The file carries 7 at this head, 6 of them pre-existing. The mechanism the sentence relies on is sound, but the count is wrong and a reader checking the claim will not find three. (b) Two of the five new assertions measure language semantics rather than the contract: expect(withoutIt.getEffectiveObjectPermissions?.({…})).toBeUndefined() holds by optional chaining alone, and expect(map && 'lead' in map).toBe(false) / expect(map?.lead).toBeUndefined() assert about a literal the test itself wrote. The normative "absent entry = no grant" rule is enforced in @objectstack/formula, which packages/spec cannot reach from here — so those lines document rather than pin.

api-surface / json-schema untouched is CORRECT — verified with a radius and a control, not accepted. packages/spec/api-surface/contracts.json records ISecurityService (interface): an export NAME plus kind. getReadableFields, a pre-existing MEMBER of that same interface, appears in no api-surface shard (exit 1), while ISecurityService appears in the same radius (exit 0) — so interface members are not recorded, and adding one moves nothing. api-surface-signatures.json is scoped to the 27 defineX factories (read in full); ISecurityService is not one, and build-api-surface.ts's own SCOPE docblock confirms both artifacts describe the export surface only. In packages/spec/json-schema/, ISecurityService is absent (exit 1) while EffectiveObjectPermission is present (exit 0 — json-schema/security/EffectiveObjectPermission.json and objectstack.json): the radius is zod schemas, and a TypeScript interface member falls outside it. No regeneration was owed, and no baseline update is missing.

② Semver level

The changeset grades '@objectstack/spec': minor, and @objectstack/spec is the only package this diff moves. Against judgeLevel (scripts/check-changeset-no-major.mjs:1618) that yields offenders (moved packages graded patch) empty and raised (moved packages graded minor or above) = @objectstack/spec minor, so refusable = offenders.length > 0 && raised.length === 0 is false: the level axis discharges rather than reaching the enforce verdict. minor is correct and required for a widening, and no other moved package is left at patch because there is no other moved package. Check Changeset is green on both of its runs.

③ Boundary flags

Clause-②: yes (widening) is correct, judged from the diff and the card. The source file's entire change is one optional member added to ISecurityService, plus the single deleted line — the existing type-only import, rewritten to add EffectiveObjectPermission to its brace list. Nothing renamed, nothing narrowed, nothing removed; a security service that omits the member still satisfies the contract. Declared in both the PR body and the changeset.

Scope discipline holds. 3 files, +216/−1: the changeset, packages/spec/src/contracts/security-service.ts, packages/spec/src/contracts/security-service.test.ts. Nothing under packages/objectql, nothing in plugin-security, nothing touching evaluateOptionVisibility — the engine half stays with #18783, which is pm:blocked on this card.

⚠️ CI state at review time: NOT CONVERGED — and this verdict does not underwrite the part that had not landed. At the reading stamped above, the head carried 37 check runs: 27 success, 6 skipped, 4 still in_progress — Test Core (1/6), Test Core (5/6), Test Core (6/6) and Type Check · workspace. Zero were red, failed, cancelled or timed out, and none turned red while I watched the set converge from 14 outstanding down to 4. Everything this review's own findings rest on had already landed green: Lint & Repo Gates (which settles the line-length question the new import line raises), Build Core, Type Check · source gates, Type Check · consumer gates, Type Check · debt ledger, Check Changeset on both runs, Governed Surface Queue Guard, Dogfood Regression Gate on all three shards, Temporal Conformance (live PG + MySQL), and Test Core shards 2/6, 3/6 and 4/6.

⛔ But Test Core is one of the seven REQUIRED_CONTEXTS (scripts/check-required-contexts.mjs), so three of its six shards plus the workspace typecheck were still outstanding when this record was written. The verdict below is the contract verdict — the shape, the reuse, the census call, the clause, the level, the scope, the pins and the baselines — and it does not attest to those four runs. Confirm they are green before acting on it; anything red there is a finding this record has not made.

Not acted on by this review. needs:contract-review is left hanging as dispatched; no label write, push, approval, draft flip, enqueue or merge was performed. The docs-drift comment is advisory and its gate is green — neither page it lists enumerates ISecurityService members (content/docs/kernel/contracts/index.mdx:42 is a one-line prose row), so this member leaves no doc obligation behind. #18545, named on the card's Refs line, answers 404; per dispatch that is a suspended account's issue and nothing was inferred from its absence.

Implemented-by: claude/issue-19578-isecurityservice-effective-object-permission-reader
Reviewed-by: session_01AmH9bKvGoLjiY86Q4Z3og2

VERDICT: PASS

---

Generated by Claude Code

[github-actions]

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

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

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

• Test Core (5/6) — 失败步骤: Publish this shard's attestation（日志不可读，点进 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，按失败测试文件聚合）：

• ⚠️ 本次没有可用的聚合签名（日志里没有能解析出测试文件名的 FAIL 行）—— 这不是「没有同签名的其他 PR」，是这一轮没测到。跨 PR 聚合本次不可用，请手工比对其他 PR 的同类评论。
• ⚠️ 24h 评论账本没读完（超过 5 页仍未读到窗口尽头），所以上面的「不同 PR 数」是下界，不是全量。

历史信号：

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

分诊清单：

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

---

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

[os-steve]

Merge-queue dequeue triaged — the tests PASSED; the artifact upload got a 403, 2026-09-21T21:50Z

The triage bot said the log excerpt was unreadable and asked for a manual read. Here it is, from the failing
job's own log (Test Core (5/6), job 106511930225, queue run 35653654976, queue head 74456e8b5c).

The failing step is not a test — and the log says the tests passed

check-test-completeness: OK (11 of 11 scheduled package(s) reported, 0 had nothing to run,
                             0 never reached; 8884 test(s) declared and all accounted for).
…
Attested: test-5-of-6 ran to completion with every step green (run 35653654976, attempt 1).
…
##[error]Failed to FinalizeArtifact: Received non-retryable error:
         Failed request: (403) Forbidden: Error from intermediary with HTTP status code 403 "Forbidden"

⇒ the shard ran its full 8884 declared tests, all accounted for, and attested itself green. Both
actions/upload-artifact@v7 finalizations then failed — the timings artifact and the shard attestation —
each with the same (403) Forbidden … from intermediary. The job failed on the upload, and Test Core
then failed its Verify test shard results step because the attestation artifact it reads was never
finalized.

⛔ There is no AssertionError, no Test timed out, no Hook timed out anywhere in the log — the two
signatures the triage note says separate a real regression from load. The failure names a service, not a
test.

Why this is ⛔ not this PR's

reading	value
this PR's diff	3 files: a changeset, an interface declaration, its sibling test — ⛔ nothing touching CI, artifacts or uploads
this PR's own head CI, 52f0330d9781b1ef3e1dbdadfc78a68f47f35755	35 latest-per-name, 30 success, 5 skipped, 0 red — including Test Core (5/6), the same shard, whose attestation upload succeeded there
⭐ the nine merge_group CI runs before this one	all success — 9cc5010c70, 5c5b67fc41, 236cec19a5, f77b806565, 0e658fbe93, a60e04d7d4, 1f69917c5c, 8dba7aac31, b49728f700
the same signature on any other recent failed run	none — the other recent failures are a PR Automation red on a different PR and two Lint & Type Check reds on other heads, none carrying an artifact 403
the bot's own history line	「本 PR 过去 24h 无队列失败记录(首次)」 · 「过去 24h 队列共有 0 个失败构建(不含本次)」

⇒ a one-off artifact-service refusal. ⛔ Not a flake diagnosis offered in place of a root cause: the root
cause is named, quoted from the log, and is an upload returning 403.

What happens next, and the budget it spends

Re-arming once, which is the only retry available for a dequeue (the queue run is gone; re-arming builds a
fresh one). That is the single re-run this PR gets. ⚠️ If the next queue build fails the same way, it is ⛔ not
re-armed again — it becomes a report against the artifact service with two identical readings, not a third
rebuild of everything behind it in the queue.

⛔ Nothing about the PR changes: no commit, no body edit, no label. The head stays
52f0330d9781b1ef3e1dbdadfc78a68f47f35755.

---

Generated by Claude Code