diff --git a/WORK_LOG.md b/WORK_LOG.md
index 5bc483d..e75d9b8 100644
--- a/WORK_LOG.md
+++ b/WORK_LOG.md
@@ -77,6 +77,7 @@
 - flow 第 2 部分（2026-10-03）：选批并进第 2 部分；不回放 16-real-1；验收看整体研究质量（方向、多样性与判重、提案、挑刺、回应、预测、选批，加过程数字），不只看某一个想法；这一段的提示词先按调研结论诊断再改，改完提交后才跑，看到结果不再调；三块合成一份任务书。用户原话："直接看也没有联合优化是狭隘的，我们其实是要从更广阔的领域去分析整一个系统，它有没有正常高质量的运行"、"选批并进部分 2；不回放"、"这个部分现有的 prompt 一定是有问题的"、"同意，合成一份，写任务书 14 吧"。
 - 第 1 轮方向分析与提示词第二次改（2026-10-03）：监督者按路线（不按单个想法）读了 6 次运行，能走到最好的那类解法 6/6 次都有人想到，但常被写成备选或"做法类别"之一；18/18 人第一个入口从读基线半径函数出发、按代码工序分工；压低它的理由是"求确定、好归因、怕白跑"，不是技术理由。用户定两处改法，由监督者直接改提示词（ff5c8dd），再写任务书 15 让新会话重跑对照：①正向只管冲分、消融负责解释、估分照实；②先不看代码自己解题，再拆基线工序，两边对照。用户原话："正向实验，就是为了去追求最高的分……你这样实验你可以去冲。然后后面的反向实验有人给你兜底"；"先让他脱离代码……假设自己没有代码的情况之下……列出解法……在思考输出之中把这个解法列一下就好了……然后第二，他需要对现在的解法进行拆解……进行一个综合的分析"；"提示词你直接改，改后后还是写一个任务书让新会话执行"。flow 第 3 部分顺延为任务书 16。
 - flow 第 3 部分（2026-10-04）：⑨–⑫ 照方法实现，写完采纳停下；验收看五样研究质量（实现照协议没有、核验员判得对不对、押注和实测对比、分数和参考项目第 1 轮对比、程序账目），不设硬线；实验员、核验员这一段的提示词先诊断再改，改完提交后才跑、看到结果不再调。用户原话："我基本认同，唯一我觉得需要补充的就是 prom 需要修改……这次那几位的 prompt 也同样需要修改"。因为提示词要改，任务书 15 的三份研究恢复时会被提示词哈希核对挡下，改为从头新跑 3 份（监督者定，顺带重复一次任务书 15 的路线对照）。监督者另定：一批里的正式运行一个接一个跑、检验时不和别的研究同时跑（候选多半按秒数停，抢 CPU 会改分数）；轻量检查次数按每次调用计、不进账本；修复阶段按"第几次"编号。
+- flow 第 4 部分（2026-10-04，任务书 17）：先写任务书 17 交新会话执行，同时监督者离线做 Jev 比上限的检验。这一段的提示词（解释、收尾、消融实现、消融核验）同样先诊断再改，改完提交后才跑、看到结果不再调；研究者角色提示词不动。收尾的"下一步"由"在哪个因子上继续"改为"沿某个因子继续，或换一条更可能拿最高分的路线"（方法.md 4.3 ⑱）。验收从头真实跑 3 份完整研究到余额用完，不回放 16-real-1；3 份同时跑，一份研究内的正式运行仍一个接一个跑，用每次运行的 CPU 时间与墙钟时间之比核对没有互相抢。用户原话："我建议先写任务书 17（消融到收尾），然后让一个flow完成任务17，同时我们可以用这 6 个实测分数加上参考项目的账本，离线检验"、"我感觉改提示词真的很重要"、"我基本同意，唯一的问题是3份不能并行跑吗？"。
 
 ## 未完成
 
@@ -107,4 +108,4 @@
 
 ## 下一步
 
-任务书 16 已完成并经监督者核对。下一步：Jev 比上限的离线检验（"未完成"第一条，任务书 16 的 6 个实测加参考项目账本），然后 flow 第 4 部分（消融到收尾，任务书 17）。
+任务书 17（flow 第 4 部分：消融到收尾）已写好，交新会话执行。监督者同时做 Jev 比上限的离线检验（"未完成"第一条，任务书 16 的 6 个实测加参考项目账本）。之后是 export、plugin。
diff --git a/docs/方法.md b/docs/方法.md
index c85de7f..b3696e4 100644
--- a/docs/方法.md
+++ b/docs/方法.md
@@ -326,7 +326,7 @@
 **⑱ 信念本更新与收尾（每位研究者）**
 
 - 本轮的全部结果在同一个事务里算完并公开。下一阶段的材料据此现算出新的信念本。
