[REQ-092][VERIFY] Prove descriptor-only bounded artifact transfer end to end

[jinjunnn]

Capability

Descriptor-only、authenticated、bounded artifact transfer across Platform and Desktop。

Covers

jinjunnn/alpha-work#1 AC1–AC6。

AC7 不由本票承载 —— 父票 Evidence map 把它指给 descriptor-only schema/forbidden-field CI gate(静态契约门),那是每 PR 都跑的闸,不是运行期矩阵能证的东西。本票原写「AC1–AC7」是超卖。

Matrix

• status/result/list/MCP/transcript 含二进制产物 → JSON 无 base64/data URL/内容字段。
• 100 MiB 正常流 → digest 一致，传输额外峰值 RSS 不超过父需求上限。
• 超大 Content-Length → 读 body 前拒绝；无长度/少报/chunked → 首次越界 abort。
• 断网、取消、digest mismatch、ENOSPC → loud typed error，无 final/.part 残留。
• Range、重复下载、同名与并发下载 → 内容正确且无碰撞。
• slow consumer 与 envelope 边界 → 内存/队列保持有界。
• renderer IPC/log/manifest/file name 扫描 → 无 bearer、Buffer、完整字节。

Results

逐项记录 PASS/FAIL；FAIL 创建窄 bug 并挂父需求。矩阵执行完关闭本 VERIFY，任何 FAIL 阻止父需求完成。

Parent

Refs jinjunnn/alpha-work#1

[jinjunnn]

矩阵执行完毕(七格)

证据:docs/verification/2026-08-25-req092-402-artifact-transfer/ ·
PR #1117 · 被测树 ac-402 @ base alpha 8ba7d11ec · 未改生产代码

• status/result/list/MCP/transcript 含二进制产物 → 部分 FAIL(descriptor 面闭合 PASS;result 无约束透传 FAIL;MCP/transcript 测不到)
• 100 MiB 正常流 → 摘要 PASS;峰值 FAIL(Electron +84.0/+84.4/+84.6 MiB,3/3 轮;限速 ~8 MB/s 仍 +81.2 MiB)
• 超大 Content-Length / 无长度·少报·chunked → 部分 FAIL(读前拒 + chunked 越界 abort PASS,两侧边界都测;少报长度 + descriptor 无 size 无 sha256 ⇒ 静默截断报成功)
• 断网、取消、digest mismatch、ENOSPC → PASS(node + Electron 各 10 条,含 8 MiB HFS+ RAM 卷上的真 ENOSPC)
• Range、重复下载、同名与并发 → 部分 FAIL(空文件·重复·折叠同名·8 路并发·同窗去重 PASS;同名不同件静默覆盖 FAIL;Range 测不到)
• slow consumer 与 envelope 边界 → PASS(慢消费者 +19.8 MiB@100MiB vs +18.3 MiB@25MiB;两个上限恰好/恰好+1 两侧都对)
• renderer IPC/log/manifest/file name 扫描 → PASS(五面零发现,扫描器先用投毒载荷标定九中九)

FAIL 开出的窄票(都 Refs alpha-work#1,本票不修)

票	格	一句话
#1111	3	少报 Content-Length + descriptor 无 size/sha256 ⇒ 截断的前缀被当成下载成功(逐字节确认)
#1112	5	同名不同件静默覆盖;manifest 仍为第一件断言着已经不对的尺寸/摘要,第二件不在账本,IPC 两次都回 {ok:true}
#1113	1	CloudJobStatusV1.result 是无约束 {},内联 base64/data URL 直达 renderer;scrubInlineContent 零调用点
#1114	2	峰值 RSS 超 32 MiB。带 needs-decision:强制 GC 下只有 +18.6 MiB ⇒ 先要 owner 裁「32 MiB 量的是驻留高水位还是活内存」,否则改代码还是改 AC 措辞没法定

没测到的格 / 半格(如实记,没有编数字)

1. MCP tool result 与模型 transcript(格 1 的另一半)—— 云 MCP 工具由平台 facade 提供,alpha-code 对这些结果不施加任何契约(符号名 + 常量消费者两条独立检索轴各自 0 命中)。本仓没有可断言的接缝。
2. Range 的正向行为 —— 桌面从不主动发 Range(origin 侧记录的 Range 头全 null)。正向验收在平台 content endpoint。本票只验证了「origin 擅自回 206 partial 时摘要/尺寸不变量照旧生效」。
3. 生产平台今天实际发什么 —— 本轮无可用线上凭据;所有平台行为由本机裸 socket origin 扮演。
4. 打包态 / 崩溃恢复 / 非 macOS / 更高并发 —— 见证据 README §5 完整表。

两次量错(README §1),因为它决定别的数字该不该信

1. 第一版 Bun.serve origin 造不出「超大 Content-Length」这个条件(Bun 把手写的 content-length 换成 chunked)⇒ 那一格当时走的是另一条分支而看上去是绿的。改裸 socket origin + 先跑 9/9 标定后才是真绿。
2. 第一版内存跑在 bun 上(+249393 MiB),而桌面 main 跑 Electron 的 Node(+84 MiB),差 34 倍。

---

以下是建议,不是本票的格,请 owner 裁

按票面硬约束,这些都没有加进七格、也没有据此判红:

1. outcome.path 把本地绝对路径交给 renderer(实测 /private/var/folders/…/.alpha/runs/<run>/artifacts/report.bin)。父需求 Non-goals 写着「不向 renderer、模型或远端暴露本地绝对路径或 bearer token」,但 AC5 正文只点名 token,第 7 格也只写「无 bearer、Buffer、完整字节」。建议:要么把它收进 AC5,要么明确它不在范围内 —— 现在两处文字互相矛盾。
2. PUBLIC_RESULT_MAX_BYTES(shared/cloud-artifact-descriptor.ts:92)零消费者。 真正生效的 512 KiB 上限来自 vendored limits.json 的 NON_STREAMING_PAYLOAD_MAX_BYTES(同值、不同来源)。不是功能缺口,是一个会漂移的重复常量。建议开 chore 删掉或改成 re-export。
3. 限额闸一在生产参数下不可达:descriptor.size > maxBytes 的前提是 deps.maxBytes < 104857600,而 pinned schema 已把 size 卡在 maximum: 104857600。效果仍是零网络 fail-closed,只是分类码是 invalid-artifact 而非模块抬头自述的 over-limit。建议:要么改抬头,要么接受它是纯 defence-in-depth。
4. [REQ-092] 少报 Content-Length + descriptor 无 size/sha256 ⇒ 截断的文件被当成下载成功 #1111 / [REQ-092] 同名不同件的 artifact 互相静默覆盖,manifest 与盘面就此不符 #1112 这两个缺陷,既有单测结构上覆盖不到,原因同一类:被测对象之外的东西被手写了替身(假 Response 没有 HTTP 框定;命名判断只读目录不读账本)。建议:若要把它们变成每 PR 闸,得先接受「测试里要起一个真 socket origin」这条成本;本目录的探针刻意没有登记进 scripts/gate-files.tsv,那是范围外的决定。