Four Steps That Must Not Be Interleaved
Landing a finished piece of work is four things: stamp the record that lives with the material, commit it together with that stamp, push it, and write the log entry that says this happened. Any one of them alone is unremarkable. What matters is that no other landing may happen between them.
If another session slips a landing in between your stamp and your push, the repository and the record now describe different histories, and nothing in either one says so. That is the worst class of data problem: silent, plausible, and discovered months later by someone trying to answer an unrelated question.
Be exact about what the lease buys, because it is easy to over-claim. It excludes other landings. It does not make the four steps atomic, and the difference is not academic: if your own process dies after the push and before the log entry is written, you get the identical split history with nobody else involved — the material says it landed, and the workshop's log does not. Serialization is not transactionality. What closes that remaining gap is not a bigger lock but a reconciliation pass — a view that walks the repository against the record and reports where the two disagree.
The Lease, and the Lock It Is Not
The mechanism is a lease held on the target repository for the duration of those four steps. The word is borrowed for the property that matters: a holder who never comes back can be taken off it. Be precise about what is borrowed. In distributed systems a lease is time-bounded: it expires unless the holder renews it, and expiry is how a dead holder is removed. This workshop keeps the property and drops the timer, on purpose — a slow interactive session is not a dead one, and a timer cannot tell the two apart.
Compare the plainest kind of lock, the one this track's busy day kept tripping over: version control's own index lock, a file with no expiry that a crashed process leaves behind. It holds until someone notices, and the recovery is a human finding the stale lock and deciding it is safe to delete. Many locks avoid that with a timeout, or by dying with their process; that one does neither. This lease is held until released, or until someone breaks it deliberately and the break is itself recorded, which turns "the holder never came back" from an incident into a delay. Given that these holders are interactive sessions on laptops that get closed, that recorded way out is load-bearing rather than theoretical — and it is a design choice of this workshop, not what the word means everywhere.
Verification Is Part of the Motion Too
One more coupling belongs here: the landing refuses to proceed unless the latest recorded verification for this unit of work passed. Not a suggestion in a document — the command reads the event and exits if it is absent or failed. (Until 2026-10-13 any earlier pass would do; the previous track's lesson on a log with teeth tells how that gap was found.)
There is an override, and using it writes that fact into the record. That combination is the shape to aim for everywhere: the escape hatch exists, because a guard with no override gets removed the first time it is wrong at an awkward hour, and taking it is never invisible.
You could ask why the verification check lives inside the landing command at all, rather than as a separate step people are asked to run first. That separate arrangement is exactly the one that rotted in the previous track: when verification is independent of the landing, a step that costs nothing to skip eventually gets skipped. Rather than asking for the order to be honored, make the wrong order unable to proceed.