-- 每位研究者写一段收尾：什么被支持了、什么被挑战了、下一步想在哪个因子上继续。把结论推广出去时，要写清它覆盖哪些设定。收尾正文原样放进下一轮的提案材料，所有人都能读到。
+- 每位研究者写一段收尾：什么被支持了、什么被挑战了、下一步想往哪走：沿某个因子继续，或换一条更可能拿最高分的路线（用户 2026-10-04 定：正向只管冲分，收尾不把下一轮限在已有因子上）。把结论推广出去时，要写清它覆盖哪些设定。收尾正文原样放进下一轮的提案材料，所有人都能读到。
 - 本轮结束时：
   - 跑过的候选（正向运行已经启动）解封作者自评，进导出；其中有有效成绩的，进战绩里"作者自评 vs 大家合并"那一栏；
   - 入选了却没跑成的候选，解封作者自评并离开候选池；〔自定〕
@@ -363,7 +363,7 @@
 | 核验          | 逐项结果（条款、因子、保障：找没找到、在哪里）；没有归属的改动逐条判断是否越界                                                         | 说明                                                                                 | 推出通过与否                              |
 | 消融实现 / 核验   | 需要一起关的因子，或"这一格跑不起来：原因"；`concerns`；核验的逐项结果（代码同上，由程序冻结）                                                                  | —                                                                                  | 这一格的正式运行                            |
 | 解释          | 每一格的三个数                                                                                         | 机制等文字                                                                              | 信息价值、确认 / 否定、信息账                    |
-| 收尾          | —                                                                                               | 什么被支持、什么被挑战、下一步在哪个因子上继续                                                            | 进下一轮的提案材料                           |
+| 收尾          | —                                                                                               | 什么被支持、什么被挑战、下一步往哪走（沿某个因子继续或换路线）                                            | 进下一轮的提案材料                           |
 
 
 **三个数**：必须严格递增，q₁ < q₅ < q₉，否则退回。认为分数几乎不会变时，写一个很窄的范围，例如 1.2999 / 1.30 / 1.3001。没有"不知道"这个选项，拿不准就把一成和九成拉开。
diff --git a/docs/结构.md b/docs/结构.md
index 8a51695..6634b5d 100644
--- a/docs/结构.md
+++ b/docs/结构.md
@@ -119,7 +119,7 @@
 | 1. 骨架、研究开始、第零轮 | 从账本算出现在到哪；"下一步做什么"的纯函数（步骤先后只写这一处）；主循环；恢复入口；派一个模型任务、跑一次正式运行两个共用动作；冻结配置、建镜像、基线；第零轮 | 第零轮的研究质量六问（任务书 12）：入口里有没有关键想法；分到的入口分没分开；好方向分出去没有；入口是不是改代码的路线；入口有没有写答案；讨论有没有用。另杀进程再启动，不重跑、不重扣、不漏写 | 关键想法和死路清单取自同类系统与参考项目高分运行的研究路径；16-real-1 第零轮回放，分配和参考项目相同，并用同样六问打分当对照 |
 | 2. 开轮到选批 | 4.3 ①–⑧（选批由用户 2026-10-03 定并进来） | 第 1 轮的整体研究质量（任务书 14）：提案在研究路径上处在哪一步、多样性与判重、提案质量、挑刺与回应、预测是否合理、选批、过程健康；同一轮的提示词按调研结论先诊断再改 | 不回放（用户 2026-10-03 定）。参考项目高分运行（12-real-2、14-real-1、15-real-1、15-tight-2、16-real-1）第 1 轮的文字和我们的 3 次运行一起去掉来历，交全新上下文的审阅者按同一套方面打分比较 |
 | 3. 实现到采纳 | ⑨–⑫ | 扣掉的次数等于确认启动的运行数；修复用完不跑、不扣、记事件 | 15-tight-2 第 1 轮的修复 |
-| 4. 消融到收尾 | ⑬–⑱ 与研究结束 | 解释冻结早于任何一格启动；每格只结算一次 | 选格输入和 15-real-1、16-real-1 比；最后整份回放 16-real-1，当四部分合起来的验收 |
+| 4. 消融到收尾 | ⑬–⑱ 与研究结束 | 解释冻结早于任何一格启动；每格只结算一次 | 不回放（用户 2026-10-04 同意）。从头真实跑 3 份完整研究到余额用完，当四部分合起来的验收；消融与收尾和参考项目 15-real-1、15-tight-2、16-real-1 并排看 |
 
 **怎么验证**（用户 2026-10-03 定）：一律用真 Jev、真 Docker，不做假的 Jev、Docker、任务，flow 不为此开替换口子。同样的输入真实跑几次，结果都符合要求就算通过；真实运行里没出现过的情况不专门造出来测。用户原话："我建议用一律用真 Jev、真 Docker。因为其实我们现在是在做科学研究，不是在开发程序……我们只需要重复运行多次"。模型一侧两种都做：
 
