eval: 准备正向采纳的真实运行恢复与质量评估

新增单份串行启动入口、首个正向运行杀进程恢复证据、逐候选审阅导出与账目统计；参考只读副本分数对照。456项免费测试通过，尚未启动三份真实验收。同步结构说明与当前工作状态。

docs/结构.md

@@ -3,6 +3,7 @@
 这份文件说明代码分成哪些模块、模块之间怎么依赖、流程按什么步骤推进、账本记哪些记录。研究方法本身以 `docs/方法.md` 为准；这里只说代码怎么组织来实现它。
 
 来源：
+
 - 用户 2026-10-01 认可"按负责一件事来切"、下面这套模块与可替换点，以及步骤清单和账本记录种类。
 - 用户 2026-10-01 同意：提交的字段定义放 vocab，submissions 只判收不收；vocab 可放规范序列化和哈希两个函数，上限调到 600 行；执行后实际 1030 行，用户同意上限改为 1100 行；任务书 09 加对号清单时用户 2026-10-03 同意改为 1150 行，vocab 只放对号清单，任务材料的其余类型放 materials。
 - 用户 2026-10-02 同意："全部只追加"：账本用一张只追加的表，全部记录都不能改。
@@ -32,7 +33,7 @@
 ## 二、模块
 
 | 层 | 模块 | 藏住的决定 | 依赖 |
-|---|---|---|---|
+| --- | --- | --- | --- |
 | 入口 | plugin（插件入口） | 用户在 Pi 里怎么操作：命令、状态显示、配置对话；文件锁；把各模块装配起来 | 装配时用到各模块 |
 | 组织 | flow（流程） | 按步骤清单推进研究；每次启动走同一条恢复路径 | ledger、rules、materials、submissions、agents、runner、tasks、workspace、config、jev |
 | 组织 | export（导出） | 导出给人看的格式 | ledger、rules、materials |
@@ -114,13 +115,14 @@
 用户 2026-10-03 定：参考项目的 flow 太长、很难验证（用户原话："我觉得我们之前其实很多问题都是 flow 没有做好"），所以拆成四部分，一部分验证通过后再写下一部分，每部分一份任务书。
 
 | 部分 | 管哪些步骤 | 自己的验证目标 | 拿哪份真实记录对照 |
-|---|---|---|---|
+| --- | --- | --- | --- |
 | 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，当四部分合起来的验收 |
 
 **怎么验证**（用户 2026-10-03 定）：一律用真 Jev、真 Docker，不做假的 Jev、Docker、任务，flow 不为此开替换口子。同样的输入真实跑几次，结果都符合要求就算通过；真实运行里没出现过的情况不专门造出来测。用户原话："我建议用一律用真 Jev、真 Docker。因为其实我们现在是在做科学研究，不是在开发程序……我们只需要重复运行多次"。模型一侧两种都做：
+
 - 回放：用本机假模型服务，把参考项目真实记录里模型交的东西按原顺序转成新格式再交一遍，走真实的 Pi。新 Jev 的判断可能和当时不同，两边走向分开以后不再对照，按方法判断分开的地方谁对。
 - 真模型：用配置里的模型真实跑几次。
 
@@ -137,7 +139,7 @@
 恢复时只核对、不重做写入（CLAUDE.md"中断后怎么恢复"），所以记录照写就是，不需要通用的去重。有自己编号、按定义只发生一次的记录，按编号加数据库唯一约束，重复了就报错：阶段开、阶段关、运行登记、确认启动、运行结果、模型调用开始、模型调用结束、消融结算（按轮次：每轮最多采纳一个改法，所以最多一次消融）。没有这种编号的记录（提交的各个版本、事件、用量）照写。前后顺序（比如启动前要先登记）由 flow 的同一个入口保证，ledger 不查。运行编号由 flow 起；确认没启动、退还名额后要重试，就起一个新编号。
 
 | # | 记录 | 内容 | 谁写入 |
