diff --git a/WORK_LOG.md b/WORK_LOG.md
index 802b86f..1af4430 100644
--- a/WORK_LOG.md
+++ b/WORK_LOG.md
@@ -24,7 +24,7 @@
 - 任务书 11（收尾，提交 13a7e60）：假设专用指标冻结时加候选前缀，全名"候选编号.短名"，只在 materials 的 `freezeProtocol` 加；短名恢复不能含 `.`（最长 64），已占用清单只剩任务的指标和两个保留键。消融格核验不通过重做时，材料写"工作目录是上一次交的这一格代码的副本"，能读的版本加上它，完整代码照旧列出；消融实现提示词同步改。jev 判重的材料说明补 `keySettings` 一句。materials 1868 行（上限 1850，多出主要是 `freezeProtocol`），submissions 391 行，vocab 1118 行。`npm test` 405 条通过；`npm run test:jev -- jev-latest` 判重一问照常拿回概率。结构.md 第八部分 vocab、materials、jev 已更新。
 - 任务书 12（flow 第 1 部分：骨架、研究开始、第零轮）：src/flow 11 个文件、775 行（预期 900–1200；实验员、核验员会话接法和多份提交的编号要用到第 2、3 部分才写），materials 1897 行（+29：`finalEntries`、`researcherId`、`StudyRecord`），eval/ 1006 行。`npm test` 418 条通过（新增 flow 下一步 11 条、真 Docker 2 条：研究编号重复报错、docker run 没启动后停下不在本进程重跑）。全新上下文审阅 2.5、2.7 一轮，采纳两条（同上两条测试对应的修复）。真实检验：16-real-1 回放分配与当年完全相同、0 退回；三处杀进程、两份同时跑全部通过。**研究质量未通过**：3 次真实运行（`/home/iomgaa/inforsi-eval/2026-10-03-r0-real-1`、`-2`、`-3`，2、3 被内存回收杀过一次、按正式恢复路径续跑完）第 1、3 问都不通过，入口全体没有 K1（联合优化）；材料核对符合方法.md 4.2，交用户判断。
 - 任务书 13（第零轮重测，提交 a423497 及收尾提交）：三处小改动——研究编号只许小写、`task`/`promptDir` 必须绝对路径（config +22/−7，`npm test` 420 条通过）；检验第 2、6 问每对两个顺序各问一次取平均（eval +35/−17）。用监督者改过的提示词真实跑第零轮 3 次（`/home/iomgaa/inforsi-eval/2026-10-03-r0-v2-1`、`-2`、`-3`，都一次跑完没中断）：**研究质量仍未通过**，3 次第 3 问都不通过（v2-1、v2-3 的 K1 入口没被分出去；v2-2 分出去了，但另一个分到的入口判为只停在 D2；v2-1 分到的一个判为停在 D1、D2，v2-3 一个停在 D1），v2-1 另有第 4、5 问不通过；第 1 问 3 次都通过（入口全体里各有 1 个指向 K1，上次 0/3）。按事先定的规则照实收下，不再调提示词。上次 3 次运行和 16-real-1 回放用新的第 2 问复评在 `2026-10-03-rescore-*`（只有 r0-real-3 第 2 问由不通过变通过）。
