Model the state before the buttons
The inspected source defines explicit service states such as starting, running, stopping, and restarting. Its event model records status requests, launch failures, process scans, logs, configuration changes, and source-control operations.
Neighboring services have a name, directory, entry point, detected port, runtime status, and notes. Port detection carries both a source and a confidence level rather than pretending every inferred setting is certain.
Permissions belong in the view
Launch configuration includes separate network, read, and write permissions with allowlists. That makes the intended Deno capability boundary part of the service record. A command preview provides an inspectable representation of how a selected service will start.
The model also records Redis dependencies and identifies which service provides them. For a workspace composed of many small applications, this helps explain why a page can be present while a dependency is unavailable.
The event structure includes method, path, timestamp, and state, creating a common vocabulary for explaining what the dashboard requested and what the service reported.
Show uncertainty instead of hiding it
A dashboard becomes more useful when it distinguishes an observed process from an inferred configuration. Port confidence, runtime status, launch permissions, and event history give different kinds of evidence. Keeping those fields separate helps an operator understand whether a service is stopped, misconfigured, still starting, or simply not observable yet.