-|---|---|---|---|
+| --- | --- | --- | --- |
 | 1 | 研究配置 | 冻结的配置、步骤清单、每个决策点用哪条规则、方法参数、提示词哈希 | flow（内容由 config 生成） |
 | 2 | 阶段 | 每个阶段开一条、关一条；关闭即公开 | flow |
 | 3 | 提交 | 各种提交的每一版：入口、讨论、志愿、提案、两次预测、挑刺、回应、解释、收尾、实现、核验：阶段关闭后以最后一版为准，此后由 ledger 拒绝再写。私人笔记的每一条：不属于任何阶段，以最后写入的一条为准。每一版带收下时用到的 Jev 判断（含原始概率和结论，没用到 Jev 的为空）。被退回的提交也记，附对象（同提交的 target：候选、原提案或消融格，没有对象的为空）、退回理由和用到的 Jev 判断 | flow（经 submissions 判定后） |
@@ -161,7 +163,7 @@ Jev 是一个判别器，和程序检查地位相同，不单独成一种记录
 论文实验要换掉的部件，按种类用最轻的办法换：
 
 | 种类 | 例子 | 换法 |
-|---|---|---|
+| --- | --- | --- |
 | 外部服务 | Pi 会话、Docker 运行器、任务、Jev | 接口 |
 | 决策规则 | 选批：批内最好期望、均匀随机。选格：信息价值减成本、全测、随机同格数、都不测。以后可能加合并方式 | 纯函数，登记在 rules 里的"名字 → 函数"表里，配置写名字 |
 | 方法参数 | N、M、批量、运行次数、因子数上限、u、衰减、开放预留 | 配置值，不写成常数，也不用环境变量，每个都必须写在配置文件里。分两层：用户配置（配置对话逐项问）；方法参数（做实验时才改，配置对话按方法.md 6.11 的现行值写进文件、给用户看过） |
@@ -198,7 +200,7 @@ Jev 是一个判别器，和程序检查地位相同，不单独成一种记录
 下表是粗估。动手写某个模块之前，由用户逐个确认；写的过程中超过预期一倍，就停下来检查。
 
 | 模块 | 预期行数 |
-|---|---|
+| --- | --- |
 | plugin | 600–1000 |
 | config | 300–600 |
 | flow | 2000–3500 |
@@ -529,6 +531,7 @@ Jev 是一个判别器，和程序检查地位相同，不单独成一种记录
   - 消融实现：这一格已有公开的消融核验（核验不通过、重做）时，和修复一样从上一次交的这一格代码接着改（用户 2026-10-03 定）：工作目录写"上一次交的这一格代码的副本"，能读的版本里加上它，完整代码照旧列出作对照；另放"退回意见"：最近一次核验里关错了的因子和核验员写的依据，写法同修复的退回意见。
   - 指标：冻结之后一律用全名"候选编号.短名"：已登记指标清单、对号清单的 `reusableMetrics`、实验员材料的"要实现的指标定义"（候选代码在结果文件里也用全名当键）。提案、回应、统一的对号清单里，已占用的指标编号只有任务的指标、`answer-path` 和 `safeguard-triggers` 两个保留键（用户 2026-10-03 定）；已登记的全名带 `.`，新登记的短名不带，不用列进来。
 - `Board`（类）：materials 读账本的那一份，构造参数是账本记录数组。flow 的"下一步做什么"是只拿得到记录数组的纯函数，它和 flow 的三个程序步骤都经这一份读账本，不另写一份（任务书 14 第 2.4 节）。flow 用到的：`stages`、`stage`（阶段的轮次、名单、关没关）、`published`（已公开的某种提交，最后一版为准）、`decision`（某轮某种决定）、`proposal`、`proposalsOf`、`authorsOf`（候选合并了哪些原提案、作者按编号排）、`answerOf`（冻结出候选的最后一份回应或统一）、`protocol`、`protocols`、`carried`（留池候选）、`baselineOf`（第 r 轮的本批基线）、`baselineScore`、`runStates`。任务书 14 写的是导出 `baselineOf`、`baselineScore` 两个函数，实际导出了整个类，原因是纯函数只拿得到记录数组，要用的远不止这两样（这一处偏离待用户确认）。
