Skip to content

Leases and admission

A lease records permission for a resource: its holder, a durable generation, and an expiry. There are three scopes:

Scope Covers Example
Checkout lease Exact files inside one checkout src/auth/session.ts
Repository intent Literal paths or trailing /** subtrees, advertised across worktrees src/auth/**
Host singleton Machine-wide resources, unique across all workspaces port:3000

An intent overlap between worktrees can warn even when their checkout resources are isolated. Inside one shared checkout, the same conflict denies under block policy.

Terminal window
majlis begin T-14 --paths 'src/auth/**' # claim the task and declare intent
majlis lease acquire ... # explicit resource operations
majlis lease renew ...
majlis lease release ...

Admission checks, acquisition of the complete resource set, the event append and the retry result commit in one transaction: BEGIN IMMEDIATE on a pinned connection, with foreign_keys=ON, WAL and synchronous=FULL. A failed acquisition cannot leave a partial grant, and success is sent only after commit.

Only committed durable state grants permission. In-memory indexes can find candidates but cannot approve a write.

  • An observed edit never creates a lease afterwards. It is evidence that an edit occurred.
  • Expiry does not prove the writer stopped. It removes permission to begin a new write. Unresolved writers quarantine the resource.
  • A cached admission result is retry evidence, not permission to run the same tool again.

Admission paths are absolute and physically confined to the registered checkout. Raw parent traversal, unresolved symlinks and hard-linked regular targets are rejected. Resolved aliases identify the same resource, including alternative case spellings on a filesystem positively identified as case-insensitive. Unverifiable file identity fails closed.

When admission meets a conflict or an enforcement gap, the trusted workspace policy decides what happens. See Policies.