From 9a4a0c81e955e559e6599d1337bc1cc3e1a90736 Mon Sep 17 00:00:00 2001
From: iomgaa <iomgaaycz@gmail.com>
Date: Sun, 4 Oct 2026 02:10:05 -0400
Subject: [PATCH] =?UTF-8?q?docs:=20=E6=96=B0=E5=A2=9E=E4=BB=BB=E5=8A=A1?=
 =?UTF-8?q?=E4=B9=A6=2016=EF=BC=88flow=20=E7=AC=AC=203=20=E9=83=A8?=
 =?UTF-8?q?=E5=88=86=EF=BC=9A=E5=AE=9E=E7=8E=B0=E5=88=B0=E9=87=87=E7=BA=B3?=
 =?UTF-8?q?=EF=BC=8C=E5=90=AB=E5=AE=9E=E9=AA=8C=E5=91=98=E3=80=81=E6=A0=B8?=
 =?UTF-8?q?=E9=AA=8C=E5=91=98=E6=8F=90=E7=A4=BA=E8=AF=8D=EF=BC=89?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---
 WORK_LOG.md                    |   3 +-
 任务书/16-flow-3-实现到采纳.md | 288 +++++++++++++++++++++++++++++++++
 2 files changed, 290 insertions(+), 1 deletion(-)
 create mode 100644 任务书/16-flow-3-实现到采纳.md

diff --git a/WORK_LOG.md b/WORK_LOG.md
index 4268ea1..1d92c17 100644
--- a/WORK_LOG.md
+++ b/WORK_LOG.md
@@ -71,6 +71,7 @@
 - 第零轮收尾（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 吧"。
 - 第 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 会改分数）；轻量检查次数按每次调用计、不进账本；修复阶段按"第几次"编号。
 
 ## 未完成
 
@@ -103,4 +104,4 @@
 
 ## 下一步
 
