InfoRSI/任务书/10-submissions.md

任务书 10：submissions（收件），以及 materials 的几处修改

写 submissions 模块：一份模型提交，收下还是退回。先由程序检查，再问 Jev。开工前先改 materials 的几处地方，这些是监督者核对任务书 09 时发现的。

本任务书已由用户和监督者在 2026-10-03 一起确定。下面说的"监督者"，是在参考项目目录里和用户讨论设计的另一个会话。

开工前先读

• CLAUDE.md：全部，尤其是"罕见情况怎么办"（什么算边界、哪些不算）、"不设默认值"、"测试"。

• docs/结构.md：

  • 第二部分：submissions 一行，以及"几条边界"里"收不收一份提交，只在 submissions 一处判"；
  • 第四部分：账本记录第 3 种（提交与退回）、第 4 种（冻结协议）；
  • 第八部分：vocab（SUBMISSION_SCHEMAS、Checklist、JevJudgment）、ledger、tasks（protectedChanges）、workspace（compareVersions）、jev、materials 各节。

• docs/方法.md：

  • 第五部分：每种提交的字段、三个数严格递增、保障短名、指标登记、延续；
  • 4.2、4.3 ②⑥⑨⑭⑯：哪些提交要过哪些检查、Jev 在哪里判；
  • 6.6：一格的几种结局。

• WORK_LOG.md："未完成"里"任务书 09 核对后要改的 materials"7 条、"留给 submissions 的跨字段规则"14 条、"给 submissions"那条、"核验提交 body 的字段说明"那条、"jev 判重材料加关键设定"那条。

• 参考项目（只读，不要改）：

  • /home/iomgaa/Projects/RivalBits/src/rounds/submissions.ts、/home/iomgaa/Projects/RivalBits/src/rounds/task-submissions.ts：程序检查；
  • /home/iomgaa/Projects/RivalBits/src/controller/submit.ts：先程序后 Jev 的顺序、退回文字怎么写。

  这三个文件合起来约 2400 行，真正属于"收不收"的约 750 行；去掉已删的功能和 vocab 已经管的字段形状，剩下的才是要搬的。第五部分列了保留和删除。

一、先改 materials（任务书 09 核对后要改的）

1. 挑刺的"现在交什么"：closing() 里挑刺落进了研究者的通用一句"调用一次交上就完成了"，和任务说明"可以交一份或几份，每份调用一次"相反。模型多半照最后一句只交一份。给挑刺单写一句，和提案那句类似。
2. 上一次为什么被退回，按对象找：账本的退回记录加一个"对象"字段，和提交记录的 target 同义（候选、原提案、消融格，没有对象的写 null）。materials 按"阶段、作者、种类、对象"找本人最后一次被退回的原因。删掉 callPrefix 和按调用编号前缀定位的写法，WORK_LOG 里"同一人同一阶段同一种任务不并行"那条要求随之作废（核对时已删）。ledger 表结构版本号升一级，相应的测试跟着改。
3. 核验材料删掉 Jev 预扫的概率和阈值（assigned.ts 的"预扫结果"一节）：方法里没有这一项。一份实现能走到核验，说明 Jev 已经判过没问题；再把低于阈值的概率给核验员看，等于把 Jev 当提示用。用户的意思是 Jev 当判别条件用，判了就算。
4. 信念本补"合法化扣掉的分"（方法.md 6.10 第 3 条）：在选批历史的每次运行后面加一行。合法化记在判分结果的 extra 里，内容由任务决定，materials 不认识它的字段，就原样写出来。
5. 删掉"答案出自被关掉的因子，它本该关着"那句（locations.ts 的 answerPathLines）：方法里没有，也没有真实证据说明会出现。
6. 消融核验不通过可以重做（用户 2026-10-03 定，方法.md 4.3 ⑯、6.6）：
   • 重做时重发一次"消融实现"任务，材料里放上一次消融核验的结论（哪个因子关错了、核验员写的依据），写法参照正向修复的"退回意见"；
   • 一格因为重做次数用完而不跑、记"证据不足"时，这一格没有运行。现在 belief-book.ts 的 cellText 假定"证据不足"的格一定有运行，要改：没有运行时，原因从这一格的事件记录里读（事件由 flow 写，事件的写法在这里定下来、导出给 flow 用）；
   • src/rules/ablation.ts 里 insufficient 的注释跟着改。
