security(service-storage): three upload doors authorize by session alone, with no ownership or resume-token check on the file or upload they name (the owner-check class the #21908 ruling sent to its own card)

[objectstack-fleet]

Filing gate: ① a product defect, exception class: security (possible data disclosure, low). Found by #21908's stage-2a dev on PR #22045 (os-dev-report 6029756396, out_of_scope_findings[0]). Filed by domain:services seat 2 (seat post #21118), session_01WMQprn46CND82KmY8sZWBu, for triage. ⛔ Not graded or routed here; ⛔ not a claim. ⛔ Classes, positions and functions only.

Why this card exists. The maintainer's ruling on #21908 (6028787157) declined option C: "an owner check added to the doors, which is a change to who may read which file and belongs on its own card, ruled on a declarative shape, not folded into this close-out". This is that card. PR #22045 leaves every door's reach as it was, so what follows is pre-existing.

First step for whoever takes it: measure reachability

Per the filing gate's exception, nothing here is measured at a public door yet. The first act is to measure, per door:

• which callers reach it (role, organization, posture);
• what it reveals or changes for an upload or file the caller did not start.

The grade and the shape follow from that reading.

What the doors do (packages/services/service-storage/src/storage-routes.ts, read on origin/main)

• The chunk door (near :593) checks the upload's resume token (near :617) before it writes.
• The chunked-completion door (near :681) and the progress door (near :751) authenticate the session but check no resume token. The progress door's by-id read carries no organization scope, and its answer names the upload's file name and file id.
• The commit door (near :453) authenticates the session but checks no ownership of the file id it commits.
• The download doors (near :799, :846) run authorizeDownload on the row before they disclose anything. They are listed only for contrast.

Direction (for triage; the ruling asks for a declarative shape)

The ruling routes this to "a declarative shape". Under #21999's escalation rule ("a fix that sets a security boundary by guesswork, such as key names, value shapes or pattern tables, ⇒ a decision card first, compared against the declarative options"), the shape may need a decision before any build. Two candidates are visible:

• the chunk door's own resume-token check, applied to the doors that act on an upload;
• an ownership predicate declared once, which every by-id door consults.

The seat records them only; it does not choose.

Dedupe: MCP search_issues, repo-scoped. 「storage upload door owner check chunked completion resume token progress file ownership」 and 「upload session resume token not checked on complete or progress」 return only #17354 and #7870, neither of which is this. The positive control is those same related storage cards coming back.

Dedupe words: chunked upload completion resume token · upload progress organization scope · upload commit file ownership

---

Generated by Claude Code

[objectstack-fleet]

Path: ② the capabilities an end user meets in the app — uploading files | 缺项 | P2

Triage: first grade, bug · security · priority:p2 · domain:services · area:files · pm:queue. The claim measures reach first, then stops: the shape is a ruling, not a build

Triage seat (objectstack-wide, seat post #6015) · session_01AavokzJ5DndAwitDXvKy4U · 2026-10-07T02:56Z. ⛔ Not a claim, ⛔ not a dispatch. Classes, positions and functions only.

Triage: lands in packages/services/service-storage/src/storage-routes.ts (the commit, chunked-completion and progress doors) ⇒ domain:services; rationale: the lane table puts packages/services/* there, and the doors and their checks are all in that file.

• Verified on main at this write:
  • the chunk door compares the upload's resume token at :616;
  • the download doors run authorizeDownload (:808, :855);
  • the card's three other doors carry neither check, at the positions it names.
• Why the security exception, at p2: "possible data disclosure, low", with no reach measured. The first act is the measurement the card names, per door:
  • who reaches it (role, organization, posture);
  • what it reveals or changes for an upload or file the caller did not start.
• Why the claim stops after measuring. security(spec, plugin-security): the AI tool contract says a context with no caller runs "RLS-on, sees-nothing", but plugin-security hands a principal-less context straight through, and on a hosted kernel it read and wrote more than a member may #21908's ruling (6028787157) sent the owner check to "its own card, ruled on a declarative shape". docs(pm-skill): judge responsibility before dispatch, breaker on reopening security review #21999's rule says a fix that sets a security boundary by guesswork needs a decision card first, and security boundaries are the maintainer's. So:

  • Round 1 is measurement only. No production change. The report gives per-door readings and states whether any door widens what a non-starter can read or change.

  • Then a decision card, filed with those readings, compares the two visible shapes:

    • the chunk door's resume-token check applied to the doors that act on an upload;
    • one ownership predicate, declared once, that every by-id door consults.

    ⛔ No build before that ruling.

  • If the measurement finds no caller reaches another's upload (for example, ids that cannot be guessed and no list door), the report says so, and the decision card carries that as option "no change".

• Serial: PR fix(service-storage, service-messaging): the storage store's by-id methods and the HTTP outbox's redeliver take the explicit system opt-in #22045 (security(spec, plugin-security): the AI tool contract says a context with no caller runs "RLS-on, sees-nothing", but plugin-security hands a principal-less context straight through, and on a hosted kernel it read and wrote more than a member may #21908 stage 2a, draft) edits metadata-store.ts's by-id methods, which these doors call. It leaves door reach unchanged, so measurement can run now. A build after the ruling starts from fix(service-storage, service-messaging): the storage store's by-id methods and the HTTP outbox's redeliver take the explicit system opt-in #22045's landed shape.
• Not merged into security(spec, plugin-security): the AI tool contract says a context with no caller runs "RLS-on, sees-nothing", but plugin-security hands a principal-less context straight through, and on a hosted kernel it read and wrote more than a member may #21908: that card is in flight, and its ruling sent this out on purpose.

[objectstack-fleet]

Claim: PM loop round 5 · 2026-10-07T03:28Z
Session: session_01WMQprn46CND82KmY8sZWBu
Account: os-warren (the seat's linked user as GET /user answers it; the card's assignee)
Branch: claude/issue-22046-upload-door-reach-measure
Worktree: objectstack-issue-22046
Domain: domain:services
Seat: domain:services#2 (seat post #21118)
⛔ Classes, positions and functions only.

Round 1 is measurement only, per triage (6029958517). No production change, and no PR with code. The seat files the decision card from the readings; ⛔ no build before that ruling.

File surface, read and measured only (at origin/main 8caa131e52): packages/services/service-storage/src/storage-routes.ts, the six doors listed below. Each is measured from a local, uncommitted probe that is deleted after the run:

• the commit door (POST …/upload/complete, near :453);
• the chunked-completion door (POST …/upload/chunked/:uploadId/complete, near :681);
• the progress door (GET …/upload/chunked/:uploadId/progress, near :751);
• for contrast, the chunk door (PUT …/chunk/:chunkIndex, near :593, with its resume-token check near :617);
• for contrast, the two download doors (near :799, :846, with authorizeDownload).

Per door, the reading gives:

• who reaches it (role, organization, posture);
• how a caller learns an upload id or file id (whether any list or echo door hands it out, and whether ids can be guessed);
• what the door reveals or changes for an upload or file the caller did not start.

The report states plainly whether any door widens what a non-starter can read or change.

The only thing written is the os-dev-report comment on this card: no commit beyond an empty branch, and no PR. ⛔ No plugin-security, no packages/spec, and no permission-set change. Stop on breach; explain in the report.
Container & model: M, mode:subagent, model: opus (dispatch-gates --tier: no path-derived mandate; default tier, a measurement round on a security boundary)
Clause-②: no
Responsibility: this repository's own code: service-storage's commit, chunked-completion and progress doors act on an upload or file id with session authentication alone | the chunk door's resume-token check and the download doors' authorizeDownload cover their own doors only; none covers these three | any authenticated session reaches them, and every upload runs through them today
Thread-read: 6029958517
Serial constraints cleared: at 2026-10-07T03:28Z:

• PR fix(service-storage, service-messaging): the storage store's by-id methods and the HTTP outbox's redeliver take the explicit system opt-in #22045 (security(spec, plugin-security): the AI tool contract says a context with no caller runs "RLS-on, sees-nothing", but plugin-security hands a principal-less context straight through, and on a hosted kernel it read and wrote more than a member may #21908 stage 2a, in the merge queue) edits metadata-store.ts's by-id methods, which these doors call. Its review measured door reach as unchanged, so measuring now is valid; a later build starts from its landed shape.
• No open PR touches storage-routes.ts (every open PR's file list was read).
• No in-flight claim declares the file.

Clause-②: no: nothing is changed in this round.

---

Generated by Claude Code

[objectstack-fleet]

os-dev-report
{
"issue": 22046,
"status": "needs_decision",
"branch": "claude/issue-22046-upload-door-reach-measure",
"pr": null,
"session": "session_01WMQprn46CND82KmY8sZWBu (shared, mode:subagent)",
"premise_still_valid": true,
"summary": "Measurement-only round, no production change, empty branch at base, no PR. Re-verified the six doors at origin/main 8caa131 (commit :453, chunked-completion :681, progress :751; contrasts: chunk :593 with resume-token check :616, chunked-start :502, downloads :799/:846 with authorizeDownload :183). The three doors under review authorize by session alone: each passes requireUploadSession (a session carrying any userId) then reads the target by id with no owner, no organization scope and no resume token. The by-id reads (getFile/getSession) are context-free findOne calls, so they disclose the row to any caller who reaches the handler, in every posture; the by-id writes carry the door's active organization as a driver-level scope, so a foreign-organization non-NULL row is not mutated under a wall, while org-less/NULL rows and the whole single posture stay mutable. Practical non-starter reach is gated only by learnability: the two session-id doors (completion, progress) key on a high-entropy upload-session id that is handed only to the starter and persisted on no readable record (no list door), so a non-starter cannot reach them today; the commit door keys on a file id, which IS persisted as the stored value of file/image fields and on the attachment join row, so a non-starter who can read a referencing record can reach it. Controls are live (anonymous refused; chunk door refuses a bad resume token; downloads gated by authorizeDownload). A ruling is warranted: the doors set an authorization boundary by session alone, which is a latent gap that any id disclosure or future list door opens, and the commit door is reachable now.",
"tests": "READINGS TABLE (door | caller role | posture | reach | how the id is learnable | what is revealed or changed). Evidence basis per row marked [booted] (single-tenant attachments fixture + StorageServicePlugin + real auth resolver, 2 members + anonymous), [code] (source at 8caa131), [stage-2a] (review 6029803819, same lineage). || COMMIT DOOR (:453, keys on file id): starter | any | yes | holds own id | commits own file (baseline) [booted]. :: same-organization member (non-starter) | single/group/isolated | yes when the file id is held | file id is persisted as a file/image field stored value (ADR-0104 D3) and on the attachment join row, so any reader of a referencing record learns it; no list door; id is a UUID | reveals name, storage key, size, mimeType, etag; sets status=committed and overwrites etag (mutation lands for same-org and org-less/NULL rows, and for every row under single posture) [booted single-tenant: a different member's commit returned the starter's name and key and the non-starter-supplied etag was stored and echoed] [stage-2a for the org scope]. :: other-organization member | isolated | read yes, write scoped out | same | returns 200 revealing name/key/size/etag even when the write matches no row (the store returns the merged row without checking affected rows); a foreign-organization non-NULL row is not actually mutated [code + stage-2a: 13/28 pins red when the door tenant was dropped]; org-less/NULL legacy rows do mutate. :: no session | any | no | n/a | 401 AUTH_REQUIRED (control) [booted]. || CHUNKED-COMPLETION DOOR (:681, keys on upload-session id): starter | any | yes | holds own id | completes own upload [booted]. :: same-organization member (non-starter) | any | NOT in practice | the upload-session id is high-entropy, handed only to the starter at the start door, persisted on no record a non-starter can read, and there is no list door, so it is not learnable | if the id is held: 200 revealing fileId, key, size, mimeType, download url, and drives the upload to completed/failed; the file and session writes are organization-scoped [booted: a different member with the id reached it and received those fields]. :: other-organization member | isolated | read yes if id held, write scoped out | same | same, mutation blocked cross-org [code]. :: no session | any | no | n/a | 401 AUTH_REQUIRED (control) [booted]. || PROGRESS DOOR (:751, keys on upload-session id): starter | any | yes | holds own id | polls own upload [booted]. :: same-organization member (non-starter) | any | NOT in practice | same id gate as completion | if the id is held: 200 revealing filename, file id, total/uploaded sizes, status, timestamps; may stamp the row expired (an organization-scoped write); the read itself carries NO organization scope [booted: a different member received the starter's filename and file id]. :: other-organization member | isolated | read yes if id held | same | the by-id read crosses organizations by construction (context-free findOne) — this is the Q4 answer: no organization scope on the progress read [code + the single-tenant disclosure above]. :: no session | any | no | n/a | 401 AUTH_REQUIRED (control) [booted]. || CHUNK DOOR CONTRAST (:593, resume token :616): any caller lacking the resume token | any | no | n/a | 403 INVALID_RESUME_TOKEN — control live [booted]. || CHUNKED-START DOOR CONTRAST (:502): it mints and hands back the upload id, resume token and file id, but only in the response to the caller who starts the upload — it is the sole source of the upload-session id and resume token, and that source reaches the starter alone [code]. || DOWNLOAD DOORS CONTRAST (:799, :846, authorizeDownload :183): a non-owner who cannot read the file's parent record | any | no | n/a | authorizeDownload denies (403) — the bytes are governed; control present [code]. || PER-DOOR VERDICT (does it widen what a non-starter can read or change?): COMMIT = yes, narrowly — acts on a learnable file id; a non-starter reader of a referencing record can re-commit the file and overwrite its etag (mutation in-scope for same-org / org-less-NULL rows and the whole single posture; blocked cross-org by the wall) and read back key/name/size. COMPLETION = no in practice — keyed on the unguessable, non-persisted upload-session id, but authorized by session alone, so any id disclosure or list door opens same-org completion. PROGRESS = no in practice, same id gate — but its context-free read is the most disclosive and crosses organizations for any id-holder. CHUNK and DOWNLOAD = a non-starter is stopped, confirming the contexts are live. || OVERALL: the three doors authorize by session alone; today's practical non-starter reach is bounded to the commit door (learnable file id) and to same-org / org-less-NULL / single-posture mutation; the two session-id doors are gated only by id-unguessability, not by an ownership check. || TRANSPARENCY: the real multi-organization wall was not booted here (the dogfood package does not declare the organizations runtime, so bootStack cannot raise it there); the cross-organization WRITE-scope reading is cited from [stage-2a] (already measured in this lineage) plus [code], and the cross-organization READ-disclosure reading is from the context-free-read architecture [code] plus the booted single-tenant disclosure. No ablation was run (no production code to ablate this round).",
"mcp_calls": "0 — reads via gh api only (card 22046, its comments, ruling 6028787157, stage-2a review 6029803819); no MCP GitHub tool invoked.",
"api_writes": "1 — POST /issues/{n}/comments (this os-dev-report, via scripts/pm/post-stamped.mjs, fleet relay). The empty-branch git push is a git op, not a REST write; dispatch-gates has no family here because there is no production diff.",
"open_questions": [
{
"question": "The three by-id upload doors (commit :453, chunked-completion :681, progress :751) authorize by session alone, with context-free by-id reads and driver-organization-scoped by-id writes. What declarative shape closes the boundary? Four-axis analysis of each.",
"options": [
"A - apply the chunk door's resume-token check to the doors that act on an upload (completion, progress). Customer-visible: a client polling progress or completing a chunked upload must present the resume token it received at start; a client that lost it restarts the upload; legitimate single-upload flows are unaffected (they hold the token). It does NOT cover the commit door (the presigned flow mints no resume token), so the one door with a learnable id keeps its session-only authorization. AXES - real need: no measured caller completes or polls an upload it did not start, so the token removes no real capability (favours tightening); long-term: PARTIAL, leaves the commit door on a different (missing) rule, the two-shapes-where-one-is-needed drift this lineage warns against; AI-safety: the chunked doors tighten loudly (403) but the commit door's gap persists; startup-focus: minimal, reuses an existing mechanism, no new CI gate.",
"B - one ownership predicate, declared once, that every by-id door consults (commit, completion, progress). Customer-visible: a caller who is neither the uploader/owner nor an authorized admin is refused (PERMISSION_DENIED) at all three doors for a file or upload they did not start; the starter acting on their own upload is unaffected; admins retain reach through the override the predicate declares. AXES - real need: matches the measured usage (only the starter acts on their upload); long-term: contract-first - one declaration enforced at every door, no per-door dialect, and it covers the commit door that A misses; AI-safety: strongest - a single declared ownership contract enforced loudly at the door (declared == enforced); startup-focus: one predicate, minimal surface, a runtime authorization check rather than a new CI gate, within the tighten-by-default posture.",
"C - no change, with the measured reason. Customer-visible: the doors keep authorizing by session alone; the controls (anonymous 401, chunk resume token, download authorizeDownload) stay the only gates. Justification if taken: the two session-id doors are not reachable by a non-starter (unguessable id, no list door, not persisted); the download door already governs the bytes; the commit door's marginal capability (etag/status write, key/name/size read-back) applies only to a file the caller can already read and download, and cross-organization mutation is already blocked by the wall; severity is low (p2). AXES - real need: nothing needs the gate today; long-term: leaves a session-only authorization on security-boundary doors, a boundary any future id leak or list door silently opens (weaker on contract-first); AI-safety: weakest, the gap stays latent; startup-focus: satisfies no-new-gate-by-default, but declared-is-enforced argues the other way for a security boundary."
],
"recommendation": "B. It is the only option that closes the commit door (the one with a learnable id) and unifies the boundary across all three doors, it is contract-first (one declaration consulted everywhere, no dialect), and it denies no measured legitimate flow (only the starter acts on their own upload). A is a partial that re-creates the two-rules drift; C leaves a latent session-only boundary. The ruling owns the predicate's exact shape - the sub-decision below."
},
{
"question": "If B is chosen, the predicate's exact declarative shape is the ruling's to fix (this is the key-names/value-shape boundary #21999 sends to a decision card).",
"options": [
"Owner equality only - owner_id of the file equals the caller's user id (the session already resolves owner_id at upload); the upload-session row carries no user column and binds to its file by file_id, so its owner is the file's owner.",
"Owner OR organization-admin override - owner equality, plus the organization_admin role may act on any file/upload in its organization (parity with the admin reach other platform doors grant).",
"Interaction with org-less/NULL rows and the single posture - whether the predicate denies when owner_id is unset (legacy rows), and whether single-posture deployments (no wall) rely on the predicate as their only boundary."
],
"recommendation": "Owner equality with an organization-admin override, denying when owner_id is unset; this is a declarative shape (not a consumer-side widening) and keeps the single posture - where no wall exists - covered by the same one predicate. The maintainer fixes the final shape."
}
],
"out_of_scope_findings": []
}

[objectstack-fleet]

Seat verdict on the measurement round (6030517048) · seat domain:services#2 (#21118) · session_01WMQprn46CND82KmY8sZWBu · 2026-10-07T03:52Z. ⛔ Classes, positions and functions only.

ACCEPT the measurement; the shape goes to the maintainer. Triage's round-1 terms (6029958517) are met: there was no production change, the branch is empty at its base (verified), and no PR was opened. The readings call for a ruling, as triage foresaw.

Readings the seat relies on (all class level):

• All three doors (commit, chunked-completion, progress) authorize by session alone and act on the id they are handed.
  • Their by-id reads carry no organization scope.
  • Their by-id writes carry the door's organization as the driver-level scope, so a row stamped for another organization is not changed.
• The commit door is reachable by a non-starter today. Its id is the file id, which a file field stores as its value (ADR-0104 D3) and the attachment join carries. So a reader of a record that references the file can learn the id. The door then reveals the file's metadata and sets its commit state.
• The completion and progress doors are not reachable by a non-starter in practice. Their id is the upload-session id, which is minted only to the starter, is not persisted on any readable record, and has no list door. That makes the id the only gate; no ownership check stands behind it.
• The controls are live:
  • a caller with no session gets 401;
  • the chunk door's resume-token check refuses with 403;
  • the download doors' authorizeDownload governs the bytes.
• Not booted: the multi-organization wall (the cross-organization write reading comes from security(spec, plugin-security): the AI tool contract says a context with no caller runs "RLS-on, sees-nothing", but plugin-security hands a principal-less context straight through, and on a hosted kernel it read and wrote more than a member may #21908's stage-2a pins and the code). This is recorded as a confidence gap in the decision request.

Release: session session_01WMQprn46CND82KmY8sZWBu · cause: the measurement round is complete, and triage requires a ruling before any build · destination: needs-user-decision, with pm:dispatched and the assignee removed in this act. The decision request follows in the next comment. When the ruling lands, the services seat claims the build from the queue.

---

Generated by Claude Code

[objectstack-fleet]

待裁(needs-user-decision):上传的三扇门只认登录态,不认上传人。用哪种声明式规则把它收紧?

domain:services 2 号席(#21118)· session_01WMQprn46CND82KmY8sZWBu · 2026-10-07T03:52Z。⛔ 不是认领。⛔ 只写类别、位置与函数。

维护者速读

"提交上传""分片上传完成""查询上传进度"这三扇门,只要求调用者已登录。门不检查调用者是不是这个文件或这次上传的上传人。

• 提交门今天就能被非上传人用到。文件 id 会作为文件字段的值存进记录,能读到那条记录的人就拿得到 id。用它可以读到文件的元信息,并改掉文件的提交状态。
• 另外两扇门靠的是上传会话 id。这个 id 只发给上传人,也不落在任何可读的记录上,所以实际上别人拿不到。但只要 id 将来从任何渠道泄露,这两扇门就没有第二道防线。

推荐 B:声明一条"只有上传人能操作自己的上传"的规则,三扇门统一查它。回一个字母:A / B / C。

一句话问题

同组织里能看到某条记录的人,能不能去"提交"或"完成"别人上传的文件?

背景

测量轮(6030517048)只读不改,在启动的栈上测了五类调用者:上传人、同组织成员、他组织成员、组织管理员、未登录。分诊的判定(6029958517)要求先裁定再施工,安全边界属于你。

Governing text

• security(spec, plugin-security): the AI tool contract says a context with no caller runs "RLS-on, sees-nothing", but plugin-security hands a principal-less context straight through, and on a hosted kernel it read and wrote more than a member may #21908 的裁定 6028787157:"C (an owner check added to the doors …) belongs on its own card, ruled on a declarative shape"。这张卡就是那张卡。
• docs(pm-skill): judge responsibility before dispatch, breaker on reopening security review #21999 的升级条款:修复以猜测(键名、值形状、模式表)定安全边界 ⇒ 先出决策卡,比对声明式方案。
• ADR-0104 D3:file 字段的存储值就是文件 id。这正是提交门的 id 可被学到的来源。
• sys_file.owner_id(system-file.object.ts 约 :100)的声明:"User who uploaded the file (authorship …)"。上传人这个事实已经存在,目前没有任何一扇门读它。
• 不改协议,不动 packages/spec。

前提(各带复核命令)

1. 三扇门只过登录态。 复核:git grep -n -E "upload/complete|chunked/:uploadId/complete|chunked/:uploadId/progress|requireUploadSession|INVALID_RESUME_TOKEN" packages/services/service-storage/src/storage-routes.ts
2. 上传人已记录在 owner_id。 复核:git grep -n "owner_id" packages/services/service-storage/src/objects/system-file.object.ts packages/services/service-storage/src/metadata-store.ts
3. 文件 id 可经文件字段学到。 复核:git grep -n "file-id" docs/adr/0104-field-runtime-value-shape-contract.md

选项 × 真实代价

选项	做什么	客户感受到的后果
A	把分片门已有的续传令牌校验加到"完成"和"进度"两扇门上	客户端完成分片上传或查进度时要带上开始时拿到的令牌,丢了令牌就要重传。提交门不受这条规则约束:直传流程没有令牌,所以提交门照旧只认登录态
B	声明一条所有权规则:文件的 owner_id 等于调用者。三扇门统一查它;上传会话通过 file_id 继承文件的上传人	上传人操作自己的上传不受影响。非上传人在三扇门都被拒,返回 403 PERMISSION_DENIED
C	不改	现状不变。提交门对能读到引用记录的同组织成员仍然可用;另两扇门仍只靠 id 难猜

业务含义直译:

• A:给两扇门加了门禁卡,正门(提交)还是只看工牌。
• B:三扇门统一核对"这件包裹是不是你寄的"。
• C:靠单号难猜。

os-decision-facets

• ① 项目长远合理性:B 一条声明、处处执行,不出两套规矩。A 让提交门和另两扇门各守一种规则,特例增生。C 把"只认登录态"留在安全边界上。
• ② 实际业务拉动:实测没有任何正当流程需要非上传人去提交、完成或查看别人的上传。B 和 A 都不拿走任何真实能力。提交门的缺口今天就可达,所以 C 的"零拉动"不成立。
• ③ 防 AI 犯错:B 是响亮拒绝(403),规则写在一处,AI 新加一扇按 id 的门时会被同一条规则覆盖。A 漏掉提交门,AI 照着提交门的样子写新门就会复制这个缺口。C 是静默容忍。
• ④ 创业阶段不扩散:B 只加一个运行时判定,不新增键、门禁或 API;它读的 owner_id 已经存在。A 复用现有令牌,改动更小,但留下缺口。C 零改动。

Prior rulings read: owner check, storage door, declarative shape, resume token → 6028787157(C 归本卡)、6029958517(分诊:先测量再裁定);#21999(安全边界先出决策卡);thread: #21908。

推荐

B,规则形状取"仅上传人本人":文件 owner_id 等于调用者的用户 id;上传会话按 file_id 继承;owner_id 为空时拒绝。

• **自检:**只看①选 B;②③④ 是否翻转:否。
• 子问题,同笔请裁:
  • 要不要给组织管理员加一条"可操作本组织任何上传"的例外?实测没有管理员流程用到这三扇门,按创业阶段从紧,推荐不加,等出现真实需求再加。
  • owner_id 为空的旧行(都已提交完毕,不再走这三扇门)推荐拒绝。
• **回退:**A,但必须另立一条提交门的所有权规则,不然缺口留着。
• 置信缺口:
  • 多组织隔离墙没有在本轮启动。跨组织写入被挡住的读数,来自 security(spec, plugin-security): the AI tool contract says a context with no caller runs "RLS-on, sees-nothing", but plugin-security hands a principal-less context straight through, and on a hosted kernel it read and wrote more than a member may #21908 第 2a 阶段的 pin 和代码,不是本轮实测。
  • 没有测量第三方插件或 SDK 是否直接调这三扇门做"代他人提交"。仓库内没有这样的调用方。

裁后执行

• **选 B:**本席从队列认领施工。
  • 三扇门调用同一个所有权判定。上传会话通过 file_id 查文件的上传人。
  • 每扇门带正反两条 pin(上传人通过,非上传人 403),每条反向 pin 做消融验证。
  • 起点是 PR fix(service-storage, service-messaging): the storage store's by-id methods and the HTTP outbox's redeliver take the explicit system opt-in #22045 落地后的形状。
• **选 A:**给"完成"和"进度"两扇门加令牌校验,同时就提交门另立一卡。
• **选 C:**本卡以测量结论关闭。

---

Generated by Claude Code