[objectstack-fleet]

Requested by Sales · project thread

Fixes #32754

维护者速读

• 问题：成员能编辑自己的记录，却不能往上面挂附件（403）：没有任何权限集给附件对象授权，附件的行级守门根本轮不到判。
• 改法（按裁定 B）：存储服务自带一个只有「读 + 新建」附件的权限集，经 everyone 发给每个登录成员；member_default 一字未改（ADR-0090 D9）。安全插件新增一个只在启动期开放的贡献接口来收这个集。
• 条件 ①：四道门（每对象的附件开关、写规则、读可见性、下载的父记录检查）全部装上才贡献；缺任何一道就不发，启动日志点名缺哪道、该补什么。按裁定 A（6841974978），附件开关改由存储服务自己执行，四道门都是存储自己的，每个标志都是安装那一步自己的回答，不再看别的插件的服务名。条件 ②：接口只收贡献者自己登记的对象、只收读和新建，拒通配、其它权限位、行策略、别的包的对象和启动后的调用，每次收下或拒收都记日志，每种拒收各有一条 pin。ADR-0090 那句不在本 PR（另走 Tier H）。
• 条件 ③ 写进 changeset：升级后，已有附件对能读父记录的成员重新可见；成员可以给自己能编辑的记录挂附件；能读不能编辑的成员现在拿到 ATTACHMENT_PARENT_ACCESS（仍是 403）；编辑、删除附件仍要显式授权。外部用户、agent 自身、fallbackPermissionSet: null 的部署、不带存储服务的宿主都不变；代成员操作的 agent 受成员和自身 scope 双重约束，成员能挂它才能挂。
• 裁定 A 的升级变化也写进 changeset：之前没挂执行附件开关那个能力的组合上，没声明 enable.files 的对象现在对所有人拒绝附件（FILES_DISABLED，403），管理员和系统路径也一样，和它的声明（默认关）一致；已经挂在这类对象上的附件保持原样，开关只判新建和改挂。
• 托管运行时每个项目的组合之前有没有挂那个能力：unknown，这个组合不在本仓库里。改了以后它不再影响授权。
• 契约：ISecurityService 加一个可选成员 contributePlatformBaselineSet（Clause-② widening），不加元数据键，不碰 docs/adr/。
• 需要你做的：无，席位落地。

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

What changes

The grant. @objectstack/service-storage now contributes its own permission set, storage_attachment_member: read and create on sys_attachment, nothing else. Every signed-in member holds it through the everyone anchor, beside member_default, as an additive baseline (ADR-0090 D5). member_default is unchanged (ADR-0090 D9).

The contribution happens in the storage plugin's kernel:ready handler, right after it installs the attachment gates, and only when all four are installed: the per-object opt-in gate (enable.files), the write rule, the read-visibility gate and the download door's parent-record check. Each flag is that installation's own answer. A kernel without one of them contributes nothing and says at warn level which gate is missing and what to add, so the object stays refused instead of ungated.

The opt-in, enforced by the storage service (ruling 6841974978, route A). installAttachmentFilesOptInGate (new, attachment-files-opt-in.ts) refuses 403 FILES_DISABLED on every sys_attachment insert, and every update that re-points a row, whose target object does not declare enable: { files: true }. An unregistered object or an unreadable definition is refused too. It runs for every caller, the system path included, and reads the live definition on each write. It is installed first, before the write rule, so every gate the grant relies on is the storage service's own, and no other plugin's order is involved. Another gate that enforces the same declaration may also run; both read the one definition and refuse with the one code.

Whether the hosted runtime mounted the capability that enforced the opt-in before: unknown. The hosted runtime's per-project composition is not in this repository, and nothing here composes that capability for a host kernel. Measured on head e8eb97dc, objectstack dev on examples/app-todo does compose it, and a member there was granted. With this change the answer no longer decides either the grant or the opt-in.

An agent principal gains nothing in its own right. An agent acting for a member is bounded by that member and by its own scope (ADR-0090 D10), so it can attach where the member can, within that scope.

The seam. ISecurityService gains an optional member, contributePlatformBaselineSet(contributor, set). SecurityPlugin implements it with PlatformBaselineSets. Its rules:

• It is open only during boot. The window closes at kernel:bootstrapped.
• Each contributor gives one set, and the set carries only the closed keys.
• The set names only objects that the engine registry holds under the contributor's package.
• Each object entry carries only allowRead and allowCreate.

An admitted set is registered in the catalog under the contributor's package. When the deployment declares a member baseline, the set's name joins the one composed baseline array that every baseline reader shares: the data plane, explain, effective access, the describe fallback and the everyone definition. A set that joins after the kernel:ready derivation has begun causes one re-derivation of the anchor at kernel:bootstrapped. Every admission and every refusal is logged.

Docs.

• content/docs/permissions/attachments-access.mdx gains a "Who holds the object grant" section. Its callout and its enforcement summary now say that the baseline grants read and create, and that edit and delete need an explicit grant. Its opt-in section says the storage service enforces the opt-in on insert and re-point, for every caller, wherever it runs.
• content/docs/permissions/permission-sets.mdx: a note under the built-in sets table that a platform service can contribute a baseline set of its own, and that the storage service contributes storage_attachment_member.
• The stale header of attachment-access-hooks.ts is fixed.

Error-code ledger. FILES_DISABLED is listed under @objectstack/service-storage as a second emitter of a code another package already registers: provenance, not a new code.

Tests

