Classification
The Developer Registry decides whether a service is development work. It reads the executable and the command line, and it publishes the sentence behind every verdict.
Three outcomes, not two
| Verdict | Meaning |
|---|---|
developer | Recognised development work. Shown in Developer mode. |
system | Recognised as something else — a browser, a media player, a sync client, a vendor helper. |
unclassified | The registry has never seen it. This is the default, and it is a real answer. |
system and unclassified both hide in Developer mode, but they stay distinct because they are different claims. One says “this is a known thing that is not development work”; the other says “this has not been classified”. Only the second means the registry has a gap worth reporting.
What decides
Two kinds of rule:
- Dedicated programs, by executable name. A database server is a database server whatever port it was told to use.
- General runtimes, by command-line signature. A Node or Python process is not development work in itself — it depends entirely on what it was told to run. The command line is where that evidence lives.
Never by port number
A port is a number a program chose. It is not evidence of what that program is, and a table mapping ports to products is wrong the moment anyone passes --port.
This is why a dev server on an arbitrary high port is still classified correctly, and why a database on a non-default port is still recognised as a database.
Every verdict carries its reason
The classification block in the detail panel always contains a sentence naming the rule that produced the result — a registry entry, a matched command-line signature, or the absence of both. It is never empty.
A classification you cannot check is one you cannot correct. Publishing the reason turns “this is wrong” into “this rule is wrong”, which is something that can be reported and fixed.
The registry is versioned
Every snapshot records which version of the registry classified the services in it. A disagreement can therefore be pinned to a specific version of the tables rather than to “the app”, and a rule change is a visible event rather than silent behavioural drift.
It is not exhaustive, and says so
There will always be development tools the registry has not seen. Those are reported as Unclassified rather than guessed into either bucket, which means:
- They are hidden from Developer mode — the registry has no basis for showing them there.
- They are visible and clearly labelled in System mode, so you can see exactly what was not recognised.
A screenshot in which everything is neatly classified would misrepresent the product. The unclassified state is a feature of the model, not an embarrassment in it.
Classified, but not a service
A background worker can be classified as development work and still not appear in Services, because a service is defined by holding a listening socket. It appears in Processes instead. The model stays consistent rather than making an exception.