commit before you move the machine

A long-running operation accumulates work that exists in exactly one place: a working copy on a machine that is about to be replaced. Uncommitted means undurable, and a group of lanes writing into one working copy between integrations produces precisely the state that is easiest to lose and hardest to notice losing.

The move was prepared with a commit whose only job was preservation. It captured uncommitted state before any migration step, so the old machine could be abandoned without first taking an inventory of everything that had been living on it. Nothing in that commit is legible as progress, which is exactly why it is the one most likely to be skipped.

That is the tension. Preservation competes for the same attention as results and always loses, and it is most needed at the moment when everyone is occupied with the move. The rule the operation adopted is blunt: state lives in shared history and never on a single machine, and leaving a machine is a procedure with a defined first step.

The snapshot was not the end of it. Late lane updates landed during migration preparation, which is the ordinary case rather than the exception: work does not pause because hardware is changing. A preservation commit is therefore not a one-time act but the opening of a window in which everything else still has to be integrated.

Cost: a commit nobody will read twice, taken at the least convenient moment, and a migration whose first phase produces no visible change at all. What it proves is that continuity here is a discipline with a price attached, not a property that hardware is expected to supply on its own.