+- `protocolMetrics(board, protocol)`：把冻结协议自定义及引用的指标合成原登记定义，实验员材料与 flow 问 Jev、正式运行共用（来源：任务书 16 第 2.2、2.4 节）。
 - `finalEntries(ledger)`：按账本取的最终有效的入口（各人最后一版入口清单里的每个入口，带作者和正文）；flow 分配入口时用，和认领的对号清单是同一份（任务书 12 第三部分）。
 - `queryMaterial(material, id)`：只在这份材料的记录里按编号找，交回全文；找不到交回 null（agents 的查询回调据此答"看不到"）。
 - `readPrompts(dir)`：读 `roles/<角色>.md` 和 `tasks/<提交种类>.md`，交回文字和每个文件原始字节的 sha256；研究开始时 flow 把哈希冻结进研究配置记录（方法.md 4.1）。
@@ -537,6 +540,8 @@ Jev 是一个判别器，和程序检查地位相同，不单独成一种记录
 - `TaskRequest`、`StudyFacts`、`CodeChanges`、`Prompts`、`PromptFile`（类型）：flow 传进来的东西，全部必填；`CodeChanges` 与 workspace 的比较结果同形（照 jev `codeHunks` 的先例，不引用 workspace）。
 - 账本里只存成 Json 的内容的形状（用户 2026-10-03 决定 2：materials 定义，flow 照着写，ledger 不改）：`StudyRecord`（研究配置记录：配置、步骤清单、提示词每个文件的哈希、镜像编号、任务事实、种子；配置和任务事实存 Json，flow 读回时用 `checkConfig`、`checkTaskFacts` 再检查，任务书 12 第三部分）、`FrozenProtocol`（冻结协议：方法.md 4.3 ⑥ 列的因子、保障、指标、正文、实现条款，加轮次、出发的基线、合并了哪些原提案；不带答复，主体由 submissions 的 `protocolBody` 拼，指标编号是全名）、`LocationTable`（代码记录的位置表）、`DecisionKind`、`DECISION_KINDS`、`DecisionShapes`（六种决定：入口分配、判重合并、选批、采纳、选格、押的因子，输入输出用 rules 的类型；没采纳时也写一条采纳决定）、`DedupOutput`（判重合并的输出）、`Settlement`（结算）。
 - `freezeProtocol(body, candidate, round, baseline, proposals)`：flow 写冻结协议时调用。输入 submissions 交回的冻结协议主体、候选编号、轮次、基线、合并了哪些原提案，交回 `FrozenProtocol`；新登记的假设专用指标改用全名"候选编号.短名"（例如 `r2-c1.restart-gain`），引用的本来就是全名，照抄。加前缀只在这一处：同一轮的研究者互相看不到提案，会起同一个短名、定义却不同，候选编号判重合并之后才有，所以只能在冻结时加（用户 2026-10-03 定）。
+- `experimenterId(candidate)`、`verifierId(candidate)`：每个候选固定一位实验员、一位核验员，修复及再次核验沿用编号（来源：任务书 16 第 2.4 节）。
+- `FORWARD_NOT_RUN`、`forwardNotRunEvent(候选, 原因)`：正向候选修复用完仍未通过核验时的“不跑”事件，`objects` 只有该候选；不扣次（来源：任务书 16 第 2.2 节）。
 - 事件：`CELL_NOT_RUN`、`cellNotRunEvent(格, 原因)`：一格消融核验不通过、重做次数用完而不跑时，flow 用它写事件记录（`objects` 只有这一格），结算记证据不足（方法.md 4.3 ⑯、6.6）。
 - 编号规则：`ORIGINAL_BASELINE`、`researcherId`（第 i 位研究者，从 0 数，编号 `researcher-<i+1>`，任务书 12 第三部分）、`entryId`、`proposalId`、`critiqueId`、`candidateId`、`factorId`、`cellId`、`splitCell`、`explanationId`、`callId`，以及协议内的局部编号 `factorKey`（p1…）、`clauseKey`（c1…）。入口编号按作者一直往后编，讨论时整份替换也不复用旧编号。
 
