Okamžik
Dvě okna asistentů jsou otevřena na stejném adresáři. Každé vidí, jak se pod ním objevují a mění soubory, které nezapsalo. Každé dělá přesně to, oč bylo požádáno. Výsledný commit obsahuje obě práce a nevysvětluje ani jednu.
Proč k tomu dochází
Pracovní strom nezná pojem vlastníka. Nic v objektech gitu nenamítá proti dvěma zapisovatelům a signál, který by jednomu workerovi řekl o druhém — aktivní úloha, její rozsah, její worktree — ve výchozím stavu neexistuje. Otevřít druhé okno nic nestojí a často je to správné; chybí záznam, který to dělá bezpečným.
Proč to lepší model nevyřeší
Model světa každého workeru je správný pro to, co dokáže pozorovat. Pozoruje, že se soubor mění, a nemá žádný kanál, kterým by se ten druhý worker mohl přihlásit.
Co to stojí
Prokládané commity, které nelze vrátit nezávisle, ověřování nad stromem obsahujícím něčí rozpracovanou změnu a čas strávený zjišťováním, kdo z dvou lidí či workerů za selhání odpovídá.
Co Majordomus dělá
Na checkout je aktivní jedna úloha: druhý start se odmítne a jmenuje úlohu, která jej drží, dokud první není předána nebo dokončena. Každá úloha deklaruje svůj rozsah a check a finish selžou na souborech dotčených mimo něj. Napříč checkouty se ostatní worktrees čtou z git worktree list a překrývající se aktivní rozsah se hlásí při start. Kde se k sdílenému serveru tohoto repozitáře připojí několik klientů AI, každý může oznámit, na čem pracuje, a číst, co oznámili ostatní.
Před a po
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)Co nedělá
Nezamyká souborový systém a nikomu nebrání v úpravách. Odmítne zaznamenat druhou souběžnou úlohu v jednom checkoutu a hlásí překryv napříč worktree; rozhodnutí o koordinaci zůstává na lidech.