diff --git a/任务书/17-flow-4-消融到收尾.md b/任务书/17-flow-4-消融到收尾.md
new file mode 100644
index 0000000..e23e6cc
--- /dev/null
+++ b/任务书/17-flow-4-消融到收尾.md
@@ -0,0 +1,322 @@
+# 任务书 17：flow 第 4 部分（消融到收尾、一轮接一轮、研究结束）与这一段的提示词
+
+这是 flow 四部分里的最后一部分（`docs/结构.md` 第三部分"flow 分四部分写，各自验证"）。做完以后，一份研究能从采纳往下走：
+1. 列消融格、研究者写解释、程序选格；
+2. 实验员实现消融格、核验员核对，不通过就重做；
+3. 正式运行选中的格、结算、定押的因子；
+4. 研究者写收尾，轮末解封；
+5. 开下一轮，一轮接一轮，直到运行次数用完。
+
+余额用完后走到"导出"一步时停下，原因写"导出还没写"。
+
+一份任务书里有三块，**按顺序做**：
+
+1. **第一块：改提示词。**解释、收尾、消融实现、消融核验这一段的提示词。用户 2026-10-04 定：和任务书 16 一样，先诊断再改，改完先提交，再做后面两块。
+2. **第二块：写代码。**写 `src/flow` 的 ⑬–⑱、轮末动作、下一轮和研究结束。
+3. **第三块：真实运行和评估。**从头真实跑 3 份完整研究，按研究质量评估。
+
+本任务书已由用户和监督者在 2026-10-04 一起确定。下面说的"监督者"，是在参考项目目录里和用户讨论设计的另一个会话。
+
+## 开工前先读
+
+- `CLAUDE.md`：全部。尤其是"测试"一节：flow 的验收看研究质量；正式代码和检验代码完全分开。
+- `docs/方法.md`：
+  - 第三部分：角色与材料；
+  - 4.3 ⑫–⑱、4.4；
+  - 第五部分：解释、收尾、消融实现、消融核验四种提交；
+  - 6.6 消融结算、6.7 选格、6.8 押的因子、6.9 信息账、6.10 信念本；
+  - 第七部分：预算、扣次、"什么时候开下一轮"；
+  - 第九部分：中断与恢复。
+- `docs/结构.md`：
+  - 第三部分：步骤清单，以及"flow 分四部分写，各自验证"；
+  - 第四部分：账本记录；
+  - 第八部分：flow、materials、submissions、rules、workspace、runner 各节。
+- `docs/调研/提示词.md`：提示词怎么写的调研结论。第一块必读。
+- `任务书/16-flow-3-实现到采纳.md`：第 3 部分的写法，这次照着往下接。第一块的做法和它的第一块相同。
+- 任务书 16 的产出：`/home/iomgaa/inforsi-eval/2026-10-04-task16/report.txt`（执行报告），以及同目录下的诊断、调研、审阅文件。第一块可以直接复用那次的调研结论，不必重查同一批参考实现。
+- `WORK_LOG.md`："关键决定"最后几条；"未完成"里"给 flow"的条目，第六部分列了哪几条归这次。
+- 参考项目（只读，不要改）：`/home/iomgaa/Projects/RivalBits/src/controller/` 下消融、解释、收尾、下一轮的部分。看它怎么做，不照搬结构。
+
+## 一、第一块：改这一段的提示词
+
+### 1.1 范围
+
+可以改的：
+- `prompts/tasks/explanation.md`、`wrapUp.md`、`ablationImplementation.md`、`ablationVerification.md`；
+- `prompts/roles/experimenter.md`、`prompts/roles/verifier.md` 里**只讲消融的那几句**（任务书 16 刚改过，正向的部分不动）；
+- `src/vocab/submissions.ts` 里解释、收尾、消融实现、消融核验这四种提交的**字段说明**（`description`）。只改措辞，不改字段的结构、类型、必填与否；vocab 上限 1150 行。
+
+不改的：
+- `prompts/roles/researcher.md`：它同时管着提案，改了会影响第 2 轮的提案，而研究者那一段已经定好不再调；
+- 研究者其余任务提示词（提案、预测、挑刺、回应等）；
+- 实验员、核验员提示词里正向的部分；
+- `tasks/circle_packing/` 下的任务文件。
+
+### 1.2 怎么做
+
+1. **读调研结论。**`docs/调研/提示词.md` 全文，以及任务书 16 产出里的 `implementation-research.txt`、`verification-research.txt`、`historical-diagnosis.txt`。
+
+2. **针对这一段再调研。**派子 Agent 去查。参考项目的克隆在 `/home/iomgaa/Projects/RivalBits/reference/`。子 Agent 只读、不写 md，结论直接回复。值得查的方向：
+   - 让模型对一组实验结果事前写出可检验的解释、事后对号：AI-Scientist 的实验分析与写作提示、co-scientist 的反思与评审步骤；
+   - 一轮结束后怎么把结果交给下一轮，让下一轮既用上已有发现、又不被锁在小步调参上：openevolve、aideml、ShinkaEvolve 等进化或搜索系统怎么写"上一轮的总结"和"下一步"；
+   - 消融实现：只关一个部件、其余不动，怎么写才不多改也不漏改。任务书 16 查过的"照规格实现、不顺手改进"结论可以直接用。
+
+3. **拿真实记录诊断。**读参考项目运行里研究者、实验员、核验员在这一段实际交了什么：
+   - 账本在 `/home/iomgaa/rb-acceptance/{16-real-1,15-real-1,15-tight-2,14-real-1,12-real-2}/board.sqlite`，只读，用 `sqlite3 -readonly`。任务书 16 已经复制过一份到 `/home/iomgaa/inforsi-eval/2026-10-04-task16-diagnosis/`，可以直接用那份；
+   - 提交在 `submissions` 表：阶段编号里带 `analysis` 的是解释，带 `update` 的是收尾，带 `ablate-implement`、`ablate-verify` 的是消融实现和消融核验（14-real-1、12-real-2 是旧方法的 `split`，可作参考）；
+   - 参考项目每次运行当时用的提示词在 `/home/iomgaa/rb-acceptance/<运行>/prompts-used/` 下，会话原文在同一目录的 `sessions/` 下。新项目的提示词是以它为底稿改的。
+   - 收尾要和**下一轮的提案**对着读：收尾里写的"下一步"，下一轮有没有人照着提、提成了什么样。
+
+   列出你看到的毛病，也列出做得好的地方，每条写清四样：现象、证据位置（库名、表、编号）、提示词里是哪一句引起的、怎么改。
+
+   监督者已知的三条，核实后可以直接用：
+   - **收尾和"冲分"冲突。**`wrapUp.md` 要每人写"下一步想在哪个因子上继续"，样本也是"沿某个因子继续调"。收尾原文会整段放进下一轮的提案材料，而提案提示词现在要求"交最可能拿最高分的那条，哪怕换掉整道工序"（提交 ff5c8dd）。方法.md 4.3 ⑱ 已改为"下一步想往哪走：沿某个因子继续，或换一条更可能拿最高分的路线"（用户 2026-10-04 定）。提示词照这个改，并用参考项目的"收尾 → 下一轮提案"核实这句话实际起了什么作用。
+   - **第 1 轮之后已经贴近已知最好。**任务书 16 的三份第 1 轮采纳 2.6307–2.6343，已知最好是 2.635983。第 2 轮起研究者面对的是"离已知最好只差一点"。解释、收尾里现在没有一句帮他们想这种处境：还差的那一点可能在哪、哪些因子其实没出力、哪条结论只在某个设定下成立。写的时候不出现任何题目的具体数值或做法，用无关领域的例子说明这种处境。
+   - **消融两份任务提示词和角色提示词重复。**"不要自己跑正式实验""两个保留键怎么写""看不清照实写"等内容，任务书 16 改过的实验员、核验员角色提示词里已经有一份，措辞也变了。同一段内容只放一处：角色提示词里有的，任务提示词里删掉，只留本次任务特有的。
+
+4. **改。**照 `docs/调研/提示词.md` 第三、四部分的原则写。任务提示词里不写字段怎么填（那是字段说明的事）。
+
+5. **自查泄露。**照 `docs/调研/提示词.md` 第四部分最后一条：
+   - 改完用填圆的关键词搜一遍你改过的全部文件，搜到就改掉，搜不到才算过。关键词至少包括任务书 16 用过的 18 个，再加"消融""收尾"样本里可能出现的题目数值（例如 2.6、26）；
+   - 例子只用和题目无关的领域，不出现任何填圆的做法、数值或参考项目跑出来的具体经历。
+
+6. **先提交，再写代码和跑。**提示词改完单独提交一次。之后的真实运行全部用这一版，**看到运行结果以后不再改提示词**。结果不管好坏都照实收下，交给用户。
+
+## 二、第二块：代码
+
+### 2.1 管哪些步骤
+
+config 的 `ROUND_STEPS` 从 `listCells` 到 `wrapUp`，加上轮末动作、开下一轮，以及 `STUDY_STEPS` 里"一轮接一轮直到余额用完"和 `export`：
+- `listCells`、`explanation`、`selectCells`：列格、解释、选格；
+- `ablationImplementation`、`ablationVerification`：消融实现、核验，不通过就重做；
+- `ablationRun`：消融运行；
+- `settle`：结算、押的因子、消融中发现；
+- `wrapUp`：收尾，以及轮末解封；
+- 余额用完后走到 `export`，停下，原因写"导出还没写"。
+
+代码按"第 r 轮"写，不写死轮数。第 2 部分（开轮到选批）原来只在第 1 轮真实跑过，第 2 轮起的留池候选、信念本、"从第 2 轮起说明新观测"、判重时和留池候选比较，这次第一次真正走到。出问题按 CLAUDE.md 修。
+
+`next-step.ts` 里 `roundsNext` 的 `step.id !== "listCells"` 是任务书 16 留下的临时写法（WORK_LOG"给 flow"），这次去掉，按步骤清单正常处理"按配置跳过"。
+
+### 2.2 怎么走（方法.md 4.3 ⑫–⑱）
+
+**什么时候有消融**
+- 采纳了、而且被采纳的改法有 2 个以上因子，才走 ⑬–⑰。
+- 没采纳，或被采纳的只有 1 个因子：⑬–⑰ 都不做，直接到收尾（方法.md 4.3 ⑫）。这几步不写记录，从采纳决定和冻结协议就算得出"这一轮没有消融"。
+- 配置关掉消融时，步骤清单已经标了"按配置跳过"，照现有的跳过写法记事件；解释照样写正文、不交三个数（方法.md 第十一部分）。验收用的配置开着消融，这种情况不专门造出来测。
+
+**列格（⑬）**
+- 用 rules 的 `listCells`，被采纳改法的每个因子一格。不写记录：格从冻结协议现算，格编号用 materials 的 `cellId`。
+
+**解释（⑭）**
+- 研究者阶段，每位研究者一个任务，没有对象；材料由 materials 现有的解释材料给。
+- 解释阶段关闭即冻结。ledger 已经会拒绝"有格启动以后才冻结解释"，flow 照顺序走就不会碰到。
+
+**选格（⑮）**
+- 输入照 rules 的 `CellRuleInput` 拼：基线、完整分数、方向、已知最好、ε、λ、因子、各条解释，加 `ComboParams`（余额、每批上限、`knowledgeUse`、`decay`）和种子。
+- 种子用 `decisionSeed` 的**版本 2**（选批已用版本 1，WORK_LOG"给 flow"）。
+- 规则取步骤清单里 `selectCells` 那一步的，调 `runCellRule`。写一条决定，种类 `cells`。
+- 没选中的格**不另写事件**：没测的原因和"含它的最好组合"都在这条决定里，materials 的信念本也是从这里读的。
+
+**消融实现与核验（⑯）**
+- 每个选中的格派一个实验员任务，对象是格；工作目录从被采纳的完整代码取出。不同格的实验员同时实现。
+- 交上来后：
+  - 交了"这一格跑不起来"（`cannotRun`）：`known.code` 传 null（WORK_LOG"给 flow"），这一格不核验、不运行、不扣次；
+  - 否则用 workspace 存成一个版本，用 tasks 的 `protectedChanges` 查不许改的文件，拼成 submissions 的 `AblationCode`。
+- 实现阶段关闭后，每个交了代码的格派一个核验员任务。材料里的改动是"完整代码到这一格代码"。用 submissions 的 `ablationOutcome` 判通过没有。
+- 不通过的格，在核验阶段关闭后退回原实验员重做，从他上一次交的这一格代码接着改（materials 的消融实现材料已经这样写）。重做完再核验，只核验重做过的格。
+- 次数和正向修复用同一个上限 `config.maxRepairs`。用完仍不通过：用 materials 的 `cellNotRunEvent(格, 原因)` 写事件，不跑、不扣次，结算记"证据不足"。
+- 阶段编号按"第几次"排：`r<轮>-ablationImplementation-1`、`r<轮>-ablationVerification-1`、`r<轮>-ablationImplementation-2`、`r<轮>-ablationVerification-2`……第几次从账本里数，不另存。
+- 实验员报了"还要一起关的因子"（`alsoOff`）时，这一格实际关掉的是几个因子。几格实际关掉的因子完全相同时，用 rules 的 `sharedSettings` 判断沿用哪一格的结果，不重复跑（方法.md 6.6）。
+- 实验员、核验员的编号：materials 现有的是按候选编号起的，消融格按格编号起，需要的话在 materials 补，和正向的写法一致。
+
+**消融运行**
+- 通过核验的格，用 flow 已有的 `formalRun` 跑，用途写 `ablation`，对象是格。
+- 一份研究里的消融运行**一个接一个跑**，同正向。
+- 完整代码和基线的分数直接取本批已有的运行结果，不重跑（方法.md 4.3 ⑯）。
+
+**结算（⑰）**
+- 选中的格全部有结果、"跑不起来"或"不跑"事件后结算。
+- 输入照 rules 的 `SettleInput` 拼：每个因子一格，结局取"有效分数 / 证据不足 / 没测 / 跑不起来 / 一起关"之一；调 `settleAblation`，写一条结算记录。
+- 押的因子用 rules 的 `chooseBet`，写一条决定，种类 `bet`。结算和押的因子在同一个事务里写。
+- "消融中发现"已经在 `settleAblation` 的输出里，materials 的 `baselineOf` 会据此把那一格的代码当成下一轮的基线；flow 不另写采纳记录。确认这一点在真实运行里对得上：出现了就核对下一轮的基线；没出现就在报告里写"没出现"，不专门造。
+
+**收尾与轮末（⑱）**
+- 研究者阶段，每位研究者一个任务，没有对象。
+- 收尾阶段关闭**之后**，写轮末动作（WORK_LOG"给 flow"两条）：
+  - 本轮选批选中的每个候选（跑过的、入选了却没跑成的）解封作者自评：写解封记录。解封只在收尾阶段关闭后写，提前写会泄露（materials 审阅时实测过）。
+  - "入选了却没跑成的候选离开候选池"不用写记录：materials 的 `Board.carried` 只留从没进过任何一批的候选，已经算对。
+  - 本轮全部解封写在同一个事务里。
+
+**下一轮和研究结束**
+- 收尾做完后，余额至少还有 1 次就开下一轮；余额为 0，一轮接一轮这一步做完，走到 `export`，停下，原因写"导出还没写"（方法.md 第七部分"什么时候开下一轮"）。余额用 rules 的 `runBalance` 从运行记录算。
+- 本轮正向批量 k = min(每批上限, 余额)，选格最多"余额 − 1"格，这两条 rules 已经有，确认选批和选格用的余额是当时的余额。
+- 方法.md 第七部分说的情况——最后一次正向用掉了全部余额、又采纳了多因子改法——各格记"没测：剩余次数不够"。真实运行碰到就核对；没碰到不专门造。
+
+### 2.3 每一步以哪条记录为准算做完
+
+接着 `docs/结构.md` 第八部分 flow 一节的那张表往下加：
+
+| 步骤 | 看到哪条记录算做完 |
+|---|---|
+| `listCells` | 不写记录：从采纳决定和冻结协议现算 |
+| `explanation` | 这一轮解释阶段的关闭记录；这一轮没有消融时不开这个阶段 |
+| `selectCells` | 本轮的选格决定（`decision`，种类 `cells`） |
+| `ablationImplementation`、`ablationVerification` | 每个选中的格都已结束这一段：交了"跑不起来"，或最近一次核验通过，或重做次数用完、有"不跑"事件。中间每次实现、核验阶段各有开关记录 |
+| `ablationRun` | 每个通过核验的格，最近一次消融运行有结果，而且不是"没启动" |
+| `settle` | 本轮的结算记录（`settlement`），以及同一事务里的押的因子决定（`decision`，种类 `bet`） |
+| `wrapUp` | 收尾阶段的关闭记录，以及本轮选中的每个候选都有解封记录 |
+| 一轮接一轮 | 新一轮开始时余额为 0 |
+| `export` | 现在不做：走到这里停下，原因"导出还没写" |
+
+### 2.4 规模
+
+flow 现在 1302 行，预计加 500–800 行，上限照结构.md 第七部分的 2000–3500。materials 只补格的角色编号（如果需要），不超过 1950 行。
+
+## 三、第三块：真实运行和评估
+
+### 3.1 跑什么
+
+- 用第一块改好的提示词，配置照 `eval/round-zero/research.json`，只换研究编号。
+- **从头新跑 3 份完整研究**，一直跑到余额用完、停在"导出还没写"。不接着跑任务书 16 的三份：提示词改了，恢复时提示词哈希核对会挡下。
+- **3 份研究同时跑**（用户 2026-10-04 同意）。一份研究里的正式运行仍然一个接一个跑，所以同一时刻最多 3 个正式运行的容器，每个限 1 个核，机器有 16 个核。为了确认没有互相抢 CPU：
+  - 每次正式运行列出 CPU 时间和墙钟时间之比（运行结果里本来就记着）；
+  - 记下运行期间机器的负载（沿用任务书 16 的 `machine.jsonl` 做法）；
+  - 比值明显低于 1 的运行照实列出，查是否和机器负载对得上。不为此重跑。
+  - 任务书 16 的 `eval/forward/acceptance.ts` 要求"启动区间互不重叠"，这次不适用；新的检验不加这一条。
+- 估计每份 8–12 小时。监督者那边会同时离线调 Jev 做另一项检验，只调接口、不占 Docker，不影响这边。
+- 3 份里挑 1 份，在**第一个消融运行确认启动以后、出结果之前**，杀一次控制进程再启动。检查：
+  - 恢复时按容器名找到这次运行，接着等它，没有重跑；
+  - 这次运行只扣了一次；
+  - 结果照常写进去，结算和后面的步骤照常走完。
+- 中途出错先查原因：
+  - 是程序的毛病，按 CLAUDE.md 修了，从出错处续跑；修了什么写进报告。修了 flow 以后，已经写进账本的记录照原样用，不重算；
+  - 是服务一时调不通，接着跑（`node eval/lib/cli.ts --resume --dir <研究目录>`）。
+
+### 3.2 评估：研究质量
+
+不设硬线，结果照实交给用户。前五样看第 4 部分自己的研究质量，后两样看整份研究。
+
+**第 1 样：解释的质量。**
+- 每一条解释，派一个全新上下文的子 Agent，在**看不到消融结果**的情况下读：解释正文和三个数、被采纳改法的因子清单、本批运行结果、实验员的提醒。回答：
+  - 它说出了具体的机制吗？写了什么情况下不成立吗？
+  - 三个数和正文说的一致吗（正文说某因子撑大半，关它那一格的范围是否靠近基线）？
+  - 范围宽窄是否合理：宽到什么结果都包得住，还是窄到没有依据？
+  - 同一轮几位研究者的解释有没有真正不同？
+  - "我没有具体机制判断"用得是否诚实？
+- 然后对上结算：每条解释在每格是确认还是否定；有没有"现有测法分不开"。
+
+**第 2 样：选格。**
+- 每次选格，列出：因子、各格事前合并范围、各组合的信息价值、成本、净值，选了哪几格、没选的原因。
+- 回答：选中的格是不是大家分歧最大、或最可能改变下一步方向的格；有没有因为大家意见一致而一格都不测的情况（方法.md 第十二部分第 7 条），出现了几次。
+
+**第 3 样：消融实现照要求没有、核验员判得对不对。**
+- 每个跑过的格，派一个全新上下文的子 Agent。给它：冻结协议、完整代码、这一格的代码、位置表、`alsoOff` 和 `concerns`。回答：
+  - 是不是只关了指定的因子：有没有多关、少关；
+  - 保障是否原样保留，关掉的因子的指标是否写 null；
+  - 答案路径标签是否和关掉以后的分支对应。
+- 同一个子 Agent 再看核验员每次的逐项结论：该判不通过却通过的、不该判不通过却判了的；有重做的，看重做是否只改了被指出的地方。
+
+**第 4 样：消融结果说明了什么。**每格一行：
+- 关掉的因子（及一起关的）；
+- 实测分数、撑几成；
+- 这一格的答案出自 `main`、某个因子还是某条保障，保障动手了几次。答案出自保障的，这一格量到的可能是保障而不是关掉因子的效果，标出来；
+- 合并范围和实测落在哪一段。
+
+另列：配合关系标签、押的因子、有没有"关掉反而更好"或"消融中发现"。
+
+**第 5 样：收尾和接力。**
+- 每条收尾，派一个全新上下文的子 Agent 读：收尾原文、本轮的信念本和结算。回答：
+  - 有没有把"改法有效"说成"机制被证实"；
+  - 有没有用生成某个解释的那次运行去支持这个解释；
+  - 结论有没有写清覆盖哪些设定；
+  - "下一步"是沿某个因子小步调整，还是换一条可能拿更高分的路线，理由是什么。
+- 再对着下一轮的提案看：下一轮的提案用上了上一轮的哪些发现；是在已有因子上小步调参，还是提出了新的完整路线；离已知最好只差一点时，研究者怎么判断还能做什么。
+
+**第 6 样：整份研究的走向。**每份研究列：
+- 每一轮：正向候选、采纳了什么、采纳分数、离已知最好还差多少、有没有消融、测了几格；
+- 分数随轮次的曲线，和参考项目 15-real-1、15-tight-2、16-real-1 的逐轮采纳分数并排（参考项目当时的提示词带填圆做法，这一项它们占了便宜）。
+- 每个跑过的正向候选一行，接着任务书 16 第 3.2 节第 3 样的表：路线代号、合并的一成、一半、九成、作者自评（这次已解封，直接读解封记录）、实测、落点。这份数据监督者之后要用来检验 Jev。
+
+**第 7 样：程序账目。**每份研究列：
+- 确认启动的正式运行数（基线、正向、消融分开）和余额减少的次数，两者应相等；最后余额为 0；
+- 每格核验了几次、重做了几次、最后跑没跑；"跑不起来"和"不跑"的格有没有扣次数、有没有写事件；
+- 解释阶段关闭早于本轮任何一格的确认启动；每轮最多一条结算；
+- 每轮的解封记录写在收尾阶段关闭之后，覆盖本轮选中的全部候选；
+- 第 2 轮起的基线等于上一轮采纳的（或消融中发现的）代码；
+- 轻量检查每次调用用了几次、有没有超过上限；
+- CPU 时间与墙钟时间之比（3.1）；
+- 杀进程那一次的三条检查。
+
+### 3.3 怎么算通过
+
+**程序部分必须过**：
+- `npm run check`、`npm test` 全过；
+- 3 份研究都跑到余额为 0、停在"导出还没写"，每个阶段开关成对；
+- 扣掉的次数等于确认启动的运行数；
+- 杀进程那一次的三条检查都成立。
+
+**研究质量不设硬线，照实交给用户。**
+
+质量不好时，先查是不是 flow 或 materials 写错了：抽一次运行，看研究者、实验员、核验员"模型调用开始"里存的材料，是否符合方法.md 第三部分和 4.3 ⑭–⑱。材料错了就修，修完重跑。材料对，就照实报告，**不再改提示词**（第一块第 6 条）。
+
+## 四、正式代码和检验代码分开
+
+照任务书 12 第四部分的 7 条。这次新加的检验代码放新目录 `eval/full/`，共用的工具放 `eval/lib/`，能复用 `eval/forward/` 的就复用。运行目录、审阅结果都放 `/home/iomgaa/inforsi-eval/<日期-名字>/`，不提交。
+
+## 五、文档
+
+完成后更新：
+- `docs/结构.md` 第八部分 flow 一节：
+  - "做完以哪条记录为准"的表，加上第 2.3 节的几行；
+  - "谁做、对哪个对象"的表，加上解释、消融实现、消融核验、收尾；
+  - 消融阶段编号怎么排；轮末解封；研究结束；
+  - 三份研究同时跑、一份研究内一个接一个跑；
+  - 新加的 `eval:` 命令；
+  - 本节开头"现在走得到的只有第 1 轮"等过时的话改掉。
+- `docs/结构.md` 第八部分 materials 一节：补上新导出的东西（如有）。
+- `WORK_LOG.md`：
+  - "已完成"补一条；
+  - 删掉这次做到的"给 flow"条目；
+  - "关键决定"不用你写，监督者核对时补。
+
+不新建 md 文件。
+
+## 六、"给 flow"的条目里归这次的
+
+`WORK_LOG.md`"未完成"里的：
+- 选格用随机规则时，种子用版本 2。
+- 步骤清单没有单列"轮末动作"（解封作者自评、入选未跑的候选出池），flow 要做这些。
+- 解封只在本轮收尾阶段关闭后写。
+- 消融格核验不通过、修复次数用完时写 `cellNotRunEvent(格, 原因)` 事件，结算记 insufficient；重做时把上一次这一格的提交取出来当工作目录。
+- 消融实现交了 `cannotRun` 时 `known.code` 传 null，否则传存版本的结果。
+- `next-step.ts` 里 `roundsNext` 的 `step.id !== "listCells"` 临时写法去掉。
+
+## 七、审阅
+
+这次写到了消融的扣次、选格和结算、轮末解封、研究结束，都是账本里"驱动实际动作的决定"（方法.md 第九部分）。写完后另派一个全新上下文的子 Agent 审阅一轮，只看：
+- 消融的实现、核验、重做循环，"跑不起来"和"不跑"；
+- 消融运行的登记、扣次和恢复；
+- 选格、结算、押的因子的输入是不是照 rules 的类型拼对了；
+- 解封的时机；
+- 开下一轮和研究结束的条件。
+
+审阅只防 CLAUDE.md"罕见情况怎么办"里的三类情况，提了别的照列不改。
+
+## 八、验收与报告
+
+做完后本地提交，然后在回复里交一份报告。报告写正文，不把日志全文附进去，日志放在证据目录、报告里给路径。监督者会对着实际文件、账本和评估输出逐项核对：
+
+1. 提交号：提示词那次单独列；新增和修改的文件，分 `prompts/`、`src/`、`tests/`、`eval/` 列；`src/flow` 和 materials 的总行数。
+2. **提示词**：
+   - 诊断出的毛病和做得好的地方，按第 1.2 节第 3 条的四样写；监督者已知的三条，核实结果分别写；
+   - 每份提示词改了什么、依据哪条毛病或哪条原则；
+   - 泄露自查用的关键词和搜索结果；
+   - 再调研派了哪些子 Agent、查到了什么。
+3. `npm run check`、`npm test` 的结果，完整输出放证据目录。
+4. 程序部分：3 份研究的研究目录、轮数、停下原因；杀进程那一次的三条检查。
+5. 研究质量：第 3.2 节七样的表和结论。
+6. 每份研究每一轮一行：正向候选、采纳与分数、消融测了哪几格、每格撑几成、押的因子。
+7. 你和这份任务书、结构.md、方法.md 不一致的地方，以及为什么。
+8. **规则不清楚的地方**：哪里让你犹豫、哪里你是靠猜的。没有就写"没有"。没有真实证据的可能情况，在这里提一句就够，不写进 WORK_LOG。
+9. 正式代码和检验代码分开的自查，逐条写"做到了"或"没做到、为什么"。