Lab installation: a path out, and why the daemon having one is not enough

A container runtime on the same workstation sets the kernel's forwarding policy
to drop, and the virtualisation daemon's own accept rules do not override it —
both are consulted and a drop anywhere is the answer. The machines then get
addresses and resolve names, because the daemon's resolver is on the bridge, and
discard every packet to anything real.

The sharpest 'available is not adequate' yet: nothing is misconfigured, nothing
logs, and it presents as every image pull hanging. A workstation that runs
containers is the ordinary case, so it is a prerequisite — verified by reaching
something, never by reading a setting.

Claude-Session: https://claude.ai/code/session_01LrgweAeERJYBg88c5cKDzF

03-DESIGN/01-to-be/04-lab-installation.md

@@ -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