2.0 KiB
status, opened, located-in, fixed-by, amended-design
| status | opened | located-in | fixed-by | amended-design | ||
|---|---|---|---|---|---|---|
| resolved | 2026-09-21 |
|
mesh-lab feat/mesh-tests-and-runtimes (the suite compares each stocked runtime against its source and rebuilds it where older, missing or uncommitted); proven by removing an image and watching the run rebuild it | 03-DESIGN/01-to-be/01-end-to-end-testing.md |
A stocked runtime image is never rebuilt by the run
Symptom, as observed
A per-module bed stocks the module's runtime image — the tool runtime carrying that module's code — from the workstation's image store, by tag. The image is built by hand, by a script in the lab repository that the suite never calls. On the day issue 073 was worked, the images for six modules whose beds were about to run dated from two weeks before the manifests they were to be installed with; the catalogue's code for those modules had changed since, and every bed would have passed against the old image. The suite's own rule — the run rebuilds what it tests — is held for the host binary and the controller image and not for these.
Why it matters beyond this instance
- Silence and success look alike again. A bed that passes against a stale runtime reports the module proven; nothing says the image predates the code.
- It is the same fault issue 005 named, one layer down: a stale artifact reporting success against code that moved.
- The receipt now names the catalogue's commit (ADR 0089), which makes this sharper, not better: the receipt claims a commit whose runtime code was never built into what ran.
What would close it
The suite builds, or refuses to stock, a module runtime whose image is older than the module's source in the catalogue the run is pointed at — the same treatment the host binary and the controller image get. Or the scenario says which images it stocks stale, and the receipt says so too.