The write order is not sloppiness. A dedup ledger is an idempotency record, and the safest moment to write to it is before the work starts. Write on completion, and a crash mid-batch replays items you already sent. Write on arrival, and the ledger never lies about what has been seen. Plenty of implementations pick arrival, because that is the cheap durable point, and then the ledger is a seen-set with a field called `done` [5].
Then the cap runs. It exists to keep the pipeline from overwhelming downstream services, and items over the line are meant to wait for the next cycle [6]. In this order they do not wait. They are already in the ledger, so the next cycle's dedup step recognises them and skips them [5]. The trim is a delete wearing the label of a defer. The second commit message says it without decoration: "pipeline: stop burning jobs at the cap, and stop starving the best source" [9].
Volume is why nothing tripped. Spread 175 items across a full day of hourly runs and the average run reports a little over seven [1]. Seven is the count an operator reads as normal and moves on.
The rest of the dashboard was measuring liveness. The self-test log returned a pass on four checks in 3318ms [11], and the mail watcher returned `"ok": true` [12]. The restart counters were louder and less useful: cto-aipa at 99 restarts in two days is roughly one every 29 minutes [3], and algom-stream at 55193 in fourteen days is about 164 per hour, one every 22 seconds [2]. A counter moving that fast has stopped being an alarm and become weather.
The check the author says was missing is items ingested against items delivered, with an expected delta [14]. The word doing the work there is "expected". Once you have a cap, the delta is never zero, so the useful form is a conservation statement: ingested equals delivered plus deferred plus deduped, with every term readable for the cycle. That forces the ledger to hold a state rather than a boolean, claimed versus delivered, which is the same constraint the landed fix satisfies by running the cap before anything gets marked [8].
Whether this reproduces in your pipeline comes down to two lines you can find in an afternoon. Locate the ledger write and locate the trim, then check which runs first, and whether the trim re-enqueues the overflow or drops it. If the overflow is pushed onto the next cycle's input before the ledger is touched, you have a defer. If not, you have this incident with different variable names.
One more constraint is worth reading, because it explains why the ordering bug survived a day. The operator's own notes file states that Cursor Cloud, Cursor Desktop and Claude Code all work the same repo, none of them can see each other's chats, and the only artefacts all of them read are HubSpot and that file [16]. The author says this missing shared context makes incidents like this harder to debug [17]. An invariant that spans two steps has to live somewhere both editors will read it, which is what a wiki entry titled "the queue marked 175 items done before anyone read them" is actually for [15].