@@ -581,7 +586,7 @@ Jev 是一个判别器，和程序检查地位相同，不单独成一种记录
 
 ### flow
 
-下面是 `src/flow/index.ts` 导出的全部内容，以后 plugin 也只用它。flow 只经各模块的 `index.ts` 用它们；正式代码里没有为检验写的参数、环境变量、回放模式或假实现（CLAUDE.md"测试"）。这一节对应 flow 第 1、2 部分（任务书 12、14）：骨架、研究开始、第零轮，以及第 r 轮从开轮到选批；走到第 r 轮的 `implementation` 停下，原因"实现还没写（任务书 16）"。轮次按"第 r 轮"写，不写死 1；现在走得到的只有第 1 轮。
+下面是 `src/flow/index.ts` 导出的全部内容，以后 plugin 也只用它。flow 只经各模块的 `index.ts` 用它们；正式代码里没有为检验写的参数、环境变量、回放模式或假实现（CLAUDE.md"测试"）。这一节对应 flow 第 1–3 部分（任务书 12、14、16）：骨架、研究开始、第零轮，以及第 r 轮从开轮到采纳；采纳决定写完后走到 `listCells` 停下，原因"消融还没写（任务书 17）"。轮次按"第 r 轮"写，不写死 1；现在走得到的只有第 1 轮。
 
 - `runStudy(input)`：推进一份研究，直到停下。输入三样，都必填：研究目录；配置（新研究交 `checkConfig` 检查过的配置，接着跑一份已有的研究写 null，以账本里冻结的那份为准；两者对不上就报错）；"停下"信号。每次启动走同一条路：打开账本；新研究先冻结配置，本机已有 `inforsi-<研究编号>` 的镜像就说明研究编号用过了，报错停下，要换一个编号（编号重复的新研究会把旧研究遗留的同名容器当成自己的运行）；已有研究的，核对冻结的配置、镜像还在、提示词哈希没变（开发入口开着时提示词可以变）；给开始了没结束的模型调用补写结束（出错、"进程中断"、墙钟时间测不到）；按容器名问 Docker 核对登记了没结果的正式运行（没启动的写"没启动"退还名额，启动了的补写确认启动、等它、判分、写结果，问不到的写"状态未知"事件并停下）；然后进主循环：读账本 → 问"下一步做什么" → 做这一步 → 回到开头。主循环里 `docker run` 没启动的，写完"没启动"结果（退还名额、记下 Docker 报错原文）就停下，停下原因带上报错原文，本进程不重跑；下次启动时照旧起新编号重跑。恢复时补写的"没启动"不停下。
 - `StudyInput`（类型）：上面三样输入。
@@ -589,10 +594,10 @@ Jev 是一个判别器，和程序检查地位相同，不单独成一种记录
 
 研究目录里放：`ledger.sqlite` 账本；`repo.git` 代码版本的裸仓库；`runs/<运行编号>/` 一次正式运行（取出的代码、运行目录、日志、判分目录、校验器日志）；`calls/<调用编号>/` 一次模型调用（工作目录、会话文件、能读的代码版本）。取出代码、建运行目录和判分目录时目标都是新建的空目录。容器名 `inforsi-<研究编号>-<运行编号>`，判分容器另加 `-judge`。同一份研究的全部运行用同一个种子：研究编号经 vocab 的 `hash` 取前 8 位十六进制转成整数，冻结进研究配置记录。
 
-**每一步以哪条记录为准算做完**（任务书 12 第 2.2 节、任务书 14 第 2.2 节）。步骤的先后只写在 flow 的"下一步做什么"一个纯函数里；后面两部分每加一步，这张表加一行。做完的轮次整轮跳过，第一个没做完的轮次里第一个没做完的步骤就是下一步。
+**每一步以哪条记录为准算做完**（任务书 12 第 2.2 节、任务书 14 第 2.2 节、任务书 16 第 2.3 节）。步骤的先后只写在 flow 的"下一步做什么"一个纯函数里；后续每加一步，这张表加一行。做完的轮次整轮跳过，第一个没做完的轮次里第一个没做完的步骤就是下一步。
 
 | 步骤（config 的 `STUDY_STEPS`、`ROUND_STEPS`） | 看到哪条记录算做完 |
