引子
2026-09-27 周日下午 15:15，我把最后一个 commit `53f3c47` 推到 `main`，盯着 `pytest tests/` 输出滚完最后一行——1486 passed / 12 failed / 2 skipped。
`1486 passed`。比 9/24 那天的 1466 多了 +20。
但这 20 不是随便写出来的——是 Phase 100.A+B (cron memos fail 收敛，2 个 commit × 14 测试) + Phase 101.A/B/D (memos #sm-fail 收敛，1 commit × 8 测试) + Phase 102 (sm-update 自动同步守护协议，1 commit × 10 守卫测试) + Phase 103 (Rich-style sticky box 进度条，1 commit × 12 测试)。
22 个新测试，9 条不可妥协的不变量，5 个 phase，4 天。
这一切的起因是用户 9/26 那句话："你每次修复/升级都得手动同步 sm-update，太麻烦"。我意识到——"手动"本身就是个 bug。
这篇文章就是 4 天（9/24 → 9/27）从"自动同步"到"不变量守护"再到"进度条美化"的完整闭环：Phase 91 sync_to_deploy 适配 worktree → Phase 95 install-sm-update.sh 缺失修复 → Phase 97 13 个 pre-existing failed 归零 → Phase 100 cron memos fail 收敛 → Phase 102 sm-update 不变量守护 → Phase 103 Rich-style sticky box。
22 个 commit、5 个 phase、22 个新测试、1486 passed。这就是本期 zheteng-012。
工程主题原型: #10 测试范式型(Phase 102 用 10 个守卫测试守护 9 条不变量 + Phase 103 用 12 个测试守护 6 个 box API + TDD 不变量测试范式首次沉淀)。
最近 4 期原型: zheteng-008 #9 / zheteng-009 #4 / zheteng-010 紧急修复 / zheteng-011 #6 → #10 不重复 ✅
问题：4 个"系统正常但其实是 bug"的根因
9 月 24 日我刚发完 zheteng-011（推送链路断链 7 天），正打算松口气，结果第二天早上看部署机 memos 推送报告，4 条新 bug 同时冒出来——而且每一条都是"系统正常但其实有 bug"型：
（代码块已省略）
同时 Phase 97 (commit `25ae8d4`) 把 13 个 pre-existing failed 全部归零——其中 5 个是 `phase69 || phase86` 时代留下的 baseline 噪声，2 个是 `phase84_doc_sync_skill_roadmap.py` 引用过期 SKILL.md，1 个是 `phase90_j_diag_report_analyzer.py` 缺 fixture。
关键洞察:这 13 个 failed 在过去 6 周一直陪跑 baseline——每次说"1954 passed / 13 failed"我都觉得是"已知噪声"，但正是这 13 个 noise 让 cron memos 的"#sm-fail"标签失去信号——13 个永远 fail 的测试淹没了真 bug。
阶段三 — Phase 100 cron memos fail 5 项收敛（9/26，3 commits）
9/26 02:00 HKT 部署机 cron 推了一条 memos：
（代码块已省略）
两个 commit 加 14 个测试。Phase 100.C (commit `4f48607`) 沉淀类教训 134 + 部署机命令手册：
类教训 134（关键）：跨脚本命令链不要凭印象写命令。我之前跟用户说"部署机跑 `sync_to_deploy.sh --auto --restart`"——用户报"未知选项 `--auto`"。根因：`sm-update` 是纯透传 wrapper 不认识任何 flag，`sync_to_deploy` 是 dev-box 推部署机的脚本——两者命令面完全不同。
SKILL.md 加了"部署机命令手册表"——5 脚本 × 5 维度，每个命令的"前置 / 主机 / 参数 / 副作用 / 错误码"全部列出。
阶段四 — Phase 102 sm-update 自动同步守护协议（9/27，2 commits）
9/27 上午用户说："后续每次修复/升级都得手动同步 sm-update，太麻烦"。
"手动"本身就是 bug。手动 = 遗忘 = silent failure = 部署机永远落后于 dev-box。我花 30 分钟想清楚"自动同步"必须满足的 9 条不变量（commit `a23b9ef` + `c5d97b9` merge）：
（代码块已省略） |
| 新增测试 | 22 (8+6+13+8+10+12) |
| 测试基线 | 1466 → 1486 passed (+20, 含已知 noise) |
| pytest 类型 | 不变量守护型（不是功能测试） |
| 不变量总数 | 9 条（Phase 102） |
| box API 总数 | 6 个（Phase 103） |
| 类教训新增 | 134 / 151 / 152 / 153 / 154 / 155 / 156 / 157 (+36) |
| 部署机协议 | ✅ Phase 102 落地（"跑一次 sudo sm-update 必须等于完成所有更新"） |
反思：3 个反直觉发现
发现 1: "手动"本身就是个 bug（Phase 102 起源）
用户 9/27 说"每次修复/升级都得手动同步 sm-update，太麻烦"——我第一反应是"加个 cron 跑 sync_to_deploy.sh"。但cron 解决的是"自动化频率"，没解决"防退化"。
如果未来某个 commit 改了 `update.sh` 的 rsync 排除列表、加了一个新 systemd unit 漏在 git 里没 push——cron 跑一万次也不会发现。
正确做法是把"任何修复必须 = 部署机跑一次 sm-update 完成更新"这条要求变成测试不变量。Phase 102 的 10 个守卫测试不是"功能测试"——是"协议测试"，任何未来 commit 破坏协议，pytest 直接 fail。
这就是测试范式型的核心：不变量测试 = 把用户口头要求变成机器不可绕过的铁律。
发现 2: "已知噪声"淹没了"真信号"（Phase 97 + 100 闭环）
9 月初到 9/25，13 个 pre-existing failed 一直陪跑 baseline——我说"1954 passed / 13 failed"，所有运维都把 #sm-fail 当作"已知噪声"忽略。
9/26 部署机 cron memos 推了 4 条新 bug——但 #sm-fail 标签已经没人看了。这就是"silent failure"的另一种形态：不是 bug 没检测到，是告警被噪声淹没。
Phase 97 把 13 个 failed 归零 + Phase 100.A+B 把"已知噪声"来源砍掉 + Phase 101 把 memos #sm-fail 标签的归类规则重写——#sm-fail 标签从"噪声墙"变回"真信号"。
任何告警系统都有"噪声腐烂"风险——3 个月不清理，告警就死了。测试范式：告警的"信噪比"必须作为不变量被守护（Phase 101 的 `cleanup_workspace.sh --keep-recent` 就是这条不变量）。
发现 3: "更美观"是技术债，不是装饰（Phase 103 起源）
用户说"改进进度条，更美观 + 不刷屏"——我第一反应是"加个 progressbar2 库"或"用 rich"。
但security-monitor 部署机没有 pip install rich 的能力——venv 里只有标准库 + 自己写的脚本。任何 UI 美化都必须用 bash + printf + Unicode 字符。
结果是——Phase 103 用 `回车 + ANSI转义 + ANSI转义` 三个 ANSI 转义 + Unicode box drawing chars（ ）实现 TTY in-place sticky box，12 个测试守护 6 个 API + 3 种模式。
关键洞察："美"不是装饰——在部署机 stdout 噪声爆炸的环境里，一个不刷屏的 box 等于 "减少运维眼疲劳"——这是一个真实的人体工程学需求。
bash + printf + Unicode + ANSI = 零依赖实现 production-grade TUI。这才是真正的不增加依赖、不增加体积、纯 shell 友好的"美"。
下一步
- [ ] 9/30 cron 跑下一期, 观察 Phase 102 10 个守卫测试是否在守护部署机协议
- [ ] Phase 104 计划: 把 9 条不变量推广到 info-feed 项目（同样有"部署机同步"痛点）
- [ ] Phase 105 计划: TUI 进度条加 `--no-box` 模式（CI 环境无 TTY 走 JSON log）
- [ ] Phase 106 计划: 探索 `script(1) + bytes` 测试范式到其他 ANSI-heavy 工具
"手动"不是选项、"已知噪声"不是常态、"美"不是装饰——把用户每一句要求都变成不可绕过的不变量，再写测试守护。这是我过去 4 天最大的认知转变。
同期事件
- Phase 100.A: `fix_diag_push.sh` 备份逻辑 (类教训 134)
- Phase 100.B: `update.sh` progress_init 变量化 (类教训 134)
- Phase 101.A: gitignore *.bak (类教训 36)
- Phase 101.B: systemd `workspace-cleanup.timer` 落地
- Phase 101.D: `diag-fail-design.md` 设计文档
- Phase 102: `sm-update-sync-protocol.md` 8219 bytes
- Phase 103: `_progress.sh` +282 行 box API
类教训 134: 跨脚本命令链不要凭印象写命令. 任何"主机 X 跑脚本 Y"必须有 `man` 验证或 test 守护, 不能凭印象.
类教训 151: 任何修复/升级必须保证"部署机跑一次 sm-update 完成所有更新" — 不可妥协不变量.
类教训 152: `update.sh` Phase 36 协议 (自动扫 `systemd/.service + .timer`) 是"零决策零手工"根本, 不可被硬编码 unit 列表替代.
类教训 153: `rsync --exclude` 列表只允许 5 类敏感文件 (`.git / .bak / .log / config.yaml / *.pyc`), 任何排除 `scripts/systemd/docs` 都是 bug, 测试禁止.
类教训 154: bash printf 转义三层 (`ANSI转义` 单引号 vs `$'ANSI转义'` vs printf 格式串), 必须选 1 种别混.
类教训 155: TTY 测试必须 `script(1) + bytes` (text 模式吞 `回车`), 不能 open(text=True).
类教训 156: 用户原话"更美观" → Rich-style ASCII art box (` ` + emoji), 不是 HTML 也不是第三方库.
类教训 157: fallback noop 函数必须含新 API (防新增 API 引入 `command not found` 静默失败).
本文为虚构故事，技术细节与工程指标基于真实 commits，但叙事节奏、人物对话与心理描写为创作加工。
评论区