Module lock 

One target held by one apply at a time.

An apply reads the target, decides against what it read, stages, and renames. Two of them interleaved can each pass their own validation and then commit over each other, leaving one plan’s files beside another’s record: a target describing a landing that never happened. The transaction cannot see that, because it renames files it staged before the other run existed.

So an apply takes the target first and holds it until its postconditions have run. The lock is one file under the state root, named for the canonical target path, created with create_new so the creation is the acquisition, and removed when the guard drops. It lives outside the target because a target’s cleanliness is judged byte by byte, and a lock file inside it would be drift.

Where the lock cannot be taken, the apply refuses. A guard that silently does nothing is worse than none, because the call site still reads as guarded.

It is advisory, and it bounds this engine’s own runs rather than every writer: a hand edit during an apply is what the before-digests and the postconditions are for.

Structs

TargetLock

One target held for the life of this value.

Constants

LOCKS_DIR

The directory holding the locks, under the state root.

Functions

acquire

Take target for this run, or refuse.

acquire_in

The acquisition against one locks directory, which is what the tests drive so no test has to move the state root out from under itself.