结论：支持保存未完成工作、按条件复用权重、引入健康监督；不建议按草案原文直接落地。 必须先明确四件事：跨环状态如何封存、权重在哪些输入上有效、LCB 衡量哪种随机性、终选资源如何受到硬保护。

以下代码位置以审阅基线 336073a 为准。审阅期间执行相关文件正在被并行修改，因此工作区链接的行号可能发生偏移；这里不把新增实现视为已经验证。全程只读，未修改文件或运行实验。

1. 跨环续做（§5）

合理，但应实现为“新 run 导入不可变检查点”，默认开启新 Engineer 会话。

草案的问题描述略有过时：G39 已经会提交并尝试执行未完成 Engineer 留下的 run.py，占位 METHOD 通过额外审查处理；随后才清理工作目录。因此真正需要挽救的是尚未完成的编辑状态、会话上下文和训练检查点，不宜把所有被截止的节点都改成 carried_over，否则会失去已有的即时验收机会。见 controller.py:2049、controller.py:1765。

• “已有同会话续跑能力”不能直接套用到 search Engineer。 通用 backend 有 resume，但搜索入口没有传 session id；每次调用还会删除并重建私有 opencode 状态。见 roles.py:71、roles.py:258。旧会话还保留旧路径、工具结果、实验表和提示，追加一句新说明不能保证这些前提被替换。最小方案是：新会话＋完整的新环提示＋原 PLAN＋结构化交接摘要＋只读历史轨迹。摘要不限于最后 30 条，因为关键约束可能早已退出尾部；摘要也不能代替原始证据。
• 必须保留真实父节点，不能按“新树结构”直接改写谱系。 父节点仅因去重失去调度资格，与因数据泄漏、视图依赖等审查失败，性质不同。前者保留原 parent_commit，另记调度代表；后者不能“续做照常”，应先自动复审继承代码、权重和 PLAN。目标、数据或工具改变时，也要重新确认 PLAN 是否适用。现有导入会在评分指纹不同后清空旧排名并安排部分重评，说明“旧分数可直接用于新环”本就有条件。见 continuation.py:163。
• 剩余查分额度必须来自持久日志，而非会话摘要。 现在 Engineer 注册的是新节点 id 和完整额度；评分服务只从本 run 日志恢复该 client 的已用次数。跨环换 id 后自然会归零。应使用稳定的逻辑节点身份，累计各段已计费查询，并在封存前结清或取消在途请求；恢复时只扣一次。见 controller.py:1990、service.py:465。
• §5.1“训练不杀”和§5.4“不延长环”存在直接冲突。 当前 cutoff 是搜索结束，stop_at 是整个 run 的硬截止，程序受阶段终点约束。健康不能成为越界理由。最小修改：在 cutoff-node_tail 请求 Engineer 交接；执行中的训练最多运行到 cutoff，届时保存最后一个完整检查点并终止进程组；释放资源后才进入终选。见 budget.py:4、execute.py:143。若没有训练恢复协议，带走权重不等于能够恢复训练；优化器、随机数和训练步数等状态需要明确。
• 封存必须是一个完整事务。 顺序应为：停止写入者和在途工具 → 验证检查点完整性 → 写不可变快照及逐文件哈希 → 登记 ledger → 结算节点状态和虚拟访问 → 写 stop manifest。下一环只能从通过验证的快照复制。当前 work/ 属于账本豁免的 scratch，不能只保留一个原目录路径。见 ops.py:640、archive.py:388。恢复尝试还应计入新环节点和资源预算；当前 max_nodes 明确排除 imported 节点，直接复用旧行会漏计。见 controller.py:1109。

规则方面，新锁可以承接已结束 run 的封存输入，但不能把改变配置后的工作描述成原锁定 run 的继续执行。这是对规则的架构解释；官网没有明示批准“可变旧会话跨锁续接”。草案“提示词哈希以新环为准”应改成“每段分别保留所属锁和全部提示”。官方规则 §9

