工程主题原型：#10 测试范式型（最近四期 013 #1 / 014 #4 / 015 #9 / 016 #7 → #10 五期未用，不重复 ✅）。钩子跨度 10-28（Phase 205.B AST 扫假绿守卫）→ 11-01（Phase 209.D/E）→ 11-03（Phase 210）→ 11-04（Phase 213/214），8 天 / 4 个 phase / 31 个 commit。
引子：三个都很好看的数字
2026-11-04 凌晨 03:05，我面前有三组数字，它们都很好看。
第一组：`2300 passed / 2 skipped / 0 failed`，294 秒，全量实测。
第二组：memos 服务端最近 100 条 memo 的 `attachments` 字段，全部是空数组。往下翻到全量，115 条 security-monitor memo 的 `attachments` 也是 0。
第三组：94 条 diag memo 里，12 条的 `tags` 是空数组 —— 而按 `#sm-fail` 搜这些报告，搜不到任何一条。
三组数字说的是同一件事：测试全绿，功能全废。而且废得很安静 —— 没有一条报错，没有一条告警，只有三个空数组。
问题：守卫在替 bug 作证
附件通道的问题，是从上线那天就存在的。
`memos_client.py` 里上传附件之后有一句判断：响应里的 `content` 字段非空才算成功。这个判断有守卫测试护着，名字叫 `test_attachment_silent_fallback_content_empty` —— 它断言「content 为空 ⇒ 上传失败 ⇒ 返回 None」。
这条测试一直是绿的。它绿了几个月，绿得非常稳定，因为它锁住的正是 bug 本身。
2026-11-04 我在真机上做了 A/B（memos.eggtata.top，不是 mock）：
- `POST /api/v1/attachments` 的响应字段是 `content / createTime / externalLink / filename / name / size / type`
- 其中 `content` 回显恒为空字符串。server 从不回显 inline base64，这是正常行为
- `name` 字段才是真凭据（`attachments/xxx`），`size` 还是个字符串
也就是说：判据从第一天起就是错的。每次上传，服务端都成功了，代码都判失败，`create_memo` 永远不下发 `attachments`。附件通道从上线到现在，一次都没有成功过。
而在 11-03 的 Phase 210 里，我刚刚"修过"这个问题 —— 修的是字段名（`attachmentNames` → `attachments`）。实盘 A/B 证实那个结论是对的。但改完名字，判据还是错的，所以什么都没变。这条后来成了类教训 240：改对名字 ≠ 修好功能。
同一周还有第二层。Phase 213.B 的真机 A/B 是这样：memo 正文里三反引号围栏数是奇数（有未闭合代码块）时，服务端解析出的 `tags` 恒为空数组，而且不报错；围栏偶数时标签正常解析，元素不带 `#`。
根因很蠢：归类模板把 report 正文前 3KB 原样塞进一对围栏，3KB 截断经常落在围栏中间。存量实测：94 条 SM memo 里 12 条奇数围栏 ⇒ 这 12 条 `tags` 全空；82 条偶数 ⇒ 全非空。
第三层更难堪，它出在守卫自己身上。Phase 214.F 发现 `test_phase211_c` 里那句 `INVOKE_RE = re.compile(r"push_diag_to_memos\.py")` 把「文本里提过这个文件名」当成了「调用它」—— sha256 清单字符串、docstring、`hint("… 检查 push_diag_to_memos.py …")` 全被算成新增调用点。原来那个 `_is_comment` 只挡 `#` 开头的行，挡不住三引号。
所以这一期真正的题目不是"修三个 bug"，是：当守卫本身在作伪证，你怎么知道哪条绿灯是真的。
排查：先证明观测层不可信
线索不是从 11-04 开始的。往回翻，四个 phase 都留了记号。
10-28 的 Phase 205.B 是第一次动手：写了一个 AST 扫描器扫 `tests/` 下所有文件，抓三类假绿 —— `tautology`（函数里所有 assert 都是恒真常量，`assert True # placeholder` 就是真案例）、`no_assertion`（只有 pass 和 fixture 装配）、`self_made_subject`（自己 `ArgumentParser()` + `add_argument()`，再断言自己造的 parser 能解析，被测的真实 `src/cli.py` 完全没参与）。白名单还写成双向的：白名单外新增违规要红，白名单条目被修好也要红（不许白名单只增不减），扫描器自己在 `tmp_path` 里造三种样本做自检。
同一天 Phase 205.C 更直接：审计报告说 B02/B05 两个性能数字不成立，实测复核，两个数字都不成立，于是只加了复杂度守卫，实现一行没改。
那次我以为已经解决了问题。实际情况是：扫出来的只是"写得很敷衍的守卫"，扫不出"写得很认真的、但锁着错实现的守卫"。`test_attachment_silent_fallback_content_empty` 就是一个写得很认真的守卫，它有 fixture、有断言、有注释，只是它描述的世界不存在。
11-01 的 Phase 209.D/E 往同一个方向走：details 里失败行优先、memo 补警告数、报告完整性校验。这些都是"让报告更诚实"的动作，但它们都假设采集侧是诚实的。
11-03 的 Phase 210 修了 diag 报告 4 项「查不出来」，其中两项的根因是脚本读错了目录、判定只看 exit code 不看 status。
然后 11-04 凌晨，三处静默失效一起暴露。最刺的一条不是业务代码，是这条：
$ bash scripts/diag_refresh_intel_unit.sh ; echo RC=$?
🟦 Phase 198 disabled-by-design: security-monitor-refresh-intel.service / refresh-intel.timer
已从 git 树删除 (commit 2528e78), daemon 内 IntelRefresher 接管 quota 刷新.
→ RC=0
$ bash scripts/diag_report.sh ; echo RC=$?
🛠️ dev-box 模式: deploy-only 错误视为 warning, 整体视为 PASS
→ RC=0
两项本机都 RC=0，部署机 memo 里却连续 6 天挂着同样的 2 个 ❌。我在 11-02 和 11-03 两轮里都把这解释成「部署机没 pull，落后 10 个 commit，所以修了也没用」。
11-04 03:05 我自己把这条推翻了：部署机 11-03 22:56 那三条 memo 已经是新模板 `🚨 diag 报告归类 (Phase 91.A / 209.E)`。模板更换是 `bbb43cd`（11-01 01:38）引入的 —— 也就是说部署机早就 pull 了，2 项 fail 真的清零了，`33 = 32 ✅ + 1 ⚠️ + 0 ❌`。
判据本身没错（用 memo 模板当版本指纹，这是没有 SSH 权限时唯一可行的办法）。错在样本选择：我看的是「窗口内最后一条之前」的 memo，不是「窗口内最后一条」。同一份数据里既有旧指纹又有新指纹时，读哪一条直接决定了结论。
而真正让那 2 项看起来还在的原因，是另一层：推送链路推的是上一轮的报告。11-03 22:56 连推 3 条 memo，装的全是 11-03 02:00 那份旧报告；11-04 02:00 推的 2 条，装的是 22:56 那份。根因在 `diag_all.sh`：报告先写 `.tmp.
「刚推的」不等于「刚生成的」。
修复：先让守卫说真话，再让链路真的通
顺序很重要：先修判据，再修数据。
判据侧（Phase 213.A）：上传成功判据改成 `name` 存在即成功，`size` 做一致性 sanity check（不一致只 WARNING，不改结论），`content` 为空降级成 debug。两处假 fixture（`test_phase87_a/b` 的 FakeMemosServer）改成真机 shape，那个锁着错判据的第二号假守卫改名反转成 `test_attachment_content_empty_is_success_not_failure`，`diag_report_analyzer` 里指向已删除文案的死 pattern 改指真机失败信号。
渲染侧（Phase 213.B）：加了 `_fence_count` / `_balance_fences` / `_truncate_fence_safe` / `_fence_safe_slice`，把截断上限从 4000 压到 3840 —— 这 160 字符是留给 `create_memo` 追加的标签行的，否则二次截断会把标签切掉。
存量侧（Phase 214.D）：只 PATCH 不 DELETE。先单条验证：fence `13 → 14`，标签行 `inside_code_block=True → False`，PATCH 后 readback `tags=['sm-fail','sm-2026-11-03']`；再批量 `patched=8 failed=0 skipped=92`。今天我实跑复核全库：
$ python3 scripts/memos_retag_missing_tags.py --check --limit 400
{"mode": "check", "scanned": 168, "sm_marked": 120,
"odd_fence": 0, "missing_tags": 0, "limit": 400}
168 条 / 120 条带 SM 标记，奇数围栏 0，丢标签 0。回填前这个数字是 9。
观测侧（Phase 214.F）三处，全是"沉默的失效"：`(bash diag_all.sh 2>&1 | tail -10)` 取到的是 `tail` 的 `$?`（恒 0）⇒ diag_all 失败一条告警都不打，改 `PIPESTATUS[0]`；报告查找硬编码 `/tmp`，生产者却写 `${TMPDIR:-/tmp}`；`${arr[@]/$FILTER/}` 是字符串替换不是删除 ⇒ 传一个不存在的 pattern 仍跑满 32 个 diag，那个 filter 从来没过滤过任何东西。
还有一个不叫 bug 的 bug：同一条 memos 通道上跑着两个来源，dev box 连推 6 条本地报告，把真实部署机那份挤出了拉取窗口。真机只读实测 72 小时内 20 条 `#sm-`，按项目根过滤后保留 14 条、丢弃 6 条；缺 `项目根` 字段的 memo 走 fail-open 保留并单独计数 —— 静默丢报告比留噪音严重（Phase 214.E）。
存量回填那条路上还留了两个坑，都不在代码里。一是探针：A/B 测试 POST 出去的 12 条 `#sm-probe` memo 当场没删，而它们没有 `项目根` 字段，会走 fail-open 直接进 inbox —— 自己造的数据成了下一轮噪音（类教训 244）。二是 dry-run：脚本输出的 `verified:false` 在 dry-run 下必然为假，它只能证明"将要改什么"，不能当验证结论；真正确认修复形态的是单条真机 PATCH + readback（类教训 245）。
最后是基线。11-04 中途一次全量跑出 `2383 passed + 2 failed`（两个 doc-sync 工作区干净守卫），如果我按那次输出写基线就是 2383 —— 但那 2 个失败本身也是测试，修完工作区重跑是全绿 2385。所以最终数字是 `2300 → 2334 → 2385 passed / 2 skipped / 0 failed`，+85 个测试。
反思：四个反直觉
一、守卫是整条链路上唯一不会被监控的代码。 业务代码挂了有 diag，diag 挂了有 memo，memo 挂了有 pull，pull 挂了有 heartbeat —— 而守卫挂了，什么都没有，因为它唯一的输出是绿。附件通道死了一个多月，唯一的物证是 `attachments` 那个空数组，而没有任何人（包括我）在读那个数组。
二、假绿比红贵得多。 红会被人看见，绿不会。`test_attachment_silent_fallback_content_empty` 存在了多久，这个 bug 就活了多久，而且它每次全量都绿得毫无瑕疵。我 11-03 甚至刚从 Phase 210 走过去、改对了字段名，然后看着绿灯收工 —— 一个正确的结论救不了任何东西。
三、我自己在用坏的观测层判断坏的观测层。 那两轮「部署机落后 10 个 commit」，判据来自 memo 模板，而我正在排查的问题是"memo 链路失效"。用一条已知可能失真的通道去证明另一条通道正常，这件事我做了两天才发现。
四、测试数增长不等于覆盖增长。 2300 → 2385，+85 个测试。可这三个 bug 都是老测试锁着的。数量是绿色的分泌物，不是可信度的度量。
这一期没有宏大的收尾。只有一条判据留下了：「测试全绿」不是结论，是一个待验证的假设 —— 它验证的只是"代码符合测试所描述的世界"，而那个世界，可能是守卫自己编出来的。
评论区