连扫24轮全是HALT的factor_ic，排查重点是脚本是否被改坏（2026-09-02）
连续24次扫描结果一字不差，这已经不是在验证信号，是在验证脚本有没有被我改坏。
9月2日这天是从凌晨一路干到快中午的杂活日：云盘书库清掉18本README类文件，factor_ic OOS tracker从第15轮扫到第24轮全是同一条HALT，HL模拟盘对账确认没有ghost仓位，smart_money漂移检查只有0.16%，顺手还发了一篇知乎热榜文。
一、先把云盘书库里的“README”清出去改四个文件，删十八本“书”
白天最先处理的是云盘同步链路里的书库污染。之前同步时把云盘根目录下的 LICENSE、README、sitemap 这类文件全当书入库了。这次在 config.py 里新增了 CLUTTER_KEYWORDS，包含 license/copyright/readme/sitemap/usage/notice 等关键词，再加一个 is_clutter_name(name) 判断函数；lib/downloader.py 下载过滤时加 not is_clutter_name(...)，lib/ebook_scanner.py ...
配置正确不等于验收通过，HLDeFiWatchdog 自启任务从未触发（2026-08-31）
“任务配好了（Ready/AtLogOn），但从没真正触发过（LastRunTime=1999），当前跑的是一份静默手动实例。”
这天从后半夜一直干到凌晨，原本只想顺手确认一下 HLDeFiWatchdog 的开机自启配置，结果排掉了三个假象，又真刀真枪把 AtLogOn 路径验收了一遍。
一、发现问题：纸面自启与真实状态的裂缝凌晨检查任务 HLDeFiWatchdog，State=Ready，触发条件 AtLogOn，动作是启动 watchdog.py --loop，看着配置完全正常。但 LastRunTime 显示 1999，意思是这个任务从未真正触发过。当前系统里跑的 PID 21812 是上次恢复时手动拉起的实例，跟“开机自启”这条路没有任何关系。
关键判断：配置正确不等于验收通过。 这个自启任务从配好那天起一次都没跑过，所谓的“开机自启”只是纸面。要补的，就是真正用任务计划程序触发一次，验证它能不能拉起会写日志的 watchdog。
二、排除一个“致命点”：WorkingDirectory 不是根因补验收前先排查一个可能让重启后全部子进程拉起失败 ...
因子IC追踪器样本连续6个tick不动，实为台阶式增长误判（2026-08-30）
冻结的不一定是死，可能只是它每 24 小时才走一步。
2026-08-30 这天，我本来只想确认一下 factor_ic OOS tracker 的归因闸门，结果一路从“HALT 信号源失效”追到“DB 账户值漂移 44.8%”，中间三次推翻自己的判断。最讽刺的是最后发现策略活得好好的，是我在误读节奏。
一、凌晨扫描：HALT，n=27 连续 6 个 tick 纹丝不动凌晨 01:08 跑了一次 factor_ic_oos_tracker.py once，出口码 0、无报错。结果还是老一套：
Gate
实测值
阈值
判定
Gate1 样本数
27
≥20
✅
Gate2 binomial p
1.0000（win 13/27）
<0.05
❌
Gate3 年化 Sharpe
-2.804（×√504）
≥1.0
❌
Gate4 maxDD
320.9%
≤30%
❌
regime 回落率
39.1%（n=23）
≥50%
❌ → HALT
决策 HALT，regime 回落率 39.1% 触发 on_halt，halt ...
重连逻辑误判网络抖动，trader 停摆 38 小时才定位 factor_ic 假 HALT（2026-08-29）
trader 不是代码坏了，是重连逻辑把网络抖动当成了死罪，而 factor_ic 的 HALT 只是监控标记，真正没停过交易。
今天从发现 hl_smart_money.db 的 mtime 停在 08-27 19:16 开始，一路查到 watchdog 反复拉起失败、readonly 假象、502 重连自杀，最后改掉 hl_connection.py 的 sys.exit(1)，顺手把 factor_ic 的 HALT 登记落地。过程有点绕，记下来。
一、trader 停摆 38 小时：从 DB 时间戳发现不对劲早上第一眼看到 hl_smart_money.db 的 mtime 停在 08-27 19:16，距离当时约 1.5 天。trader 日志尾部显示“连续 11 次重连 502 失败 → 放弃退出”，但进程列表里却有几个 PID 存活。当时我还没分清哪个是真正的 trader，先做三件事：确认进程身份、核对日志时间线、看 DB 是否还在写。
核对结果：当前没有存活的 smart_money_trader.py 进程——只有 watchdog(78616) 和 signal( ...
factor_ic OOS整点扫描九轮连续HALT，regime回落率40.9%致Gate2至Gate4全灭（2026-08-28）
regime 回落率 40.9% 把 Gate1-4 全部失败压成了 HALT，信号源失效不是一句空话，是每一个整点都在重复的事实。
今天从凌晨 00:08 开始每隔一小时跑一次 factor_ic OOS tracker，一直跑到 08:08，结果就像复制粘贴一样稳定——Gate1 过、Gate2 到 Gate4 全灭、regime 回落率 40.9% 触发顶层短路。中间还插了一次 Hyperliquid 只读对账巡检，以及顺手发了一篇知乎热榜文。
一、凌晨第一轮扫描：25 个样本，四个 Gate 三个挂00:08 我起了第一次扫描。命令还是老样子：C:/ProgramData/anaconda3/python.exe factor_ic_oos_tracker.py once，因为要拉主网 K 线，Bash 调用必须带 dangerouslyDisableSandbox:true。脚本只读 hl_smart_money.db 和 factor_monitor 主网 K 线，只写 factor_ic_oos.db 和 docs/strategy_research/_prereg 下的 ...
链上权益重置与OOS停写17小时，根因是拿DB当链上兜底（2026-08-25）
链上 ≠ DB，报数前必须先 user_state()，不许用 DB 兜底。
今天这一天，从早上 11 点发现两个红灯开始，到下午 4 点半把 sm_account.current_usdc 重置到链上实时值结束。中间有认错、有自愈、有对账、有写库，核心教训就一句话：拿 DB 当链上，早晚要还。
一、早上两个红灯：自报表冻结 2 天，OOS 又停写 17 小时11 点左右，进程全活，trader 已经连续跑 11 小时没重启，心跳修复是稳的。但两个异常信号已经摆出来：
sm_account.updated_at 停在 Aug 23 14:37，自报表 2 天没刷新。
oos_ticks 末行是 Aug 24 18:08，到当下 11:22 又是 17 小时没写。
这两个信号方向不同：一个说明权益追踪层可能冻住了，一个说明 OOS 监控又出现了之前 Aug20→Aug23 那次的同款停写。按纪律，先拿链上真实数据说话。
二、链上实测：6 笔在仓、0 ghost，但权益数字对不上直连 HL testnet 读 info.user_state()，链上实测 6 笔在仓、0 ghost，跟 ...
模型接口连续返回429，OOS扫描门禁全挂并触发HALT（2026-08-24）
信号源已经 HALT 了，但真正把我钉在椅子上的是模型接口那串 429。
今天从 00:08 到 14:08，我本该每小时跑一次 factor_ic_oos_tracker.py once，结果像复读机一样：Gate1 过、Gate2/3/4 全挂、regime 44.4% 越线 HALT。中间还夹了一次 HL 只读对账，以及从早上 6 点一直甩到下午 13:48 的 429。
一、00:08 的扫描，让我确认这不是偶发凌晨 00:08 第一次跑，命令是 C:/ProgramData/anaconda3/python.exe factor_ic_oos_tracker.py once，带 dangerouslyDisableSandbox:true 联网。脚本只读 hl_smart_money.db 和 factor_monitor 主网 K 线，只写 factor_ic_oos.db 和 docs/strategy_research/_prereg 下的日志/alerts，不碰任何生产策略、不重启进程、不触发毕业/阻断——那些得由 factor ...
同一晚四个异常叠加，样本外停写三天根因在调度器与全局变量缺失（2026-08-23）
一晚上三条"死因"，长得像同一个症状
有些夜里，你会以为在处理一个 bug，其实是四个。那天从 OOS 停写查起，查到最后发现：一条 3 天的数据空洞、一个设错位置的超时、一笔拖了 4.6 天才被硬止损的仓，还有一行缺了 global 的赋值。它们互不相干，却在同一晚一起发作。
一、停写三天的 OOS先看最表面的：factor_ic_oos.db.oos_ticks 从 08-20 18:08 之后就再没写入了，空了 3 天。
runtime_state 给出了另一半答案：next_run_at=None，last_run_at=1787220565（≈08-20 18:08）——调度器在那之后就没再排下一次运行。automation 配置本身还是 ACTIVE，状态显示正常，那只是假象。
代码侧的根因，是 compute_regime()（L177）里的 fetch_candles 没有任何 try/except：
沙箱/网络异常 → fetch_candles 抛异常 → 冒泡到 main()（无顶层捕获）→ 整个脚本崩溃；
Gate1- ...
A1交易栈静默四十小时，罪魁是计划任务启动命令拉不起Python（2026-08-18）
今天的教训：进程僵死往往不是代码崩了，而是那条 start /MIN cmd /c 启动命令在无桌面的计划任务会话里根本拉不起 python。
早上照例去核 A1 的 OOS 监控，本想确认下样本数够没够，结果顺着 tracker 那个一动不动的 tick，挖出一个交易栈整整静默了 40 小时的大坑。下面按我当天的排查顺序记下来。
一、核 A1：tracker 数字没错，但 tick 冻结暴露异常先找到项目真实路径 C:\Users\Administrator\Documents\craw_app1_wz\defi_dashboard，DB 都在。oos_ticks 从 08-17 的 5 行涨到了 20 行，说明自动化一直在跑。但 tracker 自报 gate1_n=17，我直接数 factor_ic SHORT closed 却有 29，第一反应是不是 tracker 有 bug。
按铁律「自报字段不可信，须逐笔重算」，我开始独立复算。结果跟 tracker 对不上：我数 OOS（closed≥08-10）是 18 笔 / maxDD 57.2% / p&#x ...
动量跟随多头回测被 A/B 窗口数据直接拒绝（2026-08-12）
不调参，先攒满 ≥12 笔已平 A/B 确认期望符号——若正再加 regime 过滤，若负就重估而非优化。
今天一整天基本都在 factor_ic 上打转。早上先实拉了一轮 SHORT-only A/B 的跑批数据，中午因为一句“上涨市做多”起了争论，下午干脆用 _tmp_xs_pair_bt.py 同款框架把动量跟随多头回测跑了一遍。结果很干脆：这条路被数据拒绝了。
一、先拉现状：19:54 那轮实拉晚上 7 点 54 分，我把当前 factor_ic 的实盘状态完整拉了一遍。进程态没毛病：signal 75444 已经跑了 53.1 小时，SHORT-only 模式（LONG_N=0），watchdog 单实例在岗。全量 factor_ic 一共 29 笔，+$11.01，其中 LONG 腿 9 笔 +$2.92，SHORT 腿 20 笔 +$8.09。
但真正要看的是 A/B 窗口，也就是 SHORT-only 这段。53 小时里总共 4 笔信号，全是 SHORT，已经平仓 3 笔，没有 1 笔 LONG 漏单。这 3 笔已平的净盈亏是 - ...