7. 三处旧说法：
   • tasks/circle_packing/TASK.md 里"保障写'无'时写 {}"，改成和 vocab 一致；
   • src/vocab/submissions.ts 开头注释里的 q₁ ≤ q₅ ≤ q₉，改成严格递增；
   • agents 读代码工具的 offset 参数：提示词里已经不提它了。删掉 offset，单次读的上限照旧。

另外两处小改动：

• jev 判重材料加"关键设定"：DedupFactor 加 keySettings，判重的材料里带上它。问题里写着"设定不同就不算同一个改法"，现在 Jev 却看不到设定。问法其余部分不动，阈值照旧，也不重新校准。
• 核验提交 body 的字段说明补一句：同一行同时出现在因子和保障里时，在说明里写一句提醒（方法.md 4.3 ⑨）。

二、submissions 做什么

用"实验员交了候选 r1-c1 的实现"举例：

1. agents 收到模型的提交，交给 flow 的提交回调。
2. flow 先把实验员的工作目录存成一个版本（workspace），和本批基线比较，拿到"改了哪些文件"和"代码差异"；再用 tasks 的 protectedChanges 算出改了哪些不许改的文件。这些是提交之后才知道的东西，不在对号清单里。
3. flow 把提交内容、这次任务的对号清单（存在"模型调用开始"记录里的那份）、第 2 步算出的东西一起交给 submissions。
4. submissions 先做程序检查，有一项不过就退回，不再问 Jev；全过了再问 Jev，有一问判"是"就退回。
5. submissions 交回"收下 + 用到的 Jev 判断"，或者"退回 + 原因 + 用到的 Jev 判断"。flow 照着写账本，agents 原样回给模型。

submissions 不读账本，也不写账本，只看交进来的东西。它只依赖 jev 和 vocab（结构.md 第二部分），不引用 tasks、workspace、materials：要它们算的东西，由 flow 算好传进来。

三、对外提供什么

经 src/submissions/index.ts 导出，函数名由你定。

1. 判一份提交：输入下面这些，全部必填，可以没有的写 null。

• 提交种类和内容（vocab 的 Submission）、对号清单（vocab 的 ChecklistOf<K>）、Jev 的模型名。

• 按种类区分的"提交之后才知道的东西"，用联合类型写，写不出"挑刺带代码差异"这种组合：

  • 提案：本人本阶段已经收下几条（替换时不算被替换的那条）。超过对号清单的 maxProposals 就退回；
  • 回应：作者那条原提案的内容。submissions 用它拼出冻结协议（见第四部分第 3 条）；
  • 实现、修复：代码存成版本了没有。存不了就带 workspace 给的原因；存成了就带改了哪些文件里属于不许改的那些、代码差异块（jev 的 codeHunks 切好的），以及冻结协议里给 Jev 对照的那几项；
  • 消融实现：交的不是"跑不起来"时，同样带"存成了没有"和不许改的文件；
  • 其余种类：没有。

  代码存不了也交给 submissions 退回，这样所有退回都只在这一处判、写法一样。

• 交回：

  • 收下：用到的 Jev 判断（没问 Jev 的为 null）；回应和统一另交回拼好的冻结协议主体（因子、保障、指标、正文、实现条款，就是方法.md 4.3 ⑥"冻结协议包括"那几项），flow 在回应阶段关闭时补上轮次、基线、合并了哪些原提案，写成 materials 的 FrozenProtocol；
  • 退回：原因文字和用到的 Jev 判断。

2. 核验通过没有：给一份已经收下的核验，交回通过或不通过，以及不通过的那几项。任何一项没落实，或者任何一条没有归属的改动判为越界，就是不通过（方法.md 4.3 ⑨）。

3. 消融核验通过没有：给一份已经收下的消融核验、这一格要关的因子、实验员报的一起关的因子。要关的那几个都写了"关着"，其余因子都写了"照留"，才算通过（方法.md 4.3 ⑯）。