-- 任务书 14（flow 第 2 部分：第 r 轮开轮到选批，提交 2c6fdce 提示词、f98d664 代码、a2a1392 eval，以及之后的收尾提交）：提示词按参考项目高分运行第 1 轮的真实记录诊断后改了研究者角色提示词和这一段的六份任务消息（角色提示词 6836→4386 字）。src/flow 1105 行（上限 1700），materials 1910 行（上限 1950，导出 `Board`、讨论原文里作废的入口编号标"（已作废）"），vocab 1132 行；`npm test` 437 条通过。全新上下文审阅一轮（三个程序步骤与恢复），没有会污染账本的问题。3 次真实运行 `/home/iomgaa/inforsi-eval/2026-10-03-r1-v1-kill`、`-r1-v1-a`、`-r1-v1-b` 都停在第 1 轮选批后（原因"实现还没写"），杀进程四条通过；盲评和 Jev 结果在 `/home/iomgaa/inforsi-eval/2026-10-03-r1-compare/`，研究质量（两位盲评，我们 3 次对参考 5 次）：方向一项低 1.1、1.8 分（我们 9 条提案只有 1 条做联合优化、3 条判为停在构造或只改半径的死路，9 条都含固定圆心求半径；参考项目当时的提示词带填圆做法），挑刺、回应、预测、选批持平或略高，多样性、提案质量持平；材料核对符合方法.md 第三部分与 4.3，按事先定的规则不再调提示词。
+- 任务书 14（flow 第 2 部分：第 r 轮开轮到选批，提交 2c6fdce 提示词、f98d664 代码、a2a1392 eval，以及之后的收尾提交）：提示词按参考项目高分运行第 1 轮的真实记录诊断后改了研究者角色提示词和这一段的六份任务消息（角色提示词 6836→4386 字）。src/flow 1105 行（上限 1700），materials 1910 行（上限 1950，导出 `Board`、讨论原文里作废的入口编号标"（已作废）"），vocab 1132 行；`npm test` 437 条通过。全新上下文审阅一轮（三个程序步骤与恢复），没有会污染账本的问题。3 次真实运行 `/home/iomgaa/inforsi-eval/2026-10-03-r1-v1-kill`、`-r1-v1-a`、`-r1-v1-b` 都停在第 1 轮选批后（原因"实现还没写"），杀进程四条通过；盲评和 Jev 结果在 `/home/iomgaa/inforsi-eval/2026-10-03-r1-compare/`，研究质量（两位盲评，我们 3 次对参考 5 次）：方向一项低 1.1、1.8 分（我们 9 条提案只有 1 条做联合优化、3 条判为停在构造或只改半径的死路，9 条都含固定圆心求半径；参考项目当时的提示词带填圆做法），挑刺、回应、预测、选批持平或略高，多样性、提案质量持平；材料核对符合方法.md 第三部分与 4.3，按事先定的规则不再调提示词。监督者核对（2026-10-03）：check、test 437 条重跑通过，账本阶段顺序、冻结时机、不挑自己的提案、杀进程续跑都核过；"9 条只有 1 条做联合优化"是按关键词数的，按路线看 3 次里有 2 次交出能走到最好的完整路线且都入选（b 的 r1-c3、kill 的 r1-c2）；参考项目当时的提示词带填圆做法，方向一项的比较不公平；盲评分数只在执行报告里，磁盘上没有，监督者没核到分值。
 
 ## 关键决定（用户原话见各提交说明）
 
@@ -68,8 +68,11 @@
 - 研究编号只许小写；配置里的路径必须是绝对路径；检验"分没分开"两个顺序都问取平均（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 吧"。
+- 第 1 轮方向分析与提示词第二次改（2026-10-03）：监督者按路线（不按单个想法）读了 6 次运行，能走到最好的那类解法 6/6 次都有人想到，但常被写成备选或"做法类别"之一；18/18 人第一个入口从读基线半径函数出发、按代码工序分工；压低它的理由是"求确定、好归因、怕白跑"，不是技术理由。用户定两处改法，由监督者直接改提示词（ff5c8dd），再写任务书 15 让新会话重跑对照：①正向只管冲分、消融负责解释、估分照实；②先不看代码自己解题，再拆基线工序，两边对照。用户原话："正向实验，就是为了去追求最高的分……你这样实验你可以去冲。然后后面的反向实验有人给你兜底"；"先让他脱离代码……假设自己没有代码的情况之下……列出解法……在思考输出之中把这个解法列一下就好了……然后第二，他需要对现在的解法进行拆解……进行一个综合的分析"；"提示词你直接改，改后后还是写一个任务书让新会话执行"。flow 第 3 部分顺延为任务书 16。
+
 ## 未完成
 
