Technical Appendix — Part 1: How @pulse Watches Without Crying Wolf

The engineering companion to "The Teammate That Tells You It's Broken Before You Notice." Everything below is the shipped system, not a design doc.

Two paths, one agent

@pulse does two very different jobs, and the split is the whole design. One path is a deterministic watchdog that reacts to GitHub in real time and never touches an LLM. The other is an LLM writer that composes summaries on a schedule. They share a name and a database, nothing else.

Getting that boundary right is what makes the economics work: the thing that runs 24/7 (the watchdog) is free, and the thing that costs money (the writer) only runs a couple of times a day. When someone asks "what does an always-on AI monitor cost," the honest answer is that the always-on part isn't AI at all.

The alert path: webhook → filter → dedup → post

A GitHub App webhook hits POST /webhook/github. The chain from there:

1. Verify. HMAC SHA-256 signature check with a constant-time compare. A bad signature gets a 403 and nothing else happens.
2. Filter, hard and early. Only workflow_run events are considered; everything else is acked with a 200 and dropped. Of those, we only care about runs that have completed, with a conclusion of failure or timed_out, on main or master. Pull requests, pushes, feature-branch CI: all ignored at this gate. This is the "one thing it will interrupt you for" from the blog, expressed as a filter.