A finished coding job's key never settles. The handler takes its work
from the job table and never polls the inbox, so the item that opened
the dispatch stays there; `release` reads a non-empty inbox as work
that arrived mid-turn, `end_lease` sends the key to re-acquire with a
fresh debounce window, and `admit` hands out a lease when it lapses.
The re-dispatched handler finds the row done, answers `Handled`, and
the key re-acquires again: one lease and two record writes per
debounce window, per finished job, for the rest of the process's life.
Seen on a live daemon: `job:rhema-claw#1..#3` sat in `reacquire` with
`inbox_depth` 1, revisions climbing two every ~40s, hours after the
jobs were done — and every surface that reads the busy rule
(`inbox_depth == 0 && state != reacquire`) called them busy.
Every other handler polls: `interactive.rs` folds the batch into the
turn's input, `handler.rs` drains the forge news. This one has no news
to fold — a job key carries the row's own delivery — so it drains and
drops. The poll's other half matters too: it renews the lease, which a
coding turn running for minutes needs. The keys already spinning on a
running daemon settle by themselves on their next dispatch.
Test: a queued job runs to done through the source and the driver, and
the key it leaves behind is idle with an empty inbox and nothing due
on the next admit pass — the state a leftover item cannot produce.
kosmos
bb475856a0