记录一次 factor_ic 第 82 次 HALT 的监控夜（2026-09-03）
记录一次 factor_ic 第 82 次 HALT 的监控夜（2026-09-03）
真正危险的信号源失效，不是突然崩掉，而是每次都稳定地不达标。
那天凌晨 1 点刚过，我照例让自动化去跑 factor_ic OOS tracker。到早上 8 点 15 分，屏幕显示“第 82 次”，结果还是那一串熟悉的数字：regime 回落率 37.0%，HALT。一晚上什么都没变，但这恰恰是最值得记录的地方。
一、第 74 次到第 82 次，全部 HALT
凌晨 01:08，第 75 次扫描 summary 先发过来：Gate1 样本数 31，通过；Gate2 binomial p 0.7201（win 14/31），不通过；Gate3 年化 Sharpe −2.732，不通过；Gate4 maxDD 320.9%，不通过；regime 回落率 37.0%（n=27），阈值 50%，触发 HALT。
命令是 C:/ProgramData/anaconda3/python.exe factor_ic_oos_tracker.py once，Bash 里带 dangerouslyDisableSandbox:true 才能访问主网 K 线。脚本只读 hl_smart_money.db 和 factor_monitor 主网 K 线，只写 factor_ic_oos.db 和 docs/strategy_research/_prereg 下的 alerts/halt log，别的一律不碰。
后面每次跑，数字完全相同：03:10 第 76 次、05:13 某次、07:14 第 81 次、08:15 第 82 次，还是 p=0.7201、Sharpe=−2.732、maxDD=320.9%、regime=37.0%。历史记录里前 73 次也是 HALT，等于这个因子信号已经连续 82 次被判失效。
不是脚本坏了，是信号源真的没起来。
二、一条 failed 通知的虚惊：下载早完成了
白天插进来一条 failed 通知，来自 8 小时前启动的同步监控脚本 xESucp。我第一反应是电子书下载挂了，结果一翻日志发现完全不是那么回事。
17:06 到 18:45，双映射下载逐步到 100%：ebook-sync 25.42GB、ebook-sync2 2.85GB，状态都是 Completed。18:53 收尾 flag sync_finalized.flag 已经生成，删映射和移文件都执行完了。可监控脚本完成任务后没有退出，继续空转 poll 了 2 小时，最后 gRPC 长连接被服务端断开，报 DEADLINE_EXCEEDED，进程异常退出，任务就被标记成 failed。
下载和入库早在 18:45-18:53 就完成了，这个 failed 只是监视器自己被踢下线，对书库零影响。 那天书库 614 本完整，我直接忽略了这条通知。
三、链上-DB 漂移检查：0.25%，没脱钩
上午还跑了一次 Hyperliquid smart_money 的链上-DB 漂移检查，防止 testnet 重置导致 sm_account 基线和链上脱钩。
执行的是 _sm_sanity_check.py，带 dangerouslyDisableSandbox:true。输出一行 OK chain=902.7127 db=904.9517 drift=0.25%，退出码 0。阈值是 5%，0.25% 远低，db_updated 是 2026-09-03T01:04:29Z，六分钟前刚更新，数据新鲜。
不用打扰用户，也不用重置 sm_account。
四、顺手把 52 本 TXT 书封从 PNG 占位改成真 JPEG
下午精力还有剩，我把电子书库的 TXT 封面问题收拾了一遍。之前 52 本 TXT 的封面其实是一堆 PNG 占位编码，文件名还写着 .jpg，标题大量是从正文首行按 UTF-8 读 GBK 得到的乱码，比如 ƪ>ݼҪ 其实是《庆余年》，\ufeff斗破苍穹 前面带 BOM。
方案很简单：从文件名重新解析标题和作者，合成莫兰迪深色系真 JPEG 封面。最后 43 本标题修正，27 本作者补全，全库真封面率从 91%（560/614）拉到 100%（612/614）。还剩 2 本不是 JPEG，无所谓，不影响使用。
五、遗留：HALT 还挂在原地
到 08:15 第 82 次扫描结束，factor_ic OOS 依然是 HALT。按规则，解除挂起需要单独执行 factor_ic_oos_apply.py --confirm，不在当晚自动化范围内。
另外 HL 只读对账巡检发现一个 orphan：hl_testnet.db 里 BTC，szi=+0.00101，entry=79385，upnl=−$1.54，链上有但本 DB 没有，按设计只告警不修复。这条也留着，等下次再说。
那天夜里没有突然的 crash，也没有惊险的脱钩，只有一行行重复的 HALT 和一条假 failed。监控这件事做到最后，往往就是盯着那些“没变化”的数字。