Files
hq/02-DECISIONS/0172-the-lab-is-a-module-and-runs-a-bed-when-the-mesh-asks.md
T

2.9 KiB

topic, status, date, deciders, reconstructed, extends
topic status date deciders reconstructed extends
the mesh accepted 2026-10-02 jochen false 02-DECISIONS/0016-the-lab.md

172. The lab is a module, and runs a bed when the mesh asks

Context

The lab raises virtual machines and runs the mesh on them, end to end, before a change reaches a real machine (ADR 0016). It runs on one machine of the mesh, the one with the virtualisation it needs. Until now the only way to start a bed there was to sign in to that machine and run the lab's command line by hand, with a dozen environment variables pointing at sibling checkouts.

Nothing in the mesh could ask for it. An agent working through the mesh's own tools could build, merge and push a change, and could not prove it in the lab first. The operator's direction on 2026-10-02: work on another machine goes through a mesh tool, not a shell on it.

Considered Options

  1. Keep the lab a command line on one machine. Every run is a person, or an agent with a shell on that machine, outside the mesh.
  2. The lab is a module. Assigned to the machine that can run it, serving tools that run a bed against named branches and say how it went.

Decision

Option 2.

  • A lab module, assigned where the lab can run, serves five tools: whether this machine can run beds, run beds against a branch per repository, a run's state, its log, and stopping it.
  • A run is the lab's own suite, against fresh checkouts of the named branches from the mesh's forge, side by side as the lab expects them. It builds what the beds place from those checkouts, as the suite already does. It answers at once with an id, like a build: a bed takes minutes, and a call does not.
  • Only branches on the forge are run, never code handed to the tool. What a run tested is what the forge holds at the commit it names.
  • The lab is reached over the mesh only. Its tools travel the bus, and the module opens no port.
  • No grant beyond the mesh's own. Running a bed is root on the lab's machine, but anyone who can call the mesh's tools can already do worse. The operator's judgement on 2026-10-02.

Consequences

  • An agent proves a change in the lab through the mesh, the same way it builds and pushes one.
  • The lab's machine carries a module whose runtime holds the virtualisation's and the container runtime's sockets, and a toolchain to build the mesh with.
  • A run's checkouts are its own, so two runs never build from each other's tree. Old ones are removed when their run ends.

How this is checked

Rule Checked by
A run checks out exactly the named branches, and reports the commits it tested the module's tests over a forge fixture, and each run's answer
A run answers at once, and its state and log follow it to the end by hand, the first run
The module opens no port the composed filter of the lab's machine