A number-gate abort pinned one bad draft at the queue head for 13 days

A gate that aborts on the first violation depends on something else to move the violating record, and in the followers lane nothing did. The queue file is read from the head, the batch is the first entries off it, and the aborting run exited without recording the draft that caused the abort ^[8]. So the next day's run rebuilt the same six-entry batch, hit the same blocked draft, and exited 3 again ^[8].

The queue climbed from 336 entries to 390 while that was going on, 54 new entries across the 13 days, roughly four a day ^[3][16]. Six drafts were re-examined on every run ^[8]. The other 384 were never looked at once ^[17].

The replacement at followers_send.mjs:84-97 runs the same check and does something different with the result. It maps each draft to its handle and its checkColdOutbound hits, keeps the ones with hits, appends a row to the SENT ledger with ok:false and reason 'number-gate: ...', adds the handle to an exhausted set, and builds sendable from the drafts that are not in it ^[9]. The call to process.exit(3) is deleted, and dm.mjs:82-94 got the same edit ^[10].

The skip survives to the next run because exhausted is rebuilt from the ledger by matching the string 'number-gate' inside the reason field, at followers_send.mjs:49-51 and dm.mjs:50-52 ^[11]. That puts the reason text in the control flow. Reword the prefix and the record returns to the head of the queue.

The abort path was not silent in the logs. process.exit(3) was recorded day after day, and it was never wired to a Discord alert, so it never reached anyone ^[4]. An alert on that exit would have surfaced the fault after the first run on 8/28 ^[18]. It would not have restarted the lane, because the head of the queue still has to be cleared by a state write.

The second incident from the same day shows how much of this turned on ordering. Composer timeouts for the same three people counted as three consecutive failures, tripped the stop guard, and the four people behind them went unsent for two runs in a row ^[12]. That one cleared itself, because a timeout is transient. The leaking draft was still in front 13 days after it first blocked a run ^[2][8]. "An unrecorded anomaly stays parked at the head of the queue, so it never heals itself," bokuwalily wrote ^[13].

This shape hits a job of yours only when the pre-send check aborts the batch instead of the record, the selection order is stable across runs, and the abort leaves no state behind. A queue with randomised selection, or retries that reorder the head, steps past the bad record eventually. The measurement is now a Japanese comment above the gate in followers_send.mjs: measured 2026-08-28 to 09-10, one kouAI_work draft, 13 days at zero sends ^[14].