18. 跨环续做与 seed / 重复执行策略

0. 要解决的问题

1. 环的边界会丢工作。 run 链每环一个锁定 run（T1 24 h，其余 12 h），--continue-from 把上一环已打分的节点、晋级分数和已证否方向带过去，但截止时还没做完的 Engineer 工作、被截止切断的训练执行没有可靠的交接。（G39 已经会提交并执行会话被切断时留下的可运行 run.py，这条即时验收保留。）
2. 同一个候选被重复执行约 9 次（权威 seed 0、--ablate 对照、晋级 seed 1、2、终选护栏 5 个新 seed）。对训练型程序，每次都从头训练。
3. 固定 30 分钟执行上限对 OT / CFM / VAE 太紧；但"无时限"不能挤占终选护栏。

1. seed、训练状态与结论范围

• 三种随机性分开：程序 seed（--seed，默认只影响采样 / 生成）、评分 seed（本地评分 = 程序 seed，覆盖评分器抽样）、训练 seed（EXECUTION.json 的 train_seed，默认 0；seed_affects_training: true 时训练 seed = --seed）。
• 晋级的 3 seed 均值与终选护栏的 LCB 是"给定冻结权重和当前评测数据"的条件结论，不说明重新训练这个方法也稳定优于基线；final 视图重新训练，也不在这组 LCB 覆盖内。
• 训练随机性只做诊断：终选最后、仍有时间时，对入围的训练型候选做一次冷启动重现检查（seed 0，不放回权重，同一训练 seed），记录分数差与输出是否一致，不进排名、不进护栏。（草案的"前 5 名各重训 1 次（seed 1 --retrain）"取消：统计保证有限，还会占用必要的终选预算。）

2. 多 seed 接口（后置）

--out-dir --seeds 批量接口和"每节点提前生成 seed 0、1、2"不做：权重复用（§3）已消除大部分昂贵重训，提前评分会让不会晋级的节点也付评分成本。晋级照旧按需跑 seed 1、2。以后若加入，必须要求每个输出与单 seed 执行一致、与 seed 列表顺序无关，只在明确的"不支持接口"时回退，逐 seed 配对记录。

3. 权重复用（ARTIFACTS.json 的 per_view）

• 声明：[{"path": "weights/model.pt", "sha256": null, "per_view": true}]，路径必须在 solution/ 的子目录里。程序约定：权重文件在就加载，不在就按训练 seed 训练并写出。
• 生命周期：提交时 per_view 文件不进 git、不按提交存；同一缓存键第一次执行时权重目录可写（目录里指向产物库的硬链先换成私有副本），执行成功后验收（文件在、普通文件、≤ 8 GB）并不可变登记（artifacts/<sha256> 只读 + artifacts/per_view/<tree>/<key>.json，首写者为准，进账本）；之后只读回放。同键的并发首跑等持锁者训练完再回放。已登记的权重缺失或哈希不符 → interrupted，不悄悄重训。
• 缓存键 = 训练代码与配置（提交的 solution 树）+ 训练 seed + 合法输入内容（视图按内容哈希；proxy10 / X3 / final 互不回放）+ 依赖环境（venv、pip freeze、modeling 快照）+ 影响训练的参数（--ablate：对照训练自己的权重）。
• 回放：同一视图上的晋级 seed、护栏 seed、--continue-from 的下一环（产物库与索引随导入硬链过去）。不回放：视图盲检查的伪装视图与复核、冷启动重现检查（fresh）。

4. 健康监督与终选资源保护

