# JEV checkpoint 线交接（2026-09-30）

## 当前结论

项目仍未有可以诚实写成主方法的创新结果。test checkpoint 标签没有读取，`runs/ckpt-policy-freeze/` 尚未建立；因此不能调 test 阈值、不能做 test 结果选择，也不能开始最终论文定稿。GPU6/7 归本项目长期使用，GPU0–5 属于 RL，不能碰。

已验证的可靠事实是：密集 checkpoint 标签揭示了真实停止余量，但现有被动信号不足以安全回收预算。counts GBDT、自评 probe、0.6B 文本模型和 LSM 规则在 dev 上都无法同时满足解决率和风险门槛。0.6B 文本头是当前单轨迹成本节省最好的基线，但它没有形成预算相同下的提交/继续/重开收益。

不能用“美化”替代方法创新，也不能改造或编造数字。可以改善叙事、图表和排版，但论文主张必须能由原始收据复算。

## 数据和标签边界

权威数据入口：

`runs/ckpt-pilot-dataset-timeout-thread-amended-20260927/dataset.json`

- dev：40 任务、160 次尝试、4,091 个决策标签。
- ext：300 任务、599 次尝试捕获；其中 580 次/296 任务可用于训练，13,601 个训练决策点。
- test：60 任务、239 次尝试捕获；官方 checkpoint 标签继续封存。

test 允许做的事情只有不含标签的特征计算，例如文本缓存或 9B 自评。所有任务、特征、模型、阈值、成本规则和冻结文件写入 `runs/ckpt-policy-freeze/` 之前，禁止读取 test 标签。

## 已完成的基线和模型

九个 0.6B 文本模型（joint / independent-now / independent-final，三 seed，含 final1 recovery4 与 final2 successor）均有独立 readout。总体审查结论为 `PARTIAL_DESCRIPTIVE_LABEL_ABLATION_ONLY`：当前标签相对最终标签在部分 resolve-loss 菜单上省输入 token，但解决率和 harm 存在 trade-off，没有建立相对 counts 的安全增益、部署保证或总体保证。

代表性结果：

- counts failure-termination：Q=77/160，输入省 17.7944%，但 H 的条件区间不能支持总体 H≤1%。
- 9B 自评：AUC 约 0.78；单轨迹在允许约 1 个点损失时只能省约 6% 输入。
- 0.6B 文本模型：AUC now 约 0.77、final 约 0.76；gain 头单轨迹约省 11.2%（零点损失菜单）到 13.2%（允许一点损失），但预算化 submit/continue/restart 没有超过原生策略。
- GBDT 在 2× token 预算下最多只出现约 1.9 个点的描述性增益，不能作为安全结论。

这些数字来自 dev/ext，不能转写成 test 或总体保证。详细证据见 `refine-logs/CLAIMS_FROM_TEXT_FULL_SUMMARY_20260929.*` 及各 seed 的 CLAIMS 文件。

## 方法路线及关闭原因

初始 ACRB（artifact ledger + current/final + risk budget + abandon）经独立 review 判为 RETHINK：与 hazard / optimal stopping / Fail-Fast 的既有结构重叠，risk budget 没有可识别定义。

随后三条“agent 独有执行见证”路线均按预先 kill 条件关闭：

1. **Crossed provenance**：20 任务、80/80 视图有效，但 17 个任务四视图全通过、3 个全失败，没有 code/test 分化。
2. **Persistent failure witness**：8 任务、16 视图；7 个失败仍失败，1 个 rc1→rc4 仍失败，没有 failure→pass。
3. **Repair-response**：4 任务、8 视图；current 与 code-reversed 公共命令返回码完全一致。

同任务 group-wise patch stopping 也查到与 R4P 的直接重叠，不能作为新方法。P3 typed fixed instance 因可训练机会不足而关闭，效果标记为 `NOT_EVALUATED`，不能包装成负结果。

## 最新可复现筛选

`analysis/future_repair_signal_screen.py` 和 `runs/future-repair-signal-screen-20260930.json` 对 train_ext 做了一个只用于信号诊断的 future-repair 目标筛选：

- 13,601 个决策点，1,830 个正例，300 个任务；
- 任务分组 5 折 HistGradientBoosting，AUC=0.7892185481；
- `test_read=false`；没有拟合部署策略、没有选择阈值、没有读取 test。