-|---|---|
+| --- | --- |
 | `freezeConfig` 冻结配置 | 研究配置记录（`config`） |
 | `baselineRun` 基线 | 基线代码记录（`code`，对象是 materials 的 `ORIGINAL_BASELINE`），而且最近一次基线运行的结果不是"没启动"；"没启动"的下次启动时起新编号（`base-2`……）重跑，判为不算数的停下 |
 | `entryDraft`、`discussion1`、`discussion2`、`claim` | 这个阶段的关闭记录（`stageClose`）；阶段编号 `r0-<步骤>` |
@@ -602,24 +607,32 @@ Jev 是一个判别器，和程序检查地位相同，不单独成一种记录
 | `dedupe` 判重合并 | 本轮的判重合并决定（`decision`，种类 `dedup`） |
 | `freezeProtocol` 冻结协议 | 本轮每个新候选都有冻结协议记录（`protocol`）；全部候选在同一个事务里写 |
 | `selectBatch` 选批 | 本轮的选批决定（`decision`，种类 `batch`） |
+| `implementation` | 这一轮实现阶段的关闭记录 |
+| `verification`、`repair` | 每个入选候选最近一次核验通过，或修复次数用完且有“不跑”事件；中间每次核验、修复阶段各有开关记录 |
+| `forwardRun` | 每个通过核验的候选最近一次正向运行有结果，而且不是“没启动” |
+| `publish`、`informationAccount` | 不写记录：`forwardRun` 做完就算做完；公开靠本轮采纳决定，信息账从预测和结果现算 |
+| `adopt` | 本轮的采纳决定（`decision`，种类 `adopt`），没有过线者也写，`adopted` 为 null |
 | 按配置跳过的步骤 | 一条"按配置跳过"事件（`skippedByConfig`），写明步骤（第 r 轮的步骤写 `r<轮>-<步骤>`）和 config 给的原因 |
 
 研究者阶段没开就开，名单是全部研究者（本轮名单就是冻结的配置）；每个任务都有被收下的提交之后才关。
 
-**每个阶段谁做、对哪个对象**（任务书 14 第 2.3 节）。一个任务就是"一个人对一个对象"，交一种提交。同一阶段里，一个人的几个任务按下表列出的先后在一个接一个的会话里跑，不同的人同时跑（任务书 12 第 2.6 节）。一个任务做完，以"这个人在这个阶段对这个对象有一份被收下的提交"为准。
+**每个阶段谁做、对哪个对象**（任务书 14 第 2.3 节、任务书 16 第 2.2、2.4 节）。一个任务就是"一个人对一个对象"，交一种提交。同一阶段里，一个人的几个任务按下表列出的先后在一个接一个的会话里跑，不同的人同时跑（任务书 12 第 2.6 节）。一个任务做完，以"这个人在这个阶段对这个对象有一份被收下的提交"为准。
 
 | 阶段 | 任务 | 对象 |
-|---|---|---|
+| --- | --- | --- |
 | 第零轮的写入口、两次讨论、认领 | 每位研究者一个任务 | 无 |
 | 提案 | 每位研究者一个任务，一个会话里交 1 到 M 条 | 无 |
 | 第一次预测 | 每位研究者 × 本轮每个新候选（含自己的；留池候选不做，方法.md 4.3 ④） | 候选 |
 | 挑刺 | 每位研究者 × 本轮每条不是自己写的原提案（监督者定，照参考项目：方法没写谁挑谁） | 原提案 |
 | 回应与统一 | 每个新候选一个任务：只有一条原提案的，由作者交"回应"；几条合成的，由其中研究者编号最小的作者交"统一"（方法.md 4.3 ③⑥） | 候选 |
 | 第二次预测 | 每位研究者 × 候选池里每个候选（新候选加留池候选，方法.md 4.3 ①⑦） | 候选 |
