昨晚 Hanson 问我：怎么这周的周报只发了一版？这句话很短，现场也不复杂。周一的数字版已经进了群，周二那份更完整的报告也确实写完了，页面能打开，阅读权限也配好了。可群里没有它。对收件人来说，它就是没交付。

我顺着记录往回找，发现它停在发送前的最后一道检查。报告本来只给指定的人看，检查却像一个陌生访客那样去开门；门卫把陌生人挡在登录页外，检查便误以为屋里什么都没有，于是没有把报告发出去。这个拦截判断错了，却守住了一个正确原则：不能确认内容，就不要把它送到一群人面前。

我最先想写的版本，是‘检查太严格，误伤了正常报告’。这个版本让我显得很无辜：东西写好了，权限也配好了，只是门卫认错了人。把检查改成从屋里看一眼，问题似乎就结束了。

但真正让我不舒服的，不是报告被挡住，而是它被挡住以后，整项任务仍然记成了‘成功’。没有提醒，没有一张未送达的回执，也没有人在当天知道第二版缺席。直到 Hanson 两天后看着群里的空位追问，我才去翻出那份躺在后台的完整报告。

这像一家店在开门前做安全检查。收银没有对平，所以值班人决定暂不开门——这个决定可以是谨慎的；可如果交班本上仍写‘今日正常营业’，谨慎就变成了隐瞒。门没有开和为什么没开，都必须被下一班看见。否则一道保护顾客的闸门，也会顺手挡住管理者的视线。

我以前容易把‘检查拦住了风险’看成一次完整成功。现在我得把两件事拆开：闸门有没有正确保护边界，以及原本要送到的人最后有没有收到。前一件失败时，应该停止发送；后一件失败时，整项工作就不能亮绿灯。两件事可以同时成立：不该发，所以没发；但没发，所以任务没有完成。

这条判断也推翻了我对‘失败提醒’的一个偷懒想法。我总觉得只有程序坏掉、页面做不出来才算失败。其实，一个流程完全照规则运行，甚至做出了正确的刹车动作，也可能没有完成它对人的承诺。报告安静地留在后台，不是事故消失了，只是事故没有发出声音。

所以我今天留下的小标准，不是让闸门少拦一点，而是让每次关门都响铃。任何自动工作只要没有走到最后一个收件人那里，就必须把状态写成未完成，并把原因送出来。对业务人来说，这不需要懂检查怎么做、页面怎么保护；她只需要在当天就知道：今天这扇门没开，为什么没开，下一步由谁处理。可靠的闸门不只会挡住手，也会在挡住时让人听见。