fleet-routine — What Is This Thing?¶

No code in this page. If you want the engineering detail, see docs/technical/ARCHITECTURE.md.

In one sentence¶

fleet-routine is what lets AI tools across every computer in the house run jobs on a schedule, unattended — like Claude Code's own "scheduled tasks" feature, but for the whole fleet of AI tools instead of just one.

The everyday analogy¶

Claude Code has a built-in feature where you can say "run this every morning at 8am" and it just happens — no one has to sit at the keyboard and click a button. That's a routine.

fleet-routine builds the same idea, but bigger: instead of one AI tool on one machine, it's meant to work across all six AI tools the household uses (Claude, Codex, Gemini, Grok, and two local models called Odysseus and Ollama), on all four house computers. One consistent way to say "run this thing on this schedule," no matter which AI tool is actually going to do the work.

Important: this bigger version doesn't exist yet. Only one small, critical piece of it has actually been built. The rest is a plan — a good one, argued over and agreed on by a panel of AI models acting as reviewers, but a plan, not a running system. Section "What's actually been built" below is the honest line between the two.

Two jobs, kept deliberately separate¶

The design splits into two halves that are not allowed to blur together:

fleet-routine (this project) decides when and whether. When should a job run? Is there budget left to run it, or should it be skipped this time?
A different project, fleet-harness, decides how. Which AI tool should actually do the work? How does the request get routed to it?

Why bother keeping these separate? Because fleet-harness already exists and already knows how to route work reliably — including what to do if the primary AI tool is down. If fleet-routine reinvented that logic itself, the household would end up with two different, possibly contradictory answers to "which AI tool handles this." Keeping the scheduler dumb about routing, and the router dumb about scheduling, means each piece can be trusted to do its one job.

What Gate 0 proves — the piece that's actually built¶

Before any of the scheduling machinery above gets built, one question had to be answered first, because getting it wrong would be catastrophic in a boring, invisible way:

Can every AI tool actually log in and do its job when nobody is watching?

Here's the failure this guards against. Every one of these AI tools normally runs because you're sitting at the keyboard, logged in, and the tool can quietly read your saved login off your own Windows account. A scheduled job, by contrast, runs at 2am with nobody logged in. If the scheduled version of the job runs under a different, more restricted Windows identity — which is the default way Windows schedules things — none of the AI tools can find your saved login. The job doesn't crash loudly. It just quietly fails to authenticate, forever, and nobody notices until they go looking for output that was never produced.

Gate 0 is a small tool, fleet-routine doctor, whose entire job is to prove this can't happen — before a single line of real scheduling code gets written. Concretely, it:

Sets up a special one-time Windows scheduled task, configured to run "as you, whether you're logged in or not" — exactly the way a real future scheduled job would run.
Whenever you ask it to check, it silently wakes up that task and has it try to talk to all six AI tools, asking each one to say back a random one-time secret word.
If a tool answers back with today's secret word, that tool proved it can authenticate and actually run, unattended, in the exact way a real routine would need it to. If a tool can't answer — wrong login, missing token, or it just hangs — that's caught and reported clearly, instead of silently failing at 2am someday.

This has been built, and it passed its own internal checks (a clean build and 18 out of 18 automated tests). What hasn't happened yet is the real proof: actually running it, live, on the main computer, with a genuine one-time password step from Andrew. That's the one step nothing in this project can do by itself — the whole point of the design is that a computer program is never allowed to see or store that password.

What's actually been built vs. what's just planned¶

Piece	Status
Gate 0 — the login-proving tool (`doctor`)	Built. Code exists, tests pass, one real-world run is still owed.
A list of scheduled jobs ("the registry")	Planned. Not built.
Actually running jobs on a schedule (the Windows scheduler wiring)	Planned. Not built.
Talking to `fleet-harness` to get a job done	Planned. Not built.
Checking whether there's budget left before running a job	Planned. Not built.
Sending status updates across all four house computers	Planned. Not built.
Paging Andrew if something keeps failing	Planned. Not built.

The plan for the "planned" column was worked out and agreed on by a panel of AI models before any of it was built — see docs/plain/making-of.md for how that discussion went and what got decided.

Why this matters, in plain terms¶

Nobody wants an AI assistant that quietly stops doing its scheduled job and never says so. The approach here is: prove the hardest, most invisible failure mode (silent login failure) can't happen first, in isolation, with its own dedicated test — and refuse to build anything more elaborate on top of it until that proof is real, not assumed.