Skip to content

Diagrams — Fleet Dispatch

Referenced throughout docs/technical/ARCHITECTURE.md and docs/README.md.

Mermaid baseline

Renders natively on GitHub and in any Mermaid-aware viewer — no build step required.

  • listener-loops.md — the four concurrent tasks inside fleet-dispatch serve (HTTP accept, gated queue-drain, availability presence, repo-scan) and why Task.WhenAny (not WhenAll) watches them.
  • job-signing-sequence.md — sign → verify → gate → execute → report, for both the OneDrive queue path and the direct LAN peer path, side by side.
  • availability-state-machine.md — the published-heartbeat hysteresis state machine (90s gaming grace / 120s streaming grace), plus the explicit note that the execution-time hard gate has no state machine of its own — it re-reads live signals fresh on every job.

C4 container diagram

  • c4-container.d2 — source, rendered with D2 (present on this build machine: d2 v0.7.1).
  • c4-container.svg — rendered output. Regenerate after an architecture change with:
d2 docs/diagrams/c4-container.d2 docs/diagrams/c4-container.svg

Scope: one Fleet Dispatch node (any house PC — every other house PC runs an identical set of containers) plus the shared infrastructure it depends on (OneDrive dispatch folder, peer registry files, the fleet key, the usage-governor state file) and the external actors/systems it talks to (the operator, Fleet Mission Control, Steam/OBS/registry signals, the harness CLIs, Odysseus, and peer nodes on the direct LAN path).

No Visio source exists or is planned for this repo — Mermaid for anything that changes often (architecture evolves alongside the code that renders these diagrams as text), D2 for the one diagram that benefits from an explicit container-boundary layout.