LEP: Successor locks for scoped causality tracking

[mjansson]

Summary

This proposal adds causal exclusive locks for unmergeable files in Lore's free branching model.

Each unmergeable file gains a server-side per-file "head" pointer naming the latest revision that modified it within a lock scope. An exclusive lock can only be acquired on a branch whose last-modification revision for the file (looked up via Lore's existing per-file-id back-pointer index) equals that head — i.e. the branch already contains every prior committed edit in scope.

Each unmergeable file becomes one linear edit chain per scope, embedded in the larger DAG; the lock acquisition is the gate that enforces successor-only progress within the scope. Scopes are first-class server-side entities with their own identity and lifecycle, independent of any specific branch; each branch carries a scope_id in its metadata, inherited from its parent at creation.

A repository has a default scope that all branches join unless they explicitly opt into another scope; a repository that only ever uses the default scope behaves identically to a global per-file chain (the degenerate case).

The check is constant-bounded — a single revision-id comparison against Lore's existing back-pointer lookup — with no path-keyed state and no materialized (branch × file) indices.

[rajpratham1]

This proposal is well thought out and addresses a real limitation of exclusive locking in a free-branching workflow. The distinction between temporal locking and causal ordering is clearly explained, and the introduction of scoped successor locks provides a scalable solution without introducing expensive global state. The design also does a good job of leveraging existing infrastructure (back-pointer index and mutable store) instead of adding complex new indexing.

[rajpratham1]

Really nice proposal overall. I like how it separates lock state from causality rather than trying to make a single mechanism solve both problems. The motivation clearly explains why traditional exclusive locks are insufficient under free branching, and the scoped successor-chain approach feels like a natural extension of Lore's existing architecture.

The design also scales well by reusing the existing per-file back-pointer lookup and keeping the validation to a constant-bounded revision comparison instead of introducing branch × file state. The scope abstraction is well motivated and avoids unnecessary coupling between release branches, main, and experimental work.
I also appreciate that the proposal discusses lifecycle management, enforcement policies, and the degenerate cases up front, making it easier to reason about operational behavior.

I don't see any blocking concerns from what I've reviewed. Looks solid to me and I'm happy to approve. Nice work! 🚀

[epic-lore-bot]

Imported as Lore CR-498.

[mjansson]

Committed and going into implementation