Brokentooth.io / 06 Writing / A star map can't drive the machines
A star map can't drive the machines
Why the attractive first NEXUS visualization had to make room for real operational surfaces.
The first NEXUS star chart did something important: it gave the fleet a shape. It also revealed what it could not do.
Looking at a star does not let you inspect a terminal, watch a model load into GPU memory, find out which agent owns a worktree, or steer a desktop. The goal was never to make a screensaver for a homelab.
I wanted one place where the whole Brokentooth cluster could become comprehensible and, eventually, usable.
One machine, many kinds of presence
A physical computer might have a real graphical desktop. Another machine may be deliberately headless, spending its life compiling code. A third can host a model and never have a screen worth looking at. Some activity belongs to an agent session, not to any single desktop.
Treating all of those as identical computer screens would make the interface misleading. So the next NEXUS work introduces the idea of a surface: a descriptive view of something you can meaningfully observe. A desktop can have one. A terminal, workload, service, or agent session can have its own. The surface should say whether it has been observed, is unknown, or is only proposed.
That last distinction is particularly important for the Muse side of the system. Two registrations with similar names are not proof that two machines can be reached or that either agent is available to take instructions.
Beauty and authority are separate jobs
The star chart can remain an optional atlas. But the working face of NEXUS should be direct: find a node; inspect what is true; locate the right workbench; act only through the controls that are actually authorized.
The original read-only slice already exists. The richer surface work began in an isolated branch and was not part of the published private preview at the time of this note. Screens, commands and approvals belong to later integration gates.