feat(install): install Pi when missing, ask before replacing it

[lucy-wolfe]

The installer printed a command for Pi and hoped. It handles it now.

state	behaviour
Pi absent	installed, no prompt
Pi below the floor	Upgrade Pi to >= <floor>? [Y/n], default yes
Pi at or above the floor	nothing, exactly as before

The asymmetry is the decision. An absent prerequisite is installed without asking, because chief cannot run a single person without it and there is nothing for the user to weigh. A Pi that is merely too old is their working tool, and replacing it is a different act — so that one asks. Declining exits nonzero with a clear message: a zero status would tell a calling script the box is ready when the runtime every person needs is too old.

The floor is read, never restated

It has one definition, in pi_floor.rs, and the repository's guard bans copying that number into scripts — rightly, because a copy is a second definition wearing a copy's clothes.

Verified before building on it: the release process already stamps it into the manifest as piFloor, and that is pinned by tests. The installer reads it from the manifest it has just unpacked, so a version bump touches no shell script. A release whose manifest carries no floor simply skips the check rather than guessing.

Two shell facts, both learned by running the branches

Both end the installer silently if got wrong, and neither is visible by reading.

A prompt in a piped script must read /dev/tty. This file is curl … | sh, so stdin is the script text — reading stdin would consume the rest of the installer.

And /dev/tty must be tested by opening it, inside a subshell. The device node exists in a container with no controlling terminal, so [ -r /dev/tty ] is true and the redirect then fails. Worse, the obvious guard is fatal:

if { : < /dev/tty; } 2>/dev/null; then   # ends the run, status 2, no message
if ( : < /dev/tty ) 2>/dev/null; then    # evaluates to false, as intended

: is a POSIX special built-in, and a redirection error on one is fatal to a non-interactive shell. It does not evaluate to false — it ends the installer. Measured twice: first as raw shell errors printed above the question, then as a trace stopping dead at the call.

Where there is no terminal, the default is taken and said, because a silent choice made on somebody's behalf is what surprises them later.

The other two failure modes

• npm missing refuses cleanly with the existing die() style rather than half-installing.
• A Pi that npm reports as installed is checked against the floor before being called ready. npm exiting zero is not the same as the floor being met — a global install can land later on PATH, or resolve to something still too old. Announcing "ready" without looking would be one more claim outrunning its evidence.

Nothing after chief itself is installed aborts the run, except the one deliberate decline.

Verified by running every branch

Absent Pi · at floor · above floor · below floor answering y · below floor with bare Enter · below floor answering n (exit 1, clear message) · below floor with no terminal · below floor with no npm · and a manifest carrying no floor at all.

The interactive cases were driven through a real pty, not simulated.

Coordination

The README currently documents installing Pi as step one, because until now the installer only warned. When this lands, that step becomes optional and the quick start collapses to a single curl.

Checks

sh -n install.sh — this file is piped straight into a shell, so a syntax error is a broken install rather than a failed test — plus all 98 repository guards and CI.

[lucy-wolfe]

Merged into the v0.5.7 integration branch and shipping in #16. The commit is on that branch verbatim; GitHub could not retarget this pull request because a cross-fork PR's base must live in the base repository, and the integration branch lives on the fork. The review that happened here stands.