diff --git a/04-ISSUES/214-a-plan-loses-track-of-the-controller-it-rebuilds/00-report.md b/04-ISSUES/214-a-plan-loses-track-of-the-controller-it-rebuilds/00-report.md
new file mode 100644
index 0000000..5bcfcd2
--- /dev/null
+++ b/04-ISSUES/214-a-plan-loses-track-of-the-controller-it-rebuilds/00-report.md
@@ -0,0 +1,36 @@
+---
+status: open
+opened: 2026-10-03
+located-in:
+  - mesh-controller
+fixed-by:
+amended-design:
+---
+
+# 214 — A plan loses track of the controller it rebuilds, and waits on it for ever
+
+## What was observed
+
+2026-10-03, a merge to the controller's repository planned three tiers: the controller itself, then
+the build agent, then the route proxy. The controller's build finished and was recorded at 19:24:
+
+```
+mesh-controller    built 2ebbb799 g14   2026-10-03 19:24
+```
+
+Twenty-seven minutes later the plan still read `tier 1 of 3 … mesh-controller asked`, and every later
+plan waited behind it. It was stopped by hand; the later tiers were never asked.
+
+## Why it matters beyond this instance
+
+The controller rebuilding itself is the one plan whose first tier replaces the process that runs the
+plan. The new controller starts with the plan's state as stored, and the outcome of the build that
+produced it arrived to the old one, or between the two. Every merge to the controller's own repository
+can end this way, and each one blocks every plan after it until somebody notices.
+
+## Diagnosis
+
+Owner mesh-controller (the planner). **Fix direction:** on start, and whenever a plan waits on a
+build, the plan settles an `asked` build against the build records — a build recorded as built from
+the plan's commit is that tier's outcome — so a plan resumes after the controller replaced itself.
+A test: a plan whose build outcome was recorded while no controller followed it resumes on start.
diff --git a/04-ISSUES/215-a-module-built-at-a-commit-stops-following-its-branch/00-report.md b/04-ISSUES/215-a-module-built-at-a-commit-stops-following-its-branch/00-report.md
new file mode 100644
index 0000000..0bfc600
--- /dev/null
+++ b/04-ISSUES/215-a-module-built-at-a-commit-stops-following-its-branch/00-report.md
@@ -0,0 +1,35 @@
+---
+status: open
+opened: 2026-10-03
+located-in:
+  - mesh-controller
+fixed-by:
+amended-design:
+---
+
+# 215 — A module built once at a commit stops following its branch, and merges leave it out
+
+## What was observed
+
+2026-10-03, a catalogue merge changed seven modules. Its plan built six; `unifi` was not in it,
+though its change was in the same commit. A second merge the same evening left it out again. Its
+build records name a commit where every other module names a branch:
+
+```
+unifi   built 9c97a8a1 …   http://…/mesh-catalog.git at 9c97a8a
+```
+
+Built by hand from `main` it was registered again and the change reached its machine.
+
+## Why it matters beyond this instance
+
+A module that was once built at a commit — to pin it during a fix, or by a build asked with a `ref`
+— silently stops following its branch: merges plan without it, `status` does not say it is behind its
+branch, and nothing says it is pinned. The operator learns it when a change does not arrive.
+
+## Diagnosis
+
+Owner mesh-controller. **Fix direction:** a build asked at a commit does not change the branch a
+module follows; or, if pinning is meant, the pin is said — in `module list`, in `status`, and by a
+merge's plan naming the module it leaves out and why. A test: building a module at a commit and then
+merging a change to it plans it.
diff --git a/04-ISSUES/216-a-bundle-nothing-loads-is-built-and-never-delivered/00-report.md b/04-ISSUES/216-a-bundle-nothing-loads-is-built-and-never-delivered/00-report.md
new file mode 100644
index 0000000..bdc2ad4
--- /dev/null
+++ b/04-ISSUES/216-a-bundle-nothing-loads-is-built-and-never-delivered/00-report.md
@@ -0,0 +1,30 @@
+---
+status: open
+opened: 2026-10-03
+located-in:
+  - mesh-controller
+fixed-by:
+amended-design:
+---
+
+# 216 — A tools bundle nothing says to load is built, recorded, and never delivered
+
+## What was observed
+
+2026-10-03, seven modules moved their tools from a container to a bundle. Each built, each build was
+recorded, and the machines that run them reported current — with none of the bundles on them. The
+composer delivers a bundle only when the runtime loads something from it, and that is derived from
+the module's `tools` list when the artifact names no `loads`; these modules had neither.
+
+## Why it matters beyond this instance
+
+Every step reported success: the build, the registration, the push, the machine's apply. The tools
+were simply absent, and the old container was gone. A rule the composer applies silently is a rule
+nobody learns until the tools are missing.
+
+## Diagnosis
+
+Owner mesh-controller (the catalogue's registration check). **Fix direction:** a bundle that nothing
+loads, runs or unpacks — no `loads`, no `tools` list on its module, no resource naming it — is refused
+at registration, naming the field that would deliver it. A test: such a manifest is refused; adding
+`loads` admits it.