第 2、3 条判的是"收下之后的结论"，不是"收不收"。放在这里，是因为它们和第 1 条一样，都是对一份提交内容做的判断。

四、要做的检查

程序检查

WORK_LOG 那 14 条，加下面几条：

• 不许改的文件（方法.md 4.3 ⑨）：实现、修复、消融实现，改了不许改的文件就退回，原因里写出是哪几个文件。消融实现也查，因为"运行的规矩和正向运行相同"（4.3 ⑯）。
• 代码存不了：退回，原因原样写 workspace 给的（例如哪个路径是符号链接）。
• 指标编号不能和已占用的重名：已占用的编号指最终指标、常规辅助指标、之前登记过的假设专用指标，对号清单里的 takenMetricIds 就是这些（WORK_LOG"给 submissions"那条）。

退回原因要写出该写什么。覆盖不全、编号写错时，原因里列出对号清单里该写的全部编号，例如"挑刺编号应当是 r1-a1-1.a2.1、r1-a1-1.a3.1，你写的 r1-a1-1.a2.2 不在里面"。参考项目在真实运行 15-tight-2 第 3 轮里，模型连续抄错挑刺编号，加上这一条之后改好了（参考项目提交 378fe68）。

Jev

提交	问什么	怎么问
回应、统一	冻结条款三问：改动了评测、自相矛盾、太含糊（checkProtocol）	对拼好的冻结协议问一次
实现、修复	代码改动五问（checkHunk）	每个差异块一次。没有差异块的改动（二进制、只改可执行位、空文件增删）Jev 看不到内容，不问
其余	不问	消融实现照参考项目不问：冻结协议里没有登记"关掉以后"的随机性和停止条件，五问没有对照

• 一份提交的几问全问完再决定。有一问判"是"就退回，原因里列出每一问的问题名、概率、阈值；代码改动还要写出是哪个文件的哪一块，附上那一块的差异原文。参考项目 submit.ts 的退回文字可以借。
• Jev 调不通、回答读不懂，jev 会报错。submissions 不接住这个错，让它往上抛，flow 按内部错误停下研究。这不是模型交得不对，不能记成退回。
• 判"是"用的是 jev 交回的 yes。jev 怎么比阈值（现在是严格大于）是 jev 的事，submissions 不再比一次。

回应怎么拼成冻结协议

• 回应：因子、保障、指标、正文四项，changes 里写了哪一项就整项换成新的，没写就用原提案的。实现条款取回应自己的。答复不进冻结协议：它们已经在回应或统一的提交记录里。materials 的 FrozenProtocol 去掉 replies 和 replyBody，第二次预测要的"挑刺与答复"从这个候选已公开的回应或统一提交里读。
• 统一：直接用统一提交自己的字段，不再叠原提案。
• 因子数上限、延续、保障短名、指标这几条规则，对拼好以后的协议查。原提案已经查过的部分，没改就不会出新问题，但拼好再查一遍，写法最简单。
• 拼法只写在这一处。flow 写冻结协议时用 submissions 交回的结果，materials 读账本里存好的协议，都不再自己拼。

五、参考项目的保留与删除

处理	内容
删除	vocab 字段定义已经管了的形状检查：多字段、少字段、空文字、数组长度、编号写法。Pi 调提交工具之前就按 vocab 查过，agents 把查不过的也报给了提交回调
删除	程序补的编号是否合法、整份能不能规范序列化：编号由程序起，序列化是我们自己的程序
删除	cannotImplement、requirementMap、metricsImplemented、feedbackResponses、codeHash：新项目的字段里没有这些
删除	回应的条款要指向基线里存在的文件、行号不超出、函数名能找到：新项目的条款是自由文字，评测被改由 Jev"改动了评测"那一问判
删除	指标短名不能含"."：参考项目拼前缀才需要；新登记的指标"规格写得够不够具体""是不是换个说法测同一个量"两类 Jev 问题；naive 的可行性：方法里都已删除
删除	提案至少一条指标、保障清单不能为空：新项目里没有就交空数组
删除	消融实现的代码不能和完整代码一模一样：没关掉指定的因子，消融核验会查出来，不用在收件时再查一次
删除	因子名称、入口名称不能重复：没有真实证据说明出过问题
不归 submissions	替换的是不是本人刚交的：由 ledger 写入时拒绝（结构.md 第二部分）
不归 submissions	参数 JSON 被截掉一半、必填字段交 null：agents 已经处理了
保留	退回原因里列出该写的编号（真实证据见第四部分）

