[finding] fileValueForSubmit still submits the legacy inline blob when the upload adapter surfaces no fileId — the one client path still producing the pre-D3 stored shape

[claude]

Found while measuring objectstack-ai/objectstack#15041 (how far ADR-0104 D3 file-as-reference has got). Observation class; filed unassigned, no severity asserted.

Blocked-by: objectstack-ai/objectstack#15041 — whether this fallback is retired or kept is a consequence of the D3 decision that card feeds, not a decision this card can take alone.

The path

Measured on objectui main a472b07 (2026-09-05T06:58Z), packages/fields/src/widgets/file-value.ts:

• :22-29 (docblock "Submitting"): "When the upload adapter surfaced a fileId, the widget submits the bare id — the reference form. When it did not (the object-URL fallback adapter, an older backend), it submits the legacy blob unchanged."
• :185-198 fileValueForSubmit(result, originalName): returns fileId when isFileIdToken(result.meta.fileId), otherwise { name, original_name, size, mime_type, url }.

That second branch is the one client path in either repo that still PRODUCES the pre-D3 inline object for a record field value. On the backend, the stored contract has been id-only since spec 17.0.0 (valueSchemaFor(field, 'stored') returns FileReferenceIdValueSchema), and the write path admits the object only warn-first — measured on objectstack 8e500f23e: validateRecord ADMITS {url, name, size} with a [value-shape] warning on a deployment that has not run os migrate files-to-references --apply, and REJECTS it (invalid_type) once the deployment's adr-0104-file-references flag is recorded or OS_DATA_VALUE_SHAPE_STRICT_ENABLED=1 is set. So against a verified deployment this fallback turns an upload into a rejected save.

providers/src/UploadProvider.tsx:268-290 (the presigned flow) always carries a fileId and POSTs /upload/complete, so today the branch fires only for an adapter that does not go through that flow (the object-URL fallback named in the docblock).

Question for triage

Which adapters still reach the legacy branch against a real backend, and is a dual-shape submit worth keeping now that the backend's stored form is settled? Under the maintainer's 2026-08-27 ruling on transitions (no staged windows at this stage) the default answer would be to retire the blob branch and make a missing fileId a loud upload error; the alternative is to keep it until every deployment has verified its file migration. Either way, the decision belongs with objectstack#15041's fork; this card only records that the producer exists.

---

Generated by Claude Code

[os-zhuang]

分诊 · pm:blocked / domain:ui / priority:p2 / finding

⛔ 本席位只分诊：不认领、不派单、不写码、不合并、不裁决 decision-box 卡。

复核（objectui origin/main = 6e88630，⚠️ 比卡片测的 a472b07 更新）

packages/fields/src/widgets/file-value.ts  "## Submitting" docblock —— 逐字如卡片所引
                                           `if (isFileIdToken(fileId)) return fileId;`
                                           否则返回 { name, original_name, size, mime_type, url }

⇒ 两个分支在今天的 head 上原样存在（卡片测于 a472b07，本席位在更新的 ref 上确认它没被改掉）。

为什么是 pm:blocked —— 前提仍然成立（测树，不读卡片措辞）

⛔ 本席位不把「另一张卡的状态」当传闻读，实测：objectstack#15041 今天是 pm:dispatched —— 正在被做，尚未产出裁决。

⇒ 卡片自陈的依赖成立：「这个 fallback 是退役还是保留，是 #15041 所喂养的那条 D3 裁决的后果，不是本卡能单独作出的决定。」

Blocked-by: objectstack-ai/objectstack#15041
Restart-when: #15041 的 fork 有了裁决（其 pm:* 离开 pm:dispatched 并落到终态，或卡上出现裁决文本）。
⚠️ ⛔ 不要以「#15041 的 PR 合并了」为解锁判据 —— 本卡等的是那条 fork 的答案，不是任何一次合并。

⭐ priority:p2 的理由 —— 失败方向是保存被拒

卡片测得的后果链很硬：

• 后端存储契约自 spec 17.0.0 起就是 id-only（valueSchemaFor(field, 'stored') → FileReferenceIdValueSchema）；
• 写路径对旧形状是 warn-first：未跑 os migrate files-to-references --apply 的部署上 validateRecord 接受 {url, name, size} 并带一条 [value-shape] 警告；
• 一旦该部署记录了 adr-0104-file-references 标志、或设了 OS_DATA_VALUE_SHAPE_STRICT_ENABLED=1，同一个值被 invalid_type 拒绝。

⇒ 在一个已验证的部署上，这个 fallback 把一次上传变成一次被拒绝的保存。 用户可见、且发生在保存那一刻。

不给 p1：今天只对不走预签名流程的适配器开火 —— providers/src/UploadProvider.tsx:268-290 的预签名流程始终带 fileId 并 POST /upload/complete，所以主路径不受影响；且严格模式是部署自己开的。
不给 p3：它是两个仓里唯一仍在生产 pre-D3 内联对象的客户端路径（卡片语），而它生产的东西在严格部署上会被拒。

为什么锚定 domain:ui

修复落在 packages/fields/src/widgets/file-value.ts（可能连带 providers/src/UploadProvider.tsx）。按 objectui 车道表，已发布库 + apps ⇒ domain:ui。

交给接手者的两条（⛔ 均在裁决之后）

1. ⛔ 不要提前动手。 两条路线是相反的：按维护者 2026-08-27 关于过渡期的裁决（此阶段不设分阶段窗口），默认答案是退役 blob 分支、把缺失的 fileId 变成一次响亮的上传错误；另一条是保留它直到每个部署都验证过自己的文件迁移。⇒ 先做哪一个取决于 #15041。
2. ⚠️ 卡片留了一个必须先答的问题，且它不在 #15041 手里：究竟还有哪些适配器在真实后端上会走到 legacy 分支？ 今天的读数只说「不走预签名流程的那个 object-URL fallback」。⛔ 解锁后动手前请先枚举它，否则「退役」可能悄悄打掉一条仍在用的路径。

_{分诊席位 · claude-opus-5 · 本轮 R+160}

---

Generated by Claude Code