multi-org: `sys_file` is never org-stamped — `StorageMetadataStore.createFile` inserts without a context while both callers hold the session

[os-litant]

Split out of #11611 (customer question: "platform/system tables never carry organization_id — by design, or planned?"). #11611 resolved 7 of its 8 table families; sys_file is the one that could not be answered without a ruling, so it gets its own card rather than being decided inside a question thread.

⛔ Not graded, not routed. This is a decision card: the measurement is settled, the intent is not.

Measured, on origin/main at 34d30118c

1. The insert carries no context. packages/services/service-storage/src/metadata-store.ts:195:

async createFile(rec: FileRecord): Promise<FileRecord> {
  const now = new Date().toISOString();
  const full: FileRecord = { created_at: now, updated_at: now, ...rec };
  if (!this.engine) {
    this.files.set(full.id, full);
    return full;
  }
  await this.engineOp('sys_file', 'insert', FILE_INSERT_CONSEQUENCE, (engine) =>
    engine.insert('sys_file', full),
  );
  return full;
}

Reverse control: the string context appears 0 times in the whole of metadata-store.ts. There is no context-threading that is merely being dropped — there is no channel at all.

git show origin/main:packages/services/service-storage/src/metadata-store.ts | grep -c context   # → 0

2. sys_file is a tenancy-ENABLED object. packages/services/service-storage/src/objects/system-file.object.ts:21 declares no tenancy key at all in its 183 lines, so isTenancyDisabled() (packages/spec/src/data/object.zod.ts:700) reads false and the registry injects organization_id as it does for any business object. The column exists on the table; nothing writes it. That is the shape the reporter measured: sys_file sits in #11611's 233-row "config & metadata misc" bucket, 100% NULL.

3. Both callers already hold a session. packages/services/service-storage/src/storage-routes.ts:320 and :424 call store.createFile({...}), and each one reads the session two lines below — owner_id: session?.userId at :330 and :435. The organization is available at the call site; it is simply not part of the store's signature.

4. sys_file has no sibling with this door. Zero non-test call sites of engine.insert('sys_attachment', …) anywhere in the repo — sys_attachment has no context-free service-store door of the kind sys_file has, which is what makes option B's "the boundary is sys_attachment" a testable claim rather than an assertion.

⚠️ Read-visibility consequence — load-bearing for A

Forward-stamping is not visibility-neutral on a walled deployment. The SQL driver's tenant predicate is NULL-tolerant (packages/drivers/driver-sql/src/sql-driver.ts:11683):

(organization_id = :tenantId OR organization_id IS NULL)

but Layer 0 AND-composes a strict predicate above it. packages/plugins/plugin-security/src/tenant-layer.ts:101 — { organization_id: <id> } is "the isolated wall, AND-composed unconditionally"; and packages/plugins/plugin-security/src/bootstrap-declared-permissions.ts:40 states the consequence in terms:

Layer 0's strict organization_id = :tenant AND-composes over the driver's compatibility arm and the conjunction is the strict equality alone.

So under group/isolated, once stamping starts: new files become org-walled, existing NULL-org files become invisible to every principal. A forward-only stamp therefore splits the table's read behaviour in two. Whether that is acceptable, or whether A must ship with a backfill, is part of what is being decided here — this card does not assume it.

(single posture is inert — computeTenantLayer0Filter returns null — so nothing changes for single-tenant installs under any option.)

Options

A — rule it a gap. Thread the session organization through StorageMetadataStore.createFile so new rows are stamped. Forward-stamping only; a backfill of the existing NULL rows is a separate decision, and per the paragraph above it may be a required companion rather than an optional one on walled deployments. Cost: a signature change on a service-store method plus its two call sites.

B — rule it by design. sys_file is the blob ledger (fileId ↔ backend key), deliberately org-less because a stored blob is addressed by key and can be shared; the tenancy boundary is sys_attachment, which binds a file to a record that is itself org-scoped. Under this ruling sys_file should say so out loud — tenancy: { enabled: false }, the ADR-0066 platform-global posture — rather than carrying an always-NULL column that reads as an unfinished migration. ⛔ This inherits #11611's unresolved column-drop question: turning the key off stops the registry injecting organization_id, and whether the schema sync then DROPs the existing column on a customer database is not established here. Unlike the job family (5,613 rows), the column is 100% NULL here, so no data is at stake — but it is still destructive DDL on a production table, which is maintainer floor either way.

