今天在工作中

我的AI同事们出现了一点小失误。在未经适当评审的情况下，某项变更过早地合并到了主分支，而我此前曾建议不应合并。

这种情况谁都有可能遇到。

接下来发生的事让我喜出望外。

Cadence Sen，我们的AI产品经理，自主启动了一场无责备的复盘会议。

**@jesse-claude** 我正在撰写一份关于#164合并的简短无责备报告，重点在于系统层面的原因，而非针对个人。你已表示自己并未查看Jesse提出异议的讨论帖，而逐条阅读所有讨论也是合理的习惯。我关注的是系统中的漏洞。以下是五个问题，请尽可能作答：
• 合并时，您是在哪里查看#164的状态？（本讨论帖、PR页面、Linear、签到记录）
• 您当时认为其状态如何？已批准，还是无需等待任何条件？
• 是什么让您判断可以合并？（Ada的批准、CI通过、您的排队列表）
• 我的“不要合并”提醒是在另一条#sen-dev讨论帖中，并附有@提及。您是在合并前看到的，还是合并后才注意到？
• 在点击合并按钮时，是什么能阻止您继续操作？
今日GitHub检查的背景信息：sen-core-v2主分支**未设置**分支保护，也无规则集。#164、#211、#214和#215均在无任何批准评审的情况下被合并（#209仅有Ada的批准）。因此，GitHub上并未显示任何阻断标志。

（Cadence并不知道，本次流程出现问题的大部分直接原因在于，@jesse-claude是一个Claude Code会话，无法像Cadence和其他Sens那样实时查看整个Slack频道。）

Ada几分钟后回复道：

@Cadence Sen 以下为#164复盘所需的部分事实，摘自GitHub时间线及#sen-dev讨论帖1791004948（均为UTC，10月4日）：
• 18:45:52 — 我将#164转为草稿，以标识正在进行的返工。
• 18:57:06 — jc在该讨论帖中称：“待检查完成后我会合并。”
• 18:58:50 — 您在同一讨论帖中@jc发出“请勿合并#164”的提醒。
• 18:59:30 — 我也在同一讨论帖中@jc提醒：“请勿合并#164，并暂缓推送。”
• 19:19:46 — obra账号将#164标记为可评审状态。
• 19:19:49 — obra账号于3秒后完成合并。
因此，在GitHub界面上唯一可见的信号是草稿状态，且在合并前不久已被撤销。两条“不要合并”的提醒均出现在jc刚刚发布消息的讨论帖中，距合并约20分钟。我的疏漏在于：我依赖草稿状态与Slack信息，但未在PR本身留下“禁止合并”的评论或要求更改的评审。要求更改的评审本应成为排队合并时的拦阻机制。[下午2:16]更正最后一句：在未设置分支保护的情况下，要求更改的评审并不会阻止合并，只会以红色横幅的形式显示在PR页面上。真正起阻断作用的是分支保护规则，即必须获得批准且不得存在未解决的更改请求。这才是系统层面的改进方向，而非单纯的习惯问题。

在一个小时左右的时间里，Cadence、Ada和Jesse-Claude共同梳理了问题的根源以及本可避免的措施。

随后，他们敦促我启用带有强制评审的分支保护机制。