Skip to content

fleet-routine — Making Of

Status: LIVING. This document is updated as the project moves; it is not a fixed retrospective. Where the project actually is right now: Gate 0 only (FLT-104), status In Review. Everything past Gate 0 (FLT-105 through FLT-108) is a plan, not history — there's nothing built yet to narrate for those. This file will grow a new section per phase as each one actually lands.

Sourced from git log, BUILD-REPORT.md, and docs/FLT-104-gate0-auth-smoke-spec.md. No claim below goes beyond what those three sources say.

Beat 1 — 2026-07-17 21:18 — Scaffold + first spec draft

Commit 04d778a: fleet-routine: scaffold fleet-routine + Gate 0 auth-smoke spec. The repo, the solution skeleton, and the first draft of docs/FLT-104-gate0-auth-smoke-spec.md land together.

This is where the project's core constraint gets written down for the first time: fleet-routine is a scheduling plane, not an orchestrator, and Gate 0 — proving all six harnesses can authenticate non-interactively — is the GO/NO-GO for everything downstream. No scheduler line of code is allowed to exist until Gate 0 passes.

Beat 2 — 2026-07-17 21:38 — Council folds into the spec

Commit c8c1fe4: fleet-routine: fold council decisions into Gate 0 spec. Twenty minutes after the scaffold, a council pass resolves three concrete open design questions and writes the answers straight into the spec (§9):

  1. Odysseus/Ollama probe targets: localhost only (127.0.0.1:7000 / 127.0.0.1:11434). Remote-host reachability is explicitly deferred to FLT-107 — folding it into Gate 0 would turn a binary auth go/no-go into a flaky network inventory check.
  2. S4U credential handling: persistent reused probe task, OS-custodied secret. One-time doctor --register-probe (interactive password prompt, held by Windows LSA/DPAPI from then on); --noninteractive only ever triggers and reads. "Throwaway" (an earlier draft's word) is reinterpreted as idempotent / no persistent side effects — not literally re-registered every run, which would force the password prompt back into the loop on every invocation.
  3. Canary matching: contains, case-sensitive, fresh per-run nonce, ANSI-stripped and CRLF-normalized first. Exact-match was rejected because it fails in practice: reasoning models prepend thinking text, chat models add markdown, local models truncate. contains is "the strictest rule all six reliably satisfy."

Separately, a council seat (streaming gpt-oss:120b) had proposed running the smoke test under the SYSTEM account instead of Andrew's user. That proposal is explicitly rejected in the spec (§1) — SYSTEM loads a different profile with no access to any harness's OAuth token store, so a SYSTEM-run probe would prove nothing about the context real routines will actually run in.

This same architecture pass (council opus 2026-07-17, FLT-34) also settled the bigger question of whether fleet-routine should exist as a separate C# repo at all, or be absorbed into fleet-harness/Python. Ranking D/grok > A/claude > B/codex > C/gemini > E/local, the council returned 5 AGREE / 2 DISSENT in favor of keeping them separate — the two dissents (both heaviest-weighted local seats) argued for the absorb-into-Python option and were overruled. That result is what docs/BOARD.md and docs/technical/ARCHITECTURE.md §1 describe as "council-approved architecture." Reports: llm-council/reports/2026-07-17_191704_should-the-fleet-harness-flt-1-the-universal.md (the separate-repo decision) and llm-council/reports/2026-07-17_212623_resolve-3-concrete-design-questions-for.md (the three questions above) — both in the fleet-wide llm-council project, not this repo.

Beat 3 — 2026-07-17 22:06 — doctor gets built

Commit 47176f1: fleet-routine: implement doctor auth-smoke (Codex build, Claude-verified). Twenty-eight minutes after the spec settled, the entire doctor CLI — WindowsProbeTask.cs, ProbeRunner.cs, Probes.cs (all six harness probes), Canary.cs, Gate.cs, Models.cs, and the five xUnit test files — lands in one commit.

Build attribution matters here and is stated plainly in BUILD-REPORT.md: Codex wrote the code, offloaded under governor RED (the fleet's usage-governor was in a constrained tier at the time), and Claude verified it independently — not on Codex's word. The verification actually ran the gates: dotnet build -warnaserror → 0 warnings, 0 errors; dotnet test → 18 passed, 0 failed.

BUILD-REPORT.md's reviewer notes flag one thing explicitly as unresolved at this point: passwordless TaskLogonType.S4U yields a token without network credentials. The working theory is that this is fine, because harness OAuth tokens are read from local disk and vendor API calls carry those tokens, not Windows network creds — but the report is honest that this is a theory until the first live run proves it. If a harness fails with AUTH_TOKEN_MISSING specifically under S4U (and not under an ordinary interactive run), the documented fallback is to revisit password-stored logon (TaskLogonType.InteractiveOrPassword). This is, in the report's own words, "precisely the risk Gate 0 exists to surface" — the uncertainty is the point of building the gate, not a gap in it.

BUILD-REPORT.md also lists what's still owed at this point: a council code-review gate hadn't run yet (the build's own runner had died before its review step), and the live Gate 0 run on the main PC — which requires Andrew to do the one-time interactive --register-probe step himself — hadn't happened.

Beat 4 — 2026-07-17 22:07 — Board reflects reality

Commit 9249cb6: fleet-routine: board -> In Review (doctor built + verified), one minute after the build lands. docs/BOARD.md is updated to show FLT-104 as In Review rather than In Progress, with the same two owed items called out in the board's own words.

Beat 5 — 2026-07-18 14:17 — Council review lands fixes

Commit 8672a9f: fleet-routine: apply council review fixes to doctor. The council code-review gate that Beat 3 flagged as owed runs, and finds a real gap: the original --allow-missing implementation let any failure on a named harness through, including a broken credential. The fix — visible directly in the source comments on this branch — tightens Gate.cs so AllowlistableFailures covers only PATH_OR_EXE_NOT_FOUND, MODEL_UNAVAILABLE, and NETWORK_UNREACHABLE; an AUTH_TOKEN_MISSING, AUTH_PROMPT_REQUIRED, DPAPI_DECRYPT_FAILED, or CANARY_MISMATCH on a named harness stays a hard FAIL no matter what's in --allow-missing. The new behavior is locked in by GateTests.Allow_missing_must_not_swallow_auth_or_canary_failures — a test written specifically to name the four failure classes that must never be excusable. See docs/diagrams/auth-smoke-gate.md for why this matters: without this fix, --allow-missing could have been used to greenlight a genuinely broken credential, which is exactly the failure mode Gate 0 was built to catch in the first place.

What's still owed, as of this document

Straight from BUILD-REPORT.md, cross-checked against the current source tree:

  • Live Gate 0 run on the main PC — the actual acceptance criterion (spec §7.1: principal non-SYSTEM + logonType: S4U in real output, all six harnesses verdicted). This requires Andrew to run the one-time interactive --register-probe step himself; nothing in this repo can do that step unattended by design.
  • TODO(FLT-104) in WindowsProbeTask.cs — still present in source as of this writing — to align the account/RunLevel configuration with the real fleet-dispatch listener config as that config evolves.

What comes next (not yet started)

FLT-105 (run-now vertical slice through the C#↔fleet-harness seam) is blocked on Gate 0 actually passing on the main PC, not merely on the code existing. See docs/BOARD.md for live status and docs/diagrams/routine-lifecycle.md for what FLT-105 through FLT-108 are expected to build.

Update this file with a new numbered beat each time a phase of the project lands — do not let it go stale relative to git log and docs/BOARD.md.