docs: 新增任务书 14（flow 第 2 部分：开轮到选批，含提示词诊断与整体质量盲评）

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

WORK_LOG.md

@@ -66,6 +66,7 @@
 - 提示词改一版（2026-10-03）：例子一律换成和题目无关的领域；去掉参考项目填圆运行留下的具体做法；入口的起点分三类（基线代码、题目本身、做法类别），先列六到八个再挑；讨论加"按最后会做成哪类改动归类"一问；角色提示词改为"已知的方法可以用来提假设，只是不算证据"。用户原话："我也同意改提示词，但是我觉得我们需要看一下那些参考项目的提示词咋写的……还有你可以找一些给pi写的skill写的比较好的那种也参考一下"、"我建议你调研完直接去改一版提示词吧，这样没有信息损失。改好后再写任务书让new session重新测"。
 - 研究编号只许小写；配置里的路径必须是绝对路径；检验"分没分开"两个顺序都问取平均（2026-10-03，用户同意监督者建议）。
 - 第零轮收尾（2026-10-03）：提示词改后第 1 问 3/3 通过（上次 0/3），第 3 问 0/3。核对账本：6 次运行 18 人第一志愿从没撞过、人人把自己写的入口排第一，没人把联合优化排第一（v2-1 作者自己排第 3），所以分配规则不起作用，原待定的"改分配规则"撤掉。第零轮不再调；六问照旧每次记录、不再卡进度；"好方向有没有被做出来"改到部分 2 验收：第 1 轮提案里有没有联合优化、入选没有。依据：入口不约束提案（16-real-1 研究者 2 分到读评测的入口，第 1 轮提 SLSQP 被采纳）。用户原话："同意，记下来然后讲部分 2"。
+- flow 第 2 部分（2026-10-03）：选批并进第 2 部分；不回放 16-real-1；验收看整体研究质量（方向、多样性与判重、提案、挑刺、回应、预测、选批，加过程数字），不只看某一个想法；这一段的提示词先按调研结论诊断再改，改完提交后才跑，看到结果不再调；三块合成一份任务书。用户原话："直接看也没有联合优化是狭隘的，我们其实是要从更广阔的领域去分析整一个系统，它有没有正常高质量的运行"、"选批并进部分 2；不回放"、"这个部分现有的 prompt 一定是有问题的"、"同意，合成一份，写任务书 14 吧"。
 ## 未完成
 
 - 第零轮之后再看（2026-10-03 定，等部分 2 的数据）：②第一条消息里没有题目本身，要模型自己查 TASK.md，是否由程序放在最前面；③三位研究者拿到完全一样的提示，是否给每人分一个不同的看题路径；④研究者角色提示词每个任务都发全文，是否按任务只发用得到的几节。
@@ -95,4 +96,4 @@
 
 ## 下一步
 
-任务书 13 已核对。第零轮到此为止，进 flow 第 2 部分：监督者给用户讲部分 2，定下后写任务书。
+任务书 13 已核对。第零轮到此为止。flow 第 2 部分已写成任务书 14（`任务书/14-flow-2-开轮到选批.md`）：先改这一段的提示词，再写 ①–⑧ 的代码，最后真实跑 3 次，和参考项目 5 次高分运行的第 1 轮盲评比较。等用户另开会话执行。

docs/结构.md

@@ -116,8 +116,8 @@
 | 部分 | 管哪些步骤 | 自己的验证目标 | 拿哪份真实记录对照 |
 |---|---|---|---|
 | 1. 骨架、研究开始、第零轮 | 从账本算出现在到哪；"下一步做什么"的纯函数（步骤先后只写这一处）；主循环；恢复入口；派一个模型任务、跑一次正式运行两个共用动作；冻结配置、建镜像、基线；第零轮 | 第零轮的研究质量六问（任务书 12）：入口里有没有关键想法；分到的入口分没分开；好方向分出去没有；入口是不是改代码的路线；入口有没有写答案；讨论有没有用。另杀进程再启动，不重跑、不重扣、不漏写 | 关键想法和死路清单取自同类系统与参考项目高分运行的研究路径；16-real-1 第零轮回放，分配和参考项目相同，并用同样六问打分当对照 |
