Migrate autonomous dispatches to box execution; retire Fleet Runner when its queue goes quiet

[catomean]

Context (measured 2026-08-13, prod pending_commands)

• 1,173 runner commands since 2026-05-18. Breakdown: peek_start/stop 882 (last used Aug 6 — organically abandoned), dispatch 242 (1–4/day, daily, active), misc 47.
• The daily dispatches are the scheduled/autopilot fleet (datacat, surf-your-life, truthseeker, orangecat…) — workload that needs a checkout + credentials + Claude CLI, not the laptop. It dies when the lid closes (see keep-awake hooks, 31/34 nightly non-success).
• One dispatch already targeted /home/ubuntu/dev/prime-tower — the dispatch model is machine-agnostic; the laptop is just the default target.

Principle

The interactive laptop workflow never touches Fleet Runner (typed prompts reach the ledger via the capture hook, a plain shell script). Fleet Runner exists solely to bridge cloud→laptop for autonomous work — work that belongs on the 24/7 box.

Plan

1. Point scheduled/autopilot dispatch targets at box execution (cloud-builder path; box already holds checkouts).
2. Watch pending_commands: when dispatch count goes to ~0 for 2+ weeks, the runner carries nothing.
3. Retire the Electron runner. If remote-driving the laptop specifically ever proves necessary, replace with a ~200-line auto-updating systemd daemon — never Electron.

Deletion as a consequence of the queue being empty, not an act of will.

🤖 Generated with Claude Code

[catomean]

Phase-1 progress (2026-08-13): dispatch routing was already cloud-first — projectPreferredChannel pins to the laptop only when a project has a dirPath but no cloneable git_url. The only four such projects (BiasLens, Bitbaum, ivy-portal, printcraft) all had GitHub remotes; their git_url is now filled in prod, so every registered project is cloud-eligible. Watch-item: biaslens/printcraft clone on first cloud dispatch — verify box creds cover them. Remaining for retirement: watch pending_commands channel=local go quiet, then decommission the Electron runner (#227 decides delivery).

[catomean]

Re-measured today (2026-08-26), 13 days after the numbers in the body. The retirement condition has moved decisively in the wrong direction — this plan should not proceed as written.

Both premises are now false

claim in this issue (Aug 13)	measured Aug 26
peek_start/stop — "last used Aug 6 — organically abandoned"	303 calls in the last 14 days, last used 07:57 today
dispatch — "1–4/day"	105 in 14 days — avg 7.5/day, peak 19

      type       | total | last_14d |       last_used
-----------------+-------+----------+------------------------
 peek_start      |   626 |      171 | 2026-08-26 07:57:42+00
 peek_stop       |   559 |      132 | 2026-08-26 07:57:54+00
 dispatch        |   345 |      105 | 2026-08-26 04:00:05+00
 auto_continue   |   244 |      244 | 2026-08-13 23:09:54+00
 focus_tab       |    29 |       14 | 2026-08-25 19:15:45+00

Step 2 of the plan is "watch pending_commands: when dispatch count goes to ~0 for 2+ weeks, the runner carries nothing." Dispatch volume roughly doubled instead. And peek, written off as organically abandoned, is the single most-used command type in the queue and was used minutes before this measurement.

Why the peek number is the more interesting one

A feature declared dead on the strength of one quiet week came back and is now the dominant traffic. That is worth separating from the dispatch growth: it means the Aug 13 snapshot did not merely undercount, it read a lull as an ending. Any future retirement gate on this queue should require a sustained-quiet window rather than a last-used date, or it will keep proposing to delete things during their quiet weeks.

Consequence for #227

#227 names option 3 — freeze the runner, accept manual updates, pending retirement here — as "the cheapest correct path," conditional on this issue actually retiring the component. It isn't retiring. Fleet Runner is carrying more traffic than when retirement was proposed, so the delivery pipeline had to be fixed for real rather than frozen. Done in #370.

Suggested amendment

The principle in this issue still holds: autonomous work that needs a checkout, credentials and a CLI belongs on the 24/7 box, not on a laptop that dies when the lid closes. Step 1 (point scheduled/autopilot dispatch at box execution) is worth doing on its own merits and is what would actually drain the queue.

What should change is the framing: retirement is not pending a quiet queue that is getting louder. Step 1 first; re-measure after; and treat "deletion as a consequence of the queue being empty" as a rule that requires the queue to become empty, which nothing has yet caused it to do.

Leaving this open, with the body's timeline now known to be wrong.

🤖 Generated with Claude Code