Skip to content

Fleet Dispatch, Plain Version

Plain track. Full technical detail: docs/technical/ARCHITECTURE.md. Index of everything: docs/README.md.

What it does

Fleet Dispatch is a trusted worker that runs on every house PC. It lets one PC ask another to run a command — a Claude prompt, a PowerShell script, a build, whatever — and get the result back. Think of it as a very careful, very suspicious remote-control system: it will run almost anything you sign with the right key, but it checks that signature, checks whether the target PC is busy, and checks whether the target PC is being used for gaming or streaming, every single time, before it does anything.

The two ways to send a job

  1. Slow and durable (queue) — you drop a signed job in a shared OneDrive folder. The target PC picks it up next time it checks (every 30 seconds or so), runs it, and drops the result back in OneDrive. Works even if the target PC is off right now — it'll run the job when it comes back.
  2. Fast and direct (peer) — you send the signed job straight to the target PC's listener over the house network and wait for the answer. Only works if the target PC is on and reachable right now, but it's near-instant.

Both paths do the exact same checks before running anything — same signature check, same "is this PC busy" checks — they just differ in how the job gets there and how fast you hear back.

It never runs an unsigned or relabeled job

Every job carries a cryptographic signature made with a shared secret key that only lives on the house PCs (never in OneDrive — it's copied machine-to-machine over SSH). Before running anything, the listener recomputes that signature and checks it matches, byte for byte, using a comparison method that doesn't leak timing information an attacker could use to guess the key. If the signature doesn't match, or looks tampered with, or has already been run once before (replay protection), the job goes to a "rejected" pile with a plain-English reason instead of running.

One detail that matters a lot: the label that says how disruptive a job is (a "trivial" check-in versus a "heavy" build) is part of what gets signed. That's deliberate — if that label weren't signed, someone who could drop files in the queue (but didn't have the real key) could relabel a heavy job as harmless to sneak it past the "don't disturb me while gaming" check below. Signing it closes that door.

It refuses to disturb you while gaming or streaming

This is the newest piece. Every PC constantly checks, right before running any non-trivial job:

  • Is OBS (streaming software) running? → refuse everything except the most basic status checks.
  • Is Steam reporting a game is running? → refuse anything heavy (builds, AI runs, anything that might pop up a window), but still allow trivial background checks.
  • Did you manually flip a switch (an override file) saying "I'm unavailable" or "I'm available anyway, ignore what you're seeing"? → that wins over everything else.

This check happens fresh, every single time, right before a job runs — it never trusts a cached "I checked five seconds ago" answer. There's a separate slower-moving status (updated every few seconds, published so other tools can show "is this PC busy" without asking twice) that deliberately waits about 90 seconds after you stop gaming (or 120 seconds after you stop streaming) before saying you're free again — so a tool watching that status doesn't see it flicker on for the half-second between you alt-tabbing and jumping right back into the game. The actual "can this job run" decision never waits, though — it's always based on what's happening right now.

What it's not (yet)

  • It won't pause a job that's already running when you start gaming mid-job — it only stops new jobs from starting.
  • It doesn't (yet) detect a game that isn't on Steam and isn't on a manually-maintained allow list — that's on a documented "not built yet" list, not a silent gap.

Learn more