the installer has to arrive before the disk it will install from

Every provisioning pipeline is destructive on purpose: it partitions, formats and overwrites, then asks the machine to become something else. The trap is ordering. The bootstrap the pipeline needs has to be in memory before the first destructive step, because the copy on disk is about to stop existing, and the route that would fetch it does not exist until an image has been installed. Two of the early pipeline versions failed here, and neither failure looked like an ordering bug from the outside — the machine simply stopped answering.

The second ordering trap is naming. Devices are not guaranteed the same names after a formatting pass, so anything written down by name can point at the wrong disk on the next run. The pipeline addresses filesystems by stable identifiers instead, and each stage writes its findings to a file the next stage reads, so a failed run can be restarted at the step that failed rather than from the beginning.

Making each stage independently verifiable cost more than writing one long script. It is also the reason a rebuild is now a routine instead of an afternoon. The receipt is unattended boot: the finished machine has to come up with nobody watching, twice, and do nothing different the second time.

What this proves is narrower than it sounds. The hard part of provisioning is not installing software; it is sequencing steps that each remove the precondition of the last one, on a machine that is allowed to go silent exactly once.