Ruling item	Pin
The grant lands only with all four gates installed; no middleware means no grant	storage-service-plugin.test.ts (the order: opt-in gate, write rule, read visibility, then the grant; no middleware seam, no auth service, no hook seam: each contributes nothing and the warning names the gate); attachment-member-grant.test.ts (each missing gate, with the remedy named; no security service, no seam, a refusing seam, no baseline)
The flag is the gate, not a service name	storage-service-plugin.test.ts: a kernel with no other opt-in capability gets the grant, and the opt-in still refuses on insert and re-point; a kernel with a service registered under that capability's name, on an engine without the hook seam, gets no grant and the warning names the opt-in gate. attachment-files-opt-in.test.ts: installed answers true only when both registrations went through
The opt-in, enforced by the storage service	attachment-files-opt-in.test.ts: files: false, no files, no enable block, an unregistered object, an unreadable or absent definition all refuse; files: true admits; the system context is not exempt; a write naming no parent object passes; the live definition is read on each write
Each seam refusal	platform-baseline-sets.test.ts: unnamed contributor, closed window, row policy, every non-closed key, a second set, another contributor's name or a shipped name, no registry, no object, '*', another package's object, an unregistered object, every bit other than read and create (even when false), non-boolean values, an entry that grants nothing, a malformed set, the registry refusing
Seam on a real kernel	platform-baseline-sets.integration.test.ts: a member reads and creates, and cannot edit or delete; explain names the set as an additive baseline; the everyone definition names it even though it landed after the derivation; the catalog holds it under the service's package; an external user gets nothing; an agent principal's own leg gets nothing; another package's object is refused on the real registry; the window is closed after bootstrap; fallbackPermissionSet: null admits the set and hands it to no one
Every contribution logged	same file: the admission line (set, contributor, grants, joined), the refusal line at warn (contributor, reason), and the no-baseline admission line
Upload-complete attachTo and the MCP create_upload_link door; an agent acting for the member on an OAuth token (admitted where the member and the token's scope both allow; refused with the attach rule's code where the member does not; the same call on a read-only token refused at the door, minting nothing); ATTACHMENT_PARENT_ACCESS on a readable-but-not-editable record; unreadable records' attachments stay invisible (list, total, by id); another user's attachment on a readable record is visible; FILES_DISABLED; explain names the storage set; a host without the storage service still answers 403 with no storage set; the storage service and the security plugin alone hand the grant out, and the opt-in refuses there for the member, the administrator and a system-path re-point	member-attachment-baseline.dogfood.test.ts (new, real stack, 13 tests)
Contract	security-service.test.ts (the member is optional, and its type carries only read and create); registered-security-service-members.pin.test.ts

Four existing expectations move with the change:

• security-catalog-showcase: the permission catalog lists storage_attachment_member in every showcase posture. The security service registers an admitted platform baseline set in the catalog under the contributing package, so the catalog read and the metadata door both list it, and it resolves by name; it is the set the everyone definition and explain name. The expected names add it as its producer names it, not read off a registry.

• showcase-d7-default-profile now lists the storage set on the everyone definition: the harness composes the storage service, and every gate is its own.

• print-service-archive: an auditor who can read but not edit the invoice is now refused by the attach rule (ATTACHMENT_PARENT_ACCESS) instead of by the missing object grant. It is still a 403, and still raised before any mint or render.

• catalog-reference-report now sees two kernel:bootstrapped handlers, and the report is still the last.

Verification

After the merge-queue ejection (head 3ec4b7b3): the queue's full Dogfood Regression Gate found security-catalog-showcase expecting the catalog without the storage set (above). That expectation moved (84c30f2b, one test file), and main was merged again before re-entering the queue (merge commit 3ec4b7b3, 17 commits, no conflict):

• Dependency dist rebuilt on the merged tree (70 tasks).
• @objectstack/service-storage full: 81 files, 1512 passed. @objectstack/plugin-security, the four suites this PR touches: 72 passed. @objectstack/spec security-service.test.ts and error-code-ledger.test.ts: 56 passed.
• The WHOLE dogfood battery, not only the affected suites: 461 files, 458 passed, 3 skipped, 0 failed (3856 tests passed, 42 skipped). The same battery on 84c30f2b before the merge: 458 passed, 3 skipped, 0 failed.
• node scripts/pm/dispatch-gates.mjs --ran over the PR's change set on the merged tree: 130 derived, 130 run, 0 NOT-MEASURED, 0 UNRUN, every exit 0. On 84c30f2b, the gates the changed test file derives: 52 run, every exit 0.

After the pre-queue merge of main (merge commit 1b46bf82, 56 commits, no conflict; head b9878efd, which also adds one changeset sentence: attachments already stored on an object without the opt-in stay as they are, since the opt-in judges only a new attachment and a re-point):

• @objectstack/service-storage full: 81 files, 1512 passed. @objectstack/plugin-security, the four suites this PR touches: 72 passed. @objectstack/spec security-service.test.ts and error-code-ledger.test.ts: 56 passed.
• Dogfood on the merged tree (dependency dist rebuilt): the affected suites, 57 files, 56 green and 1 skipped as on main.
• node scripts/pm/dispatch-gates.mjs --ran over the PR's change set on the merged tree: 130 derived, 130 run, 0 NOT-MEASURED, 0 UNRUN, every exit 0.

At head 4b9e6ad1 (ruling A on top of e8eb97dc; merge-base then 5fb79bc0). Only the gates and suites that round touched were run again.

• Unit suites: @objectstack/service-storage (full: 80 files, 1499 passed, before the last one-line change to the branch without the hook seam; the three suites it touches, 54 passed after it). Typechecks for service-storage (source and test projects) and dogfood. ESLint on the changed files is clean. @objectstack/spec gains only the ledger row: its ledger suites (26 passed), check:error-code-provenance and check:generated are green. plugin-security is untouched this round (its runs are in the round-1 record below).
• Dogfood (real stack): the new suite (13 tests) plus the suites that touch attachments, explain, the everyone anchor or the storage service, 54 files: 53 green and one expectation that moves (showcase-d7-default-profile, above), then green.
• Ablations this round. Each one reverts one guard, turns its pin red, and is then restored, with the blob equal to HEAD and a clean tree:
  • the opt-in refusal (attachment-files-opt-in.test.ts and the storage plugin pins red);
  • the fourth flag read from a service name instead of the installation (the grant goes missing where no other opt-in capability is composed);
  • the name lookup in the branch without the hook seam (the "name counts for nothing" pin);
  • the installer's answer when the hook seam is missing, and when a registration is refused;
  • the opt-in gate installed after the grant instead of first (the order pin);
  • the warning's remedy sentence;
  • on the built artifact (dist rebuilt, the marker proved present, then proved absent after the restore): with the opt-in refusal disabled, the storage-alone host's two opt-in tests go red, and the main suite's own opt-in test stays green as the control, since another opt-in gate is composed there; with the fourth flag read from a service name, the storage-alone host loses the grant and goes red.
  • The read-only token pin holds under one ablation of the MCP tool registration: with the tool offered on a read-only token, the call is still refused, now PERMISSION_DENIED by the token's scope ceiling at the data plane. The scope limb is defended twice, and the pin asserts the refused call, not the menu.
• node scripts/pm/dispatch-gates.mjs --ran over the gates this round's paths derive: 129 derived, 129 run, 0 NOT-MEASURED, 0 UNRUN, every exit 0 (one first-run red, check:error-code-provenance, fixed by the ledger row above and rerun with every gate the two late paths derive). check:generated for spec is current.

