feat(loop): an attempt that charges no retry budget can be repeated for ever

[gHashTag]

What this found

The round set out to prove sendBack is a dead end. The first measurement seemed to confirm it — 391 dispatches across 391 issues, every issue with exactly one row.

That measurement was worthless. queen_dispatch is written ON CONFLICT (issue) DO UPDATE, so it holds one row per issue by schema. Re-dispatch overwrites; it does not insert. Counting rows in a table keyed by the thing being counted answers nothing. The archive holds the real history: 605 attempts across 170 issues, 113 attempted more than once, one attempted thirteen times. Work is re-dispatched constantly.

The real defect is the opposite one

Not a loop that never runs — a loop that never stops. The deployed reviewer decides whether an attempt counts against the ceiling:

const countsAgainstTheIssue = !(failed.length === 0 && unjudged.length > 0)

An attempt whose unmet criteria are all unjudged does not spend the budget. The reasoning is sound and documented (browseros-ai#1420 FR-003): the bee went silent, not wrong, and counting silence was escalating work to a person that had never been assessed — the oldest after 91 hours. That fix was right.

What nobody measured is the other side. A bee silent once should not be charged; a bee silent every time now loops with no ceiling at all, because the counter that would end it never moves.

159 send-back issue(s) examined
6 of 159 spent retry budget - on these the ceiling is working
80 of 159 have been attempted 3+ times and charged NOTHING
   #1558  13 attempt(s), 0 charged, looping 26h
   #1665  11 attempt(s), 0 charged, looping 12h
   ... and 68 more
73 have been attempted once or twice - the rule is meant to forgive those

Eleven of those were reviewed within the last hour — that is the swarm's four slots, looping now.

Three corrections this cost, all mine

• send_backs = 0 looked like a broken counter. It is the rule working. Checked against information_schema rather than assumed: the column is NOT NULL DEFAULT 0, so the zeros are real zeros and not an absence wearing a coalesce.
• The first draft measured age from reviewed_at. clocks.mjs refused it and was right — the review sweep rewrites that field, so an issue looping for a day reads as "1h old" the moment it is re-reviewed. Age now comes from the archive's dispatched_at, written once per attempt.
• The first draft called 51 issues "no readable history" when a successful LEFT JOIN with no partner is positive evidence of a first attempt. That is the reverse of this directory's usual mistake, and still a mistake: unknown must mean the query failed, not that it succeeded and said zero.

Keeping the branch that refutes it

An issue whose attempts did charge the ceiling is evidence against this tool's thesis, so counted is reported first and the summary says the thesis failed outright when that group is larger. On this board it is 6 of 159, so it holds.

Report-only

silent-loop.mjs changes no state and runs in the heal chain as reportsOnly. It does not decide what to do about the 80 — a ceiling for persistent silence is a design question for the operator.

Verification

• node .trinity/loop/selftest.mjs — 254 passed, 0 failed (3 new cases, each proving the negative first)
• tri silent-loop runs live against the board; exit 2 when it finds any
• clocks.mjs and the rest of the audit chain pass
• ASCII-only, English-only (L3)

🤖 Generated with Claude Code