The bootstrap starts a step earlier than recorded

Asked whether postgres has to be installed, and the answer exposed a missing
step. The store is a container, so something must run containers before anything
else happens — and a container runtime is a PACKAGE, not a container.

Step 0 is where several threads meet. It is what the host's capability detection
already reports, and the first use of that report by something other than a
person. It is adopted rather than installed when the machine already has a
runtime with configuration somebody chose. And it is a package, needing the
machine's own package manager and a network, both of which ADR 0046 permits.

So the host's bootstrap vocabulary is six shapes: package, container, file,
directory, service, action. Stage 2 built three of them.

The node host design now names which three remain and why the lab cannot yet
exercise them — a sealed scenario fetches nothing and its machines carry no
container runtime, which is lab-installation work rather than a constraint on
the design, because production machines have a network.

03-DESIGN/01-to-be/05-the-node-host.md

@@ -163,11 +163,19 @@ what it is. No control plane, no declarations, no network. Verifiable immediatel
 the first node's path, and it is the claim the skeleton's Move 1 rests on and has never proved:
 that one host can raise the substrate alone.
 
-The first vocabulary is bounded by something the lab makes unavoidable: **a scenario is a
-closed address space**, so a resource that must be fetched cannot be applied there at all. So
-stage 2 begins with what needs no network — files, directories, service state — and the types
-that need artifacts wait on where those come from, which is open in
-[`02-scenario-declaration.md`](02-scenario-declaration.md).
+Raising the substrate needs six shapes in the host's vocabulary, and stage 2 built three:
+
+| | |
+|---|---|
+| `directory`, `file`, `service` | **built** |
+| `package` | a container runtime must exist before a container can run |
+| `container` | pulled by digest ([ADR 0046](../../02-DECISIONS/0046-the-installer-fetches-what-it-pins.md)) |
+| `action` | provisioning steps the bundle declares and the host verifies ([ADR 0047](../../02-DECISIONS/0047-the-bundle-may-carry-actions-the-link-may-not.md)) |
+
+The lab cannot yet exercise the last three: a scenario is a closed address space, so nothing can
+be fetched there, and its machines carry no container runtime. That is lab-installation work
+([`04-lab-installation.md`](04-lab-installation.md)) rather than a constraint on the design —
+production machines have a network.
 
 **3 — link and store.** The node connects, receives declarations, and holds what it applied.
 

03-DESIGN/01-to-be/07-the-substrate.md

@@ -85,13 +85,29 @@ is what keeps the bundle small enough for a person to read and check.
 The order, from [research 011](../../01-RESEARCH/011-the-module-graph/worked-provider.md):
 
 ```
-1  the host applies the bundle          the store runs; no mesh exists
-2  a database is created in it          a provisioning step, done locally
-3  the control plane's schema applied   a migration against that database
+0  a container runtime exists           detected, or installed as a package
+1  the store runs                       pulled by digest, from the bundle
+2  a database is created in it          an action, run locally
+3  the control plane's schema applied   an action, against that database
 4  the control plane starts             and only now is there a mesh
 5  everything else is provisioned       the ordinary path
 ```
 
+**Step 0 is easy to leave out and it is where several things meet.** A substrate service is a
+container, so something must run containers before anything else happens — and a container
+runtime is a *package*, not a container. It is:
+
+- what the host's capability detection already reports, and the first use of that report by
+  something other than a person;
+- **adopted rather than installed** when the machine already has one with configuration somebody
+  chose ([research 012](../../01-RESEARCH/012-the-minimum-viable-node/00-overview.md));
+- a package, which needs the machine's own package manager and a network — both permitted by
+  [ADR 0046](../../02-DECISIONS/0046-the-installer-fetches-what-it-pins.md).
+
+So the host's bootstrap vocabulary is five shapes: **package**, **container**, **file**,
+**directory**, **service**, and **action**. Files, directories and services exist; the rest do
+not yet.
+
 **Steps 2 and 3 happen before there is a mesh to do them**, which is why provisioning is part of
 the bootstrap rather than a service consumers use later. They are **actions** the bundle
 declares and the host runs