+- 用 Jev 代替研究者押注（用户提，2026-10-03 定这次先不做）：做成开关、可当论文消融。设想只换选批用的那份押注，研究者照旧押、照旧记战绩，两边可比；Jev 一次只给是非概率，三个数要靠问一串"会不会超过某分"反推。先离线检验：参考项目 8 个验收账本里的真实候选、研究者押注和实测分数，比谁排得准。任务书 15 的结果若显示"提案变激进了、但押注仍压低激进路线、选批不选"，就是做它的直接理由。
 - 第零轮之后再看（2026-10-03 定，等部分 2 的数据）：②第一条消息里没有题目本身，要模型自己查 TASK.md，是否由程序放在最前面；③三位研究者拿到完全一样的提示，是否给每人分一个不同的看题路径；④研究者角色提示词每个任务都发全文，是否按任务只发用得到的几节。现状（任务书 14）：角色提示词已瘦身到 4386 字，但仍每个任务整份发。
 - 信念本"按因子归并"（方法.md 6.10 第 1 条"出现在哪些候选里"）：现在是每个候选的每个因子一行，用"（延续 X）"连起来，没合成一行。等真实运行后再看要不要合。
 - Jev 校准：新项目跑出真实研究后，从账本取真实的 Jev 判断和材料，由 Claude 或 GPT 打标签作为校准集和留出集，重新校准九问的问法和阈值。不用参考项目 8 个验收数据库（材料格式还会变）。
@@ -97,4 +100,4 @@
 
 ## 下一步
 
-任务书 14 已完成，等监督者核对。
+任务书 15（提示词改后重测第零轮到第 1 轮选批，按路线对照）已写，等用户另开会话执行。之后 flow 第 3 部分为任务书 16。
diff --git a/docs/结构.md b/docs/结构.md
index f06abdd..4d687c5 100644
--- a/docs/结构.md
+++ b/docs/结构.md
@@ -581,7 +581,7 @@ Jev 是一个判别器，和程序检查地位相同，不单独成一种记录
 
 ### flow
 
-下面是 `src/flow/index.ts` 导出的全部内容，以后 plugin 也只用它。flow 只经各模块的 `index.ts` 用它们；正式代码里没有为检验写的参数、环境变量、回放模式或假实现（CLAUDE.md"测试"）。这一节对应 flow 第 1、2 部分（任务书 12、14）：骨架、研究开始、第零轮，以及第 r 轮从开轮到选批；走到第 r 轮的 `implementation` 停下，原因"实现还没写（任务书 15）"。轮次按"第 r 轮"写，不写死 1；现在走得到的只有第 1 轮。
+下面是 `src/flow/index.ts` 导出的全部内容，以后 plugin 也只用它。flow 只经各模块的 `index.ts` 用它们；正式代码里没有为检验写的参数、环境变量、回放模式或假实现（CLAUDE.md"测试"）。这一节对应 flow 第 1、2 部分（任务书 12、14）：骨架、研究开始、第零轮，以及第 r 轮从开轮到选批；走到第 r 轮的 `implementation` 停下，原因"实现还没写（任务书 16）"。轮次按"第 r 轮"写，不写死 1；现在走得到的只有第 1 轮。
 
 - `runStudy(input)`：推进一份研究，直到停下。输入三样，都必填：研究目录；配置（新研究交 `checkConfig` 检查过的配置，接着跑一份已有的研究写 null，以账本里冻结的那份为准；两者对不上就报错）；"停下"信号。每次启动走同一条路：打开账本；新研究先冻结配置，本机已有 `inforsi-<研究编号>` 的镜像就说明研究编号用过了，报错停下，要换一个编号（编号重复的新研究会把旧研究遗留的同名容器当成自己的运行）；已有研究的，核对冻结的配置、镜像还在、提示词哈希没变（开发入口开着时提示词可以变）；给开始了没结束的模型调用补写结束（出错、"进程中断"、墙钟时间测不到）；按容器名问 Docker 核对登记了没结果的正式运行（没启动的写"没启动"退还名额，启动了的补写确认启动、等它、判分、写结果，问不到的写"状态未知"事件并停下）；然后进主循环：读账本 → 问"下一步做什么" → 做这一步 → 回到开头。主循环里 `docker run` 没启动的，写完"没启动"结果（退还名额、记下 Docker 报错原文）就停下，停下原因带上报错原文，本进程不重跑；下次启动时照旧起新编号重跑。恢复时补写的"没启动"不停下。
 - `StudyInput`（类型）：上面三样输入。
