Lab installation: the reachability check joins the assertions it belongs with

The doc's own rule is that the lab verifies capability by outcome, never by reading a setting. A path out is exactly that kind of claim — a route and a policy can both read correctly while nothing gets through — so it is asserted by fetching something, in the table with the rest. Claude-Session: https://claude.ai/code/session_01LrgweAeERJYBg88c5cKDzF
2026-09-11 00:11:39 +02:00
parent 1ce1c3d4e0
commit e4a5d9b1d0
1 changed files with 1 additions and 0 deletions
@@ -48,6 +48,7 @@ present, but that the machine can actually do the work:
 | **the pool the lab will use is on that driver** | a pool exists, and is the slow kind — the failure that has no symptom |
 | hardware virtualisation is present | machines will be emulated and unusably slow |
 | an image can be fetched or is cached | the first raise will fail late instead of early |
+| **a machine on an uplink reaches something real**, by fetching it — not by reading a route or a policy | forwarding is being dropped by something else on the workstation; names still resolve, and every pull hangs |

 Each check states **why it matters**, in the terms of what it costs. *"The pool uses the `dir`
 driver"* means nothing to someone who does not already know it means seventy-six times slower