六、测试

不花钱的测试，放进 npm test：

• 14 条跨字段规则和第四部分加的几条，每条至少一个"该退回"的例子，再有一个"都对、收下"的例子。收下的例子要用不问 Jev 的种类（预测、挑刺、解释等），或者在程序检查那一步就退回，不会走到 Jev。
• 退回原因里列出了对号清单里该写的编号。
• 回应拼冻结协议：changes 只改一项时，其余几项取原提案的；统一不叠原提案。预期值按方法.md 手写。
• 核验通过没有、消融核验通过没有：各有通过和不通过的例子。
• 第一部分 materials 的几处：每条都有能重现原问题的测试。挑刺的"现在交什么"不再写"调用一次就完成"；退回按对象找到的是本人这个对象的，不是别的对象的；核验材料里没有 Jev 的概率；信念本里有合法化的原样记录；消融格不跑、记"证据不足"时信念本照样写得出来。

真实 Jev 的测试：jev 的地址写死在代码里，不为测试改成可配置。走到 Jev 的路径放进现有的 npm run test:jev（要花钱、要联网，不进 npm test）：

• 一份写得好的回应，三问都没判"是"，收下；
• 一份把评测改掉的回应（例如冻结协议里写"改 validate.py 的容差"），退回，原因里有这一问的概率和阈值；
• 一份实现，切出的差异块每块问一次，交回的判断条数等于块数。

报告里贴出这几次的实际结论和概率。

审阅：收不收决定了什么能进账本，写完派一个全新上下文的子 Agent 审阅一轮。告诉审阅者：

• 每条意见先回答"不写会怎样"；
• 只防三类：没人操作也会发生的、模型正常工作时就会做的、出错后发现不了的；
• 模块之间传错参数、有人用 shell 故意破坏，都只列出不改；
• 下面这些已经判断过不用防，除非有新证据：因子或入口名称重复；消融代码和完整代码一模一样；对号清单本身写错（那是 materials 的事，不算边界）。

审阅意见逐条判断，采纳或不采纳都在报告里写理由。

七、规模与文档

• submissions 预期 400–600 行，不含测试。参考项目真正属于"收不收"的约 750 行，去掉已删的功能以后约 300–350 行，再加上拼冻结协议和两个"通过没有"。超过 600 行就停下来检查。materials 改完不超过 1850 行。
• 完成后更新：
  • docs/结构.md 第七部分：submissions 的行数改成 400–600；
  • docs/结构.md 第八部分：补 submissions 对外的函数和类型，每项一句话；ledger 一节写上退回记录的对象字段；materials、jev 两节按第一部分改了的地方跟着改；
  • WORK_LOG.md：在"已完成"补一条；删掉"未完成"里已做的：任务书 09 核对后要改的 7 条、14 条跨字段规则、"给 submissions"那条、核验 body 那条、判重加关键设定那条。
• 不新建 md 文件。

八、验收与报告

做完后本地提交，然后在回复里交一份报告，监督者会对着实际文件逐项核对：

1. 提交号，新增和修改的文件列表，每个文件的行数，submissions 的总行数，materials 改完后的总行数。
2. npm run check、npm test、npm run test:jev 的完整输出。
3. 三份退回原因的实际文字：一份覆盖不全的、一份改了不许改的文件的、一份 Jev 判"是"的。
4. 第一部分每一条怎么改的，对应哪个测试。
5. 审阅意见逐条：内容、采纳或不采纳、理由。
6. 你和这份任务书、结构.md、方法.md 不一致的地方，以及为什么。
7. 规则不清楚的地方：读 CLAUDE.md、结构.md、方法.md 时，哪里让你犹豫、哪里两份文件说法不一致、哪里你是靠猜的。没有就写"没有"。没有真实证据的可能情况，在这里提一句就够，不写进 WORK_LOG。