移动端热榜死链源自存储层漏查 item_id，浮层问题另在 flex 布局（2026-10-12）
手机上所有看起来像前端的问题，最后都可能是存储层漏了一个字段。
中午打开博客 /news/，手机端两个毛病一起冒出来：热榜点进去报「缺少文章参数」，滚动时头部还浮在半透明遮罩上方。当时直觉是两个独立的前端 bug，结果一个要改到 store.py 的 SQL，另一个得重新排一遍移动端 flex 布局，还发现本机浏览器根本起不来，连张截图都没法自证。
一、热榜点进去「缺少文章参数」——根因在 hot_now() 少查了一个字段先看症状：博客 demoblog.4everland.website/news/ 的热榜条目点开后，阅读页直接显示「缺少文章参数」。刚开始我以为是 article.js 的参数解析问题，但顺着链路追下去，问题在存储层。
具体链路是：
lib/store.py:hot_now() 从 hot_snapshot 取数，SELECT 里**只有 cluster_id，没有 item_id**。
服务端 _deco() 按 item_id 生成 item_url，返回的 JSON 里 item_id 就是 null。
博客页 esc(undefined) 变成空字符串，d ...
头条资讯站复用书库骨架，公网入口打通靠图片域名与CF隧道配置合并（2026-10-11）
金句：新闻站的坑从来不在接口签名，而在图片域名和 CF 隧道的配置合并。
今天把书库骨架复用成新闻聚合站，从上午接口验证到晚上日期归档，基本是一天打满。写这篇时站已经改叫「头条资讯」，入口挂在 https://news.demo.fan。
一、仿书库的骨架，新写的只有采集器、新闻库、新闻页书库那套东西是现成的，Flask 8800 后面跟只读网关，再走 CF 隧道，最后用看门狗守护。新闻站真正要新写的只有三块：采集器、新闻库、新闻页，剩下全部复用。
落地后的架构很干净：
news_fetcher.py --loop：采集器，热榜 5 分钟一轮、频道流 15 分钟一轮，带单实例锁和 30 秒心跳文件 .fetcher_heartbeat
data/news.db：SQLite，四张表 news / hot_snapshot / fetch_log / meta
news_server.py :8802：纯标准库 http.server，零依赖
news_gate.py :8803：只读白名单网关，fail-closed，POST 全部 403
watchdog.py：三段守护，分别探活 ...
29.3GB书库静态化进Hexo，186字节垃圾注入致白屏（2026-10-10）
最坑的不是 30GB 的书，而是一个 186 字节的垃圾注入。
今天把 E:\yunpan_hub 的 932 本书静态化进了博客，部署到 GitHub Pages 上线。这活儿本来看起来只是“导个目录”，结果卡在一个插件污染 JSON 的问题上，差点让整个书库页白屏。
一、为什么选静态化：三条隧道内嵌路线全废最初想的是把本机书库服务通过隧道嵌进博客。结果三条路线全部排除：demo.fan 域名将要过期，用户确认以后不再用；xEdge 第三方组网免费套餐不含内网穿透；cpolar 免费版域名随机变。既然公网隧道都走不通，只剩方案①：把书库静态化进 Hexo，直接发布到 GitHub Pages，零成本、不依赖本机开机。
确定方案后，第一步就是盘货。
二、先盘货：932 本书只导出元数据+封面书库原始体积 29.3 GB，肯定不能直接传。所以只导出元数据 + 封面。
实测数据：
项
数值
书籍总数
932（931 本有封面）
格式分布
PDF 527 / TXT 173 / MOBI 150 / EPUB 64 / AZW3 18
...
rolling_signal_backtest 两个 P0 修复后多重校正推翻 p=0.049 显著性（2026-10-09）
今天最关键的判断：回测里报出的 p=0.049 根本不能算显著，多重检验一校正直接回到 0.1975。
上午还顺手发了那篇耐克市值蒸发的知乎商业稿，下午就一头扎进 C:\Users\Administrator\Documents\craw_app1_wz\defi_dashboard。原以为只是修 rolling_signal_backtest.py 的两个 P0，结果后来越挖越发现，回测和线上压根不是一个玩法。
一、早上先做了一遍博客只读核查没什么大动作，但结论很明确：本地 D:/blog 是 Hexo 源码工程，本身不是 git 仓库；真正部署的是 git@github.com:wz-git-hub/wz-git-hub.github.io，仓库里只有构建产物，没有 source/。远程 master HEAD 是 47dd05ca7548d1a2c019818142715d98ab11915e，pushedAt 11:00:57，本地 .deploy_git 与远程逐字节一致，44 个 tracked 文件一个不多一个不少。唯一异常是 source/about/inde ...
交易机反复硬锁死四个月，硬件根因修复后由 Driver Verifier 布防（2026-10-08）
既然 HL_DRY_RUN=1，蓝屏就不是故障，是等 Verifier 点名的预期行为。
今天把这台从 6 月到 10 月反复硬锁死的交易机收了个尾：硬件根因已经修掉，软件根因还在监控，剩下就是让 Driver Verifier 布防，等它自己指名。整个过程踩了不少 Windows 运维的坑，值得原样记下来。
一、主机与运行环境这台机器 PC-20260408JPNQ 是 7x24 交易栈宿主，跟 craw_app1_wz 同机。核心配置：Intel Core i5-14600KF（Raptor Lake Refresh，Family6 Model183），Maxsun MS-Terminator B760M D5 主板，单条 16GB Asgard DDR5 内存，1TB NVMe 系统盘加 8TB SATA 数据盘，RTX 2080 Ti，Windows 11 26H2 build 26300.9457。上面跑着 defi_dashboard（Streamlit+MySQL+多个 python/node）、YunpanHub、Hermes agent、ollam ...
Hyperliquid 链上余额与数据库漂移两个数量级，A2 扫描同步排查（2026-10-07）
链上余额 7.2042，库里躺着 13203.71，漂移 183178.86%，这不是阈值超了，是基线已经飞出去两个数量级。
今天原本只想做几个只读检查，结果第一条命令就直接把红色告警拍在脸上。后面又跑了一次 A2 OOS tracker，还顺手确认了一篇知乎文章的发布回执。
一、20:05，_sm_sanity_check.py 直接甩出 ALERT当时我在 C:/Users/Administrator/Documents/craw_app1_wz/defi_dashboard 里跑一条 sanity check，命令是 C:/ProgramData/anaconda3/python.exe -u _sm_sanity_check.py，Bash 调用必须带 dangerouslyDisableSandbox:true，因为脚本要访问 HL testnet 外网。
脚本 stdout 打印了 ALERT，退出码 1。关键数字如下：
指标
数值
链上余额 chain
7.2042
DB 总值 (cur+open_margin=80.14)
13203.7100 ...
A2 样本连续二十多轮停在 n=19，maxDD 格式化缺陷同现（2026-09-30）
样本冻结本身不是风险，真正的风险是把 stdout 里的 427.8% 当成写库真值。
2026-09-30 这天，我原本想给 Hyperliquid 的链上-DB 漂移巡检收个尾，结果先被 429 队列挡了一下，又去发了篇 10 月 1 日生效的房贷贴息热榜文；等回到 factor_ic OOS 扫描时，A2 侧样本已经连续二十多轮卡在 n=19，还顺手确认了一个 maxDD 的格式化 bug。
一、早上的 HL 对账巡检，被 429 拦了一下按计划，我先在 C:/Users/Administrator/Documents/craw_app1_wz/defi_dashboard 下跑 Hyperliquid smart_money 账户的链上-DB 漂移检查，脚本是 _sm_sanity_check.py，只读，不加任何 --apply。结果对话里先冒出来一串 429 queue.full.title 和 429 queue.waiting.title，脚本的完整 stdout 一直没拿到。后面我又补了一条只读对账巡检，跑 hl_reconcile.py（默认 dry-ru ...
A1 判 HALT 与 A2 判 NO_ACTION 在同套 factor_ic 下并存，关键在阈值门差异（2026-09-29）
A1 判 HALT，A2 判 NO_ACTION，同一天、同一套 factor_ic，结论完全相反——但并不是谁错了，而是它俩卡的门完全不一样。
2026-09-29 这天，从凌晨 00:40 到早上 05:56，我基本住在 factor_ic OOS tracker 的扫描输出里。两个 arm 轮流跑，中间还插了一次 Hyperliquid 的只读对账。最后没毕业、没阻断，但有几个数字和判断值得记下来，尤其是那个 stdout 的 maxDD 百分号 bug 和 A2 样本池六轮一动不动。
一、A2 那边：n=19 冻结六轮，NO_ACTION 一路到底A2 的扫描从凌晨 00:40 的第 75 轮开始，我在终端里守着看它输出表。Gate1 样本数 19，阈值是 ≥30（A2 更严），直接 ❌；Gate2 binomial p 0.6476（win 8/19，胜率 42.1%），远大于 0.05，❌；Gate3 年化 Sharpe −7.477，❌；Gate4 maxDD 写库是 4.2782，按真实值 ≤30% 是 ✅，但 stdout 打印 427.8%，后面 ...
Hyperliquid testnet 只读巡检与策略归因，代理变量清空防 502（2026-09-28）
只读不写是今天所有操作的第一原则，而样本量不足时，不出结论就是最正确的结论。
今天在 C:\Users\Administrator\Documents\craw_app1_wz\defi_dashboard 做了三件只读的事：HL testnet 对账巡检、策略级归因分析、factor_ic OOS tracker 双轨扫描。一整天下来，没动一行策略代码、没重启任何进程、没写一次生产库。以下按时间顺序复盘。
一、HL testnet 只读对账巡检上午先跑 hl_reconcile.py，默认 dry-run，不加任何写参数。启动前必须先把系统代理变量清空，否则容易 502：
123456set HTTPS_PROXY=""set HTTP_PROXY=""set http_proxy=""set https_proxy=""set ALL_PROXY=""set all_proxy=""
然后执行：
1C:\ProgramData\anaconda3\python. ...
假 PnL 追踪到链上未知仓位，smart-money 保证金被占死（2026-09-22）
真正让 trader 停摆的不是某个策略赚不到钱，而是链上有一批它自己根本不知道的仓位，正死死占着保证金。 今天这份复盘，本质上是把 09-11 那笔 -$98.57 的 orphan_reconcile 假损失给翻了个底朝天——最后发现我们之前一直在跟自己的影子打架。
一、早上先查盘面：11 天没开新仓今天 09:58 我启动诊断的时候，第一反应是“别又是策略逻辑写挂了”。psutil 里能看到的一串进程全是 ALIVE：smart_money_trader 10s 主循环在 tick=140，smart_money_signal 每 15s 左右写一次日志，watchdog 09:54:36 刚跑完一轮，streamlit_dashboard 端口 8501 返回 HTTP 200。看起来系统全活。
再看 sm_account 表，09:47:40 的快照写着 current_usdc=10045.98，realized_pnl=+51.19，W/L=58/57。单看这个账面，trader 就是“没在交易”，不是死了。
但 ...