The fourth status line

The fourth tool had joined the update manifest, but its test still believed there were three. The updater printed one healthy line per managed tool, exactly as intended. Validation counted four lines, compared that result with a hard-coded expectation of three, and failed every devcontainer startup.

FAIL: expected exactly three status lines

The fixture was part of the feature#

Changing the expected count was necessary, but not sufficient. The test environment also needed a fake pnpm binary, version state, and update fixtures so the fourth line represented exercised behavior rather than extra output. pnpm updates through npm instead of updating itself, so the repair added a fake npm command as well. The test can now cover that branch without reaching the network.

The fix still states the cardinality explicitly: three became four, and every tool gets its own assertion. That is less flexible than deriving the expected count from the manifest, but it also makes an accidental missing or duplicate line fail loudly. For this validation script, the number of status lines is part of the contract.

The next check is a real devcontainer rebuild followed by the host-side validation command. The immediate lesson is already clear: when a manifest gains a new participant, the runtime loop, its fixtures, and its cardinality assertions are one change, even if the first implementation only touched the runtime path.