"A Mac runs many apps. An app runs on many Macs. Two axes, two hubs — not one god-console for both."
Two Hubs, Deliberately
The family has two control centers, and they are on purpose distinct. Watchfire owns the machines: Tailscale reachability, an explicit-target fleet terminal, environment-domain sync, system and service state, macOS update campaigns, and Mac enrollment and retirement. Firelink owns the applications: the cwk* products those machines run — their census, launch, birth, deploy, and version. Where the other siblings each own an app domain, Watchfire owns the machines themselves, and Firelink is the hub for what runs on them.
Why Not One Mega-Hub?
It's tempting to build one console that 'manages everything.' Firelink and Watchfire refuse that because machines and apps are orthogonal axes. A single Mac runs many applications; a single application runs on many Macs. Their lifecycles differ — a Mac gets enrolled, updated, retired; an app gets born, deployed, versioned. Their operations differ, their owners differ, their failure modes differ. Cramming both into one hub would produce exactly the god-object the whole family avoids: a console so broad that no single mental model fits it and every screen has to answer two unrelated questions at once. Two focused hubs, each with one clear responsibility, stay comprehensible.
The Cross-Hub Boundary Is One-Directional
The two hubs do meet, cleanly and in one direction. Firelink consumes Watchfire's peer ids and its last-observed per-host liveness — as a read-only overlay, carrying Watchfire's own timestamp, never presented as a fresh Firelink probe. Firelink never tries to manage a host; that's Watchfire's domain, full stop. The boundary is observational: Firelink can show 'this app's Mac was last seen reachable at such-and-such time, per Watchfire,' and that's the extent of it. Each hub is authoritative in its own axis and a read-only guest in the other's.