2026-09-05 10:27:11 +00:00
1 changed files with 20 additions and 0 deletions
@@ -151,6 +151,26 @@ differ and the message should say which:
 - *i3 needs xorg, which is not assigned here* — assign it.
 - *this machine has no seat* — wrong machine; nothing can be installed to fix it.
 ### A capability may carry a value, and that is not a new idea
 A capability is a named fact about a machine, **detected and never assumed**. Its presence gates
 an assignment; its detail can also carry a value — `seat: card1-DP-1`, `panel: oled`, an
 architecture, an amount of memory. Nothing new is needed for that: a verdict has always had a
 detail beside its yes or no.
 So *can this run here* and *what should it be configured as* are answered by the same fact, read
 two ways. A module that must not be assigned without an OLED panel and one that dims itself
 differently on one are reading the same line.
 **What keeps the set from sprawling is the cost of adding one.** A capability must be detected,
 and the detector must say how it knows — so nobody can add one they cannot check, which is the
 whole of [04-ISSUES/007](../04-ISSUES/007-an-installed-package-is-not-a-capability/00-report.md):
 an installed package was treated as a capability and a node was assigned work it could not do.
 **And detectors ship inside the host**, which is one statically linked binary. Adding a capability
 means shipping a new host to every node that needs it. That is a real cost and it argues for
 keeping the vocabulary small and general — `seat`, not `has-nvidia-with-two-outputs`.
 ## "Flavor" is retired
 It was carrying three unrelated meanings — variants of a thing, a subset of one module a node