• 采集：每 60 s 读候选进程组（累计 CPU、I/O、属于它的 GPU SM% 与显存（nvidia-smi pmon / compute-apps 按 pid 归属，不用整卡利用率）、GPU 排队、进程状态与 wchan、cgroup 内存与余量、输出、可写目录 mtime、solution/progress.json、各探针可用性），每 5 min 汇总一条（区间内取最大 / 累计，不漏短突发）。
• 活动 = CPU、自己的 GPU 计算、I/O、D 态加 I/O、GPU 排队；心跳、日志、进度更新只作辅助，不能让只写心跳的死循环存活。删除"内存三次单调逼近上限即不健康"。
• 模式：先只观测（exec_health.enforce: false，默认）：30 min 无活动记 would_hang，用来统计误判率；程序受兜底上限 limits.time_limit_min（360 min）与阶段终点约束。enforce: true 后 30 min 无活动判 hung（候选失败）；360 min 只在监督器失效（连续 10 min 读不到进程组）时生效。
• Engineer 的停顿判定同步加入会话进程树自己的 GPU 计算。
• 截止语义：cutoff − node_tail 是 Engineer 的交接点；执行最多到 cutoff，届时 SIGTERM、宽限 60 s（程序可写最后完整检查点）、再 SIGKILL；健康不能越过 cutoff；run 的硬截止 stop_at 保留。cutoff 前移时，在飞的会话与执行经 deadline_fn 跟着提前。
• 终选预留按实测：按前 final_top_k 候选估算——未做的视图盲检查、未审查的审查时间、缺的晋级 seed、护栏全部任务（最坏候选 + 基线）、final 视图冷启动与基线 final 运行、每次执行的评分排队；执行时间用多视图合计；串行累加；reserve = max(配置值, 估计 + 10 min)，上限半个挂钟，只前移 cutoff。
• 硬保护（不依赖估算）：基线先落盘（在候选审查之前）；护栏不完整就保留基线；不降样本数、不跳护栏、不改试别的候选；配置了护栏却缺基线时拒绝候选替换（不写 final/）。
• 链级已暴露评测 seed：每环护栏的新 seed 与此前各环不重叠（例如 3–7 → 8–12），整条链的集合锁进 chain_exposed_seeds。多环反复使用同一真值集的适应性偏差不由此消除。
• run 级健康邮件每 3 小时一封（2026-10-03 用户改定），含在飞候选执行的采样摘要；邮件与 G44 只用于两环之间，不在锁定的环内人工指挥。每条 run 并发节点 2 不变。

5. 跨环续做（carryover）

5.1 什么会被带走

• Engineer 会话在交接点被切断、且没留下可执行程序 → 节点 carried_over（kind engineer）。会话被切但 run.py 可用 → 照常提交、立即执行（即时验收），封存快照只作证据。
• 权威执行被搜索阶段截止切断 → carried_over（kind execution）；下一环重跑同一提交。宽限期内写出的检查点封存为证据；没有训练续跑协议（优化器、随机数、步数状态未定义），下一环从头训练。

5.2 封存是一个事务

停止写入者（进程组已回收、打分 client 已移除、查分数已从打分日志读出）→ 检查文件 → 写不可变快照 nodes/<id>/carryover/（solution/、PLAN.json、trajectory/ 原始轨迹、checkpoint/、HANDOFF.json）与逐文件哈希 SEAL.json → 登记账本 → 结算节点（carried_over：释放虚拟访问、无访问、不进 FUTS 树）→ 控制器停止时写 stop_manifest。不依赖账本豁免的 work/。

5.3 下一环怎么接

• 导入时快照逐文件按 SEAL 校验通过才复制；校验通过的进 resume 队列，优先于 improve 抽签，每环 ≤ carryover.max_resume_per_ring（4）。
• resume 是本环的新节点（计入 max_nodes 与本环预算），保留真实父节点；父节点审查判 fail 的不续做（resume_refused）。去重不改写谱系。
• kind engineer：不调 Researcher；新 Engineer 会话 + 本环完整提示 + 原 PLAN + 结构化交接摘要 + 只读历史快照（含原始轨迹）。不续同一 opencode 会话（搜索入口没有接线，旧路径、旧提示、旧实验表风险大）。
• 查分额度按稳定的逻辑工作累计：每段封存时记录打分服务按 run 日志统计的已用次数，续做节点的额度 = 每节点额度 − 各段之和。
• 证据：resume_origin.segments[] 有序列出每一段的 run、节点、锁哈希、封存哈希、快照、轨迹、模型、预算；打包时祖先链里的续做节点把各段快照并入 lineage_trajectories，MANIFEST.json 写 lineage_segments。三环以上逐段累加。

5.4 合规

新锁承接的是已结束 run 的封存输入（与 G18 导入节点同类）；每段保留自己的锁与全部提示，不把改配置后的工作描述成原锁定 run 的继续执行。权重属于候选证据：每份分数能对应代码、输入内容、训练配置、权重哈希与评分配置；carryover 依赖的产物进入保留集合。

5.5 不做的

不跨环保留沙箱进程；不自动延长环等训练结束；不续同一 opencode 会话；--seeds 批量接口、提前三 seed、前五名固定重训后置。

6. 审阅问题的结论