Build in Public · 运营故事
当成功是一个谎言
2026 年 5 月初，我们发现了一件令人不安的事：Synapse 的 Slack 通知已经静默失效了 11 天以上，而系统全程报告"成功"。
根因是一个经典陷阱：调用方拿到 HTTP 200 就默认成功，而 Slack 真正的回执 {"ok":false,"error":"not_authed"} 写在响应体里，没有人去读那个响应体。更隐蔽的是——连健康心跳本身也走同一条链路，于是"监控的监控"也一起失效了。这就是监控悖论：当哨兵和被守卫的城门用同一把锁，锁坏了，哨兵也哑了。
为什么 11 天没人发现？因为管线每一环都亮着绿灯。GHA run 状态是绿的，HTTP 状态码是 200 的，技术层面"一切正常"——只是业务层面什么都没送达。技术成功掩盖了业务失效。
我们没有把它当成一次性 bug 修掉就算。我们把这次事故沉淀成了制度：
- 一条 P0 治理原则写进了系统宪法——Silent Fail Defense Principle：「HTTP 2xx / status=success ≠ 业务真生效；所有外部服务调用必须断言响应体业务字段（如
ok=true），断言失败必须抛异常并标记上游任务失败，禁止静默 stdout 警告；元监控必须独立于被监控管线。」（来源：CLAUDE.md，标注[ADDED: 2026-05-05]） - 两周后，又收紧出一条配套铁律——WF-09 唯一通知路径：所有 Slack 通知必须经由单一受治理的工作流，任何绕过都是违规。（来源：
CLAUDE.md[ADDED: 2026-05-19]；决策D-2026-05-19-002） - 唯一的豁免，是那条独立于主管线的元监控通道——专门用来在主路径整体失效时，从另一条道把警报送出来。（来源：一份独立于主管线的元监控脚本，授权豁免）
这就是我们说"Harness 不是宣称、是痕迹"的含义：你看到的不是一句口号，是一条带日期的规则、一份带编号的决策、和一行可审计的日志。事故没有被掩盖，它被记下来、被制度化、并且永久改变了系统的行为。