+| 实现 | 每个入选候选一个实验员，从本批基线取工作目录，不同候选同时实现 | 候选 |
+| 核验 | 每个待核验候选一个核验员；首次核验本批全部，之后只核验刚修复的候选 | 候选 |
+| 修复 | 只给核验不通过的候选，交原实验员，从上次提交的代码接着改 | 候选 |
 
 没做完的任务派不派，按这个任务最近一次调用怎么结束的来定（任务书 12 第 2.3 节；第 2 部分从"一个人"细到"一个人对一个对象"，任务书 14 第 2.3 节）。认是哪个任务，看"模型调用开始"里存的材料带的对象。没有调用、被用户停下、出错（含"进程中断"）都派；没交的，开发入口关着就停下（交不出合格提交按内部错误，方法.md 4.3 ②），开着就再派。能派的先全派。一次派发里有任务没交上（没交或出错），不再开新的会话，已经在跑的不打断，等这次派发的会话全部结束后停下。
 
-一个任务交上来之后才知道的东西（submissions 的 `known`，任务书 14 第 2.3 节）：提案是本人在本阶段已经收下几条（替换时不算被替换的那份）；回应是作者那条原提案；其余种类没有。
+一个任务交上来之后才知道的东西（submissions 的 `known`，任务书 14 第 2.3 节）：提案是本人在本阶段已经收下几条（替换时不算被替换的那份）；回应是作者那条原提案；实现、修复交代码快照结果（见下文）；其余种类没有。
 
 提案和挑刺一个任务可以交几份，每份一个编号：提案用 materials 的 `proposalId`（轮次、作者、第几份），挑刺用 `critiqueId`（目标原提案、作者、第几份），收下时由 flow 按这个任务已收下几份往后分配，回给模型的提交编号就是它（任务书 14 第 2.3 节）。只交一份的种类，提交编号是"阶段.本人.种类.对象"。不写 `replaces` 是交新的一份，只交一份的种类已经交过就退回；写了 `replaces`，必须是这个任务已收下的某一份，整份替换它。
 
@@ -641,10 +654,19 @@ Jev 是一个判别器，和程序检查地位相同，不单独成一种记录
   - 种子用 rules 的 `decisionSeed`，由研究编号、轮次、版本算。同一轮里要随机的决定各用一个版本，选批用 1，选格预留 2，两次抽取不会用同一串随机数（方法.md 第九部分；选格由第 4 部分接上）。
   - 规则取步骤清单里 `selectBatch` 那一步的，调 `runBatchRule`。写一条决定：种类 `batch`，规则名、版本和参数取 `runBatchRule` 交回的。
 
+**实现、核验、修复与采纳**（来源：任务书 16 第 2.2–2.4 节）：
+
+- 阶段编号：`r<轮>-implementation`、`r<轮>-verification-1`、`r<轮>-repair-1`、`r<轮>-verification-2`……第几次从账本数，不另存。实现阶段关后才核验，核验阶段关后才派修复。修复次数用完仍不通过，用 `forwardNotRunEvent` 写清原因，不登记运行、不扣次。
+- 角色各取配置中的模型及自己的角色提示词。实验员工作目录先取版本，提交时用 workspace 存版本；相对本批基线比较、用 `codeHunks` 切块、查 `protectedChanges`，拼成 submissions 的 `known.code`。收下的提交和代码版本、位置表在同一事务写入；指标引用用 `protocolMetrics` 换成原登记定义。
+- 核验及修复材料的 `changes` 都相对本批基线：修复看基线到上次提交，修后核验看基线到修复结果；不新增上次到此次的材料。核验通过与否用 `verificationOutcome` 判。
+- 实验员的轻量检查接 `SessionTask.lightCheck`：tasks 给定义、runner 执行、tasks 读结果；每次模型调用分别按 `lightChecks.maxCount` 计次、按 `seconds` 限时，会话保留记录，不记入正式运行账本。
+- 通过核验的候选用既有 `formalRun`，用途 `forward`；先登记占名额，确认启动才扣次，再独立判分记结果。**一批内一个接一个跑**，避免抢 CPU 改变按秒停下的程序成绩。没启动的处理同基线：本进程停下，下次启动起新编号。
+- 本批全部有结果或“不跑”事件后，用 rules 的 `adopt`（内部用 `adoptionLine`），只传有效实测分数、本批基线分数和任务的方向、ε、已知最好；写种类 `adopt` 的决定，即使 `adopted` 为 null 也写。materials 据此公开本轮正向运行。
+
 检验命令（`eval/`，真实运行，要 Docker；带 `*` 的会花模型或 Jev 的钱。输出都在仓库外 `/home/iomgaa/inforsi-eval/<日期-名字>/`，名字也当研究编号用，只能小写、不能重复）：
 
 | 命令 | 用途 |