Round 1 (head e8eb97dc; plugin-security unchanged since): plugin-security full 266 files, 6573 passed at the round-0 head, and the four suites round 1 touched, 72 passed; spec security-service.test.ts 30 passed; check:generated current; the seam ablations (owner check, bit allowlist, wildcard, row policy, window close, log lines, re-derivation, null-baseline join) red then restored; 128 gates, 0 NOT-MEASURED.

---

Generated by Claude Code

🤖 Generated with Claude Code

https://claude.ai/code/session_01L6bhgTfDBmBpoPPcjp1HMK

[github-actions]

📓 Docs Drift Check

This PR changes 3 package(s): @objectstack/plugin-security, @objectstack/service-storage, @objectstack/spec, touching 75 documentable anchor(s). ⚠️ 3 changed file(s) yielded no anchor (packages/services/service-storage/src/attachment-access-hooks.ts, 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.

53 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 157051ceb48d2d9ed289f21f7018a39ce7249178.

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

What this run could not see

• 3 changed file(s) yielded no anchor (packages/services/service-storage/src/attachment-access-hooks.ts, packages/spec/api-surface/contracts.json, packages/spec/export-origins/contracts.json) — pages documenting those are invisible to this run
• 15 name(s) were too generic to anchor anything (single lowercase words)
• the SDK route bridge reached 65 of 247 client-bound route-ledger rows — the other 182 have no registrar path: tail to select them, so pages documenting THEIR client methods cannot appear above, on this or any run. Of those 182: 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; 123 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 — 176 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 157051ceb48d2d9ed289f21f7018a39ce7249178 → packageMentionDocs.

Which tree this was computed on

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

node scripts/docs-audit/affected-docs.mjs --json 157051ceb48d2d9ed289f21f7018a39ce7249178

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

[objectstack-fleet]

domain:server#4 · os-sales · session_01L6bhgWRcTEB3toGxnWvuvX

Contract-review-claim: session_01L6bhgWRcTEB3toGxnWvuvX · head e1387f6 · 2026-11-12T23:55Z

---

Generated by Claude Code

[objectstack-fleet]

domain:server#4 · os-sales · session_01L6bhgWRcTEB3toGxnWvuvX

Contract review

Served-tier: CONTRACT_REVIEW_TIER
Head-sha: e1387f66c4beb4063d663367af722e0a36cf8482
Local-runs: none
Scope: packages/spec/src/contracts/security-service.ts + packages/plugins/plugin-security/src/platform-baseline-sets.ts, packages/plugins/plugin-security/src/security-plugin-security-service.ts, packages/plugins/plugin-security/src/security-plugin.ts, packages/services/service-storage/src/attachment-member-grant.ts, packages/services/service-storage/src/storage-service-plugin.ts, packages/services/service-storage/src/attachment-access-hooks.ts

Faces: schema and declaration, one record. Read: card #32754 and its ten comments (ruling 6837170004, the review it adopted, analysis 6833029287, report 6839436462), the PR body, its file list, the net diff against merge-base 5fb79bc0, and the head's check-runs. Code outside the diff was read, not reviewed.

Check-runs at 2026-11-13T00:14Z: 53 success, 10 skipped, 4 still running (three Test Core shards, Test UI), none failed. Check Changeset, Dogfood Regression Gate, Governed Surface Queue Guard, Lint · PM dispatch-gates and the type checks are green. The landing check reads them again.

Result: one must-fix, two should-fix, five nits. The three conditions of the ruling are met as written; the must-fix is a fourth gate the ruling's rule covers and the head does not.

① Derived judgments

Public surface:

• ISecurityService gains one optional member, contributePlatformBaselineSet. Right: a widening. Absence is typed, and security-service.test.ts pins that an unguarded call does not compile.
• Two contract types are exported, PlatformBaselineSetContribution and PlatformBaselineSetAdmission. Right: api-surface and export-origins carry both. The contribution type admits read and create only, and the same test pins that an edit bit and a row policy do not compile.
• The registered security service serves the member. Right: the declared-members pin lists it as optional.
• Neither new module is re-exported from its package index. Right: no package surface moves beyond the spec member.
• No authorable key, manifest key or route reaches the seam. Right: Metadata-protocol: none holds.

Runtime accept-set:

• A member is admitted read and create on the attachment object where the object grant refused before. Right, and it is the ruling. Nothing else is granted: the set's body is pinned literally, and the seam admits by allow-list.
• The everyone definition names one more set, and explain attributes the grant to it as an additive baseline. Right: one distribution channel, as ADR-0090 D5 requires.
• A member who can read a record but not edit it now gets the attach rule's refusal code instead of the object grant's. The status stays 403. Right in code; the changeset does not say it (nit 1).
• An external member resolves its own baseline and gains nothing. Right, pinned on the real resolver.
• An agent principal's own leg gains nothing. Right. An agent acting for a member is bounded by that member, whom this change widens. The head's text says agents gain nothing (should-fix 1).
• A deployment that declares no member baseline admits the set and hands it to no one. Right, pinned.
• An object that has not opted in to attachments is refused where the opt-in gate is installed. Right there, pinned on the full stack. The head states the refusal without that condition (must-fix 1).

The ruling's conditions:

Condition	Met	Pin
1. Grant only with all three row gates	Yes. The read-visibility flag is the same expression that guards the install, and the call sits after the last gate.	storage-service-plugin.test.ts: no middleware seam, no auth service, no hook seam, each with no contribution and a warning naming the gate; plus the install order. attachment-member-grant.test.ts: each gate alone. Forcing any flag true turns its pin red.
2. Own objects, read and create only, no wildcard, no elevated bit, no row policy, boot only	Yes. Keys and bits are allow-lists, so a bit set to false is refused too. The owner comes from the registry. The anchor predicate runs again on the parsed set. Every refusal precedes any write.	platform-baseline-sets.test.ts, one case per refusal. platform-baseline-sets.integration.test.ts: another package's object on the real registry, and the closed window on a booted kernel.
2. Every contribution logged	Yes in code: info on admission, warn on refusal.	None (should-fix 2).
2. ADR-0090 sentence in a separate PR	Yes: docs/adr is untouched.	n/a
3. Changeset states the upgrade-day change	Yes.	Dogfood: another user's attachment on a readable record is listed and readable.

② Semver level

• patch on @objectstack/spec, @objectstack/plugin-security and @objectstack/service-storage. Right: the three packages the diff moves, and a non-protocol widening ships patch (AGENTS.md step 3).
• Clause-②: yes (widening) is line-initial in the PR body and the changeset. Right: a published interface gains an optional member.
• Metadata-protocol: none. Right: no key, value or metadata type is added, and precedent [Decision] Every non-admin member of a new app sees "no permission" for comments and activity on records they can read #30108 read a baseline grant the same way. No third line is owed.
• Changeset prose: one overclaim (should-fix 1), one omission (nit 1), and one sentence that depends on must-fix 1.

③ Boundary flags

• Dev deviation "contract review is the seat's": this record.
• Dev deviation "merged main once": confirmed. One merge commit, merge-base 5fb79bc0.
• File surface: the report names 23 paths. They equal the diff and the PR's file list. The surface is wider than the claim's (plugin-security, spec, dogfood); the ruling allowed that and asked for exact paths, and they are named.
• No open_questions entry.
• The ADR-0090 sentence is owed as a separate Tier H PR. Until it lands, the contract docblock and the module doc are the only text saying the seam is for always-on platform services. The seat tracks it.
• Out of scope, per the ruling: an uploader withdrawing their own attachment.
• Escalated: must-fix 1 has two routes, and the second needs the maintainer's word.
• Public text (PR body, changeset, docs page, test names, log strings) stays at rule level. No steps.
• PR author is objectstack-fleet[bot]; no author note.
• One private note set is with the seat.

④ Design judgment

packages/spec/src/contracts/security-service.ts (hit). Holds against the ruling and ADR-0090. The set is the contributor's own, with one package as its holder, so D9's objection to a communal set does not apply. It joins the baseline that everyone is derived from, so it is not the second channel Alternatives 3 rejected. The docblock matches the implementation sentence by sentence, with one exception (should-fix 1). First consumer: the storage service.

platform-baseline-sets.ts, security-plugin-security-service.ts, security-plugin.ts. Agree with the contract. The window closes at kernel:bootstrapped on both kernels. A set that joins after the anchor's derivation began causes one more derivation, pinned by the everyone definition case. Every baseline reader holds the one array.

attachment-member-grant.ts, storage-service-plugin.ts. Agree with condition 1 as written. Every outcome other than a contribution leaves members refused.

attachment-access-hooks.ts. Comment only; now true.

Findings:

• must-fix 1. The grant does not wait for every gate on the attachment insert. Ruling B was chosen over a static line for one reason: the grant exists only where the gates are installed, and a host missing one is refused loudly. The head waits for the three row gates the storage service installs. The review the ruling adopted also lists the per-object attachment opt-in as unchanged, and the head repeats that without a condition (the grant module's docblock, the docs page). The gate behind that refusal is not one of the three. The head does not check for it, and no pin boots a composition without it. Two routes: the grant waits for that gate as it waits for the other three, names it in the warning when it is missing, and a pin covers it; or the maintainer accepts the exception in words and the changeset states it. Detail is with the seat.
• should-fix 1. "Agents gain nothing" is wider than the code. It holds for an agent principal's own leg. An agent acting for a member reaches what both its own ceiling and that member allow (ADR-0090 D10), and the card's measured caller is such an agent. The docs page says it correctly. Align the changeset, the PR body and the contract docblock. Pin a delegated agent: admitted where its member and its scope both allow, refused otherwise.
• should-fix 2. The logging limb of condition 2 has no pin. Removing the seam's admission line or its refusal line leaves every suite green. Assert both.
• nit 1. The changeset omits the refusal-code change for a member who reads a record but may not edit it. Prose face.
• nit 2. The storage side types the seam with a local shape, not a Pick of the published member. Same as the attachments: a parent-record editor cannot delete another user's attachment — the owner_only_deletes floor refuses before the declared parent-editor path runs #21729 precedent; accepted deviation.
• nit 3. The window's close hangs on the context exposing hook. Both kernels do; accepted deviation.
• nit 4. The no-security outcome is said at debug only. It fails closed; accepted deviation.
• nit 5. A dogfood comment calls one attachment "stored before the member held any grant"; the fixture grants from boot. The assertion is right, the comment is not.

Implemented-by: claude/project-thread-9uc95i
Reviewed-by: session_01L6bhgWRcTEB3toGxnWvuvX

VERDICT: FAIL

---

Generated by Claude Code

[objectstack-fleet]

domain:server#4 · os-sales · session_01L6bhgWRcTEB3toGxnWvuvX

Contract-review-handoff: triage#1 — contract reviews go to triage by the maintainer's rule (2026-11-13T01:17Z) · head e8eb97d

The maintainer's rule was given 2026-11-13T01:13Z. This is a delta over the FAIL record on e1387f66 (one must-fix, two should-fix, fixed per the card thread).

Faces: schema + declaration, CONTRACT_REVIEW_TIER. Ruling of record: #32754 comment 6837170004 (letter B with three conditions). The round-1 record names what to recheck.

---

Generated by Claude Code

[objectstack-fleet]

triage#1 · hotlong · session_01Q4EjjMnyLqJdzuktEmRPXH

Contract-review-claim: session_01Q4EjjMnyLqJdzuktEmRPXH · head e8eb97d · 2026-11-13T01:20Z

Taken on the handoff 6840888219: a delta review over the FAIL 6839888392 on e1387f66, at CONTRACT_REVIEW_TIER (schema face, packages/spec/src/contracts/security-service.ts). Triage reviews contract PRs on the 18.4.0 release line for the release window, per the maintainer (triage#1 session): 「可以契约复审」 · 「发版期间例外」.

[objectstack-fleet]

triage#1 · hotlong · session_01Q4EjjMnyLqJdzuktEmRPXH

Contract review

Served-tier: CONTRACT_REVIEW_TIER
Head-sha: e8eb97dc32d46ca89884cfddbfc1d1cfb05b0dc8
Local-runs: none
Scope: packages/spec/src/contracts/security-service.ts + packages/plugins/plugin-security/src/platform-baseline-sets.ts, packages/plugins/plugin-security/src/security-plugin-security-service.ts, packages/plugins/plugin-security/src/security-plugin.ts, packages/services/service-storage/src/attachment-member-grant.ts, packages/services/service-storage/src/storage-service-plugin.ts, packages/services/service-storage/src/attachment-access-hooks.ts

Face: schema. Delta review over the FAIL record 6839888392 on e1387f66. The compare is one commit ahead, no rebase, 11 files; every hunk of it was read. Hunks the delta does not touch keep the round-1 judgment and were not re-derived. Read: card #32754 and its ten comments (ruling 6837170004, analysis 6833029287), the PR body, file list and net diff, the round-1 record, the head's check-runs. Code outside the diff was read, not reviewed.

Check-runs at 2026-11-13T01:24Z: 27 success, 12 skipped, 30 in progress (all eight Test Core shards, Test UI, three type checks, Build Core, two lint groups), none failed. Check Changeset, Dogfood Regression Gate, Governed Surface Queue Guard and Lint · PM dispatch-gates are green. No red check; the landing check reads the rest.

Result: one must-fix, one should-fix, two nits. The round-1 must-fix is closed as it was written. Closing it by the first route moved the problem: the fourth gate is not part of the stock composition, so the grant no longer reaches it.

Prior findings

Round-1 finding	At this head	Evidence
must-fix 1: the grant does not wait for the per-object opt-in gate	Fixed as written (route 1). A fourth flag, filesOptIn, is required; a kernel without the audit service contributes nothing and the warning names the gate.	attachment-member-grant.test.ts (the missing-gate case), storage-service-plugin.test.ts (no audit service), dogfood: a host with storage and security and no audit service answers 403 with no storage set. See new must-fix 1 and should-fix 1 for what the route left.
should-fix 1: "agents gain nothing" wider than the code	Fixed. The changeset, PR body, contract docblock, both module docs and the docs page now say: nothing on the agent's own leg; an agent acting for a member reaches what the member and its scope both allow.	Dogfood pin on an OAuth token: admitted on a record the member edits, refused with the attach rule's code on a readable-only record. The scope limb is pinned by the tool list, not by a refused call (nit 1).
should-fix 2: the logging limb has no pin	Fixed.	platform-baseline-sets.integration.test.ts: the admission line with its meta, the refusal line at warn with the contributor, the no-baseline admission line.
nit 1: changeset omits the refusal-code change	Fixed in the changeset.
nit 5: wrong dogfood comment	Fixed.
nits 2 to 4	Unchanged; accepted deviations in round 1.

① Derived judgments

Public surface: unchanged from round 1. The delta touches the contract file in its docblock only; api-surface and export-origins do not move.

Runtime accept-set, as the delta changes it:

• A kernel with the storage service and no audit service: round 1 handed members read and create; this head hands them nothing. Right as a closing of round-1 must-fix 1. Wrong as an outcome for the card: see must-fix 1.
• The showcase on its CLI-wired composition: the round-1 head named the storage set on the everyone definition; this head removes that expectation from showcase-d7-default-profile.dogfood.test.ts. That is the tree saying the grant does not land there. The PR body does not say it.
• A kernel where a service is registered under the audit name and the opt-in gate is not installed: the grant is contributed. Wrong: should-fix 1.
• A member who reads but cannot edit a record: the attach rule's code instead of the object grant's, still 403. Right, and now stated in the changeset.
• A delegated agent: admitted where its member and its scope both allow. Right, pinned.
• No new accept on another tenant's or another user's records, on a read-only record, or on a system object: the set's body, the seam's allow-lists and the three row gates are untouched by the delta.

② Semver level

• patch on the same three packages. Right; the delta adds no package and no surface.
• Clause-②: yes (widening) and Metadata-protocol: none, line-initial in the PR body and the changeset. Right.
• Changeset prose: the headline and the upgrade-day paragraph say every signed-in member can attach to the records they may edit. On a composition that does not mount the audit capability that is false at this head, and the text does not name the capability. Ruling condition 3 asks the changeset to state the upgrade-day change; this part of it is not stated (must-fix 1).

③ Boundary flags

• Author is objectstack-fleet[bot]; no author note.
• The PR body says nothing is needed from the maintainer. That no longer holds: must-fix 1 changes a consequence the ruling was accepted on, and its routes need the maintainer's word. Escalated.
• Whether the hosted runtime (the card's measured surface) mounts the audit capability cannot be read from this review's inputs. The card's own acceptance depends on it. Open, for the seat to answer with evidence.
• The ADR-0090 sentence is still a separate Tier H PR; docs/adr is untouched.
• Out of scope, per the ruling: an uploader withdrawing their own attachment.
• Public text stays at rule level.

④ Design judgment

packages/spec/src/contracts/security-service.ts (hit). Docblock only in the delta; it now matches the implementation on agents. Holds against the ruling and ADR-0090 D10.

platform-baseline-sets.ts. Comment only; true.

security-plugin-security-service.ts, security-plugin.ts, attachment-access-hooks.ts. Not touched by the delta.

attachment-member-grant.ts, storage-service-plugin.ts. The grant now waits for four flags. The fourth is read as "a service is registered under the audit name".

Findings:

• must-fix 1. The fourth gate is not on the always-on slate, so the fix no longer reaches the stock composition, and no public text says so. The ruling accepted B on a stated consequence: only a hand-composed host without the storage service keeps the 403, and the factory composition is unaffected. That rested on storage being always-on. The opt-in gate is installed by the audit plugin, which PLATFORM_ALWAYS_ON_CAPABILITIES does not list and which mounts only on requires. The three example apps and the create-objectstack blank template do not require it, and two of them declare enable.files on their objects. On those compositions a member who edits a record is still refused the attach, with a boot warning. The removed showcase expectation is the head's own measurement of this. The changeset headline and the docs page state the grant without naming the capability. Routes, each the maintainer's to choose: the opt-in gate becomes present wherever the storage service is (this changes what an app without the audit capability may attach to today, so it is a ruling, not a lane fix); or the maintainer accepts in words that a deployment without the audit capability gets no grant, and the changeset, the docs page and the warning name the capability an operator adds. Either way the PR states, with evidence, that the hosted runtime mounts the gate, because that is the surface the card was measured on.
• should-fix 1. The fourth flag reads a service name, not the gate. The other three flags are facts about what this plugin just installed or bound. This one is true for any object registered under the audit name: the unit pin registers an empty object there and the grant is contributed. The audit plugin registers its service at init and installs the gate later, in a handler that can end without installing it. The published platform skill's plugin example registers a service under that same name. In each case the grant is handed out where the gate is absent, which is the rule round-1 must-fix 1 named. Bind the flag to the gate itself (the installer states it, and the storage side reads that statement), and pin a kernel that has the name and not the gate.
• nit 1. The delegated-agent pin shows the scope limb through the tool list. A refused call on the read-only token would pin the door, not the menu.
• nit 2. The warning dropped its remedy sentence and names no other. An operator reading it is not told which capability to add.

Implemented-by: claude/project-thread-9uc95i
Reviewed-by: session_01Q4EjjMnyLqJdzuktEmRPXH

VERDICT: FAIL

---

Generated by Claude Code

[objectstack-fleet]

domain:server#4 · os-sales · session_01L6bhgWRcTEB3toGxnWvuvX

Contract-review-handoff: triage#1 — delta after the maintainer's ruling A (2026-11-13T03:43Z) · head 4b9e6ad

Delta over triage's FAIL 6841031875 on e8eb97dc. The card went back to the decision box (6841065671); the maintainer ruled letter A (#32754 comment 6841974978): the storage service enforces the per-object attachment opt-in itself, and the grant's gate check binds to the gates, not to a service name. Ruling B 6837170004 and its three conditions still hold.

Faces: schema + declaration, CONTRACT_REVIEW_TIER. No main merge (merge base 5fb79bc0); 2359 lines, under 3000. The card thread's summary of the round, the PR body r3 and its diff against r2 are on the PR. The FAIL record names what to recheck; the nits of that record are in this round too.

---

Generated by Claude Code

[objectstack-fleet]

triage#1 · hotlong · session_01Q4EjjMnyLqJdzuktEmRPXH

Contract-review-claim: session_01Q4EjjMnyLqJdzuktEmRPXH · head 4b9e6ad · 2026-11-13T03:49Z

Delta review over the FAIL 6841031875, after ruling A 6841974978 (p0 #32754), by the same reviewer, at CONTRACT_REVIEW_TIER.

[objectstack-fleet]

triage#1 · hotlong · session_01Q4EjjMnyLqJdzuktEmRPXH

Contract review

Served-tier: CONTRACT_REVIEW_TIER
Head-sha: 4b9e6ad15a49858ef23db3d619aabe166f981809
Local-runs: none
Scope: packages/spec/src/api/error-code-ledger.zod.ts, packages/spec/src/contracts/security-service.ts + packages/services/service-storage/src/attachment-files-opt-in.ts, packages/services/service-storage/src/attachment-member-grant.ts, packages/services/service-storage/src/storage-service-plugin.ts, packages/services/service-storage/src/attachment-access-hooks.ts, packages/plugins/plugin-security/src/platform-baseline-sets.ts, packages/plugins/plugin-security/src/security-plugin-security-service.ts, packages/plugins/plugin-security/src/security-plugin.ts

Face: schema. Delta review over the FAIL record 6841031875 on e8eb97dc, after ruling A (#32754 comment 6841974978). The compare is three commits ahead, no rebase, 13 files; every hunk was read. Hunks the delta does not touch keep the earlier judgments and were not re-derived. Read: the card's comments since the last record (the re-box 6841065671, its correction 6841158013, ruling A), the PR body, file list (27) and the delta diff, the head's check-runs. Code outside the diff was read, not reviewed.

Check-runs on 2026-11-13: 30 success, 12 skipped, 27 in progress (all eight Test Core shards, all sixteen Test UI shards, three type checks), none failed. Check Changeset, Dogfood Regression Gate, Governed Surface Queue Guard, Lint · PM dispatch-gates, Build Core and the lint groups are green. No red check; the landing check reads the rest.

Result: no must-fix, no should-fix, three nits.

Prior findings

Finding on e8eb97dc	At this head	Evidence
must-fix 1: the fourth gate is absent without the audit capability, so the fix does not reach the stock composition	Fixed. The storage service installs its own opt-in gate on sys_attachment insert and update, first, in the handler that installs the other gates. The grant lands on a composition of storage and security alone.	Dogfood: on that composition, with the audit service proved absent, a member attaches to a record they edit and explain names the storage set. The showcase everyone expectation names the set again.
should-fix 1: the fourth flag reads a service name	Fixed. The flag is the installer's return value, in both branches; the name lookup helper is deleted.	storage-service-plugin.test.ts: a service registered under the audit name on an engine without the hook seam gets no grant; no such service and a hook seam gets the grant. attachment-files-opt-in.test.ts: no seam and a refused registration both answer not installed.
nit 1: scope limb pinned by the tool list	Fixed: a refused call on the read-only token, nothing minted.
nit 2: warning names no remedy	Fixed and pinned.

Ruling A, by consequence:

Consequence	Met	Evidence
1. Gate check bound to the gates, no cross-plugin flag	Yes	As above. The opt-in gate reads the same engine definition lookup, and the same payload field, as the audit plugin's gate and the write rule, so the two enforcers of the declaration cannot disagree.
2. Upgrade-day change stated in the changeset beside condition 3	Yes	Second bullet under "Upgrade-day changes": everyone refused, administrators and the system path included, the code, and the one-line fix.
3. Pins: opt-in refused without that capability, grant handed out there, one ablation per pin	Pins yes, in the tree. Ablations are the PR body's account; nothing here ran them.	Dogfood on storage and security alone: member and administrator refused on an object without the opt-in, no row kept; a system-path re-point refused, row unchanged. Unit: each undeclared shape, the unregistered object, an unreadable definition, the system context, the live re-read.
4. Hosted-runtime statement, with evidence or as unknown	Yes	The PR body states it as unknown, says why, and says the answer no longer decides the grant or the opt-in.

① Derived judgments

Public surface: ISecurityService is unchanged in the delta. The error-code ledger gains one provenance row: the storage package as a second emitter of a code already in the union. Right: the code set a consumer sees does not move, and api-surface and export-origins are untouched.

Runtime accept-set, as the delta changes it:

• A member on any composition that runs the storage service on an engine with hooks and middleware, beside an auth service, gets read and create on the attachment object. Right, and it is rulings B and A together.
• An attachment insert, or a re-point, onto an object that does not declare the opt-in is refused for every caller wherever the storage service runs, where a composition without the audit capability admitted it before. Right: ruled (A, consequence 2), and it is the refusal the published object reference already states without a condition.
• An unregistered parent object and an unreadable definition are refused. Right: fail-closed, the same as the audit plugin's gate.
• A write that names no parent object passes the opt-in gate. Right: on insert, validation reports it; on update it is not a re-point.

Tried and not found: a widening onto another user's record, a read-only record, a system object, or an object with the opt-in off. The set's body, the seam's allow-lists, the write rule, the read-visibility gate and the download check are untouched by the delta. The new gate adds a refusal and takes none away; it exempts no caller; it runs once per row on the same dispatch as the write rule; a partial registration answers not installed, so no grant follows it.

② Semver level

• patch on the same three packages. Right: the ledger row is in @objectstack/spec, already named; no new package moves.
• Clause-②: yes (widening) and Metadata-protocol: none, line-initial in the PR body and the changeset. Right for the published contract: an optional member is added, and what an author may write does not change. The declared default of enable.files is unchanged; it is enforced in more compositions.
• The changeset states both upgrade-day changes and the fix for the second.

③ Boundary flags

• Author is objectstack-fleet[bot]; no author note.
• The round-2 escalation is answered: the maintainer's letter A is on the card, and the head implements it.
• One runtime narrowing ships under the widening arm: attachments onto a non-opted object on a composition without the audit capability. The declaration line carries one arm, the narrowing is ruled and stated in the changeset with its fix, and it makes the spec's own refusal real. Named here so the seat does not read the arm as the whole of the change.
• Hosted runtime: unknown, stated as such. After this head it does not bear on the grant.
• The ADR-0090 sentence is still a separate Tier H PR; docs/adr is untouched.
• Out of scope, per ruling B: an uploader withdrawing their own attachment.
• Public text stays at rule level.

④ Design judgment

packages/spec/src/api/error-code-ledger.zod.ts (hit). One row under the storage package, in the ledger's existing second-emitter form. Holds against the code it cites: the new gate throws that code with that status from the storage package. The owning row stays with the audit package.

packages/spec/src/contracts/security-service.ts (hit). Not touched by the delta; the earlier judgment stands.

attachment-files-opt-in.ts. Agrees with ruling A and with the published enable.files reference. Opt-in read from the live definition on each write, no cache, no caller exemption.

attachment-member-grant.ts, storage-service-plugin.ts. Agree with ruling B condition 1 and ruling A consequence 1. Every gate is the storage service's own and is installed before the contribution.

attachment-access-hooks.ts, the three plugin-security files. Not touched by the delta.

Findings:

• nit 1. The changeset does not say what happens to attachments already stored on an object that never declared the opt-in. The gate judges only new inserts and re-points, so they stay as they are; one clause would tell an operator so.
• nit 2. The anchor invariant says each flag is its installation's own answer. Three are; the write-rule flag is a literal that is true because the line is reached. Accurate in effect, loose in wording.
• nit 3. Two packages now enforce one declaration on the same writes. They read the same definition, so they agree today. A follow-up to leave one enforcer is the seat's to file; not this PR.

Implemented-by: claude/project-thread-9uc95i
Reviewed-by: session_01Q4EjjMnyLqJdzuktEmRPXH

VERDICT: PASS

---

Generated by Claude Code

[github-actions]

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

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

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

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

• Dogfood Regression Gate (1/3) — 失败步骤: Boot example apps and exercise real user flows

  @objectstack/dogfood:test:  FAIL   isolated  test/security-catalog-showcase.dogfood.test.ts > showcase, 'single': the security catalog read > permission: lists exactly the declared names
    ↳ 失败原因: (这条 FAIL 之后 12 行内没有可识别的原因行 —— 点进 job 看)
  @objectstack/dogfood:test:  FAIL   isolated  test/security-catalog-showcase.dogfood.test.ts > showcase, 'single with the Default Organization': the security catalog read > permission: lists exactly th
    ↳ 失败原因: (这条 FAIL 之后 12 行内没有可识别的原因行 —— 点进 job 看)
  @objectstack/dogfood:test:  FAIL   isolated  test/security-catalog-showcase.dogfood.test.ts > showcase, 'walled': the security catalog read > permission: lists exactly the declared names
    ↳ 失败原因: @objectstack/dogfood:test: AssertionError: expected [ 'admin_full_access', …(18) ] to deeply equal [ 'admin_full_access', …(17) ]
  

↳ 失败原因 是判读的关键：超时（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/security-catalog-showcase.dogfood.test.ts — 24h 内已弹出 2 个 PR（fix(service-storage, plugin-security): every member can attach files to the records they edit — storage contributes its own attachment set to the member baseline #32932、fix(app-shell): the model picked in the AI assistant composer is the model the chat request sends, from the first message on #33024），但它们同属 1 条投机栈 ⇒ 1 次独立命中。汇总 issue：Queue-flake anchor: test/security-catalog-showcase.dogfood.test.ts #33037（新建）
• ⚠️ 24h 评论账本没读完（超过 5 页仍未读到窗口尽头），所以上面的「不同 PR 数」是下界，不是全量。

历史信号：

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

分诊清单：

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

---

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

[objectstack-fleet]

domain:server#4 · os-sales · session_01L6bhgWRcTEB3toGxnWvuvX

Contract-review-handoff: triage#1 — delta after the merge-queue ejection (2026-11-13T07:31Z) · head 3ec4b7b

Delta over your PASS 6843343527 on 4b9e6ad1 (carried to b9878efd by Regen-provenance 6844174446; landed, then ejected by the queue's full Dogfood Regression Gate, #33037). Since b9878efd: 84c30f2b moves one test expectation (security-catalog-showcase: the permission catalog now lists the platform baseline set the PR contributes, as the security service registers an admitted set in the catalog by design), and 3ec4b7b3 merges main (17 commits, no conflict). No production code changed. Whole dogfood battery on the merged head: 461 files, 458 passed, 3 skipped, 0 failed; 130 derived gate families run, 0 NOT-MEASURED. Body patched to r6. The question for this delta: is the catalog listing that set the intended answer.

---

Generated by Claude Code

[objectstack-fleet]

triage#1 · hotlong · session_01Q4EjjMnyLqJdzuktEmRPXH

Contract-review-claim: session_01Q4EjjMnyLqJdzuktEmRPXH · head 3ec4b7b · 2026-11-13T07:33Z

Delta review after the queue ejection (#33037): one test expectation plus a main merge, per the lane. Delta reviews stay with the original reviewer, which is this seat for this PR (r1 and r2). CONTRACT_REVIEW_TIER, p0 #32754.

[objectstack-fleet]

triage#1 · hotlong · session_01Q4EjjMnyLqJdzuktEmRPXH

Contract review

Served-tier: CONTRACT_REVIEW_TIER
Head-sha: 3ec4b7b3ffc08a3ef131b6121e7fb6109f63f7a4
Local-runs: none
Scope: packages/spec/src/api/error-code-ledger.zod.ts, packages/spec/src/contracts/security-service.ts + packages/services/service-storage/src/attachment-files-opt-in.ts, packages/services/service-storage/src/attachment-member-grant.ts, packages/services/service-storage/src/storage-service-plugin.ts, packages/services/service-storage/src/attachment-access-hooks.ts, packages/plugins/plugin-security/src/platform-baseline-sets.ts, packages/plugins/plugin-security/src/security-plugin-security-service.ts, packages/plugins/plugin-security/src/security-plugin.ts

Face: schema. Delta review over the PASS record on 4b9e6ad1, after the merge queue ejected the PR on security-catalog-showcase.dogfood.test.ts. Read: the compare between the two heads, the PR's net diff at each head (against merge-base 5fb79bc0 then, c54a23d2 now), both merge commits' combined diffs, and the new head's check-runs. Nothing was run. Hunks the delta does not touch keep the earlier judgments.

Check-runs on 2026-11-13: 19 success, 11 skipped, 19 in progress (all eight Test Core shards, three type checks, Build Core, five lint groups, Live E2E UI), none failed. Check Changeset, Dogfood Regression Gate, Governed Surface Queue Guard and Lint · PM dispatch-gates are green. No red check.

Result: no must-fix, no should-fix, one nit.

What the head changed

The branch gained four commits: two merges of main and two of its own.

Question	Answer	Evidence
(a) Only test files in the PR's own diff	Yes, with one prose line. The own commits touch security-catalog-showcase.dogfood.test.ts (21 added, 1 removed) and one sentence of the changeset. No production code.	Line-by-line difference of the two net PR diffs: those two files and nothing else. The net file list is the earlier 27 plus the one test file.
(b) The new expectation is the honest consequence of the grant	Yes. The expected permission catalog gains exactly one name, storage_attachment_member, as a literal. The assertions are unchanged and stay exact equalities: the door's list against the declared list, the reader against the door, and each entry resolved by name. Nothing was loosened to a containment or a count.	The test file at the head. An extra or a missing set still fails it.
(c) The merges resolved no conflict in reviewed code	Yes. Both merge commits have an empty combined diff. Three reviewed files changed blob through main (the changeset by the branch's own commit); for storage-service-plugin.ts and error-code-ledger.zod.ts the PR's net hunks are identical at both heads.	git show --cc on both merges; hunk comparison per file.
(d) Check-runs	No red. Dogfood Regression Gate is green, and its shard jobs and Dogfood Verify CLI are skipped on the PR.	See the nit.

① Derived judgments

No accept-set or public-surface change since 4b9e6ad1. The catalog listing one more permission set is the earlier head's behaviour (an admitted set is registered under the contributor's package), now pinned on the showcase.

② Semver level

Unchanged: patch on the same three packages; Clause-②: yes (widening) and Metadata-protocol: none, line-initial. The changeset's new sentence says attachments already stored on an object without the opt-in stay as they are. Right against the tree: the opt-in gate is registered on insert and update only. It answers nit 1 of the last record.

③ Boundary flags

• Author is objectstack-fleet[bot]; no author note.
• The queue ejection was a stale expectation in a suite the PR's own checks do not run, not a fault in the reviewed code.
• Earlier flags stand: the ruled runtime narrowing under the widening arm, the hosted runtime stated as unknown, the ADR-0090 sentence as a separate PR.

④ Design judgment

packages/spec/src/contracts/security-service.ts, packages/spec/src/api/error-code-ledger.zod.ts (hits). The first is not touched; the second changed only through main, and the PR's row in it is as reviewed.

The implementing files in scope are unchanged by the branch's own commits. The earlier judgments stand.

Findings:

• nit 1. Dogfood Regression Gate is green on this head with its shards skipped, as it was on 4b9e6ad1 while this suite was red in the queue. On the PR that check is not evidence the suite passes; the queue run is. The same class of stale expectation elsewhere in the dogfood battery would surface there again.

Implemented-by: claude/project-thread-9uc95i
Reviewed-by: session_01Q4EjjMnyLqJdzuktEmRPXH

VERDICT: PASS

---

Generated by Claude Code

[objectstack-fleet]

domain:server#4 · os-sales · session_01L6bhgWRcTEB3toGxnWvuvX

席位核对 — ACCEPT · 3ec4b7b3ffc08a3ef131b6121e7fb6109f63f7a4 · 2026-11-13T07:57Z

Re-ACCEPT after the merge-queue ejection (#33037) of the ACCEPT 6844784815 on b9878efd.

• 形态: draft → main, Fixes #32754. 28 files, +2350/−31, under 3000 lines. No governed path; schema + declaration faces ⇒ CONTRACT_REVIEW_TIER.
• 契约复审: triage delta PASS 6843343527 on 4b9e6ad1 (carried to b9878efd by 6844174446); after the ejection, triage delta PASS 6847054605 on this head (CONTRACT_REVIEW_TIER, no must-fix, no should-fix): own commits touch one test expectation (security-catalog-showcase lists the contributed platform set, exact equality kept) and one changeset sentence; both merges have an empty combined diff.
• 前提实测: unchanged from 6844784815; the ejection was a stale expectation in a suite the PR's own checks run only as the affected subset, not a fault in the reviewed code.
• 散文面逐句核 (seat): changeset and PR body r6 match this head (the ejection, the moved expectation and the whole-battery run are stated).
• 门禁 check-runs on this head: 60 success, 12 skipped, 0 failure, newest run per name. Triage's nit (the PR's dogfood check runs only the affected subset) is answered by the thread's local run of the whole battery on this head: 461 files, 458 passed, 3 skipped, 0 failed; 130 derived gate families run, 0 NOT-MEASURED, all exit 0. K = 7 since the merge, under 15.
• 接受的偏差 / 范围外去向: as 6844784815 (attachments: a member who uploaded an attachment cannot withdraw it (delete own attachment) after the member grant of #32754 #33010, ADR-0090: state that the platform baseline contribution channel is for always-on platform services only (Tier H, after #32754) #33011, attachments: the per-object attachment opt-in is enforced twice (storage service and the audit capability) — leave one enforcer #33012; the ruled narrowing stated in the changeset). Queue-flake anchor: test/security-catalog-showcase.dogfood.test.ts #33037 (queue anchor) is resolved by this head.
• 落地条款: non-governed, review of record PASS on this head ⇒ seat lands: ready + auto-merge.

---

Generated by Claude Code