Classification: test-infrastructure problem (image build / probe). The Dockerfile claims a backend it does not install, and the ratchet — correctly — refuses a plan-smoke in place of a real lifecycle.
The problem
The tools image fails the real-lifecycle ratchet:
FAIL real-lifecycle ratchet: 27, and container-linux-tools-local has done 28 before.
Something stopped running. A plan-smoke satisfies the audit above, so this
is the only check that notices coverage collapsing rather than breaking.
did a real lifecycle here: apt asdf bun cabal cargo conda dotnet emacs gem github
go helm krew link luarocks mise mix nimble nix npm opam pipx pixi pub service spack uv
the image says these are ABSENT: code
A manager the image failed to install cannot have a lifecycle. If one of these was here
last run, that is the whole shortfall — fix the install in the Dockerfile rather than
the number in /src/scripts/lifecycle-floor.txt.
Root cause
Dockerfile.tools:194 claims code (the vscode backend's binary) as part of the image's shipped set — the probe loop for m in nix code flatpak stack ... — but no step installs vscode/code-server. In the built image command -v code fails and /etc/shall-image-managers records code ABSENT. The vscode backend therefore cannot complete a real install→list→remove lifecycle, and the leg measures 27 against a recorded floor of 28. The coverage audit reports the absence as a soft, but the ratchet — which cannot be satisfied by a plan-smoke — goes red.
The ratchet comment (scripts/lifecycle-floor.txt) says the floor is 28 and was raised deliberately ("Raised 26 -> 28 on 2026-08-21 ... the repaired image measures 28"); the floor is not the thing to edit. The image is: install the binary it claims, or stop claiming it in the probe.
Fix
Install vscode/code-server in Dockerfile.tools (so the code probe finds it and the backend gets a real lifecycle), or remove code from the probe list so the image stops claiming a backend it does not ship. Either way the count and the floor must then agree without lowering the floor.
Evidence
- linux_run.txt:9665–9682, 9690–9695.
- Reproduced against
shall-it-tools: /etc/shall-image-managers contains code ABSENT, command -v code fails.
- Dockerfile.tools:194–198 (the probe that names
code).
Classification: test-infrastructure problem (image build / probe). The Dockerfile claims a backend it does not install, and the ratchet — correctly — refuses a plan-smoke in place of a real lifecycle.
The problem
The tools image fails the real-lifecycle ratchet:
Root cause
Dockerfile.tools:194 claims
code(the vscode backend's binary) as part of the image's shipped set — the probe loopfor m in nix code flatpak stack ...— but no step installs vscode/code-server. In the built imagecommand -v codefails and/etc/shall-image-managersrecordscode ABSENT. The vscode backend therefore cannot complete a real install→list→remove lifecycle, and the leg measures 27 against a recorded floor of 28. The coverage audit reports the absence as a soft, but the ratchet — which cannot be satisfied by a plan-smoke — goes red.The ratchet comment (scripts/lifecycle-floor.txt) says the floor is 28 and was raised deliberately ("Raised 26 -> 28 on 2026-08-21 ... the repaired image measures 28"); the floor is not the thing to edit. The image is: install the binary it claims, or stop claiming it in the probe.
Fix
Install vscode/code-server in Dockerfile.tools (so the
codeprobe finds it and the backend gets a real lifecycle), or removecodefrom the probe list so the image stops claiming a backend it does not ship. Either way the count and the floor must then agree without lowering the floor.Evidence
shall-it-tools:/etc/shall-image-managerscontainscode ABSENT,command -v codefails.code).