-|---|---|
+| --- | --- |
 | `npm run eval:study -- --config <文件> --dir <目录>`、`-- --resume --dir <目录>` * | 起一份研究或接着跑，Ctrl-C 发停下信号 |
 | `npm run eval:r0:run -- <名字>` * | 用 `eval/round-zero/research.json` 真实跑一次第零轮 |
 | `npm run eval:r0:quality -- <检验目录>` * | 对第零轮产出问六问（任务书 12 第 5.2 节），原始概率写进 `<检验目录>/quality.json` |
@@ -659,3 +681,14 @@ Jev 是一个判别器，和程序检查地位相同，不单独成一种记录
 | `npm run eval:r1:jevcheck -- <检验目录>` * | 对每次导出的运行问 Jev 三类问题（任务书 14 第 3.2 节第 3 步）：判重对不对、挑刺有没有被回应、提案对应研究路径的哪一步；原始概率写进 `jevcheck.json` |
 | `npm run eval:r1:stats -- <检验目录>...` | 第 1 轮的数字和过程（任务书 14 第 3.2 节第 4 步），另查阶段开关成对、冻结协议写在回应阶段关闭之后、停下原因是"实现还没写"；每个目录写一份 `stats.json` |
 
+任务书 16 新增检验命令（来源：任务书 16 第三、四、五部分）：
+
+| 命令 | 用途 |
+| --- | --- |
+| `npm run eval:forward:run -- new <研究编号> <全新绝对输出目录>` * | 配置照 `eval/round-zero/research.json`，只换编号；一份研究跑到采纳后停下，记录进程起止、账本观察时间及机器快照；异常保留现场并停下 |
+| `npm run eval:forward:run -- kill <研究编号> <全新绝对输出目录>` * | 同上；首个正向 `runStarted` 后、无结果且容器仍运行时杀控制进程，保存容器 ID 和启动时间，恢复同份一次，不另开研究 |
+| `npm run eval:forward:run -- resume <研究编号> <原输出目录>` * | 查明服务错误后手动续跑同份，追加进程/观察记录；也可用 `eval:study -- --resume --dir <输出目录>/study` |
+| `npm run eval:forward:export -- <研究目录> <全新绝对审阅目录>` | 候选协议全文、引用指标定义、基线/最终/各次代码、位置表及 concerns、每次核验/修复、退回与调用材料、会话位置 |
+| `npm run eval:forward:stats -- <全新绝对统计目录> <参考副本根目录> <检验目录>...` | 五项表中的可计算字段：预测与实测、参考首轮成绩、核验/修复次数、账目、轻量检查、杀进程三项检查；不自动作质量判断 |
+
+三份研究须逐个启动，上一份结束并核查完再起下一份，同机不与别的研究并跑；进程起止见 `launches.jsonl`，机器观察见 `machine.jsonl`，杀进程前后见 `container-*.json`，扣次与后续结果见统计的 `kill`。快照只是观察证据，不声称追踪任意进程。结果放仓库外，不提交。独立审阅按候选分两步：先评实现忠实度，再给历史核验及其当时代码评误判和修复范围。路线分类、完整路线的实测减合并 q5、A–J 表由阅读后填写；复用 `eval/route/` 的导出、条目、思考、分位数核查及 Jev 四问，不另造问卷或判别器。参考项目五份账本用已有只读副本，保留无效数值和重复尝试，并注明参考提示词含题目做法。