Fleet ## Parent

[Jhazy33]

Parent

#1 (fleet spec)

What to build

A machines registry keeps every paired machine connected while the app is foregrounded. The active machine drives full state (conversation list, composer, transcript); background machines expose a light slice (status, fatal, providers, machine metadata, busy count, pending permissions, lastSeenAt). Per-machine reconnect backoff, then slow-probe parking for background machines (60–120s probe, plus immediate probes on drawer-open and foreground), with a distinct stale/reconnecting indication until a fresh status arrives; foreground reconnect staggers active machine first. Demoable: with two machines paired, taking one offline parks it (probe interval, not ~10s hammering) and it greys out; bringing it back is noticed by a probe or on foreground.

Acceptance criteria

• Registry connects all machines while foregrounded; active machine gets full state
• Background machine after N failures parks: probe every 60–120s (injected-clock test proves the transition and interval), lastSeenAt stamped at parking
• Drawer-open/foreground triggers an immediate probe of parked machines
• Foreground reconnect order: active first, then staggered
• Stale/reconnecting state shown until a fresh status frame arrives
• Active machine never parks (keeps aggressive backoff)
• Slow-probe state machine is a pure, clock-injected module with table-driven tests

Blocked by

• Fleet ## Parent #2 (pairings-store) — the registry iterates the multi-pairing store
• Fleet ## Parent #4 (connection-extraction) — the registry drives one connection module per machine