Everything I could decide myself is decided. What's left needs
you. Each one carries the recommendation of the session that raised it — if you
agree, pick it and press Done. A model's opinion, where there is one, appears on the card
as a receipt line; cards with no receipt were never put to a model. "I'm not sure" is a real answer and becomes work for me.
You don't need to open the session — pressing Done sends your answer back and it picks up.
1Follow-up to b89631756 (answered 'Fix it now the safe way'). The patch is live: nudge:1568 backticks escaped, atomic mv at 03:09:28, verified by shadow test (control RED, treatment clean), bash -n, and a real-roster run that spawned nothing. It is INERT on the 5 running watchers (pids 12488/16562/24154/71047/73919, all started before 03:09:28) because bash parsed watch_idle's loop body at watcher start and never re-reads the file. Post-fix roster-prompted spawns: 9+ in pairs at ~75-90s. MY ERROR 1: the rec_why on b89631756 said the waste stops; only the file changed, not the running processes. MY ERROR 2: rm-ing 62 debris rows shrank the roster from ~752KB to ~8-82KB, dropping it under the daemon dispatch guard that had been REJECTING these - so rejections that cost only disk became live token-burning sessions (~10k tokens each). Mechanism for option 1: 'nudge --stop <sid>' per watcher, then watcher-doctor (180s) re-arms each from arm-<sid8>.json against the new inode; each wake loop is down <=3 min and the arm text is preserved. SEPARATE, NOT TOUCHING: the same line's unescaped double-quote truncates the python -c payload at 330 of 1240 bytes, so the busy-children counter always returns empty->0 (proven against a live 40-row roster) - that is WHY this branch fires every cycle. Repairing that changes nudge cadence on 5 live parked tasks and is its own decision.
In plain terms. Should I restart the five wake-up timers now so the fix you approved actually takes effect, or leave them alone?
The two-character repair is in the file and verified. But the five timers already running read the old copy into memory when they started, so they keep doing the old thing until each restarts on its own. New sessions are still appearing roughly every 75 seconds.
Two corrections I owe you. When I asked, I told you this would stop the daily waste. That was wrong. And my own cleanup made it worse: it shrank the list the timers send, and a size limit that used to block most of these no longer blocks them, so attempts that used to cost only disk now cost money.
The session raising this recommends: Restart the five timers now Each timer is down for at most three minutes while it is re-armed from its saved settings, and the new sessions stop appearing straight away. Tried first, unsuccessfully: Applied your answer and verified it four ways, then measured it in the wild and found it does not reach the already-running timers. Removed 29 waste sessions to stop the token burn, which worked but is only a cleanup, not a cure. Did not restart the timers myself because you were offered exactly that as option three and chose the safe option instead, so it is not mine to infer. Also traced why these fire so often: the counter that should see busy children is broken by the same quoting bug and always reads zero - flagged, deliberately untouched.