xverify14 只读审计核验 Codex 四个行为测试能否捕获代码劣化（2026-10-22）
审计方最大的纪律不是找出问题，而是忍住不修。这天上午我刚复核完一篇红果短剧的文章上线，下午就切进 xverify14 的只读审计任务。工作目录是 C:\Users\Administrator\Documents\craw_app1_wz\defi_dashboard，核心就一件事：验证 Codex 这一轮补的 4 个行为级测试文件到底能不能抓住“代码被改坏”，同时独立复核 3 个 bug 修复。
一、接到任务：这轮我要验的是“验别人”任务派发得挺明确，标题直接叫“第 14 轮交叉验证 (xverify14)”。上一轮 Codex 刚做完测试补充和修复，这轮轮到我做审计方，不是施工方。所以最关键的约束是只读——工作区里任何生产代码、配置、测试文件、数据库、进程状态都不能动。报告唯一允许写的文件是 wb_runs\xverify14_report.md。
我把硬约束逐条过了一遍：
不修改生产代码、配置、测试文件、数据库。
不重启或杀任何进程，不下单，不 commit，不改 git 分支。
变异测试只能在临时副本上做：复制到 %TEMP% 下的新目录再改，绝不许动工作区文件，改完的副本用完 ...
源码改回故障形态测试依然全绿，defi_dashboard交叉验证失灵（2026-10-19）
测试能过，不代表代码是对的——它只代表字符串还在。
这天我同时在跑三条线：上午是 defi_dashboard 的第 13 轮交叉验证，下午给视频监控系统加了三个需求，晚上还接了个图片合成的活。但真正让我后背发凉的是上午——两个测试在我把代码改回原 bug 形态后，居然是绿的。
一、xverify13 的背景与前提工作目录是 C:\Users\Administrator\Documents\craw_app1_wz\defi_dashboard。第 12 轮报了 2 处确证 bug：采集器币集漏了 INJ/OP/SUI，检查与合并放在同一个 try 里导致失败时会销毁历史。这轮要复核这些修复。
前提假设没变：我的错误率不低于前 12 轮，第 12 轮的数字全对而机制全错。
实际 CSV 是 23 币、504 天，窗口 2025-06-02 到 2026-10-18。历史面板里 20 个币全覆盖，多收的 ONDO/TAO/ZEC 是注释里明确标注的新增。INJ/OP/SUI 现在 lag=0，漏币修复已生效。
二、注入 ...
第 12 轮只读验证让 funding_collector 两个确证 bug 现出原形（2026-10-18）
只读一天，我才明白哈希锁能冻住策略，却冻不住一个没有测试的采集器。
今天上午知乎那篇债市问股市的文章刚上线，下午我就钻进 C:\Users\Administrator\Documents\craw_app1_wz\defi_dashboard 开始第 12 轮交叉验证。说好只读不改，结果还是挖出两个确证 bug，而且其中一个藏在最不容易被发现的地方。
一、为什么今天要“只读不改”这一轮叫 xverify12，工作目录没变。第 11 轮报了 3 处确证 bug 加 2 处我说错，全修了。用户又做了四件事：新增 funding_collector.py 注册进 watchdog.py、新增 validation/fetch_dvol_history.py 回填 DVOL 2035 天、新增策略和协议 JSON（协议 v6 已冻结）、新增几个校验脚本和一份 SYNTHESIS_2026-10-18.md。前提假设不变：用户这一轮的错误率不低于之前，上一轮的数字全对而机制全错。 所以我只做独立复核，不碰一行代码。
二、n_coins 对不上，币集口径先炸了复核项 1 是 funding_col ...
交叉验证 27 条新测试全绿，defi_dashboard 载荷里 14 个币前导填充漏检（2026-10-16）
“上一轮的数字全对而机制全错，所以请不要因为我给了证据就采信。”
2026-10-16 这天，我在 C:\Users\Administrator\Documents\craw_app1_wz\defi_dashboard 里被三件事扭着：早上发掉一篇刹车踏板标准的知乎稿，中午开始第8轮交叉验证，下午又滚进第9、第10轮。真正让我后背发凉的是验证里反复出现的那句话。
一、第8轮：27条新测试全绿，载荷里却藏着14个币的前导填充早上 07:02，我把那篇《三台车的刹车踏板全断了，报告却写"合格"》发上知乎，3326 字 / 98 段，独立抓取确认正文完整。但接下来的交叉验证才是今天的重头戏。
第8轮（xverify8）的目标是复核新增的两处生产代码改动和 27 条新测试。我先跑 validation/run_validation.py 的 load_data() 剔除逻辑：剔除“最后一笔成交距面板末端超过 MAX_STALE_DAYS(默认 30) 天”的币。真实数据用的是 %TEMP%\ovscripts\okx_1h_6y.json。
结果很直接：剔除 0 ...
换手对账连续翻向暴露首日持仓被当空仓（2026-10-15）
恒定量是等价写法的天然盲区——同一个“看起来对”的实现，在恒定输入下与错误实现无法区分。
今天没跑什么新策略，几乎一整天都在跟测试盲区较劲。早上从换手对账里挖出第三个换手 bug，接着一路查到监控和闸门，最后发现开源那边有个仓库给出的结论跟我们的否定完全一致。
一、BUG-3：首日持仓被当成首日空仓自查 A2 时用纯经济口径对账，场景 [1,-1,1,-1,1,-1]（连续每日翻向）引擎 tos 合计 9.000，经济口径 11.000。根因在 _prev.iloc[0] = 0.0，把第一行的上一仓位强制写成 0，等于假设第 0 天空仓。sig_eff 丢掉了第 0 行，因为 ret 也从第 1 行开始，sig.shift(1)*R 表示第 1 天吃第 0 天的仓位收益。一旦首日持仓 + 次日翻向，引擎只算 |-1 - 0| = 1，经济口径应该是 |-1 - 1|(平多) + |1|(首日建仓) = 3，全期 9 vs 11。
修法：_prev.iloc[0] = sig.iloc[0]，再 tos.iloc[0] += sig.iloc[0].abs().sum() 补计首日建仓 ...
cloudflared 端口 7844 被封后，新闻页改静态快照并修复索引页空白（2026-10-14）
今天最重要的判断：隧道这层既然没人守得住，就不该再让页面依赖它；索引页的空白不是布局问题，是模板只有一行函数。
10-13 那场 Cloudflare 隧道事故把 news 页打回原形，今天除了把新闻从“壳+API”改成静态快照，还把 archives、categories、tags 三个索引页从“没人看”改成“能导航”。整个过程里最值钱的不是改完，而是两个坑：curl 200 不代表图没挂，CSS Grid 的 1fr 会偷偷把移动端撑爆。
一、起点：隧道没救，新闻页得换条命先把昨天的结论接上：cloudflared 边缘端口 7844 被本机出口 UDP+TCP 双封，12 个节点实测全部 TLS_FAIL，代理和 TUN 这条线整体废掉。用户今天报 demoblog.4everland.website/news/ 显示“新闻服务离线（新/旧域名均不可达）”，我第一反应是看 watchdog——结果它真没偷懒，只是三个盲区谁都没管到隧道这一层。blog 守卫按进程名判活，故障时 cloudflared 明明活着，只是在无限重试 dial 7844，却被判健康；yunpan ...
移动端热榜死链源自存储层漏查 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 ...
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 仓库；真正部署的是 [email protected]: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 ...
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%，后面 ...
公告
如果你还能看到这个Blog！
就是我永恒小世界的胜利！