011: what a feature is, and what it splits into

The operator wants features gone, and 006 left it open. Measured, and the answer
is that nothing replaces them because they were never one concept.

A feature is a kind of content a module carries, detected from its directory:
twenty-one of them, each with a handler owning six stages — build, publish,
install, configure, start, verify.

The structural finding: EVERY handler implements EVERY stage. `configs` writes
files onto a node, has nothing to build, and has a build stage. `npm` publishes
to a registry, has nothing to start, and has a start stage. One interface spans
build-time and apply-time, so every kind of content must implement both halves
and most do nothing in one — and a stage that does nothing looks exactly like a
stage that failed to do anything.

They split four ways, across three tiers. Artifacts built once per version and
published, where no node is involved — delivery. Resources that are desired
state on a machine, which is what ADR 0043 already describes and the host already
does — tier 0. Actions run once against something that is not this machine, like
a migration against a database on another node — delivery, and seeds go
entirely. And checks: the prerequisites are REQUIREMENTS IN DISGUISE, a module
saying what must be true before it can be installed, which is what an edge in
the graph says; the verifiers are the read-back the host already performs.

So `feature` is one word for four things spanning three tiers, which is why the
pipeline is hard to reason about.

One property must survive the split, and it is the thing the current design got
right: content is DETECTED, relationships are DECLARED. A module that says it
has migrations and has none is a fault nobody sees until it matters — but what
it requires and provides is not visible in a directory and has to be said.

01-RESEARCH/011-the-module-graph/00-overview.md

@@ -17,6 +17,15 @@ touches:
 Whether the catalogue's missing structure is a **graph** — modules declaring what they need,
 what they offer, and what they exclude — and what that replaces.
 
+**[`features.md`](features.md) answers what happens to `feature`.** It is one word for four
+things spanning three tiers — artifacts built once per version, resources applied to a machine,
+actions run against something that is not this machine, and checks that are requirements in
+disguise. Measured: every one of the twenty-one handlers implements all six stages, so `configs`
+has a build stage with nothing to build and `npm` has a start stage with nothing to start. That
+emptiness is the conflation, and it is why a stage that did nothing and a stage that failed look
+alike. Nothing replaces it, because it was never one concept. **One property is worth keeping:
+content is detected, relationships are declared.**
+
 **[`cases.md`](cases.md) enumerates what a module can be** — twenty kinds of thing the mesh has
 to install, run, own or know about — and extracts the axes a manifest must express. Two of those
 axes appear in no current thinking: **how many instances** a thing may have, and **whether two