diff --git a/04-ISSUES/012-a-scenario-machine-is-too-small-for-four-images/00-report.md b/04-ISSUES/012-a-scenario-machine-is-too-small-for-four-images/00-report.md
new file mode 100644
index 0000000..1fbe53a
--- /dev/null
+++ b/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.