A claim is a lease on files, not a promise.
A directive is a scoped unit of work. A claim is what a worker takes out on it: a declaration of exactly which files the work will touch, filed at the moment work starts. Filing the claim is the precondition for starting, logged before the worker opens a single file.
Two workers can never hold overlapping claims on the same files at the same time. When a second claim names a file a live claim already covers, the substrate rejects it outright. The worker that filed second does not get a partial grant on whatever files are still free, and it does not wait in line for the first claim to release them. The whole claim comes back refused, and the worker has to re-scope its directive before it can start.
The interlock runs at file granularity.
Vinculum answers the concurrent-code problem the same way for every directive: two workers touching the same lines at once becomes impossible rather than a merge problem to sort out afterward. That answer is ratified as the General's architectural call (#7759). The mechanism is claim_scope, a hard interlock enforced at file granularity: the substrate refuses to grant a live claim that overlaps another live claim already in force. Workers run isolated over disjoint scopes because the interlock leaves them no other way to run.
The granularity is deliberate. Design of record #7762 states the reasoning directly: scope overlap is a decomposition smell, not a runtime merge problem. A claim whose scope intersects a live claim is rejected outright, with no warning logged for a worker to read and proceed past. Workers whose scopes do not overlap emit diffs that apply sequentially onto the trunk. A build-and-test gate runs after those diffs land, and that gate is where correctness actually gets checked.
Prevented before code exists to conflict.
A typical merge-conflict workflow lets two developers edit the same file on separate branches and finds out about the collision only when someone tries to combine both sets of changes. By then each side has already written code against an assumption the other side invalidated, and someone has to read both diffs and decide which lines survive.
Vinculum's claim model moves that check to the start. A worker that wants to claim a directive touching a file another worker already holds gets refused before it writes a line. There is no divergent code to reconcile, because the second worker never produced any. The claim is where the conflict gets caught, before either worker's code exists to conflict with anything.
Two decisions, both ratified.
The file-level interlock did not ship this way by default. It was ratified as the General's architectural call (#7759), and the design of record extending it locked the granularity at the file level and set the rule for what counts as a collision (#7762).
| What was decided | Entry |
|---|---|
| claim_scope becomes a hard interlock enforced at file granularity; workers run isolated over disjoint scopes | #7759 |
| Granularity locked at the file level; an overlapping claim is rejected outright, and correctness is checked at the build-and-test gate rather than at the merge | #7762 |
Common questions.
What happens if two workers try to claim the same file?
The second claim is rejected outright. It is not merged later and it does not sit in a queue waiting for the first claim to release the file. The worker that filed second gets an error back before it opens the file, and has to re-scope its directive to files nothing else currently holds.
How is this different from a normal git merge conflict?
A merge conflict turns up after two people have already written divergent code against the same lines, once someone tries to combine both sets of changes. A claim collision is caught before either worker writes anything, at the moment the second worker asks for a file the first one already holds.
What does "scope overlap is a decomposition smell" mean in practice?
It means a directive that needs a file another directive already claimed was not split correctly in the first place. The fix is decomposing the work differently upstream, not building a runtime mechanism to merge two workers' changes to the same lines after both have already made them (#7762).