这个结果说明过渡标签有一定可预测性，但 AUC 本身不构成方法贡献，也不能证明预算回收有效。下一步若继续，应先在 ext 上定义严格的三动作控制器和成本/未知规则，再由独立 review 判断是否值得训练；不得直接把该 AUC 写成论文主结果。

随后做了一个严格的 train_ext→dev policy screen：future-repair AUC=0.8079，但把 `p_future_repair` 作为“低于阈值即可停止”的唯一控制信号时，解决率损失不超过 1 个点的最优点是不停止，输入节省 0%。因此该监督目前只能算可预测性证据，不能算方法效果。

当前正确性头与 future-repair 头的组合网格（`p_now` 高或 `p_future_repair` 低即停止）在解决率不降时最多省 4.42% 输入，仍低于已有 0.6B 文本基线约 11%；作为负对照保留，不升级为主方法。

## 资源和运行状态

- GPU6/7 是 JEV 的长期资源；当前没有需要保留的 vLLM 服务或训练队列时，可用于新实验。提交长作业前仍须使用 `gpu_job`，并记录 lease、GPU 小时和退出原因。
- GPU0–5 不得触碰。
- 额外 checkpoint 扩展 run `runs/ckpt-ext-20260925/` 已结束：600 个计划尝试中 586 个有 checkpoint label，14 个错误（12 个 RuntimeError，2 个 VerifierTimeoutError）。这是独立采集收据，尚未自动并入 canonical dataset；使用前必须做 task/rollout 去重、unknown 分母核对和官方 verifier 完整性检查。
- 原 final1 queue 曾因 `skyrl-rl` exit 137 中断；final1 recovery4 与 final2 successor 已完成。stale queue state 不代表仍有运行任务，须以 successor 的 completion、process.log 和 readout 为准。
- 不使用全局 `pkill`、`docker rm` 或 `docker prune`；清理必须指向本项目明确的 PID/容器。

## 悬而未决的问题

1. **是否能形成真正的方法贡献？** 目前答案是否定的。优先验证主动执行证据或新的可识别监督；若没有稳定的 dev 增益，应停止扩展候选而不是改写结论。
2. **未来修复标签是否值得训练？** ext AUC=0.789 是正面信号，但还没有显示决策收益。需要一个预登记的控制器、严格的 task-group cross-fit、未知标签处理和 reviewer gate。
3. **9B hidden-state probe 是否值得做？** 提取器和线性 probe 代码已写好，但 CUDA-only kernel 尚未在不影响采集的卡上验证。若执行，先暂停一个 JEV 卡、保留另一个，采完后再恢复 keeper；结果只能先用于 dev/ext。
4. **是否扩展更多任务？** ext 已有 300 任务，除非新方法明确需要额外监督，否则不再无目标扩数据。
5. **论文什么时候写？** 用户允许等待约十个月，但要求方法创新。当前不应调用最终论文改稿循环；只有在 result-to-claim 明确支持主方法后，才调用 `aris:auto-paper-improvement-loop` 做两轮 review–edit–compile，并编译 PDF。
6. **Luna 切换时间？** 已有会话记录：2026-09-27 18:34:56（北京时间）切到 `gpt-5.6-luna`，19:21:27 切回 `gpt-6-astra`，约 46 分钟；日志只能确认设置和时间，不能确认触发者或原因。当前系统模型以本会话显示为准。

## 接手顺序

1. 先读本文件、`STATUS.md`、`refine-logs/DIRECTION_20260925.md`、`refine-logs/NEW_METHOD_IDEAS_20260930.md` 和三条路线的 pilot plan。
2. 检查 GPU6/7、现有进程和磁盘；不要读 test 标签。
3. 对 future-repair 只做预登记的 ext/dev 信号和控制器筛选，先过独立 result-to-claim / experiment-audit，再决定是否占 GPU。
4. 若没有可辩护创新，保留真实负结果，暂停方法扩展；不要用“省 token”单独包装成方法论文。
5. 若方法通过 dev 门槛，写入 freeze manifest，独立审计后才一次性评 test；最后调用 ARIS 论文技能完成论文和 PDF。

## 必须保持的审计原则

- 真实标签、失败和 unknown 保留原样；不能把 unknown 当 0 或删分母。
- 输入 token、输出 token、0.6B 逻辑 token、actor/examiner 成本分开报告。
- 同一 feature set 的多个 seed 不是独立数据复现；ext fit 不能冒充 dev/test 效果。
- reviewer verdict、同族 provisional review 和真实实验结果分开标记。
- 每个新脚本完成后立即提交 Git，只 stage `paper-jev` 明确路径。