What is wrong
install.sh treats "the files were written" and "a usable installation exists" as the same outcome. They are not, and the difference is invisible until the user's first commit.
Observed in the installer's own logic:
- an existing version checkout is reused whenever
dist/ is present, regardless of what else is missing
- post-install verification runs little more than
--version, which succeeds on an installation whose runtime data is absent
- when verification does fail, the installer prints
installed, but unverified and still exits 0
So a partially damaged checkout survives a reinstall of the same version, and a CI or configuration-management run records success for an installation that cannot validate a commit message. #533 is the symptom; this is the mechanism that lets it persist.
What it should be
An installation is a transaction, and activation is its commit point:
- materialize into an incoming directory, never over the live one
- verify a runtime manifest — every file the product reads at runtime, not just the bundle
- smoke test the incoming tree:
--version, a valid and an invalid validate, doctor --json
- atomically switch the wrapper only after all of the above pass
- on any failure, leave the previous working version in place and exit non-zero
Exit 0 must mean the installation works, not that files were copied.
Why exit code matters specifically
The current behaviour was chosen to stop a transient signal from failing a good install, and that reasoning was sound at the time. The opposite risk is now larger: automation stores exit 0, the wrapper exists, every command is broken, and the failure surfaces days later as something that looks unrelated.
A verification that cannot distinguish "temporarily unverifiable" from "definitely broken" should say which one it found, and only the first is allowed to pass.
Boundary
This is not #533. #533 is the error a broken installation produces; this is why a broken installation is reachable and why reinstalling does not repair it. Both need to be true before the commit hook can be called a dependable component.
What is wrong
install.shtreats "the files were written" and "a usable installation exists" as the same outcome. They are not, and the difference is invisible until the user's first commit.Observed in the installer's own logic:
dist/is present, regardless of what else is missing--version, which succeeds on an installation whose runtime data is absentinstalled, but unverifiedand still exits 0So a partially damaged checkout survives a reinstall of the same version, and a CI or configuration-management run records success for an installation that cannot validate a commit message. #533 is the symptom; this is the mechanism that lets it persist.
What it should be
An installation is a transaction, and activation is its commit point:
--version, a valid and an invalidvalidate,doctor --jsonExit 0 must mean the installation works, not that files were copied.
Why exit code matters specifically
The current behaviour was chosen to stop a transient signal from failing a good install, and that reasoning was sound at the time. The opposite risk is now larger: automation stores
exit 0, the wrapper exists, every command is broken, and the failure surfaces days later as something that looks unrelated.A verification that cannot distinguish "temporarily unverifiable" from "definitely broken" should say which one it found, and only the first is allowed to pass.
Boundary
This is not #533. #533 is the error a broken installation produces; this is why a broken installation is reachable and why reinstalling does not repair it. Both need to be true before the commit hook can be called a dependable component.