The empty-bodies feeder runs on a laptop, and has fired zero times since 2026-09-17 07:39 #4280

What happened

The swarm's fuel line for specs/** empty function bodies is a script on the operator's machine, run by a local scheduled task every 20 minutes.

• 2026-09-17: it fired twice between 18:03 and 05:43 instead of 36 times — the machine was asleep, and the swarm idled all night.
• From 2026-09-17 07:39 UTC it has fired zero times: every run fails within three seconds on the model the app asks for, and the failure is invisible because a script that never starts writes no log.

The standing rule for this swarm is that recurring work runs in the cloud, and the merge half moved there in #4279.

What the feeder must keep doing

Two properties were learned expensively and must survive the move:

1. It measures with the compiler a bee actually runs. Pointed at a binary built eight days earlier from uncommitted source, the same script counted 483 empty bodies in 139 files where the compiler from master counts 245 in 70.
2. It executes every command it quotes — as the exact string the bee will read — and refuses to open the issue unless each prints the value the issue claims. Eleven issues once said "today: 0 tests" about files carrying nine.

Done when

• 1. ls .github/workflows/queen-feed-empty-bodies.yml prints the path — a scheduled workflow builds t27c and runs the feeder
• 2. python3 -c "import ast;ast.parse(open('tools/queen/feed_empty_bodies.py').read())" exits 0 — the feeder lives in the repository, not on one machine
• 3. grep -c 'claims_hold' tools/queen/feed_empty_bodies.py prints at least 2 — the quoted commands are still executed before an issue is opened
• 4. grep -c 'T27C_BIN' tools/queen/feed_empty_bodies.py prints at least 1 — the compiler is the one the job built, not one on a developer's disk
• 5. python3 scripts/ci/check_pr_branch_filters.py exits 0 — the new workflow is classified

Boundary

tools/queen/feed_empty_bodies.py