-| 2. 开轮到冻结 | 4.3 ①–⑦ | 每次模型调用开始时存下的材料里，没有当时还没公开的东西 | 16-real-1 三轮提案到第二次预测回放；15-tight-2 抄错编号不再卡住 |
-| 3. 选批到采纳 | ⑧–⑫ | 扣掉的次数等于确认启动的运行数；修复用完不跑、不扣、记事件 | 选批记录的输入和 16-real-1、15-real-1 存下的比；15-tight-2 第 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，当四部分合起来的验收 |
 
 **怎么验证**（用户 2026-10-03 定）：一律用真 Jev、真 Docker，不做假的 Jev、Docker、任务，flow 不为此开替换口子。同样的输入真实跑几次，结果都符合要求就算通过；真实运行里没出现过的情况不专门造出来测。用户原话："我建议用一律用真 Jev、真 Docker。因为其实我们现在是在做科学研究，不是在开发程序……我们只需要重复运行多次"。模型一侧两种都做：

任务书/14-flow-2-开轮到选批.md

@@ -0,0 +1,297 @@
+# 任务书 14：flow 第 2 部分（开轮到选批）与这一段的提示词
+
+这是 flow 四部分里的第 2 部分（`docs/结构.md` 第三部分"flow 分四部分写，各自验证"）。做完以后，研究能从第零轮走到第 1 轮选出本批：提案 → 判重合并 → 第一次预测 → 挑刺 → 回应与统一 → 冻结协议 → 第二次预测 → 选批，然后停下，原因写"实现还没写（任务书 15）"。
+
+一份任务书里有三块，**按顺序做**：
+
+1. **第一块：改提示词。** 这一段要用的提示词，监督者和用户都认为一定有问题。先读调研结论，可以再调研，拿参考项目的真实记录诊断，然后改。改完先提交，再做后面两块。
+2. **第二块：写代码。** 写 `src/flow` 的 ①–⑧，加两处小修复。
+3. **第三块：真实运行和评估。** 真实跑 3 次，按整体研究质量评估，和参考项目的高分运行盲评比较。
+
+本任务书已由用户和监督者在 2026-10-03 一起确定。下面说的"监督者"，是在参考项目目录里和用户讨论设计的另一个会话。
+
+## 开工前先读
+
+- `CLAUDE.md`：全部。尤其是"测试"一节：flow 的验收看研究质量；正式代码和检验代码完全分开。
+- `docs/方法.md`：
+  - 第三部分：角色与材料；
+  - 4.3 ①–⑧；
+  - 第五部分：每种提交；
+  - 6.3、6.4：合并与选批；
+  - 第九部分：中断与恢复。
+- `docs/结构.md`：
+  - 第三部分：步骤清单，以及"flow 分四部分写，各自验证"；
+  - 第四部分：账本记录；
+  - 第八部分：flow、materials、submissions、jev、rules、config 各节。
+- `docs/调研/提示词.md`：提示词怎么写的两次调研结论。第一块必读。
+- `任务书/12-flow-1-骨架与第零轮.md`：第二部分（骨架怎么搭）、第四部分（正式代码和检验代码怎么分开）。两处这次照旧适用。
+- `WORK_LOG.md`："关键决定"最后几条；"未完成"里"给 flow"的条目，第十部分列了哪几条归这次。
+- 参考项目（只读，不要改）：
+  - `/home/iomgaa/Projects/RivalBits/src/controller/steps/research.ts`，里面有 `openRound`、`dedup`、`writeProtocols`、`predictInputs`、`writeSelection`。看它怎么做，不照搬结构。
+
+## 一、第一块：改这一段的提示词
+
+### 1.1 范围
+
+可以改的：
+- `prompts/roles/researcher.md`；
+- `prompts/tasks/` 下的 `proposal.md`、`firstPrediction.md`、`critique.md`、`response.md`、`unification.md`、`secondPrediction.md`；
+- `src/vocab/submissions.ts` 里这几种提交的**字段说明**（`description`），因为"现在交什么"是从字段说明生成的。只改措辞，不改字段的结构、类型、必填与否；vocab 上限 1150 行。
+
+不改的：
+- 第零轮那三份（entry、discussion、claim）：上一轮已经改过，事先定好不再调；
+- 实验员、核验员、解释、收尾、消融的提示词：后面几部分再看；
+- `tasks/circle_packing/` 下的任务文件，第二块第 2 条那一处除外。
+
+### 1.2 怎么做
+
+1. **读调研结论。** `docs/调研/提示词.md` 全文。
+2. **可以再调研。** 针对这一段的几步可以派子 Agent 去查。参考项目的克隆在 `/home/iomgaa/Projects/RivalBits/reference/`。子 Agent 只读、不写 md，结论直接回复。值得查的方向：
+   - 提出改法时怎么让几个人不交出同一个改法的不同参数；
+   - 挑刺和审稿怎么写才能挑到实质问题：co-scientist 的反思和辩论、AI-Scientist 的审稿提示；
+   - 回应和反驳怎么写；
+   - 让模型给范围预测、而且给得准：`llm_forecasting`、`forecastbench`，以及 `papers/` 下的预测类论文。
+3. **拿真实记录诊断。** 读参考项目高分运行第 1 轮里模型实际交了什么、被退回了什么、Jev 怎么判的：
+   - 账本在 `/home/iomgaa/rb-acceptance/{16-real-1,15-real-1,15-tight-2,14-real-1,12-real-2}/board.sqlite`，只读，用 `sqlite3 -readonly`；
+   - 提交在 `submissions` 表，按 `stages.phase` 区分；退回在 `audit` 表的 `submission-rejected`；
+   - 参考项目当时的提示词在它的 git 历史和 `prompts-used/` 下。新项目的提示词是以它为底稿改的。
+
+   列出你看到的毛病。每条写清四样：现象、证据位置（库名、表、序号）、提示词里是哪一句引起的、怎么改。
+
+   监督者已知的几条，你核实后可以直接用：
+   - 同一轮三个人常交出同一个改法的不同参数。12-real-2 第 2 轮三份都是"在当前最好解附近加扰动再优化"，只是幅度不同；16-real-1 第 2 轮 c2、c3 跑出逐位相同的分数。
+   - 一条后来证明有效的提案被三人都估成最低，没被选上（15-real-1 第 1 轮 c2）。
+   - 挑刺有时只说空话，没有对照代码。
+   - 研究者角色提示词 1.9 万字，每个任务都整份发。
+4. **改。** 照 `docs/调研/提示词.md` 第三、四部分的原则写。同一段内容只放一处：角色提示词里的内容不在任务提示词里再写一遍，任务提示词里不写字段怎么填（那是字段说明的事）。
+5. **自查泄露。** 照 `docs/调研/提示词.md` 第四部分最后一条：
+   - 改完用填圆的关键词搜一遍你改过的全部文件，搜到就改掉，搜不到才算过；
+   - 例子只用和题目无关的领域，不出现任何填圆的做法、数值或参考项目跑出来的具体经历。
+6. **先提交，再写代码和跑。** 提示词改完单独提交一次。之后的真实运行全部用这一版，**看到运行结果以后不再改提示词**。这是事先定好的规则：结果不管好坏都照实收下，交给用户。
+
+## 二、第二块：代码
+
+### 2.1 管哪些步骤
+
+config 的 `ROUND_STEPS` 从 `openRound` 到 `selectBatch`。走到 `implementation` 时停下，原因写"实现还没写（任务书 15）"。现在只走得到第 1 轮，但代码按"第 r 轮"写，不写死 1。
+
+### 2.2 每一步以哪条记录为准算做完
+
+接着 `docs/结构.md` 第八部分 flow 一节的那张表往下加：
+
+| 步骤 | 看到哪条记录算做完 |
+|---|---|
+| `openRound`、`carryOverPool` | 不写记录。本轮名单和提案上限就是冻结的配置；留池候选由 materials 从记录算出（`Board.carried`） |
+| `proposal`、`firstPrediction`、`critique`、`response`、`secondPrediction` | 这一轮这个阶段的关闭记录。阶段编号 `r<轮>-<阶段>` |
+| `dedupe` | 本轮的判重合并决定（`decision`，种类 `dedup`） |
+| `freezeProtocol` | 本轮每个新候选都有冻结协议记录（`protocol`）。全部候选在同一个事务里写 |
+| `selectBatch` | 本轮的选批决定（`decision`，种类 `batch`） |
+
+### 2.3 每个阶段谁做、对哪个对象
+
+一个任务就是"一个人对一个对象"。同一阶段里，一个人的几个任务按先后跑，不同的人同时跑（照任务书 12 第 2.6 节）。一个任务做完，以"这个人对这个对象有一份被收下的提交"为准。阶段关闭要等所有任务都做完。
+
+| 阶段 | 任务 | 对象 |
+|---|---|---|
+| 提案 | 每位研究者一个任务，一个会话里交 1 到 M 条 | 无 |
+| 第一次预测 | 每位研究者 × 本轮每个新候选（含自己的） | 候选 |
+| 挑刺 | 每位研究者 × 本轮每条**不是自己写的**原提案（监督者定，照参考项目：方法没写谁挑谁） | 原提案 |
+| 回应与统一 | 每个新候选一个任务：只有一条原提案的，由作者交"回应"；几条合成的，由其中研究者编号最小的作者交"统一" | 候选 |
+| 第二次预测 | 每位研究者 × 池里每个候选（新候选加留池候选） | 候选 |
+
+"派不派、什么时候停下"的规则照任务书 12 第 2.3 节，只是从"一个人"细到"一个人对一个对象"。查这个任务最近一次调用时，"模型调用开始"里存的材料带着对象，可以用它。
+
+**提交之后才知道的东西**（submissions 的 `known`）：
+- 提案：本人在本阶段已经收下几条；
+- 回应：作者那条原提案；
+- 其余照 submissions 的 `KnownOf`。
+
+提案和挑刺一人可以交几份，编号用 materials 的 `proposalId`、`critiqueId`，收下时由 flow 分配。
+
+### 2.4 三个程序步骤
+
+**判重合并（③）**：
+- 本轮新提案两两问一次 Jev（jev 的 `judgeSameChange`），每条新提案也和每个留池候选问一次。
+- 判为相同的连成一组：A 和 B 相同、B 和 C 相同，A、B、C 就是一个候选（监督者定，方法没写这种情况）。
+- 一组里有提案和某个留池候选相同，整组并进那个留池候选（方法.md 4.3 ③）。一组同时连到两个留池候选，按内部错误停下：真实运行里没出现过。
+- 新候选按组里编号最小的原提案排序，编号用 materials 的 `candidateId`。
+- 写一条决定：
+  - 种类 `dedup`；
+  - 输入：每一对的 Jev 判断，原样存；
+  - 输出：materials 的 `DedupOutput`；
+  - 规则名写 `jevSameChange`，版本 1；参数写 Jev 模型名；种子 `null`。
+
+**冻结协议（⑥ 之后）**：
+- 回应阶段关闭后，对每个新候选：
+  1. 取它最后一份回应或统一；
+  2. 用 submissions 的 `protocolBody` 拼出协议主体；
+  3. 用 materials 的 `freezeProtocol` 补上候选编号、轮次、本批基线、合并了哪些原提案；
+  4. 写冻结协议记录。
+- 一定在回应阶段关闭之后写（"给 flow"：materials 把这条记录的出现当作"已公开"，提前写会泄露）。
+- 本批基线是哪个对象：materials 已经有 `Board.baselineOf`，导出来共用，不另写一份。
+
+**选批（⑧）**：
+- 输入照 rules 的 `BatchInput` 拼：
+  - 候选：池里每个候选，各人最后一份第二次预测的三个数；
+  - 本批基线分数：materials 已经有 `Board.baselineScore`，导出来共用；
+  - 方向、ε、λ、每批上限：取自冻结的配置和任务事实；
+  - 余额：用 rules 的 `runBalance` 从运行记录算；
+  - 种子：rules 的 `decisionSeed`，由研究编号、轮次、版本算（"给 flow"：同一轮选批、选格都用随机规则时，传不同的版本）。
+- 用步骤清单里 `selectBatch` 那一步的规则，调 `runBatchRule`。
+- 写一条决定：种类 `batch`，规则名和版本取 `runBatchRule` 交回的。
+
+### 2.5 两处小修复（用户 2026-10-03 同意）
+
+1. **讨论原文里的作废编号**：讨论和认领的材料里展示讨论原文时，原文引用的入口编号已经作废的，程序在它后面就地标"（已作废）"。上一轮 v2-3 有研究者引用了不在最终清单里的编号，读的人会糊涂。写在 materials 里（谁看到什么归 materials）。
+2. **删掉 `tasks/circle_packing/baseline/SOURCES.md` 里"一个实测过的事实（参考项目里跑出来的）……"那一段**（第 21–23 行）。它把注意力引到半径函数上，研究者也引用过它。
+
+### 2.6 不花钱的测试（`tests/`）
+
+在 `tests/flow-next-step.test.ts` 里加"下一步做什么"的情形，至少覆盖：
+- 第零轮做完 → 开提案阶段；
+- 提案阶段一人交了两条、两人没交 → 只派没交的两人；
+- 提案交齐关闭后 → 判重；
+- 判重做完 → 开第一次预测，任务是每人 × 每个新候选；
+- 挑刺阶段的任务里没有"挑自己的提案"；
+- 合并而成的候选，回应阶段派给编号最小的作者交统一；
+- 回应阶段关闭、还没有冻结协议 → 写冻结协议；
+- 第二次预测关闭 → 选批；
+- 选批做完 → 停下，原因"实现还没写"。
+
+### 2.7 规模
+
+- `src/flow` 这部分新增预期 500–800 行。总数超过 1700 行就停下来检查。
+- materials 上限 1900 行，现在 1897 行，这次要导出两个已有的函数、加作废编号的标注。超过 1900 就在报告里写多在哪几处，监督者再和用户商量上限，不要为了压行数把代码挤在一起。
+
+## 三、第三块：真实运行和评估
+
+### 3.1 跑什么
+
+- 用第一块改好的提示词，配置照 `eval/round-zero/research.json`（3 位研究者、M = 1、每批上限 2、运行次数 13）。
+- 3 个新的研究编号，从头跑到第 1 轮选批后停下，跑 3 次。
+- 一个接一个跑：上次同时跑时内存不够，进程被系统杀过。
+- 3 次里挑 1 次，在第一次预测阶段中途杀一次控制进程再启动，检查：
+  - 被杀那次调用补了结束记录；
+  - 交过的任务没被重派，没交的被重派；
+  - 没有重复收下的提交；
+  - 阶段照常关闭，往下走完。
+
+### 3.2 评估：整体研究质量
+
+用户 2026-10-03 定：不只看某一个想法有没有出现，而是从整体看系统有没有正常、高质量地做研究。用户原话："你现在直接把我们要以 SOTA 方法做标杆，简化为要对着联合优化来，这是不是有一点狭义了"。
+
+**对照组**：参考项目 5 次高分运行的第 1 轮，即 16-real-1、15-real-1、15-tight-2、14-real-1、12-real-2，从它们的账本里读（不回放，用户定）。注意：
+- 12-real-2 那一版用的是投票，不是范围预测，"预测"那一项记"不适用"；
+- 参考项目那几次的提示词里写着填圆的具体做法，所以在"方向"这一项上它们占了便宜。
+
+**第 1 步：导出成同一种文本。**
+- 我们的 3 次运行和参考项目的 5 次，每次导出一份纯文本，按同样的小标题排：
+  - 提案全文；
+  - 判重结果；
+  - 每条挑刺和它的回应；
+  - 冻结协议；
+  - 两次预测的三个数；
+  - 选批结果；
+  - 退回的次数和原因。
+- 去掉能看出来历的东西：运行名、模型名、"16-real-1"这类字样；编号统一改写成"提案 1、候选 1"这种中性写法。字段名不同（"points"对"factors"）去不干净的，在给审阅者的说明里写"格式差异不代表好坏，忽略"。
+- 8 份文本随机编成"运行 A–H"，对照表另存，审阅者看不到。
+- 导出脚本放 `eval/round-one/`。
+
+**第 2 步：盲评。**
+- 派**两个**全新上下文的子 Agent 各自独立审阅，它们只读 8 份文本、`TASK.md` 和第 3.3 节的研究路径说明。
+- 每个审阅者对每份文本，按下表 7 个方面各打 1–5 分，每个分数附原文引用作依据，结论直接回复给你，不写 md。
+- 你把两份打分整理进报告，并按对照表还原成"我们的 3 次"和"参考的 5 次"。
+
+| 方面 | 看什么 | 1 分 | 5 分 |
+|---|---|---|---|
+| 方向 | 提案在研究路径（第 3.3 节）上处在哪一步 | 都在死路上，或者原地打转 | 有提案沿着路径往前走了合理的一步，或者走了一条清单上没有、但讲得通的路 |
+| 多样性与判重 | 同一轮的提案是不是不同类的做法；该合并的合了没有，不该合的有没有被合 | 几条是同一个改法换参数，判重也没拦 | 几条明显是不同的路，判重结果对 |
+| 提案质量 | 照着能不能实现；机制有没有说清；因子划得对不对；关掉一个因子时怎么做有没有写；能不能被实测推翻 | 含糊、说不清为什么会好 | 换一个人照着写代码能写出同一个东西，什么结果算它错了也写清了 |
+| 挑刺 | 有多少挑刺说中了实质问题（混杂、写不清、因子划分、保障会不会改分），有没有对照代码 | 空话、泛泛而谈 | 指出了具体问题，附代码依据 |
+| 回应 | 作者有没有认真处理挑刺：改了，或者讲清不改的理由 | 回避、只说"同意"却不改 | 逐条处理，冻结协议里看得到改动 |
+| 预测 | 范围合不合理；读了挑刺和回应以后，估计有没有变化、变得有没有道理 | 有荒谬的数（超过已知最好或远低于基线）、范围宽到什么都能包住，或两次一字不差 | 范围有依据，第二次的变化说得通 |
+| 选批 | 选中的是不是大家认为最有希望的、在研究路径上合理的那几个 | 选中的明显不如没选的 | 选得合理 |
+
+**第 3 步：用 Jev 判几个封闭的问题**（写在 `eval/` 里，不动 `src/jev/`；两个顺序都问的取平均；阈值未校准，大于 0.5 判"是"）：
+1. **判重对不对**：本轮提案两两问"是不是同一个改法"（检验自己的问法，两个顺序都问），和程序的判重决定对照。列出两样：检验判"是"而程序没合的，检验判"否"而程序合了的。
+2. **挑刺有没有被回应**：每条挑刺问"作者的回应有没有处理这条挑刺：改了协议，或者给了不改的具体理由"。
+3. **提案对应研究路径的哪一步**：每条提案对 K1–K5 和 D1、D2 各问一次（第零轮的 `eval/round-zero/ideas.json`）。只做描述，不设通过线。
+
+**第 4 步：数字和过程。**
+- 每个阶段的模型调用次数、退回次数和原因（按提交种类分）、墙钟时间、token 用量；
+- 有没有停下、交不出、卡住；
+- 预测里超过已知最好（2.635983）或低于基线（0.9598）的数，逐条列出；
+- 每个人对同一候选第一次和第二次预测的变化。
+
+### 3.3 给审阅者的研究路径说明
+
+写成 `eval/round-one/path.md`。这是给审阅子 Agent 读的输入文件，不是项目文档，放在 `eval/` 下。内容照下面写：
+
+> 26 圆填圆，基线 0.9598（圆心按同心环写死、半径逐对缩放），已知最好 2.635983。同类系统和参考项目的高分运行，大多沿着这样一条路往上走：结构化的起点或多起点 → 把圆心和半径一起交给连续优化器 → 在当前最好解附近加扰动再优化，或退火式接受 → 最后修到严格合法。辅助手段有：固定圆心用线性规划求最优半径、只动贴紧的那几个圆。死路有：只做几何构造（圆心按手排的规则摆、不移动），各系统都卡在 2.2–2.54；只改半径的分法、不动圆心，上限受布局限制。这是常见的一条路，不是唯一正确的路：一条清单上没有、但讲得通的路，同样算往前走了。第 1 轮能走多远取决于起点，参考项目第 1 轮采纳的分数在 1.55 到 2.632 之间。
+
+### 3.4 怎么算通过
+
+**程序部分必须过**：
+- `npm run check`、`npm test` 全过；
+- 3 次运行都走到选批后停下，每轮每个阶段开关成对；
+- 冻结协议都写在回应阶段关闭之后；
+- 杀进程那一次的四条检查都成立。
+
+**研究质量不设硬线，照实交给用户。** 报告里要有：
+- 7 个方面，我们 3 次的平均分和参考 5 次的平均分（两个审阅者分开列）；
+- 我们比参考低 1 分以上的方面，单独列出，附你读原文看到的原因；
+- 第 3 步 Jev 的结果，第 4 步的数字。
+
+质量不好时，先查是不是 flow 或 materials 写错了：抽一次运行，看每个阶段"模型调用开始"里存的材料，是否符合方法.md 第三部分和 4.3。材料错了就修，修完重跑 3 次。材料对，就照实报告，**不再改提示词**（第一块第 6 条）。
+
+## 四、正式代码和检验代码分开
+
+照任务书 12 第四部分的 7 条。这次新加的检验代码放在 `eval/round-one/`，共用的工具放 `eval/lib/`。导出的文本、审阅结果、运行目录都放 `/home/iomgaa/inforsi-eval/<日期-名字>/`，不提交。
+
+## 五、文档
+
+完成后更新：
+- `docs/结构.md` 第八部分 flow 一节：
+  - "做完以哪条记录为准"的表，加上第 2.2 节的几行；
+  - 第 2.3 节"谁做、对哪个对象"的表；
+  - 判重怎么连组；
+  - 新加的 `eval:` 命令。
+- `docs/结构.md` 第八部分 materials 一节：补上新导出的两个函数和作废编号的标注。
+- `WORK_LOG.md`：
+  - "已完成"补一条；
+  - 删掉这次做到的"给 flow"条目；
+  - "关键决定"不用你写，监督者核对时补。
+
+不新建 md 文件。`eval/round-one/path.md` 是检验的输入数据，不算项目文档。
+
+## 六、"给 flow"的条目里归这次的
+
+WORK_LOG"未完成"里的：
+- 同一轮里选批和选格都用随机规则时，传不同的"版本"算种子。这次做选批这一半，选格留给第 4 部分。
+- 冻结协议只在回应阶段关闭后写进账本。同一条里"解封只在本轮收尾阶段关闭后写"归第 4 部分，那半句留着。
+
+## 七、审阅
+
+这次改到了判重决定和选批决定，两处都是账本里"驱动实际动作的决定"（方法.md 第九部分）。写完后另派一个全新上下文的子 Agent 审阅一轮，只看第 2.4 节的三个程序步骤和恢复。审阅只防 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.4 节要求的表和单列项；
+   - 两个审阅者各自的打分和主要依据；
+   - Jev 结果；
+   - 数字和过程。
+6. 我们 3 次运行第 1 轮的提案名称、判重结果、选中了哪几个，各一行。全文在运行目录里给出路径。
+7. 你和这份任务书、结构.md、方法.md 不一致的地方，以及为什么。
+8. **规则不清楚的地方**：哪里让你犹豫、哪里你是靠猜的。没有就写"没有"。没有真实证据的可能情况，在这里提一句就够，不写进 WORK_LOG。
+9. 正式代码和检验代码分开的自查，逐条写"做到了"或"没做到、为什么"。