Git, worktrees, and landing

Attached sessions are polled for branch, HEAD, dirty count, upstream divergence, worktree identity, and lines changed. Every session is swept once a minute regardless of whether a pane is open, because a cached observation that only refreshes while you are looking at it goes stale exactly when you stop looking.

Line counts cover tracked changes only. An untracked file raises the dirty count and contributes no lines, because there is nothing to compare it against. A count that could not be measured is reported as unmeasured rather than as zero - a display that conflates the two reports a clean tree for a repository it merely failed to read.

An agent pane reports its working directory through the harness's hooks rather than through the shell's prompt, because a CLI holding the terminal draws no prompt. That is what makes an agent working inside a worktree report that worktree's branch and diff rather than the primary checkout's.

One row per worktree, with its files, its changes, and the live sessions standing in it. Creating a worktree is here; so is removing one.

Removal is declined rather than forced wherever Git itself would refuse: a locked worktree, one carrying submodules, one that is unclean. Git's refusals stay Git's. What actually happens on a removal is that the checkout is renamed out of the way and purged in the background, so a large tree does not hold the request open, and the registration is dropped with a targeted removal rather than a global prune - a prune would take every other checkout whose directory merely happens to be missing.

Which session and which conversation produced a commit, with a confidence, split into two roles that answer different questions:

• CommitterThe session that ran the commit. After a batch landing this is often the one that did the integrating rather than the work.
• ContributorThe session whose evidence shows it authored the content. This is the one you want when you are asking who wrote a line.

It is drawn from deterministic capture at the tool boundary rather than from the agent's account of its own work, and it changes nothing in the repository - no trailers, no notes, no rewritten history.

Landing a finished worktree branch is three steps, and the queue runs them one branch at a time so two agents cannot land into the same trunk at once.

1. Reconcile. Merge the current trunk into the branch, inside the worktree that owns it.
2. Verify. Run the verification command whose exact bytes you approved. Editing the command and approving it are two separate acts through two separate routes, which is what stops an agent approving the command its own land will run.
3. Fast-forward. Move the trunk, and only forward. Git refuses a fast-forward on divergence and refuses one that would overwrite local changes, which is what makes this step safe for a machine to take: the pipeline cannot lose work by construction.

It never resolves a conflict and it never runs a gate nobody approved. A conflict or a failed gate both need judgement and both belong to the branch's own agent, so they come back to that session as a bounded message rather than being worked around here.

• A documentation-only changeAfter reconciling, the incoming paths are matched against a closed allowlist. Matching a fixed list is a total function with no model and no heuristic in it, so it is not a judgement call. Anything it cannot answer with certainty - a source file, a rename, a submodule, an unreadable diff - runs the full gate.
• A verdict already earnedA verify-only request runs every earlier step identically, so its verdict is the verdict a land would have produced. That verdict is kept against the git tree it ran over and the digest of the command that ran, so a later land over identical content reuses it. A moved trunk yields a new tree and the gate runs again.

Both are written into the request's event trail with the reason, and the skipped step is still present in the trail. A documentation-only land would otherwise read exactly like one that passed three minutes of tests.

Every signal is observed or absent, never estimated. A step number counts markers the gate itself printed. A step total exists only where a byte-identical run has already passed, and is withdrawn the moment a run overruns it. No percentage is derived at either end, because this repository's own gate has steps that take 45 seconds and 3 seconds - a proportion drawn over that would be fiction, and a wrong number gets acted on where an absent one does not.

The land queue is off by default, per Project. It is enabled in Settings, Projects, and its queue, its verification command, and its grants live in a compact strip at the head of the Git tab's Map. A blocked row opens that strip rather than drawing a second copy of the controls.

The manual two commands remain the fallback and the thing to reach for when the queue is not enabled: reconcile in the worktree, then fast-forward from the primary checkout.

A Project pointed at a folder that is not a repository yet can be initialized from the Git tab. It is an explicit act; swe-mux does not create repositories under you.