kosmos
bb475856a0
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.