Diagram — Full Routine Lifecycle (DESIGNED, NOT BUILT)

Status: DESIGNED ONLY. Nothing in this diagram exists as code yet. It reflects the council-approved architecture in docs/BOARD.md ("Architecture (council opus 2026-07-17 — do not re-litigate)") and the non-goals list in docs/FLT-104-gate0-auth-smoke-spec.md §8. It is drawn here so the intended shape is legible before FLT-105/106/107/108 build it — treat every box below as a plan, not a fact about running software. The only real, running piece of fleet-routine today is Gate 0 doctor (see docs/diagrams/doctor-probe-flow.md).

sequenceDiagram
    participant Registry as Registry (FLT-105, DESIGNED)
    participant WTS as Windows Task Scheduler
    participant Runner as Thin runner (FLT-105/106, DESIGNED)
    participant Gov as usage-governor (fire-time check)
    participant Harness as fleet-harness routine-fire<br/>(FLT-1, Python/LangGraph — different repo)
    participant NATS as NATS JetStream (fleet.v1)
    participant Pavlok as Pavlok policy (FLT-108, DESIGNED)

    note over Registry,WTS: FLT-106: WTS registers a TRIGGER-ONLY task per routine.<br/>Trigger survives reboot/sleep and supports missed-run<br/>catch-up (StartWhenAvailable). WTS does not run the logic itself.
    WTS->>Runner: cron tick fires the routine's WTS task
    Runner->>Registry: look up routine definition (cron, budget, target harness)
    Runner->>Gov: fire-time budget check (fail-closed)
    alt governor allows
        Gov-->>Runner: proceed
        Runner->>Harness: fleet-harness routine-fire<br/>(process boundary: prompt-file in, JSON out)
        note over Runner,Harness: Runner NEVER selects the harness adapter or<br/>re-implements routing — fleet-harness owns HOW.<br/>fleet-routine only owns WHEN + budget.
        Harness-->>Runner: JSON result
        Runner->>NATS: emit fleet.v1 telemetry
    else governor denies
        Gov-->>Runner: defer
        note over Runner: defer = skip THIS tick only.<br/>Never queue-and-flush.
        Runner->>NATS: emit deferred telemetry
    end
    opt repeated failure
        Runner->>Pavlok: escalate (dedupe policy)
    end

What Gate 0 has to prove before any of this is written

Per the spec (§1), the #1 pre-build risk for this whole diagram is silent non-interactive auth failure: every box above runs headless, unattended, at 2 AM. If a harness CLI can't authenticate under the S4U execution context, the routine fails silently forever. That's why doctor (BUILT) had to exist and pass before Runner, Registry, or the WTS trigger management above are built — see docs/diagrams/auth-smoke-gate.md.

Ticket sequencing (all DESIGNED, strictly blocked in order)

flowchart LR
    G0["FLT-104 Gate 0<br/>doctor auth smoke<br/>BUILT, In Review"] -->|GO/NO-GO| F105["FLT-105<br/>run-now vertical slice<br/>C# <-> fleet-harness seam<br/>DESIGNED"]
    F105 -->|before WTS| F106["FLT-106<br/>WTS trigger via COM/API<br/>trigger-only, StartWhenAvailable<br/>DESIGNED"]
    F106 --> F107["FLT-107<br/>multi-PC JetStream replay<br/>+ Claude-native normalize<br/>DESIGNED"]
    F107 --> F108["FLT-108<br/>Pavlok dedupe/escalation<br/>+ full cap enforcement<br/>DESIGNED"]

All five anchor to FLT-34 (the parent epic). See docs/BOARD.md for live status.