2026-09-11 19:56:50 +00:00
1 changed files with 17 additions and 2 deletions
@@ -2,7 +2,7 @@
 layer: to-be
 status: designed
 code: [mesh-lab]
-updated: 2026-08-24
+updated: 2026-09-11
 decisions:
  - 02-DECISIONS/0029-the-labs-first-scenario-has-no-pipeline.md
  - 02-DECISIONS/0008-a-failed-step-fails-the-job.md
@@ -101,7 +101,22 @@ In order, on a machine with nothing:
   existed. Observed directly: a shell whose process tree predated the grant could not reach
   the daemon while a fresh lookup showed the membership present. The bootstrap has to say so,
   or the first thing a person meets is a permission error that looks like a broken install.
-5. **Verification**, as above, before anything is raised.
+5. **A path out to the internet for the machines that need one.** A scenario's own segments are
+   isolated on purpose, but a machine that fetches what it starts from is attached to an uplink
+   the daemon translates. That is the daemon's business and it does it — and then a **container
+   runtime on the same workstation sets the kernel's forwarding policy to drop**, which the
+   daemon's own accept rules do not override, because both are consulted and a drop anywhere is
+   the answer.
+
+   The result is the sharpest instance of *available is not adequate* yet: the machines get
+   addresses, they resolve names — the daemon's resolver is on the bridge, so that half works —
+   and every packet to anything real is discarded. Nothing is misconfigured, nothing logs, and
+   the failure presents as *every image pull hangs*. A workstation that runs containers is the
+   ordinary case, so this is a prerequisite rather than a quirk: forwarding must be permitted for
+   the lab's own bridges, and it must be **verified by reaching something**, never by reading a
+   setting.
+
+6. **Verification**, as above, before anything is raised.

 ## Open