Hand a job list to the cloud and watch it land

Running a batch of small fixes by hand means one person to vet, launch, chase and hand off every job — and in practice launches outran landings eightfold. The dispatcher makes that pipeline a property of the app: you hand over a job list once, and it paces, launches, returns and reports while you watch the numbers.

It is off until you switch it on

This feature rents machines on its own, without you clicking anything, so it ships off. Turn it on when you want it:

POST /cloud/worker/resume      (or set cloudWorkerDispatchEnabled in Settings)

POST /cloud/worker/hold with a reason stops it again; the hold survives a restart and always reports since when.

Submitting a batch

POST /cloud/worker/jobs
{
  "jobs": [
    {
      "projectId": "<the project>",
      "goal": "Make the retry backoff use the shared helper",
      "files": ["src/main/services/http/retry.ts"],
      "doneTest": "npm run test:agent -- tests/unit/services/http/retry.test.ts",
      "premise": "src/main/services/http/retry.ts:present"
    }
  ]
}

Every job needs a goal, the files it may touch and a done test — a job that cannot be proved done is refused before it costs anything. If you do not name an owner, the session that submitted the batch becomes it, and that owner is who hears the landed commit.

A job that lists a dependency or lockfile (package.json, any lockfile) is refused at entry: a dependency change needs a person, so it never goes to a cloud worker.

premise is optional and is the one machine-checkable field of its kind: "<path>:present" or "<path>:absent". Just before a job launches, the app re-asks it against the current tree — so a job whose fix already landed is closed without spending a start, rather than launching a worker to redo it.

Watching it

GET /cloud/worker/totals

You get the counts that matter — queued, launching, working, home, landed, held, failed, closed — per job and summed, plus a line saying exactly why nothing is launching when nothing is. If the queue cannot be read at all, the totals say unknown rather than zero: a count of zero and an unreadable queue are different facts, and only one of them is good news.

A failed job does not retry itself

If a job's launch fails, that job stops there — it is never launched again on its own, because a fault that will not clear by itself would burn the day's starts. When you have dealt with the cause, put it back with one call:

POST /cloud/worker/jobs/<job id>/requeue

Only a failed job can be requeued; anything else is still in flight and the call refuses rather than moving it.

What stops it, by name

The dispatcher pauses rather than launching blind, and it always says which of these it is. When it pauses for any of the reasons below it puts one card in your inbox — one card for the whole hold, however long it lasts — naming the hold and how to start the line again. Briefly hitting a launch quota (at the live cap, waiting for the window) is not one of these: that is the dispatcher working as designed and it raises nothing.

• A hold you set — POST /cloud/worker/hold.
• Cloud sessions switched off on this computer. (Without this check a cloud launch would quietly run on your machine instead.)
• Two launches failed in a row — the line stops rather than relaunching a fault on a timer.
• A launch cost more than the bar of processor time on this computer, so your own work is never slowed to launch faster.
• Memory is low on this machine.
• This computer is being harmed — its own load verdict reads degraded (the box is kernel-bound, fault-storming, or a drive is saturated). This is a different question from the per-launch cost bar below: that one measures what a launch adds, and cannot see a machine already overloaded by everything else. If the machine's load reading cannot be taken at all, the dispatcher holds too — a blind instrument is not a calm machine.
• Too many returns are home but not yet landed — launching waits for landing to catch up, because a pile of finished work nobody has landed is the failure this feature exists to prevent.
• The provider's start limits — the daily limit, the hourly limit, or the reserve held back so the dispatcher never spends the last of the day's starts.

What it will not do

• It never merges anything. A finished branch lands only through the app's own auto-lander.
• It never hands a failed job to a worker again on its own — a failed job is someone's decision.
• It never runs a second launch road of its own: every launch meets the same checks a cloud session you start by hand meets.