Module worktree 

Git worktree identity: the link between a linked worktree and the main checkout it belongs to (issue #004).

Why this exists at all: entitlement checks are pure string prefix matching (tools::fs_policy::under_any), and a git worktree lives at a path that is NOT under the main checkout. So an agent granted the repo it works in was refused the moment the work moved into a worktree, and the user had to re-grant the same repo under a second name. Nothing in the runtime knew the two paths were the same project.

The derivation here is deliberately read-only and one-way: it computes the relationship from git’s own on-disk metadata every time it is asked. It never writes a derived path back into profile.yaml — a grant the user did not type must not become a permanent, user-visible entitlement they then have to audit. The derived paths exist only in the built sandbox policy and in the call-time tool gate.

The on-disk shapes this reads

Main checkout: <main>/.git/ — a DIRECTORY Linked worktree: <wt>/.git — a FILE containing gitdir: <main>/.git/worktrees/<id> Worktree registry: <main>/.git/worktrees/<id>/gitdir — a file whose contents are <wt>/.git

Both directions are needed, for two different layers:

• worktree → main (main_checkout_of) for the call-time tool gate, which sees a concrete path and asks “is this reachable from something granted?”
• main → worktrees (worktrees_of) for the kernel sandbox, which must enumerate every path at seal time because Landlock/SBPL cannot ask a question later.

Functions

main_checkout_of

The main checkout that start belongs to, when start is inside a linked git worktree. None for an ordinary checkout, or outside git entirely.

worktrees_of

Every matching path in a linked worktree registered under the checkout that contains main_path.