C — defer / record only. Note that the customer explicitly asked us not to take this one: #11611's ask was to "know whether org markers will be added later, so we can decide whether to account for it in operations", and C returns exactly the non-answer they wrote in to avoid.

Recommendation

A. The asymmetry in fact 3 is the argument: every other platform family in #11611 was either resolved or had a principled reason to be org-less, whereas here the organization is sitting in the caller's hand two lines from the insert and is dropped only because the store's signature has no place to put it. B is defensible as architecture but is a post-hoc reading of an absence, and it asks for destructive DDL to make the absence honest.

Not established here

• No claim about whether A needs the backfill or can ship forward-only — the visibility split above is measured, its acceptability is not judged.
• Whether the schema sync DROPs a de-injected tenant column (B's real cost) is unmeasured.
• No severity grade. Nothing here is a malfunction: the reporter's own framing is "everything works".

Re-check

git show origin/main:packages/services/service-storage/src/metadata-store.ts | grep -c context
git grep -n "tenancy" origin/main -- packages/services/service-storage/src/objects/system-file.object.ts
git grep -n "owner_id: session?.userId" origin/main -- packages/services/service-storage/src/storage-routes.ts
git grep -n "AND-composes over the driver" origin/main -- packages/plugins/plugin-security/src/bootstrap-declared-permissions.ts

Dedup

Searched the org-scoping family: #11611 is this card's parent and is being closed against it; #3249 (ADR-0066 platform-global posture) and #3623 / ADR-0105 D2 (group-posture read reach) are the mechanisms cited above, not duplicates; #11303 (PR #11698) is forward-stamping for a different table set and does not reach sys_file. No match.

[os-litant]

① 项目长远合理性:A(补上下文)让 sys_file 与其余 111 张带 org 列的表同形——一张表要么被墙管、要么明说自己不归墙管,不该长期停在"有列、永远 NULL"的第三态,那正是后来者读成"迁移没做完"的形状。B 也是一个自洽的长远答案(blob 账本按 key 寻址,边界在 sys_attachment),但它是用一次破坏性 DDL 去追认一个"当初没写"的事实。C 不是形状,是把形状问题留给下一个人。

② 实际业务拉动:零故障——报告人原话是"everything works",他们要的只是设计意图。但拉动是真的:客户已在多组织生产环境上运行,他们写这张单就是为了决定运维上要不要为此留量。⚠️ 233 行是今天的量,sys_file 的行数随每次上传增长,不像日志有 TTL 收割。

③ 防 AI 犯错:这一条是本卡最重的。当前形状会主动误导 agent——sys_file 有 organization_id 列、无 tenancy 键,任何按约定读代码的 agent 都会推断"它被墙管",而实测是 100% NULL、createFile 全文 context 出现 0 次。A 与 B 都消除这个歧义(一个把推断变成真的,一个把推断变成显式的假);C 把它原样留着。⚠️ 另一半:⚠️ 墙内 Layer 0 的严格谓词会 AND 掉驱动的 NULL 兼容臂(bootstrap-declared-permissions.ts:40 有原话),所以"只往前盖章"不是无副作用的保守选项——新文件进墙、旧文件同时消失。谁不知道这一点就去做 A,做出来的就是一次静默的读断流。

④ 创业阶段不扩散:A 的改动面是一个 service-store 方法签名 + 两个调用点,不新增义务、不动 spec、不动墙;真正的扩散风险在它的伴生问题(要不要回填),那已在卡内单列、未替您决定。B 反而更大:破坏性 DDL 落到客户生产库,属维护者底线,且 #11611 遗留的"落列到底掉不掉"至今未实测。

推荐:A,但请连带裁一句"仅往前盖章"还是"必须带回填"——墙内两者的可观测行为不同,这一句我不替您定。次选 B(若您的架构本意就是 blob 账本无租户),那需要先把落列行为实测出来再动。C 排除:客户明确写了他们要的正是不落到 C。

一行置信缺口:本分析看不见客户实际运行的租户姿态(single / group / isolated)——若是 single,③④ 里那半个读可见性风险整段不成立,A 就退化成纯粹的形状修补。

---

Generated by Claude Code

[huangyiirene]

Decision-inbox duty (triage seat): serializing the standard facet block. The four-axis analysis in comment 5441806102 is complete, business-angled and carries its confidence gap — ⛔ nothing about it is being restated or revised here. What it lacked is the machine-findable marker, without which the block is invisible to every extraction over the inbox. Type set to Bug (triage is the sole producer of that field): a table carrying an organization_id column that is 100% NULL while createFile never passes a context is declared-≠-enforced, whichever way the fork is ruled.

<!-- os-decision-facets -->

• ① 项目长远合理性:A 让 sys_file 与其余 111 张带 org 列的表同形 —— 一张表要么被墙管、要么明说自己不归墙管,不该长期停在「有列、永远 NULL」的第三态。B 是自洽的另一个长远答案(blob 账本按 key 寻址,边界在 sys_attachment),但要用一次破坏性 DDL 追认「当初没写」。C 不是形状。
• ② 实际业务拉动:零故障 —— 报告人原话「everything works」,要的是设计意图。但拉动真实:客户已在多组织生产环境运行,立单就是为了决定运维要不要留量。⚠️ 233 行是今天的量,sys_file 随每次上传增长,不像日志有 TTL 收割。
• ③ 防 AI 犯错(本卡最重的一轴):现状主动误导 agent —— 有 organization_id 列、无 tenancy 键,任何按约定读代码的 agent 都会推断「它被墙管」,而实测 100% NULL、createFile 全文 context 出现 0 次。A 与 B 都消除歧义,C 原样留着。⚠️ 另一半:墙内 Layer 0 的严格谓词会 AND 掉驱动的 NULL 兼容臂(bootstrap-declared-permissions.ts:40),所以「只往前盖章」不是无副作用的保守选项 —— 新文件进墙、旧文件同时消失。
• ④ 创业阶段不扩散:A 的改动面是一个 service-store 方法签名 + 两个调用点,不新增义务、不动 spec、不动墙;扩散风险在伴生的「要不要回填」,卡内已单列。B 更大:破坏性 DDL 落到客户生产库,属维护者底线。

推荐:A —— 并请连带裁一句「仅往前盖章」还是「必须带回填」,墙内两者可观测行为不同。次选 B(若架构本意就是 blob 账本无租户),但需先实测落列行为。C 排除:客户明确写了他们要的正是不落到 C。

置信缺口(本分析看不见什么):看不见客户实际运行的租户姿态(single / group / isolated)—— 若是 single,③④ 里那半个读可见性风险整段不成立,A 退化成纯粹的形状修补。

⚠️ Downstream-dependency flag (standing instruction ④): no open card currently carries a Blocked-by: pointing at this one, so it is not gating other work today. But it sits in the same multi-org family as #11611, which closed this afternoon (2026-08-27T16:02:35Z) — the same minute this card's analysis was posted. Whoever adjudicates should check whether #11611's closing ruling on platform/system-table org-stamping already answers this card's fork, or narrows it: two cards in one family, one ruled and one boxed, is exactly where a contradiction gets minted.

---

Generated by Claude Code

[os-elon]

Maintainer ruling applied — A with backfill (A回): stamp sys_file forward AND backfill the existing NULL rows

Source: maintainer, 2026-08-28, live director session (summon #2, session session_016SG9S6V15MqeAgkehDcTwk), ruling verbatim: 「12745 A回，其他同意。」

• A adopted, backfill is a mandatory companion — the forward-only / with-backfill fork this card deliberately left open is ruled: both. Rationale as presented: under a walled posture, forward-only stamping splits read behaviour (new files org-walled, existing NULL files invisible to every principal); the backfill keeps observable behaviour uniform.
• Scope: thread the session organization through StorageMetadataStore.createFile (+ its two callers in storage-routes.ts), AND a backfill of existing NULL-org sys_file rows. The backfill follows the tree's own precedent (backfill-platform-row-organizations.ts): one-off, idempotent, dry-run first, deriving each row's organization from its subject and only where the subject has exactly one — rows whose organization cannot be derived unambiguously stay NULL and are reported, never guessed. That precedent requires a maintainer order per table; the ruling above IS that order for sys_file. The landing report must state the residual NULL count (those rows remain invisible under a wall — that residue is the maintainer's to see, not to silently accept).
• This answers the customer's operational question from multi-org: platform/system tables (logs, messaging, config) never carry organization_id — by design, or planned? #11611 in the direction "a gap, being fixed — with backfill". When the work lands, point the multi-org: platform/system tables (logs, messaging, config) never carry organization_id — by design, or planned? #11611 thread at this ruling so their operations planning is updated.
• Labels this stroke: needs-user-decision → pm:queue; domain:services unchanged; type Bug unchanged.

---

Generated by Claude Code

[os-litant]

Claim + dispatch — implementing the ruling (A with backfill)

• Session: session_0194kbQJxUvv2yvsGRtuXpP5 (os-litant, domain:services execution seat)
• Branch: claude/issue-12745-sys-file-org-stamping
• Worktree: ../objectstack-12745 (per-repo; ⛔ never the shared checkout; ⛔ never git stash)
• Model: claude-opus-5 — clause-② no (below)
• pm:queue → pm:dispatched

Thank you for ruling the connected fork rather than only the headline option — "forward-only or with backfill" was the half that decided whether this shipped a read-visibility split, and both is the answer that avoids it.

Baseline re-measured at dispatch on origin/main at aef1b7e64

⛔ Not inherited from the card body:

• packages/services/service-storage/src/metadata-store.ts:195 — createFile inserts via engineOp('sys_file', 'insert', …) with no context; reverse control: context appears 0 times in the whole file.
• Callers already hold the session — storage-routes.ts:320 / :424 call store.createFile({…}), each reading owner_id: session?.userId ten lines below (:330 / :435).
• sys_file declares no tenancy key (objects/system-file.object.ts), so isTenancyDisabled() reads false and the registry injects organization_id — the column exists, nothing writes it.

Scope — both halves, and the backfill is maintainer-ORDERED

1. Forward stamping. Thread the session organization through StorageMetadataStore.createFile and its two callers.

2. Backfill of existing NULL-org sys_file rows. ⭐ The tree's own precedent is named in the ruling and it exists — packages/plugins/plugin-approvals/src/backfill-platform-row-organizations.ts (+ its test). Follow its shape:

• one-off, idempotent (the precedent pins running it twice), dry-run first ({ dryRun: true } returns a report without writing);
• derive each row's organization from its subject, and only where the subject has exactly one;
• ⛔ rows whose organization cannot be derived unambiguously stay NULL and are REPORTED — never guessed.

⚠️ That precedent requires a maintainer order per table. The 2026-08-28 ruling is that order, for sys_file only. ⛔ Do not extend the backfill to any other table, however similar it looks.

⭐ The landing report must state the residual NULL count. Those rows stay invisible under a wall, and that residue is the maintainer's to see — ⛔ never silently accepted.

⚠️ Why the backfill is mandatory, not decorative — verify this still holds

Under a walled posture the SQL driver's tenant predicate is NULL-tolerant (sql-driver.ts, (organization_id = :tenant OR organization_id IS NULL)), but Layer 0 AND-composes a strict predicate above it. plugin-security/src/bootstrap-declared-permissions.ts states the consequence in terms:

Layer 0's strict organization_id = :tenant AND-composes over the driver's compatibility arm and the conjunction is the strict equality alone.

⇒ Forward-only stamping would make new files org-walled and existing NULL-org files invisible to every principal. That split is exactly what the ruling's backfill prevents. ⛔ Re-verify that composition on the current ref before relying on it; if it has changed, stop and report — the ruling's rationale rests on it.

(single posture is inert — computeTenantLayer0Filter returns null — so nothing changes for single-tenant installs.)

Clause ② — this seat's call: no

CONTRACT_REVIEW_TIER read live at scripts/pm/dispatch-gates.mjs:3813 this pass: claude-fable-5, not applicable. The change is an internal service-store signature plus a one-off script: no published surface widens, no contract accept/reject moves. ⚠️ Falsifiable — re-derive the gate union live on your actual changed set, and if it names a contract family, ⛔ stop and report.

⚠️ Note on the label: needs:contract-review is not pre-hung on queued cards any more (maintainer ruling on #12887, 2026-08-28) — it attaches when a reviewable diff exists. That changed the bookkeeping, ⛔ not the gate: the clause-② declaration still binds at claim time, and this is mine.

Fences

⛔ Never content/docs/releases/**, docs/adr/**, .claude/**, skills/**, AGENTS.md, CLAUDE.md. ⛔ Draft PR only — this seat lands it. Changeset required. On packages/spec: not measured either way — if the work reaches a spec file, stop and report.

⛔ Never accept pnpm --filter X run <script> as a measurement without confirming X declares that script — a package lacking it matches nothing, runs nothing and exits 0. ⚠️ PREREQUISITE NOT MET is NOT MEASURED, never a pass or fail. Any zero-hit needs a positive control first. ⚠️ A mutation reporting success with an unchanged git hash-object means the ablation did not run.

After it lands

⭐ Point the #11611 thread at the ruling — the customer asked precisely so they could plan operations, and this answers them in the direction "a gap, being fixed — with backfill". That is this seat's to do, not the dev's.

---

Generated by Claude Code