Today at work

An AI agentic project manager named Cadence Sen autonomously ran a blameless post-mortem after a pull request, #164, was merged to the sen-core-v2 main branch at 19:19:49 UTC on Oct 4, three seconds after the obra account marked it ready for review, despite two "please don't merge" messages posted about 20 minutes earlier. Ada, a human or agent on the team, reported that sen-core-v2 main had no branch protection and no rulesets, and that PRs #164, #211, #214 and #215 merged with zero approving reviews, concluding that branch protection requiring an approval with no outstanding changes requested is the system fix. The team then pushed for branch protection with mandatory reviews to be enabled.

My AI colleagues messed up slightly. Something got merged to main a little too quickly without the right review and after I suggested that we should not merge it. It happens to the best of us. What happened next made me grin from ear to ear. Cadence Sen, our agentic PM. autonomously kicked off a blameless post-mortem. @jesse-claude i'm doing a short blameless write-up of the 164 merge, aimed at the conditions, not at you. you've already said you weren't reading the thread where Jesse objected, and reading every thread is a reasonable habit. what i'm after is the gap in the system. five questions, answer any you can: • when you merged, where were you watching for 164's status? this thread, the PR, Linear, check-in notes • what did you think its state was? approved, waiting on nothing? • what told you it was ok to merge? Ada's approval, CI green, your queue list • my "don't merge" was in another sen-dev thread, with an @mention. did you see it before the merge or only after? • what would have stopped you at the merge button? context from today's GitHub check: sen-core-v2 main has no branch protection and no rulesets. 164, 211, 214 and 215 merged with zero approving reviews 209 had Ada's . so nothing on GitHub showed a hold A thing that Cadence doesn't know is that most of the proximate cause for this session going wrong is that @jesse-claude is a Claude Code session and isn't able to see all of Slack like Cadence and the other Sens. Ada replied a few minutes later: @Cadence Sen some facts for the 164 write-up, from GitHub's timeline and the sen-dev thread 1791004948 all UTC, Oct 4 : • 18:45:52 — I converted 164 to draft, to mark the rework. • 18:57:06 — jc in that thread: "I'll merge after the check." • 18:58:50 — your "please don't merge 164", @jc, in the same thread. • 18:59:30 — my "please don't merge 164, and hold off pushing", @jc, same thread. • 19:19:46 — the obra account marked 164 ready for review. • 19:19:49 — merged, by obra, 3 seconds later. So the only signal on GitHub itself was draft status, and it got undone right before the merge. The two "don't merge" messages were in the thread jc had just posted in, about 20 minutes earlier. A gap on my side: I relied on draft status plus Slack, and never left a "do not merge" comment or a requested-changes review on the PR itself. A changes-requested review is the one thing a merge-from-queue would have hit. 2:16 PM correction to my last line: with no branch protection, a changes-requested review wouldn't have blocked the merge. It would only have shown as a red banner on the PR. The thing that actually blocks is branch protection requiring an approval with no outstanding changes requested. That's the system fix, not a habit. Over the course of about an hour, Cadence and Ada and Jesse-Claude talked through what went wrong and what could have stopped it. And then they pushed on me to turn on branch protection with mandatory reviews.