→ had two sessions writing into one checkout without either knowing
- cost when it happens
- high
- how often
- occasional
Two assistant windows are open on the same directory. Each sees files it did not write
appear and change under it. Each is doing exactly what it was asked. The commit that
results contains both pieces of work and explains neither.
A working tree has no concept of an owner. Nothing in git objects to two writers, and the
signal that would tell one worker about the other — an active task, its scope, its worktree
— does not exist by default. Opening a second window costs nothing and is often the right
thing to do; what is missing is the record that makes it safe.
Each worker's model of the world is correct for what it can observe. It observes a file
changing and has no channel through which the other worker could have declared itself.
Interleaved commits that cannot be reverted independently, verification that runs against a
tree containing somebody else's half-finished change, and time spent working out which of
two people or workers is responsible for a failure.
One task is active per checkout: a second start is refused, naming the task that holds it,
until the first is handed over or finished. Each task declares its scope, and check and
finish fail on files touched outside it. Across checkouts, the other worktrees are read
from git worktree list and an overlapping active scope is reported at start. Where
several AI clients attach to this repository's shared server, each can announce what it is
working on and read what the others announced.
before window 1: editing lib/auth window 2: editing lib/auth
(neither knows)
after $ majordomus start "tidy the token parser" --scope lib/auth
refused: task t-20260906044337 is active in this checkout
(hand it over or finish it first)
It does not lock the filesystem and it does not stop anyone from editing. It refuses to
record a second concurrent task in one checkout, and it reports overlap across worktrees;
the coordination decision stays with the people.
What this looks like
Concrete situations, one per audience. Each is declared in the moment's front matter, so the before and the after are data rather than prose a page could drift from.
-
Two windows, one directory
solo-builder
- before
- A second session is opened for a quick fix; both sessions commit into one tree and the history interleaves two unrelated pieces of work.
- after
- One task is active per checkout: the second `start` is refused until the first is handed over or finished, and it says which task holds it.
-
A worker and a person
ai-native-team
- before
- An overnight worker is still running when somebody starts editing the same tree in the morning.
- after
- The active task record names the checkout and the scope; the overlap is reported before the second piece of work begins.
-
A shared build box
agency
- before
- Two people on one checkout produce a commit that contains both of their changes and neither of their intentions.
- after
- Scope is declared per task and `check` refuses files outside it, so the mixture is caught before the commit.
How you would know
The observable symptoms this moment declares. They are the questionnaire on the index and the input of majordomus why diagnose; nothing else defines them.
-
◻
Files changed under a session while it was working, and nothing said why.
files-changing-underneath
-
◻
More than one assistant window is pointed at the same working directory.
two-windows-one-repo
-
◻
The working tree holds uncommitted changes from more than one piece of work.
conflicting-uncommitted
Where this lives in the tool
Everything below is read out of this moment's own front matter and resolved against the repository. A name here that did not exist would fail validation.
the commands that answer it
the capabilities of the executable that answer it
what it supervises — derived from the claims below
the claims that back this page, and the evidence behind each
the rules that govern it
- majordomus.one-worker-one-scope
- majordomus.scope-integrity
- majordomus.state-consistency
the use cases that show the way out
If this one is familiar, so is the next
What this moment names, what names it, and what shares its area, audience or tags. The second and third are derived; only the first is written down.
All 38, and how they connect to the tool →