Skip to content

fleet-routine — Making Of (Plain-English)

Status: LIVING. This gets a new entry every time something real ships — it's not a one-time writeup. Where things stand right now: this project is very early. Only the first, smallest piece has actually been built and it's still waiting on one real-world test run. Everything else described here is a plan, not something running today.

For the version with commit hashes, file names, and exact dates, see docs/technical/making-of.md.

The idea gets written down

The project starts with a simple worry: what if a household AI assistant is set up to run jobs on a schedule, and one day it just... quietly stops working, and nobody notices for weeks? The whole project exists to prevent that specific failure, and the very first thing written down was: don't build the scheduler until you've proven the login problem can't happen.

A panel of AI models argues it out

Before any code got written, the design questions got put in front of a panel of different AI models (not just one) to argue over and vote on. Two things got decided this way:

  1. Should this be its own small project, or folded into a bigger existing one? A couple of the AI models on the panel argued it should just be absorbed into an existing bigger project. They were outvoted — the panel decided a small, separate project focused on only scheduling (and staying out of the business of picking which AI tool does the work) was the safer design.
  2. Three smaller technical questions — like "should the login check only test tools on this computer, or reach out to other house computers too?" (answer: just this computer, for now — a powered-off computer elsewhere in the house isn't a login problem, it's a different problem) — got settled the same way, by discussion and vote, and written straight into the plan.

One proposal was flatly rejected during this discussion: running the login test under a generic system account instead of a real person's account. That would have made the test worthless, because a generic system account can't see anyone's saved logins in the first place — testing it would prove nothing about whether the real thing works.

The first (and so far only) piece gets built

With the plan settled, the smallest, most important piece — the login-proving tool, doctor — got built. It was written by one AI tool and then independently checked by a different one, rather than just trusting the first tool's word that it worked. The checking wasn't just "does it look right" — it actually ran the automated tests and confirmed all of them passed before calling it done.

At this point, something was flagged honestly rather than swept under the rug: there's a genuine open question about whether the specific login method chosen (S4U, "run as me, whether I'm logged in or not") will actually let every AI tool find its saved credentials, or whether some of them will need a different login method instead. Nobody could be 100% sure without running it for real — and that's fine, because proving that, one way or the other, is the entire point of this first piece. It's not a gap in the plan; it's the exact question the plan was built to answer.

A second look catches a real problem

A few hours later, a second, independent review of the finished code caught something worth fixing: the "skip this one, it's not installed here" escape hatch (described in docs/plain/learn-more.md) was originally too generous — it would have let you skip a tool even when the real problem was a broken login, not a missing program. That's backwards from the intent: a broken login should never be quietly excused. The fix landed the same day, closing that loophole so the escape hatch only ever covers genuinely absent tools, never broken credentials.

What's still owed before this counts as proven

Two things, both plainly listed rather than hidden:

  • The actual real-world test hasn't run yet. The code works in its own automated tests, but the true test — running it for real, on the main house computer, with Andrew doing the one-time password step himself — hasn't happened. Nothing in this project is allowed to skip that step or do it automatically; that's a deliberate safety choice, not an oversight.
  • A small piece of configuration still needs to be double-checked against another related project's setup, to make sure the two stay consistent as both evolve.

What happens after that

Once the real-world login test passes, the next piece of work is building the actual thing that takes a scheduled job and hands it off to the right AI tool to do the work — still keeping the "decide when" and "decide how" jobs cleanly separate, as described in docs/plain/OVERVIEW.md. After that comes the actual Windows scheduling wiring, then cross-computer status sharing, then alerting Andrew if something keeps failing. Each of those waits for the one before it — nothing skips ahead in line.

This file grows a new section each time something real ships. If you're reading this and it still only has one "piece gets built" section, that means the project is still exactly where it was when this was written — check docs/BOARD.md for the current live status.