diff --git a/任务书/15-冲分与先想后看-重测.md b/任务书/15-冲分与先想后看-重测.md
new file mode 100644
index 0000000..341c794
--- /dev/null
+++ b/任务书/15-冲分与先想后看-重测.md
@@ -0,0 +1,224 @@
+# 任务书 15：改提示词后重测第零轮到第 1 轮选批，按路线分析对照
+
+这份任务书不写新的正式代码。监督者已经改好了提示词（提交 ff5c8dd），你的事是：
+
+1. 用新提示词真实跑 3 次，从研究开始跑到第 1 轮选批后停下；
+2. 和已有的 6 次运行对照，看研究者选方向的倾向变了没有；
+3. 顺手改一处字样。
+
+本任务书已由用户和监督者在 2026-10-03 一起确定。下面说的"监督者"，是在参考项目目录里和用户讨论设计的另一个会话。
+
+## 一、为什么改提示词
+
+监督者把 6 次真实运行逐份读过：3 次只到第零轮，`/home/iomgaa/inforsi-eval/2026-10-03-r0-v2-{1,2,3}`；3 次到第 1 轮选批，`/home/iomgaa/inforsi-eval/2026-10-03-r1-v1-{a,b,kill}`。读的时候不看某一个想法有没有出现，而看整条路线排在什么位置。
+
+这里说的"能走到最好的路线"指一条完整的解法：
+- 从像样的起点出发（结构化的布局或很多个起点）；
+- 把全部圆心连同半径连续地挪到局部最优；
+- 再做多起点或扰动重来；
+- 最后保证严格合法。
+
+挪圆心的手段不限一种：交给约束优化器一起解是一种，"固定圆心解线性规划、再按对偶方向挪圆心"反复交替也是一种。
+
+看到的现象：
+
+- **这类解法 6 次运行里都有人想到**，但往往排在后面、写成"备选"，或者只是"做法类别"里的一个选项。
+  - 6 次里有 5 次，有人分到了带这类解法的入口；但有的入口从基线那份被压坏的圆心起步，有的只被写成"方法类别与预算怎么花"。
+  - 第 1 轮 3 次里，有 2 次交出了完整的高上限路线，而且都被选中了（b 的 r1-c3、kill 的 r1-c2）。
+- **18 位研究者闭门写的第一个入口，全都是从读基线的半径函数出发。**三个入口的先后几乎总是"半径 → 圆心布局 → 做法类别"，正好对着基线代码的几个函数。讨论时也按这几道工序分工，一人管一道。
+- **压低这类解法的理由几乎都不是技术理由，而是"求确定"。**
+  - 原文："第 1 轮宜小而确定""先把确定的钱落袋""好归因""消融分得开""白烧 1/12 次运行"。
+  - 线性规划的耗时被反复估算，约束优化器的耗时从没人估过。
+  - 研究者三人都说"分数大头在圆心布局"，第一志愿却常常是量尺、评测口径或布局族。
+
+用户据此定了两处改法（2026-10-03，用户原话见 `WORK_LOG.md`"关键决定"），由监督者直接改提示词：
+
+1. **正向只管冲分，消融负责解释。**
+   - 研究者角色提示词开头写明：正向实验选最可能拿到最高分的路，哪怕要换掉整道工序、结果难以预料。冲失败了基线不倒退（采纳规则保底），"为什么"由消融和解释去拆。
+   - 估分照实，不因为方案激进就往高报。
+   - 写入口、讨论、认领、提案的任务提示词跟着改。去掉了"一条就很好""别占掉一次正式运行"这类往保守推的句子。
+2. **先不看代码自己解题，再拆基线工序，最后两边对照。**
+   - 写入口时三步：
+     1. 用 `read_source` 读基线之前，在思考里列出从零写会怎么解、哪种最可能拿最高分（不用交）；
+     2. 读基线，拆成工序；
+     3. 逐道对照。
+   - 提案提示词在第 1 轮让研究者在认领的入口上再做一遍。
+
+另外，消融解释提示词里有一个例子带着填圆的做法，已经换成缓存领域的例子。
+
+**事先定好的规则（用户定，改不得）：**
+- 这次只换了提示词，跑 3 次，结果不管好坏都照实收下。
+- 你不改提示词，不改配置，不改下面附录里的问卷和 Jev 问题。
+- 研究质量不设通过线：这次要的是一份可信的对照，交给用户判断。
+- 用 Jev 代替研究者押注这件事，这次不做（用户定），只留在 WORK_LOG 待办里。
+
+## 开工前先读
+
+- `CLAUDE.md`："测试"一节，尤其是"正式代码和检验代码完全分开"。
+- `任务书/14-flow-2-开轮到选批.md` 第三部分：怎么跑、怎么导出。这次照样用 `npm run r1:run` 跑。
+- 监督者的提示词改动：`git show ff5c8dd`。
+- 监督者留下的对照材料，在 `/home/iomgaa/inforsi-eval/2026-10-03-route-control/`：
+  - `texts/`：6 次运行的第零轮全文（入口、讨论、认领，按书写先后）和第 1 轮提案、两次预测的三个数、选批、第二次预测正文；
+  - `extract.py`：生成这些文本的脚本；
+  - `items.json`、`items.py`：每次运行的最终入口和提案，共 57 条；
+  - `jevroutes.ts`、`jev1.json`：对这 57 条问 Jev 四个问题的脚本和结果；
+  - `mylabels.json`：监督者自己的判断，供监督者核对时用，你不用。
+- `WORK_LOG.md`。
+
+## 二、一处字样
+
+flow 停下的原因现在写"实现还没写（任务书 15）"，在 `src/flow/next-step.ts` 和 `tests/flow-next-step.test.ts`。flow 第 3 部分顺延为任务书 16，这两处改成"实现还没写（任务书 16）"。`docs/结构.md` 里的同一句由监督者改。
+
+## 三、重跑
+
+- 配置照 `eval/round-zero/research.json`，只换研究编号，其余一律不动。三个编号：`r1-v2-a`、`r1-v2-b`、`r1-v2-c`。
+- 每次跑到第 1 轮选批后，按"实现还没写"停下。
+- 中途出错先查原因：
+  - 是程序的毛病，按 CLAUDE.md 修了重跑，修了什么写进报告；
+  - 是服务一时调不通，接着跑（`node eval/lib/cli.ts --resume --dir <研究目录>`）。
+- 不杀进程，不跑回放。
+
+## 四、对照分析
+
+对照组是已有的 6 次运行，实验组是这次的 3 次。分析都写在 `eval/` 下的新目录 `eval/route/`，产出放 `/home/iomgaa/inforsi-eval/` 下。
+
+### 4.1 导出文本
+
+- 把 `extract.py` 移植进 `eval/route/`，可以用 TypeScript 重写，也可以照原样。
+- 对新的 3 次运行导出同样格式的文本。
+- 对 6 次对照运行也用你移植后的版本重新导出一遍，和 `texts/` 里的逐字比对。不一致说明移植有误，先修好再往下做。
+
+### 4.2 逐份阅读
+
+- 9 次运行，每次派一个全新上下文的子 Agent，用附录一的问卷读全文、带原文引用回答。对照组也重新读一遍，保证两组用的是同一种读法。
+- 子 Agent 不写文件，直接回复；你把 9 份回复原样存进产出目录。
+- 子 Agent 只给文本路径，不告诉它是哪一组、提示词改过什么。
+
+### 4.3 Jev
+
+用 `jevroutes.ts` 的四个问题，问的方式和阈值都不改，对 9 次运行的全部最终入口和提案各问一次。对照组也重问，不用 `jev1.json` 的旧结果：同一组问题隔一段时间再问，概率会有浮动，重问以后两组的结果才能比。要花钱。
+
+### 4.4 思考核查
+
+新提示词要求研究者先在思考里自己解题，再读基线代码。研究目录 `calls/<调用>/sessions/` 下的会话文件存着模型的思考和工具调用。新的 3 次运行里：
+- 每个"闭门写入口"调用；
+- 每个第 1 轮提案调用。
+
+每个调用查三件事：
+1. 第一次调用 `read_source` 读基线代码之前，思考里有没有列出几种从零写的解法；
+2. 列了几种，各是什么，一句话一个；
+3. 它判为最可能拿最高分的是哪一种。
+
+列成表，每格附原文短引用。对照组也查第一件事，看改之前本来就有多少人先想再读。
+
+### 4.5 要交的对照表（事先登记，改不得）
+
+每次运行一行，9 行，标明组别：
+
+| 列 | 说明 |
+|---|---|
+| A | 闭门写的第一个入口从基线某段代码出发的人数（共 3 人） |
+| B | 能走到最好的路线有没有出现在最终入口里 |
+| C | 这类入口在每人志愿里最早排第几 |
+| D | 有没有人分到这类入口 |
+| E | 第 1 轮有没有这类完整路线的提案；有的话入选没有 |
+| F | 各候选第二次预测合并后的一半那个数和九成那个数 |
+| G | 最终入口和提案里，Jev"做好了能不能到最好的 1% 以内"判"是"的条数 / 总条数 |
+| H | 同上，Jev"相对基线算不算激进"判"是"的条数 / 总条数 |
+| I | 讨论里出现"求确定""好归因""先做稳的一步"这类理由的次数，附出处 |
+| J | 思考核查第一件事：先想后读的调用数 / 调用数 |
+
+- A 到 F 和 I 由你按 9 份阅读回复填，回复之间有出入的，回原文核实。
+- 第零轮只到认领的对照运行，E、F 填"无第 1 轮"。
+
+另附一张表：新的 3 次运行，每条最终入口和每条提案的名称、路线代号、Jev 四个概率。
+
+## 五、测试与规模
+
+- `npm run check`、`npm test` 通过。
+- 正式代码只改第二部分那一处字样。
+- `eval/route/` 预期 300–500 行。
+
+## 六、文档
+
+- `WORK_LOG.md`："已完成"补一条，写明 3 次运行的目录、对照表所在位置和主要结果。
+- 不新建 md 文件。
+
+## 七、验收与报告
+
+做完后本地提交，然后在回复里交一份报告：
+
+1. 提交号；修改的文件，分 `src/`、`tests/`、`eval/` 列。
+2. `npm run check`、`npm test` 的完整输出。
+3. 3 次运行的研究目录、停下原因、出过什么错和怎么处理的。
+4. 4.1 移植后重新导出与 `texts/` 逐字比对的结果。
+5. 4.5 的对照表和附表。
+6. 4.4 思考核查的表。
+7. 新的 3 次运行，每次的最终入口名称、分配结果、第 1 轮提案名称、判重、入选，各一行。全文给路径。
+8. 你读下来觉得新旧两组最大的不同在哪里，最可能被误读的地方在哪里。只写有原文支撑的，推断标"（推断）"。
+9. 你和这份任务书不一致的地方，以及为什么。
+10. **规则不清楚的地方**：哪里让你犹豫、哪里你是靠猜的。没有就写"没有"。
+11. 正式代码和检验代码分开的自查，逐条写"做到了"或"没做到、为什么"。
+
+## 附录一：阅读问卷（原样发给子 Agent，只替换"文件"一行）
+
+> 你在帮一位科研监督者分析一次自动化科研系统的真实运行记录。不要写任何文件，结论直接用中文回复给我。
+>
+> **背景**
+>
+> 三位 AI 研究者（同一个模型）在研究一道题：单位正方形里放 26 个互不重叠的圆，最大化半径之和。基线程序得分 0.9598（圆心用同心环构造、被 clip 压到边上、半径用逐对缩放分），已知最好 2.635983。
+>
+> 研究先有"第零轮"：每人闭门写 2–3 个"入口"（从哪里开始看）→ 两次讨论分工（可整份换入口）→ 每人排志愿、程序分配入口。部分运行还继续了第 1 轮：每人交提案 → 第一次预测 → 挑刺 → 回应 → 第二次预测（三个数 q1/q5/q9 = 一成/一半/九成可能低于的分数）→ 程序选批（最多选 2 个跑）。
+>
+> 文件：〈文本路径〉（没有第 1 轮的，第 5 题写"无第 1 轮"）
+> （全文用 Read 读，分段读完，别只看开头。）
+>
+> **路线分类（用这些代号归类）**
+>
+> - R-NLP：把全部圆心和半径（78 个数）一起交给连续约束优化器（SLSQP、罚函数梯度等）。
+> - R-SLP：固定圆心解 LP 得半径，再用 LP 对偶/敏感度指引挪圆心，交替或序列线性化。
+> - R-PHYS：生长式/物理式模拟，圆互相推开、慢慢长大。
+> - R-FAM：结构化布局族（网格、六角、行式、环）做参数扫描，半径用 LP 或构造给，圆心不做连续移动。
+> - R-LP：只在给定圆心上把半径分配做到最优（作为整条路线，不是作为某路线的部件）。
+> - R-GREEDY：往空隙里贪心塞圆。
+> - R-SEARCH：多起点、扰动、重启这类外层搜索（可与上面组合）。
+> - R-OTHER：评测口径、预算框架、几何分析、量尺诊断等不直接产出更好答案的。
+>
+> 一条入口或提案可以涉及多个代号，写主代号加部件代号。
+>
+> **要回答的问题**（每条尽量附原文短引用，≤60 字，注明作者和大致行号）
+>
+> 1. 闭门写入口：每位研究者按书写先后列出入口，标路线代号；有没有自贴的"主/备选/兜底"标签；每人的第一个入口是不是从基线的某段代码出发。
+> 2. 讨论：
+>    - a. 每份讨论里，作者认为"哪条路走对了收益最大"，原文怎么说。
+>    - b. 谈到 R-NLP、R-SLP 时，支持或压低它们的理由（预算 120 秒单核、非凸局部最优、容差为 0 的合法性、实现复杂、不好归因/测量等），原文引用。
+>    - c. 分工最终是按什么分的：按"层"（半径层/圆心层/搜索层）还是按完整路线？有没有人指出"层"不是独立路线、单做某一层到不了好答案？
+>    - d. 换入口时，换的方向是更保守还是更激进。
+> 3. 有没有人写出一条"完整解法"（起点从哪来 + 怎样把全部圆连续改进到局部最优 + 多起点或扰动 + 最后保证合法），它被放在什么位置（主/备选/没人认领）？
+> 4. 最终入口与志愿：每条最终入口的路线代号和标签；每位研究者的志愿里，R-NLP / R-SLP / R-FAM / R-LP 各自第一次出现在第几位；最后分到了什么。
+> 5. 第 1 轮（若有）：
+>    - 每条提案的路线；
+>    - 各候选的第二次预测合并范围；
+>    - 研究者是否预期 R-NLP/R-SLP 高于或低于 R-FAM；
+>    - 第二次预测正文里关于"上限""平台""局部最优""风险"的判断原文；
+>    - 哪些被选中；
+>    - 提案相对认领的入口，是更保守还是更激进了。
+> 6. 风险倾向：研究者是偏保守（先做确定能涨、可测、好归因的一步）还是偏激进（直接换掉核心做法、押大收益）？给出证据原文。有没有人明确说出自己在押注或在求稳？
+> 7. 你觉得还有什么更深层的模式值得监督者注意（比如对某路线代价的误判、对上限的认识、把"量尺/诊断"当成提案、被基线代码牵着走等），给证据。
+>
+> 回复控制在 1800 字以内，按上面 7 个问题分节。只陈述文件里有的东西，推断要标"（推断）"。
+
+## 附录二：Jev 四问
+
+问题原文和判"是""否"的说明，以 `/home/iomgaa/inforsi-eval/2026-10-03-route-control/jevroutes.ts` 为准，原样搬进 `eval/route/`。四问：
+
+- **bold**：相对基线程序，是不是激进的方向：换掉产出答案的核心做法，结果很不确定。
+- **standard**：在数值优化行家眼里，这是不是这类填装问题常规、通常可靠的做法。
+- **reach**：在 120 秒单核内认真做下去，能不能到已知最好 2.635983 的 1% 以内。
+- **complete**：是不是一条本身就能产出最终答案的完整路线，而不是一个部件、一次测量或一个框架问题。
+
+对 `jevroutes.ts` 只改文件路径：
+- 读 `items.json` 的位置；
+- `import` Jev 客户端的路径，改成仓库里 `eval/lib/jev.ts` 的相对路径。
+
+阈值一律 0.5，原始概率全部存下。