docs: WORK_LOG 记 flow 四部分拆分与真 Jev 真 Docker 验证

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

WORK_LOG.md

@@ -57,6 +57,7 @@
 - 解释的 `cells` 只按完整流程全开实现，一律要求交（用户选"只按全开实现"）；做步骤开关时再补"关掉消融时不交"。
 - 提案、回应、统一的已占用指标编号加 `answer-path`、`safeguard-triggers` 两个保留键（用户选"materials 补进清单"）。
 - Jev 退回的原因只列判"是"的几问，只用 jev 的英文问题名（用户选"只列判是的+只写英文"）。
+- flow 的验证一律用真 Jev、真 Docker，不做假的 Jev、Docker、任务，flow 不为此开替换口子，submissions 照旧直接用 jev。验证办法是同样的输入真实跑几次，结果都符合要求就算通过；真实运行里没出现过的情况不专门造出来测（2026-10-03）。用户原话："我建议用一律用真 Jev、真 Docker。因为其实我们现在是在做科学研究，不是在开发程序……我们只需要重复运行多次……没有出现情况，你不需要去考虑"。
 
 ## 未完成
 
@@ -90,3 +91,11 @@
 ## 下一步
 
 任务书 11（收尾）已核对通过（13a7e60），materials 行数范围改为 1200–1900。已完成模块收尾完毕，下一步由用户和监督者一起过 flow。用户 2026-10-03 定的做法：flow 拆成 3–5 个能各自独立验证的部分，逐个讲、定、写任务书；每部分既按它自己的目标验证，也拿参考项目真实验收运行的记录（`/home/iomgaa/rb-acceptance/*/board.sqlite`）当对照。用户原话："把这一部分拆成 3 到 5 个可以独立验证的部分""我们也可以把我们的记录作为一个标杆，然后去匹配""我觉得我们之前其实很多问题都是 flow 没有做好"。
+
+用户基本认同的拆分（2026-10-03），逐部分讲、写任务书：
+1. 骨架、研究开始、第零轮：从账本算出现在到哪；"下一步做什么"的纯函数（步骤先后只写这一处）；主循环；恢复入口；派一个模型任务、跑一次正式运行两个共用动作；冻结配置、建镜像、基线；第零轮。
+2. 开轮到冻结（4.3 ①–⑦）。
+3. 选批到采纳（⑧–⑫）。
+4. 消融到收尾（⑬–⑱）与研究结束；最后整份回放 16-real-1 当合起来的验收。
+
+对照能用的记录：只有 16-real-1 从头跑到尾没暂停，144 份提交能机械转成新格式；15-tight-2 第 1 轮有唯一一次修复；判重合并、留池、一人多条提案、修复用完在全部记录里都没出现过。故意和参考项目不同、对照时不对齐的：第一次预测在挑刺之前、修复用完不暂停、Jev 等于阈值收下。