2. seed 语义与重复执行（§1–3）

默认只影响采样可以成立，但 LCB 必须明确是“给定冻结权重和当前评测数据”的条件性结论。

• 草案遗漏了评分随机性。 本地执行默认令 scorer_seed = program_seed；因此多个 seed 同时覆盖生成和评分器抽样，不能由“官网对同一文件评分确定”推导出这里只需要生成随机性。见 execute.py:281。LCB 实际计算的是配对差值的 mean − t × sd/√n，没有训练间方差项。见 scoring_def.py:473。若待选择对象就是冻结权重，这不必然过于乐观；若据此宣称“重新训练的方法稳定优于基线”，则证据不足。final 视图需要重新拟合时，也没有被这组固定权重的 LCB 覆盖。
• “前五各重训一次”只能发现明显异常，不能证明训练稳定。 更关键的是：按草案默认语义，--seed 1 --retrain 仍可能使用同一个内部训练 seed，只是在检验重现性。要检查训练随机性，必须另设明确的 train_seed，比较时固定生成和评分 seed。建议先取消前五名必做，改为入围候选的冷启动重现检查；需要训练稳定性结论时，再设计多个独立训练重复，并预先规定异常如何影响资格。“只记录、不进排名”本身不会保护本环终选。
• ARTIFACTS 需要扩展生命周期，不能只加“存在就加载”。 基线实现是在 Engineer 提交时收集权重，权威执行的 solution/ 只读；“第一次权威执行写权重”需要明确的可写产物目录、执行后验收和不可变登记。见 runenv.py:279、execute.py:115。已经声明并冻结的产物缺失或哈希不符，应继续按契约报 interrupted，不能悄悄训练另一组权重冒充原候选。见 CONTRACT.md:86。
• 权重必须按有效训练输入隔离，消融也必须隔离。 缓存键至少包括训练代码与配置、训练 seed、合法输入内容、依赖环境，以及影响训练的 --ablate。不能把 X3、proxy、final 的权重互相回放；例如 final 允许使用的 E9.5，恰是 proxy 的目标阶段。完整机制的权重也不能直接充当“训练时关闭机制”的对照。sha256 只证明字节没变，不证明这些字节适用于当前实验。跨环不能仅凭相同的 data_epoch 数字判断输入一致。
• 两种优化不必同时做，优先权重复用，保留按需晋级。 给每个节点提前生成并打分 0、1、2，会让原本不会晋级的节点也支付两次评分和输出成本。“采样便宜”不等于评分、文件写入便宜。当前晋级有去重、无进展和审查门槛，终选也已复用同纪元的晋级结果。见 scoring_def.py:670、final.py:444。更简单的方案是保留单 seed 接口，按视图缓存训练结果，仅对真正晋级者采样。 即使 seed_affects_training=true，相同训练 seed 的确定性重放也可以缓存，不必“每次重训”。

若以后加入 --seeds，应要求每个输出与独立单 seed 执行一致、与 seed 列表顺序无关；训练依赖 seed 时不得强行共用一次训练。只在明确“不支持接口”时回退，不能把训练崩溃、OOM、超时一律当成接口不支持。所有样本仍须逐 seed 记录、配对评分，护栏缺一个样本就不能通过。

3. 健康监督（§4）

30 分钟没有日志并不等于挂死；30 分钟没有任何可信活动，可以作为调查和终止依据，但现有指标定义还不够。

