Issue 012 — a scenario machine cannot hold four images and raise a

substrate

Adding a fourth image to the two-machine scenario makes the bootstrap
fail every time, with the store's readiness check producing no output at
all — which says the container was not running rather than that the
database was slow. Three images pass nine assertions; four never get past
the store.

More memory did not change it, so memory is not the cause; the change is
kept because the reasoning holds on its own. Disk is the most likely
explanation and nothing has measured it.

It blocks proving the mesh runs its own artifact store, since the
registry module needs a registry image to mirror. The module is written
and accepted; what is unproven is a machine assigned it serving another.

04-ISSUES/012-a-scenario-machine-is-too-small-for-four-images/00-report.md

@@ -0,0 +1,55 @@
+---
+status: open
+opened: 2026-08-30
+located-in: [mesh-lab]
+fixed-by:
+amended-design:
+---
+
+# 012 — A scenario machine cannot hold four images and raise a substrate
+
+## Symptom
+
+Adding a fourth image to the two-machine scenario made the bootstrap fail every time. The store
+container was created, and its readiness check then failed for the full three minutes with
+**no output at all**:
+
+```
+failed store-ready (in mesh-store: ... pg_isready ... exit 1):
+  the action ran without error and its own verify still fails: docker exited 1:
+```
+
+Empty after the colon. The check runs `pg_isready` inside the container and prints the store's own
+last lines when it gives up; producing nothing means **the container was not running**, which is a
+different fault from a database that is slow to start.
+
+Three images: the scenario raises, both machines join, and nine assertions pass. Four: it never
+gets past the store. Reverting the fourth image restores it.
+
+## What was tried
+
+- **More memory.** Scenario machines were raised from 1 GiB to 2 GiB, on the reasoning that a
+  machine running a database, a broker and the control plane at once is genuinely small. It did not
+  change the outcome, so memory is not it — the change is kept because the reasoning holds
+  independently.
+- **A better diagnostic.** The readiness check now prints what it saw before giving up
+  ([04-ISSUES/011](../011-one-broken-module-blocks-every-other/00-report.md) changed the apply
+  around it). That is what showed the output was empty, which is what rules out slowness.
+
+## What is most likely, and untested
+
+**Disk.** Four images plus the base image on a machine whose root disk the scenario does not size.
+A database that cannot write its data directory does not start, and the container exits — which
+matches the evidence exactly. Nothing has measured it.
+
+## What this blocks
+
+The mesh running its **own artifact store** — a registry as a module — needs a registry image on
+the machine so the module can mirror one, which is the fourth image. The module is written and its
+manifest is accepted; what has not been proven is a machine assigned it serving artifacts to
+another machine.
+
+## How this will be checked
+
+A scenario raised with four images comes up and passes the assertions that three do. Until then the
+artifact-store test is not in the shared scenario, with a note saying where it went and why.