[Shadowell]

为什么

BitPro 每个母体有 3 个变体位，但生产上 12 个位长期占用 0。只读核对生产后发现，变体位空着是因为送候选进来的路几乎不通：

• 34 个在役模拟盘里只有 4 个满足研究报名条件。其余 30 个卡在：同一会话成交满 30 笔、满 14 天、成本元数据与权益采样核验。
• 这 4 个里：
  • 333 被一个挂起副作用占着（已审计对账关闭）。
  • 443 每天在开发回测时报 snapshot_range_exceeds_bound：120 个标的的 15m 数据，119 天开发窗口超过了 BitPro 100 万根的上限。
  • 509、513 的候选在终验同窗都比母体差。
• 10-11 起共 25 个候选，0 个通过严格终验。60 天窗口上要求去偏夏普概率 ≥0.95，约等于年化夏普 4 以上。

用户要求所有策略在上线后或表现差时都能自动产生变体，并逐项拍板：

• 母体满 7 天、满 20 笔后生成；7 天不到 20 笔的低频策略满 7 天也生成。
• 入场改为基本检查，接班标准不降。
• 变体来源是参数微调加 AI 研究。
• 全站赛马上限保持 60。

改了什么（三项都由配置开关控制，默认关闭，合入本身不改变线上行为）

1. 基本入场 paper_admission=basic（任务创建时冻结）。严格终验未过的候选，在同一终验窗口对母体满足以下条件，就以内容绑定的 val_basic_ 编号走原有评审：

   • 成交至少 1 笔，且不少于母体的三成；
   • 收益落后不超过 max(2 个百分点, 母体回撤的一半)；
   • 回撤不超过母体 +5 个百分点，且不超过 30%。

   严格结果如实保留（passed=false 加原因）。状态机没改，复用 candidate_validated。评审包只在基本入场时多一段 admission，严格任务的包和哈希不变。自动评审按存档数字重算，不信任标记。接班仍由 BitPro 前向赛马决定（14 天里赢 12 天）。

2. 上线探索 launch_enabled / launch_days=7：母体 7+7 证据缺失、但已满 N 个完整 UTC 日，且支持来源变体时，以 launch 触发研究。这类任务不声称退化，零成交也行；只对 BitPro 目标生效。

3. 参数微调研究员 exploration_provider=rule_tweak：

   • 探索任务（launch / proactive）由确定性的 RuleTweakProvider 驱动，不调用模型；退化和紧急任务仍用 AI。
   • 只提单参数约 ±20% 的一步邻居。
   • 完整镜像 BitPro 的参数规则：8 对快慢周期递增、动量阈值、整数类型。原因是 BitPro 在建变体时拒绝参数，会被记成未知效果，任务就会卡住。
   • 跳过已赛过或在排队的组合。
   • 开发后对有成交的候选中净收益最高者做终验。
   • 短冷却 exploration_cooldown_hours。

4. 研究窗口适配：按标的数和周期把窗口压进 BitPro 封存回测上限。443 的开发窗口从 119 天改为 81 天。

验证

• 新增 3 个测试文件。
• 38 处守卫变异检验全部被用例抓住；首轮未抓住的 8 处已补用例。
• 完整 ./scripts/check.sh 通过：前端 lint、15 项测试、构建，ruff，mypy 320 个源文件，pytest 2369 项。
• GitNexus 影响分析：build_paper_review 和 ARCController._reduce 为 CRITICAL；_scan、readiness、usage、admit 为 HIGH。应对办法是状态机不改、严格任务的评审包不变、所有新路径默认关闭。

上线后（另行执行）

按用户拍板改生产配置：launch_enabled=true、min_trades 30→20、exploration_provider=rule_tweak、exploration_cooldown_hours=2、paper_admission=basic。

已知限制

• 9 月遗留的研究副本 #529、#531、#532、#533 仍在运行，满 7 天后也会被当作母体（旧规则下 10-25 本来也会）。
• 变体多了以后，BitPro 修改策略共用文件导致的源码漂移影响面会变大。
• 与 feat(arc): 赛马输家逐项消融（开发窗口单因素回测，结果回流研究记忆） #80 有冲突，feat(arc): 赛马输家逐项消融（开发窗口单因素回测，结果回流研究记忆） #80 需要之后整理。

🤖 Generated with Claude Code