[gHashTag]

The swarm ran at 14% of capacity and the author refused to help, saying it was at the WIP limit. It was counting the wrong column.

The measurement

open queen-authored: 5   (1426 1425 1424 1421 1420)
  of those dispatched at least once: 4
  UNSTARTED, the actual queue: 1

Five open, so room = 0 and nothing was filed. Four of those five had already been dispatched and were sitting in sendBack or wait — work in progress. The real queue, issues nobody has started, was one.

Why the rule was wrong, not just mistuned

Kanban limits work in progress and never the backlog. Dependabot's open-pull-requests-limit — the model this was copied from — exists to protect a human reviewer's capacity.

Measured here over 119 dispatches:

review latency, finished → verdict	p50 0.8 s
bee runtime, dispatched → finished	p50 792 s
dispatches in 2 days	120

There is no human to protect and nothing to throttle. Little's Law gives the target instead: four workers consume roughly 18 tasks an hour while the author fires about four times an hour, so the queue must hold enough that a worker always finds something — workers + 1. That is a depth, not a census of everything open.

An issue with a dispatch row is in progress. It is not queue and is no longer counted as queue.

What is deliberately unchanged

• A count that could not be taken still returns null and still refuses to file. Zero would lift the limit rather than hold it — the oldest rule in this file.
• The stall guard still reads the oldest OPEN issue, not the oldest unstarted one. An issue dispatched six hours ago and still not closed is exactly as much evidence that the drain has stopped as one nobody ever started. The guard asks "is anything finishing"; the queue depth asks "is anything starting". Its message now prints both numbers — it once printed a count of open issues while the variable held the queue depth.

Result

room 0 → 4. Four issues filed with pairwise disjoint boundaries (Trinity-S-AI-DNA/trios#1427–browseros-ai#1430), and the swarm reached 4 bees of 4 for the first time, with 3 more queued:

tick 11:21:16Z | refusal None
skips: {"claimed": 15, "completed": 6, "missingBoundary": 2, "fileConflict": 2, "incompleteSpec": 1, "notFirst": 3}
RUNNING 4 | total 148

node selftest.mjs → 60 passed, 0 failed, no network. Three new cases pin the rule, the null-refusal, and the report agreeing with the measure it reads.