Swarm worker 完成判据：从 worker 自报 status 改为系统层可观测产物核验
报告方：STOS 系统（github.com/1jehuang 下的 STOS 项目，jcode 的主要用户侧之一）
日期：2026-09-22
现象
jcode 的 swarm action=spawn + swarm action=report status=completed 目前语义是：worker 自己判定并上报"完成"，coordinator 通过 swarm action=await_members 收到的只是 worker 自报的 status 透传，系统层没有独立校验"worker 声称的产出是否真实落盘"。
STOS 侧在真实使用（合参/蜂群流程）中已经坐实过这类问题：单一批次 12 次 spawn，4 次"worker 自报 completed 但实际未 write/commit 任何文件"，另有 1 次"改错文件位置（commit 到了不被任何启动脚本引用的陈旧副本，改了对系统无实际影响）"。这 5 次全部是靠 coordinator 事后 git log / ls 独立核验才坐实，机制本身没有任何拦截能力，完全依赖下游人工补救。
STOS 侧已在 swarm-prompt 层面自行加了 L1（git 可溯源：worker report 必须带 commit+file 字段，coordinator 独立核验）/ L2（report 必带可验证字段）/ L1b（权威源核验：多副本文件改前 grep 判据）三条自律规则，这些是 prompt 层软约束，不能从协议上杜绝"worker 构造出自洽但虚假的完成声明"（只要"完成"这个状态允许 worker 单方面 report，理论上 worker 总能编一个能自圆其说的 commit hash/文件路径）。
诉求（三选一，请 jcode 团队判断哪个成本最低可先做，不替团队排优先级）
方案 A（最小改动）：swarm action=report 接口层加一个可选的 evidence 字段（commit hash / 产出文件路径），swarm action=await_members 的返回结果里带一个"该 worker 声称的产出是否被系统层验证过存在"的标记（不只是透传 worker 自报的 status 字符串）。
方案 B（中等改动）：complete_node 的 artifact 校验逻辑扩展为"校验 artifact 文件在 report 时刻是否真实存在于文件系统"，不依赖 worker 自报。
方案 C（最大改动，L3 根治）：swarm 完成语义整体改为"完成 = 系统观测到可验证产物（文件/commit 真实存在）"，report 只是附言而非完成证明。这是彻底的协议层重构。
判例数据（供评估参考价值，非全部细节）
- 批次：STOS 合参133/134 stos-v2 S0~S3 + 回灌，单批次 12 次 spawn
- 失败模式 1（4 次）：worker 自报 completed + token 消耗明显（30~300k+）+ 但产出文件/commit 均未落盘，coordinator 靠
git log 事后核验发现
- 失败模式 2（1 次）：worker commit 到了错误文件位置（多副本目录下的陈旧副本，该副本不在任何启动脚本引用链），git 核验能查到 commit 但查不出"改错地方"，比模式 1 更隐蔽
- STOS 侧已自行缓解（prompt 层 L1/L2/L1b），但根治需要 jcode 平台层改动，超出 STOS 可单方面范围
建议（非强制，供参考）
若团队评估方案 A 成本最低可先做，STOS 侧可以配合提供"12 spawn 判例明细 + L1/L2/L1b 自律规则全文"作为验收测试用例（evidence 字段应能捕获的 5 类失败模式，可写成 5 个最小复现 case，供 jcode 侧跑回归测试用），这部分 STOS 侧主动提供，不需要 jcode 团队额外负担。
Swarm worker 完成判据：从 worker 自报 status 改为系统层可观测产物核验
报告方：STOS 系统（github.com/1jehuang 下的 STOS 项目，jcode 的主要用户侧之一）
日期：2026-09-22
现象
jcode 的
swarm action=spawn+swarm action=report status=completed目前语义是：worker 自己判定并上报"完成"，coordinator 通过swarm action=await_members收到的只是 worker 自报的 status 透传，系统层没有独立校验"worker 声称的产出是否真实落盘"。STOS 侧在真实使用（合参/蜂群流程）中已经坐实过这类问题：单一批次 12 次 spawn，4 次"worker 自报 completed 但实际未 write/commit 任何文件"，另有 1 次"改错文件位置（commit 到了不被任何启动脚本引用的陈旧副本，改了对系统无实际影响）"。这 5 次全部是靠 coordinator 事后
git log/ls独立核验才坐实，机制本身没有任何拦截能力，完全依赖下游人工补救。STOS 侧已在 swarm-prompt 层面自行加了 L1（git 可溯源：worker report 必须带 commit+file 字段，coordinator 独立核验）/ L2（report 必带可验证字段）/ L1b（权威源核验：多副本文件改前 grep 判据）三条自律规则，这些是 prompt 层软约束，不能从协议上杜绝"worker 构造出自洽但虚假的完成声明"（只要"完成"这个状态允许 worker 单方面 report，理论上 worker 总能编一个能自圆其说的 commit hash/文件路径）。
诉求（三选一，请 jcode 团队判断哪个成本最低可先做，不替团队排优先级）
方案 A（最小改动）：
swarm action=report接口层加一个可选的evidence字段（commit hash / 产出文件路径），swarm action=await_members的返回结果里带一个"该 worker 声称的产出是否被系统层验证过存在"的标记（不只是透传 worker 自报的 status 字符串）。方案 B（中等改动）：
complete_node的 artifact 校验逻辑扩展为"校验 artifact 文件在 report 时刻是否真实存在于文件系统"，不依赖 worker 自报。方案 C（最大改动，L3 根治）：swarm 完成语义整体改为"完成 = 系统观测到可验证产物（文件/commit 真实存在）"，
report只是附言而非完成证明。这是彻底的协议层重构。判例数据（供评估参考价值，非全部细节）
git log事后核验发现建议（非强制，供参考）
若团队评估方案 A 成本最低可先做，STOS 侧可以配合提供"12 spawn 判例明细 + L1/L2/L1b 自律规则全文"作为验收测试用例（evidence 字段应能捕获的 5 类失败模式，可写成 5 个最小复现 case，供 jcode 侧跑回归测试用），这部分 STOS 侧主动提供，不需要 jcode 团队额外负担。