• 采样要能区分计算、等待和遥测失效。 GPU 指标应归属候选进程或 cgroup，不能用整卡利用率；显存仍被占用不代表计算在推进。五分钟一次瞬时读数容易漏掉短突发，宜较短周期采集、五分钟汇总，并加入累计 CPU/I/O、GPU 排队状态、进程等待原因及遥测可用性。progress.json、mtime、日志增长只能作辅助，不能让不断写心跳的死循环永久存活。
• 删除“三次内存单调逼近上限即不健康”的硬判定。 缓存、预分配和分阶段加载都可能产生这种曲线；应记录余量、压力和 OOM 事件，再区分候选 OOM 与宿主资源压力。还要同步 Engineer 的监督：其现有三次 180 秒停顿机制使用 CPU/I/O 和 GPU 排队标记，没有实际 GPU 计算指标，可能先于执行器的 30 分钟监督结束会话。见 roles.py:318、runenv.py:588。
• 2 × 最长候选耗时 + 10 min 不足以估算终选。 当前 evaluate.runtime_s 是多个串行视图耗时的最大值，不是合计，也不包含完整评分和排队耗时。见 controller.py:1420、controller.py:1454。现有 final 留给最终预测的时间还取自当前 provisional winner；有护栏时通常就是廉价的 copy_last，不能代表训练候选在 final 大视图上的耗时。见 final.py:452。
• 堵住挤占护栏，靠预算隔离，不能只靠估算。 锁前固定估算算法，搜索期间持续更新：审查／视图检查、缺失晋级样本、候选与基线的全部护栏任务、评分排队、最终视图执行和落盘都应计入。按实际 GPU 槽和内存约束估算完成时间，不能只除以节点并发二。cutoff 只能提前，所有在飞工作也必须响应新的截止；诊断重训排在必要终选工作之后。对 final 冷启动或缓存未命中保留保守估计，不能用一次热缓存耗时代表全部任务。

即使估算失败，也应保证：基线先安全落盘；护栏不完整就保留基线；不降低样本数、不跳过护栏、不改试另一候选。 当前缺测拒绝已经实现于 scoring_def.py:503，但有两处应补强：候选审查发生在基线落盘之前；配置了护栏却找不到 baseline 时会直接 guard=None。后者必须改为拒绝候选替换，见 final.py:388、final.py:409。

此外，“无训练时限”与“360 分钟硬上限”需要统一措辞：若健康训练到 360 分钟仍被杀，它就是固定时限；若仅针对监督器失效，则必须定义监督器失效的判据。run 的硬截止始终保留。

4. 优先级

5. Agent 赛道合规与证据链风险

• 跨三环以上不能只记录“origin＋当前环”。 导入保留最早 origin，而当前祖先证据打包主要取最早来源目录和当前目录；如果同一工作先后在 A、B、C 环修改，仅套现有机制可能漏掉 B 段。需要显式的有序 segments[]，逐段列出 run、node、锁、输入／输出快照、完整轨迹、实际模型和预算。见 continuation.py:168、controller.py:3392。METHOD 写“分两环完成”远远不够。
• 跨环重复使用 3–7，可能破坏“新 seed”解释。 当前校验只检查它们与本环节点／晋级 seed 不重叠。见 scoring_def.py:383。如果上一环护栏结果已影响 G44、提示或后续方法选择，下一环再用 3–7 就不是独立复核。建议维护链级已暴露评测 seed 记录，并为新环预定不重叠集合；即使如此，多环反复使用同一真值集的适应性偏差仍不由这个 LCB 消除。
• 权重本身是候选证据的一部分。 每份评分必须能对应代码、输入内容、训练配置、权重哈希和评分配置；更换权重后不能沿用旧分数。carryover 依赖的权重也须进入保留集合，不能因“不在前五或胜者祖先链”被清理。现有保留策略见 13_records.md:93。
• 健康邮件和 G44 不得成为锁后人工指挥入口。 锁前确定的自动监督、停止和恢复政策可以执行；人员根据中途诊断改变本环方向、额度或选择结果则不符合自治要求。新环重新锁定时，应如实记录继承材料及配置变化，保留原始轨迹，不能用摘要重构替代。开发日志也应继续与候选上下文隔离。见 13_records.md:25、官方规则 §9。