-任务书 15 的运行、对照分析、思考核查与测试已完成，独立复审未发现阻塞问题，报告在 `/home/iomgaa/inforsi-eval/2026-10-04-route-compare/report.txt`。质量不设通过线，提示词效果交用户判断，不因结果继续调提示词或重跑。下一步由监督者与用户确定 flow 第 3 部分（任务书 16）。
+任务书 16（flow 第 3 部分：实现到采纳，含实验员、核验员提示词）已写，等用户另开会话执行。
diff --git a/任务书/16-flow-3-实现到采纳.md b/任务书/16-flow-3-实现到采纳.md
new file mode 100644
index 0000000..dbc7b3f
--- /dev/null
+++ b/任务书/16-flow-3-实现到采纳.md
@@ -0,0 +1,288 @@
+# 任务书 16：flow 第 3 部分（实现到采纳）与这一段的提示词
+
+这是 flow 四部分里的第 3 部分（`docs/结构.md` 第三部分"flow 分四部分写，各自验证"）。做完以后，研究能从选批往下走：
+1. 实验员按冻结协议实现；
+2. 核验员核对，不通过就退回修复，再核验；
+3. 正式运行；
+4. 整批公开；
+5. 采纳。
+
+写完采纳决定后停下，原因写"消融还没写（任务书 17）"。
+
+一份任务书里有三块，**按顺序做**：
+
+1. **第一块：改提示词。**实验员、核验员这一段的提示词。前几次改研究者提示词以后，研究质量都明显提升（任务书 13、15），用户 2026-10-04 定：这一段的提示词同样先诊断再改。改完先提交，再做后面两块。
+2. **第二块：写代码。**写 `src/flow` 的 ⑨–⑫。
+3. **第三块：真实运行和评估。**从头真实跑 3 次，按研究质量评估。
+
+本任务书已由用户和监督者在 2026-10-04 一起确定。下面说的"监督者"，是在参考项目目录里和用户讨论设计的另一个会话。
+
+## 开工前先读
+
+- `CLAUDE.md`：全部。尤其是"测试"一节：flow 的验收看研究质量；正式代码和检验代码完全分开。
+- `docs/方法.md`：
+  - 第三部分：角色与材料；
+  - 4.3 ⑨–⑫；
+  - 第五部分：实现、核验、修复三种提交；
+  - 第六部分：采纳线、余额、信息账；
+  - 第九部分：中断与恢复，运行次数怎么扣。
+- `docs/结构.md`：
+  - 第三部分：步骤清单，以及"flow 分四部分写，各自验证"；
+  - 第四部分：账本记录；
+  - 第八部分：flow、materials、submissions、jev、workspace、tasks、runner、agents、rules 各节。
+- `docs/调研/提示词.md`：提示词怎么写的调研结论。第一块必读。
+- `任务书/14-flow-2-开轮到选批.md`：第二部分的写法（派任务、阶段开关、"做完以哪条记录为准"），这次照着往下接。
+- `任务书/15-冲分与先想后看-重测.md` 和 `/home/iomgaa/inforsi-eval/2026-10-04-route-compare/report.txt`：上一次的路线对照，第三块要复用它的脚本。
+- `WORK_LOG.md`："关键决定"最后几条；"未完成"里"给 flow"的条目，第六部分列了哪几条归这次。
+- 参考项目（只读，不要改）：`/home/iomgaa/Projects/RivalBits/src/controller/` 下实现、核验、正式运行、采纳的部分。看它怎么做，不照搬结构。
+
+## 一、第一块：改这一段的提示词
+
+### 1.1 范围
+
+可以改的：
+- `prompts/roles/experimenter.md`、`prompts/roles/verifier.md`；
+- `prompts/tasks/implementation.md`、`repair.md`、`verification.md`；
+- `src/vocab/submissions.ts` 里实现、修复、核验这几种提交的**字段说明**（`description`），因为"现在交什么"是从字段说明生成的。只改措辞，不改字段的结构、类型、必填与否；vocab 上限 1150 行。
+
+不改的：
+- 研究者的全部提示词：上一轮已经改过，事先定好不再调；
+- 消融实现、消融核验的提示词：第 4 部分再看；
+- `tasks/circle_packing/` 下的任务文件。
+
+### 1.2 怎么做
+
+1. **读调研结论。**`docs/调研/提示词.md` 全文。那两次调研查的是"怎么让研究者提出方向"，第三部分的写法原则通用，第二部分的内容不直接适用于实验员和核验员。
+
+2. **针对这一段再调研。**派子 Agent 去查。参考项目的克隆在 `/home/iomgaa/Projects/RivalBits/reference/`。子 Agent 只读、不写 md，结论直接回复。值得查的方向：
+   - 照一份写定的规格写代码时，怎么让模型只做规格里的事、不顺手"改进"：aider、SWE-agent、OpenHands、aideml、MLAgentBench、openevolve 的实现类提示词；
+   - 代码审查、核对实现和规格是否一致，怎么写才能查出实质问题、又不乱判不通过：AI-Scientist 的审稿提示、SWE-agent 和 OpenHands 的审查提示、co-scientist 的反思步骤；
+   - 被退回以后怎么修：只改被指出的地方，不重写一遍。
+
+3. **拿真实记录诊断。**读参考项目高分运行里实验员、核验员实际交了什么、被退回了什么：
+   - 账本在 `/home/iomgaa/rb-acceptance/{16-real-1,15-real-1,15-tight-2,14-real-1,12-real-2}/board.sqlite`，只读，用 `sqlite3 -readonly`；
+   - 提交在 `submissions` 表，阶段编号里带 `implement`、`verify`；退回在 `audit` 表；轻量检查的计次在 `check_uses` 表；
+   - 参考项目当时的提示词在它的 git 历史和 `prompts-used/` 下。新项目的提示词是以它为底稿改的。
+
+   列出你看到的毛病，也列出做得好的地方，每条写清四样：现象、证据位置（库名、表、序号）、提示词里是哪一句引起的、怎么改。
+
+   监督者已知的一条，核实后可以直接用：15-tight-2 第 1 轮 c2，核验员发现实验员把线性规划里"圆到四面墙"的约束行和右端值对错了位，解的不是协议写的那个线性规划，判不通过；修复一次后通过，然后才正式运行。这是核验起作用的例子，改提示词不要把这种能力改丢了。
+
+   另外注意一件事：研究者的提示词现在写着"正向实验只管冲分"（提交 ff5c8dd）。实验员和核验员不一样：实验员照冻结协议忠实实现，不替研究者"冲分"、不顺手加改进；核验员只对照协议核对。实验员读得到研究者的提交，看看这句会不会影响他。
+
+4. **改。**照 `docs/调研/提示词.md` 第三、四部分的原则写。同一段内容只放一处：角色提示词里的内容不在任务提示词里再写一遍，任务提示词里不写字段怎么填（那是字段说明的事）。
+
+5. **自查泄露。**照 `docs/调研/提示词.md` 第四部分最后一条：
+   - 改完用填圆的关键词搜一遍你改过的全部文件，搜到就改掉，搜不到才算过；
+   - 例子只用和题目无关的领域，不出现任何填圆的做法、数值或参考项目跑出来的具体经历。
+
+6. **先提交，再写代码和跑。**提示词改完单独提交一次。之后的真实运行全部用这一版，**看到运行结果以后不再改提示词**。这是事先定好的规则：结果不管好坏都照实收下，交给用户。
+
+## 二、第二块：代码
+
+### 2.1 管哪些步骤
+
+config 的 `ROUND_STEPS` 从 `implementation` 到 `adopt`：
+- `implementation`、`verification`、`repair`：实现、核验、修复；
+- `forwardRun`：正式运行；
+- `publish`、`informationAccount`：整批公开、信息账；
+- `adopt`：采纳。
+
+写完采纳决定后，走到 `listCells` 时停下，原因写"消融还没写（任务书 17）"。代码按"第 r 轮"写，不写死 1。
+
+### 2.2 怎么走（方法.md 4.3 ⑨–⑫）
+
+**实现**
+- 本批每个入选候选派一个实验员任务，对象是候选。不同候选的实验员同时跑。
+- 实验员的工作目录：从本批基线（materials 的 `Board.baselineOf`）取出的代码。
+- 交上来以后，flow 先做三件事，再交给 submissions 判定：
+  1. 用 workspace 存成一个版本；
+  2. 和本批基线比较，用 jev 的 `codeHunks` 切成差异块；
+  3. 用 tasks 的 `protectedChanges` 查有没有改不许改的文件。
+
+  以上三步的结果拼成 submissions 要的 `known.code`。存不成版本时，照 `known` 的另一种形状交。
+- 协议规则里引用的指标，要换成原登记的定义（"给 flow"条目）。materials 的实验员材料里已经有这一步，把它导出来共用，不另写一份。
+- 收下的实现，把代码版本和因子位置表写进冻结代码记录（`code`）。
+
+**轻量检查**
+- agents 已经有轻量检查工具，它调 `SessionTask.lightCheck`。由 flow 接上：取出实验员当前的工作目录，用 tasks 的 `lightCheck` 和 runner 跑，用 `readLightCheck` 读结果。
+- 次数上限（`config.lightChecks.maxCount`）和每次时长（`seconds`）由 flow 计、由 flow 限。
+- 次数按每次模型调用计，不写进账本：会话文件里本来就留着每次检查。只有用户自己杀进程重启才可能多查几次，按"单用户不防误操作"不为它加记录（监督者定）。
+
+**核验**
+- 实现阶段关闭后，每个候选派一个核验员任务，对象是候选。
+- 材料里"起点到候选的改动"由 flow 用 workspace 的 `compareVersions` 算出来，交给 materials。"没有归属的改动"由 materials 现算。
+- 用 submissions 的 `verificationOutcome` 判通过没有。
+
+**修复**
+- 核验阶段关闭后，不通过的候选才派修复任务，对象是候选，交给这个候选原来那位实验员（"给 flow"条目：修复任务要在核验阶段关闭后再发）。
+- 实验员从他上一次交的代码接着改，工作目录取出那个版本。
+- 修复交上来，差异块仍按**本批基线**算（"给 flow"条目），不是按上一次提交算；修复材料里给的"上一次提交到这一次的改动"另算。
+- 修完再核验，只核验这次修复过的候选。
+- 阶段编号按"第几次"排：`r<轮>-implementation`、`r<轮>-verification-1`、`r<轮>-repair-1`、`r<轮>-verification-2`……第几次从账本里数，不另存。
+- 修复次数用完（`config.maxRepairs`）仍不通过：这个候选不跑，不扣运行次数，写一条事件写明原因（方法.md 4.3 ⑨）。materials 现在只有消融格的"不跑"事件名，正向的补一个。
+
+**正式运行**
+- 通过核验的候选，用 flow 已有的 `formalRun` 跑，用途写 `forward`。
+- 先登记（占名额），确认容器启动后才扣次数，再判分、写结果。这些 `formalRun` 已经做好了。
+- 一批里的正式运行**一个接一个跑**，不同时跑（监督者定）。原因：候选多半写着"跑到某个秒数就停"，同时跑的容器抢 CPU，会直接改变分数。
+- "没启动"的处理照基线：写完"没启动"就停下，下次启动起新编号重跑。
+
+**整批公开与信息账**
+- 不写记录。本批全部运行有了结果（或者有了"不跑"事件），这两步就算做完。
+- 公开靠采纳决定：materials 的 `Board.runPublic` 以本轮采纳决定的出现为准。
+- 信息账从预测和运行结果现算（结构.md 第四部分"能现算的不存"）。
+
+**采纳**
+- 用 rules 的 `adopt` 和 `adoptionLine`。输入：本批每个有有效分数的候选、本批基线分数、方向、ε。
+- 写一条决定，种类 `adopt`。没有候选过线时也写，`adopted` 为 null（"给 flow"条目：本轮正向运行靠它公开）。
+
+### 2.3 每一步以哪条记录为准算做完
+
+接着 `docs/结构.md` 第八部分 flow 一节的那张表往下加：
+
+| 步骤 | 看到哪条记录算做完 |
+|---|---|
+| `implementation` | 这一轮实现阶段的关闭记录 |
+| `verification`、`repair` | 每个入选候选都已结束这一段：要么最近一次核验通过，要么修复次数用完、有"不跑"事件。中间每次核验、修复阶段各有开关记录 |
+| `forwardRun` | 每个通过核验的候选，最近一次正向运行有结果，而且不是"没启动" |
+| `publish`、`informationAccount` | 不写记录：`forwardRun` 做完就算做完 |
+| `adopt` | 本轮的采纳决定（`decision`，种类 `adopt`） |
+
+### 2.4 共用动作要补的
+
+- "派一个模型任务"现在写死给研究者用。按角色补上实验员和核验员：
+  - 模型取配置里对应的角色；
+  - 角色提示词按角色取；
+  - 实验员有工作目录（取出的代码）、轻量检查、`known.code`；
+  - 核验员和修复材料要传 `changes`。
+- 实验员、核验员的编号：materials 只有 `researcherId`，补上这两种角色的。
+- `View.lastCall` 和 `done` 现在假定是研究者，确认对实验员、核验员也对。
+
+### 2.5 规模
+
+flow 现在 1105 行，预计加 450–650 行，上限照结构.md 第七部分的 2000–3500。materials 只补导出和一个事件名，不超过 1950 行。
+
+## 三、第三块：真实运行和评估
+
+### 3.1 跑什么
+
+- 用第一块改好的提示词，配置照 `eval/round-zero/research.json`，只换研究编号。
+- **从头新跑 3 份研究**，跑到第 1 轮采纳后停下。不接着跑任务书 15 的三份：提示词改了，恢复时程序核对提示词哈希会停下，这是方法规定的（方法.md 第九部分），不为此改程序。
+- **一个接一个跑**，不同时跑，同一台机器上也不和别的研究同时跑。原因同 2.2"正式运行"。
+- 3 次里挑 1 次，在第一个正式运行确认启动以后、出结果之前，杀一次控制进程再启动。检查：
+  - 恢复时按容器名找到这次运行，接着等它，没有重跑；
+  - 这次运行只扣了一次；
+  - 结果照常写进去，后面的步骤照常走完。
+- 中途出错先查原因：
+  - 是程序的毛病，按 CLAUDE.md 修了重跑，修了什么写进报告；
+  - 是服务一时调不通，接着跑（`node eval/lib/cli.ts --resume --dir <研究目录>`）。
+
+### 3.2 评估：研究质量
+
+用户 2026-10-04 定的五样。不设硬线，结果照实交给用户。
+
+**第 1 样：实现照协议没有。**
+- 每个跑过的候选，派一个全新上下文的子 Agent。
+- 给它：冻结协议全文、本批基线代码、最终代码（核验通过的那一版）、实验员交的因子位置表和"担心"。
+- 让它逐条对照实现条款、因子、保障，回答：有没有漏做；有没有协议里没有的"改进"；位置表对不对。每条附代码位置。
+- 结论直接回复，不写 md。
+
+**第 2 样：核验员判得对不对。**
+- 同一个子 Agent 再看核验员每次交的逐项结论，找出：
+  - 该判不通过却判了通过的；
+  - 不该判不通过却判了不通过的。
+- 有修复的，看修复是不是只改了被指出的地方。
+
+**第 3 样：押注和实测对比。**每个跑过的候选一行：
+- 路线代号：用任务书 15 附录一的分类，从冻结协议判；
+- 合并后的一成、一半、九成三个数；
+- 三位研究者各自第二次预测的一半那个数；
+- 作者自评（检验脚本直接读账本，不受封存影响）；
+- 实测分数；
+- 实测落在合并范围的哪一段。
+
+再单列一项：能走到最好的那类路线（整题联合优化、或挪全部圆心加多起点的完整路线），实测比押的高还是低、差多少。这份数据之后还要用来检验"让 Jev 比较上限"的想法（`WORK_LOG.md` 未完成里 Jev 押注一条）。
+
+**第 4 样：分数和参考项目第 1 轮对比。**
+- 从参考项目 5 次高分运行的账本里取第 1 轮各正向候选的分数和采纳结果，和我们 3 次并排列。
+- 参考项目第 1 轮采纳的分数在 1.55 到 2.632 之间。分数存在哪张表你自己查。
+- 注意：参考项目那几次的提示词带着填圆的具体做法，这一项它们占了便宜。
+
+**第 5 样：程序账目。**每次运行列：
+- 确认启动的正式运行数，和余额减少的次数，两者应相等；
+- 每个候选核验了几次、修复了几次、最后跑没跑；
+- 修复用完不跑的，有没有扣次数、有没有写事件；
+- 轻量检查每次调用用了几次、有没有超过上限；
+- 杀进程那一次的三条检查。
+
+**另外：第零轮到选批的路线对照。**这 3 份研究会重新跑一遍第零轮和第 1 轮前半段，提示词和任务书 15 相同。用 `eval/route/` 的脚本对它们做同样的 A–J 对照表，和任务书 15 的 3 次并排，看结果能不能重复。阅读问卷照任务书 15 附录一。
+
+### 3.3 怎么算通过
+
+**程序部分必须过**：
+- `npm run check`、`npm test` 全过；
+- 3 次运行都走到采纳后停下，每个阶段开关成对；
+- 扣掉的次数等于确认启动的运行数；
+- 杀进程那一次的三条检查都成立。
+
+**研究质量不设硬线，照实交给用户。**
+
+质量不好时，先查是不是 flow 或 materials 写错了：抽一次运行，看实验员、核验员"模型调用开始"里存的材料，是否符合方法.md 第三部分和 4.3 ⑨。材料错了就修，修完重跑。材料对，就照实报告，**不再改提示词**（第一块第 6 条）。
+
+## 四、正式代码和检验代码分开
+
+照任务书 12 第四部分的 7 条。这次新加的检验代码放 `eval/round-one/` 或新目录 `eval/forward/`，共用的工具放 `eval/lib/`。运行目录、审阅结果都放 `/home/iomgaa/inforsi-eval/<日期-名字>/`，不提交。
+
+## 五、文档
+
+完成后更新：
+- `docs/结构.md` 第八部分 flow 一节：
+  - "做完以哪条记录为准"的表，加上第 2.3 节的几行；
+  - "谁做、对哪个对象"的表，加上实现、核验、修复；
+  - 修复的阶段编号怎么排；
+  - 正式运行一个接一个跑；
+  - 新加的 `eval:` 命令。
+- `docs/结构.md` 第八部分 materials 一节：补上新导出的函数和新事件名。
+- `WORK_LOG.md`：
+  - "已完成"补一条；
+  - 删掉这次做到的"给 flow"条目；
+  - "关键决定"不用你写，监督者核对时补。
+
+不新建 md 文件。
+
+## 六、"给 flow"的条目里归这次的
+
+`WORK_LOG.md`"未完成"里的：
+- 没采纳时也写一条采纳决定（adopted 为 null），本轮正向运行靠它公开；修复任务要在核验阶段关闭后再发。
+- 修复的差异块按本批基线算，切好交给 submissions。
+- 问 Jev 查代码改动时，冻结协议里引用的指标要换成原登记的定义（导出共用，不另写一份）。
+
+其余几条（选格种子、轮末动作、解封、消融格、`cannotRun`）归第 4 部分，留着。
+
+## 七、审阅
+
+这次写到了运行次数怎么扣、核验结论怎么驱动修复和不跑、采纳决定，都是账本里"驱动实际动作的决定"（方法.md 第九部分）。写完后另派一个全新上下文的子 Agent 审阅一轮，只看：
+- 第 2.2 节的修复循环；
+- 正式运行的登记、扣次和恢复；
+- 采纳决定。
+
+审阅只防 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 节五样的表和结论，以及路线对照的 A–J 表。
+6. 3 次运行每个入选候选一行：名称、路线代号、核验几次、修复几次、跑没跑、实测分数、采纳没有。
+7. 你和这份任务书、结构.md、方法.md 不一致的地方，以及为什么。
+8. **规则不清楚的地方**：哪里让你犹豫、哪里你是靠猜的。没有就写"没有"。没有真实证据的可能情况，在这里提一句就够，不写进 WORK_LOG。
+9. 正式代码和检验代码分开的自查，逐条写"做到了"或"没做到、为什么"。