The lab was designed around a module under test, where a scenario is a complete mesh — forge, coordinator, cascade, verify. That is unusable for building the new mesh: all four are tier 2 and do not exist yet.
And research 009 had the sequence backwards. It put the lab at phase B, verifying tiers already built. But tier 0 is the component that takes over a machine's packages, services and network — it cannot be developed against a machine anyone needs. The lab has to exist before the thing it will test.
ADR 0029 splits scenarios into two classes:
Bootstrap
Full
Contains
VMs, the host binary, a pinned bundle
a complete mesh
Verdict from
what the host reports about what it reconciled
a pipeline result ending in verify
Exists to
develop the mesh
test what runs on it
The first is a strict subset of the second — same virtualisation, networking and lifecycle, stopping before a control plane exists — so the second is reached by addition, not rework.
The consequence worth having: raising a node from nothing stops being the least-exercised path in the system and becomes the inner development loop.
It also settles the runner's two jobs — scenario lifecycle immediately, assertion execution later.
Corrects a stale claim found while amending: the design argued scenarios were affordable with system containers and would not be with VMs. ADR 0016 superseded that reasoning; the text hadn't followed.
Issue 007 — the lab's very first requirement is installed and unusable. The virtualisation package is present and explicitly installed; both units disabled, operator in no group, client reports the server unreachable. Not issue 001 again: that's an install failing while reporting success. This is an install succeeding when success was not the point. A package is files; a capability is a running service and an identity permitted to reach it — and the module model has no vocabulary for the second.
The lab was designed around *a module under test*, where a scenario is a complete mesh — forge, coordinator, cascade, verify. That is unusable for building the new mesh: all four are tier 2 and do not exist yet.
And research 009 had the sequence backwards. It put the lab at phase B, verifying tiers already built. But tier 0 is the component that takes over a machine's packages, services and network — it cannot be developed against a machine anyone needs. **The lab has to exist before the thing it will test.**
**ADR 0029** splits scenarios into two classes:
| | Bootstrap | Full |
|---|---|---|
| Contains | VMs, the host binary, a pinned bundle | a complete mesh |
| Verdict from | what the host reports about what it reconciled | a pipeline result ending in verify |
| Exists to | **develop the mesh** | **test what runs on it** |
The first is a strict subset of the second — same virtualisation, networking and lifecycle, stopping before a control plane exists — so the second is reached by *addition*, not rework.
The consequence worth having: **raising a node from nothing stops being the least-exercised path in the system and becomes the inner development loop.**
It also settles the runner's two jobs — scenario lifecycle immediately, assertion execution later.
**Corrects a stale claim** found while amending: the design argued scenarios were affordable with system containers and would not be with VMs. ADR 0016 superseded that reasoning; the text hadn't followed.
**Issue 007** — the lab's very first requirement is installed and unusable. The virtualisation package is present and explicitly installed; both units disabled, operator in no group, client reports the server unreachable. Not issue 001 again: that's an install *failing* while reporting success. This is an install *succeeding* when success was not the point. A package is files; a capability is a running service and an identity permitted to reach it — and the module model has no vocabulary for the second.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
The lab was designed around a module under test, where a scenario is a complete mesh — forge, coordinator, cascade, verify. That is unusable for building the new mesh: all four are tier 2 and do not exist yet.
And research 009 had the sequence backwards. It put the lab at phase B, verifying tiers already built. But tier 0 is the component that takes over a machine's packages, services and network — it cannot be developed against a machine anyone needs. The lab has to exist before the thing it will test.
ADR 0029 splits scenarios into two classes:
The first is a strict subset of the second — same virtualisation, networking and lifecycle, stopping before a control plane exists — so the second is reached by addition, not rework.
The consequence worth having: raising a node from nothing stops being the least-exercised path in the system and becomes the inner development loop.
It also settles the runner's two jobs — scenario lifecycle immediately, assertion execution later.
Corrects a stale claim found while amending: the design argued scenarios were affordable with system containers and would not be with VMs. ADR 0016 superseded that reasoning; the text hadn't followed.
Issue 007 — the lab's very first requirement is installed and unusable. The virtualisation package is present and explicitly installed; both units disabled, operator in no group, client reports the server unreachable. Not issue 001 again: that's an install failing while reporting success. This is an install succeeding when success was not the point. A package is files; a capability is a running service and an identity permitted to reach it — and the module model has no vocabulary for the second.