Developer mode

The rule

Developer mode is one decision, and three consequences that read off it:

1. Take the services the Developer Registry classified developer.
2. Show exactly those services.
3. Show exactly the processes that own them.
4. Show exactly the sockets those processes hold.

Steps two to four are derived from step one, so Overview, Services, Processes and Ports cannot disagree. A service is never shown without its process, and a port is never shown without the service that owns it.

Presentation, never collection

Mode changes what is shown, not what is measured. The sampler produces the same complete snapshot in both modes, and the narrowing happens in exactly one place in the interface.

Two things follow from that:

• Switching modes is free. It triggers no scan, so it cannot be slow and cannot cost anything.
• Developer mode can never cause LocalDocks to miss something. Whatever it is hiding is one click away in System mode.

Ancestry is not evidence

An earlier version of this narrowing treated every service as developer-relevant and then spread outward through the process tree — a service’s parent, and its children. Both halves were wrong.

Every service is not developer work. A service is an observation: a process you own holding a listening socket on a non-system port. Browsers, music players, sync clients, vendor helpers and every editor window satisfy that, and on a real machine they outnumber the actual dev servers heavily. A view that included all of them would be indistinguishable from System mode.

And one hop from a service reaches whatever else its parent started — unrelated siblings, the shell, and from a terminal essentially everything running under it. Being spawned by the same thing as a dev server does not make a process part of the development picture.

The binding address is not consulted

A server on 0.0.0.0:8000 is exactly as visible as one on 127.0.0.1:8000. Hiding the wider binding would hide the one you most need to notice.

Development work with no socket

A background worker is development work, but it is not a service, because a service is defined by holding a listening socket. Such a process appears in Processes and not in Services. That is the model being consistent rather than an omission.

When Developer mode is empty

The Overview says so in words, and says what to do: start a dev server, or switch to System mode to see everything that is listening. A machine can be busy and still have no development services, and the wording exists so an empty list is not mistaken for a broken application.

If you disagree with a verdict

Open the service and read the reason in the detail panel. The snapshot also records which version of the registry classified it, so a disagreement can be pinned to a specific version of the tables rather than to the application in general. See Classification.