Jak AITM slučuje hotovou práci do dev, opravuje selhání testů po sloučení dopředu místo revertu a ověřuje, že task sáhl jen tam, kam měl.

Slučování, opravy po merge a scope gate

Jak funguje slučování

Každý task běží ve vlastní git větvi/worktree. Když pipeline doběhne (implementace, review, testy zelené), task vstoupí do AITM fronty slučování — serializované fronty, díky které se souběžné tasky nikdy neslučují do dev ve stejný okamžik a nepřepisují si navzájem změny.

  • Automatický spouštěč sloučení. Task s povoleným autoMergeDev se sloučí do dev automaticky, jakmile jeho pipeline doběhne — bez ručního schvalování, takže hotová práce přistává průběžně místo hromadění na schválení člověkem.
  • Build brána před sloučením. Větev tasku se nejprve srovná s aktuálním dev a poté se kód sestaví a typově zkontroluje tak, jak bude vypadat po sloučení. Je-li kontrola červená, opravný agent dostane omezený počet pokusů; chyby, které už v dev existují, se tasku nepřičítají. Zůstane-li brána červená, task se nesloučí a skončí ve stavu conflict s přiloženým výstupem buildu.
  • Řešení konfliktů. Pokud větev tasku koliduje s tím, co už je v dev, AITM zkusí sloučení znovu s různými strategiemi a poté předá konfliktní soubory AI řešiteli konfliktů, který obě změny zkombinuje a znovu spustí build bránu. Task čekající ve stavu conflict se automaticky kontroluje znovu; pokud příčina mezitím zmizela, sám se zotaví a pokračuje ke sloučení.
  • Řízené sloučení do dev. Sloučení probíhají z fronty jedno po druhém, takže dev nikdy není v napůl sloučeném stavu. Merge není krok pipeline: task se zobrazí jako finished se značkou Finalizing… a po sloučení přejde do archived. Dokud task zůstává v conflict, ostatní tasky ve frontě téhož tabu čekají za ním — vyplatí se ho vyřešit brzy.
Dokončený task se finalizuje a slučuje
Dokončený task při finalizaci a sloučení do dev.

Detekce a oprava chyb po sloučení

Jakmile se větev tasku sloučí do dev, AITM znovu spustí dotčené testy proti novému stavu dev. Pokud nyní selžou, výchozí reakcí není sloučení vrátit zpět.

Příklad: task přidá nové pole do sdíleného modelu. Sloučí se čistě a jeho vlastní testy projdou. Jenže jiný task, který už běžel na jiné větvi, počítal se starým tvarem toho modelu — po sloučení obou začne padat sdílený integrační test. Místo revertu kteréhokoli ze sloučení (což by zahodilo i tu druhou, funkční polovinu každé změny) AITM:

  1. Izoluje, které soubory/testy skutečně selhávají a čí změna za to může.
  2. Opravuje dopředu na větvi — vytvoří se opravný task, který cílí jen na postiženou oblast a vychází z aktuálního stavu dev (ne z diffu žádného z původních tasků).
  3. Znovu otestuje opravu izolovaně, než se pustí zpátky do blízkosti dev.
  4. Sloučí opravu stejnou frontou jako jakýkoli jiný task.

Tato filozofie „oprav dopředu“ zabraňuje kaskádovým škodám: vrácení sloučení poté, co na něm už stojí další práce, by vynutilo řetěz dalších revertů. Opravit skutečnou chybu na místě, na vlastní větvi, drží dopad omezený jen na ten jeden nalezený problém.

Vyhodnocení rozsahu tasku (Business Scope Gate)

Každý task dopředu deklaruje, kterých souborů se plánuje dotknout. Když task doběhne, Business Scope Gate porovná soubory, kterých se skutečně dotkl, s touto deklarací.

  • Mimo rozsah znamená, že změněný soubor nebyl nikdy deklarován a nemá žádnou pravděpodobnou souvislost s deklarovaným cílem tasku — například task o pokladně upraví i nesouvisející soubor administrátorského nastavení.
  • Dodatky ke scope (scope amendments). Někdy je dotknutí se nedeklarovaného souboru legitimní — musel se změnit sdílený typ nebo konstanta žije v sousedním souboru. V takovém případě task zapíše krátké, explicitní zdůvodnění navíc změněného souboru (,,scope amendment") místo toho, aby tiše překročil hranice. Zdůvodněný dodatek je přijat; nezdůvodněný soubor navíc ne.
  • Blokující vs. informativní porušení. Ne každý nedeklarovaný soubor se posuzuje stejně:
    • Blokující — změněný soubor je opravdu cizí danému tasku (jiná oblast funkčnosti, žádná sdílená závislost, žádné zdůvodnění). Toto zastaví sloučení, dokud se nevyřeší.
    • Informativní — změněný soubor leží ve stejném adresáři/modulu jako deklarovaný rozsah a je pravděpodobně související (např. sousední soubor ve stejné feature složce). Toto se označí k revizi, ale samo o sobě sloučení neblokuje.

Co se stane bugem a co novým taskem

Když krok review najde něco nad rámec bezprostředního diffu, AITM se rozhoduje mezi dvěma výsledky:

  • Stane se bugem, pokud jde o blokující porušení rozsahu, nebo o skutečnou vadu nesouvisející s deklarovaným rozsahem tasku — něco, co je již rozbité a potřebuje vlastní opravný cyklus, nezávislý na výsledku aktuálního tasku.
  • Stane se novým (návazným) taskem, pokud jde o vylepšení, „bylo by hezké mít“, nebo legitimní, ale mimo rozsah stojící nápad objevený cestou při práci na něčem jiném — jde do fronty za vlastních podmínek místo rozšiřování rozsahu aktuálního tasku.

Toto rozdělení drží diff každého tasku zaměřený na to, co měl udělat, a zároveň zachycuje vše, čeho si recenzent všimne po cestě — nic pozorované při review se tiše nezahodí, ale ani se to nepropašuje do nesouvisející změny.

Když task selže a vyžaduje zásah člověka

Ne každá chyba se dá opravit automaticky. Watchdog a samoopravné mechanismy AITM zvládají infrastrukturní výpadky a běžná selhání kompilace/testů samy, ale některé chyby jsou terminální — vyžadují rozhodnutí člověka, ne další pokus. Task skončí v terminálním stavu failed, když:

  • Konfigurace je špatně. Neplatné API klíče, nesprávná nastavení, poškozený JSON — takové prostředí kód sám neopraví.
  • AI nemá dost dat. Zadání tasku je neúplné nebo nejednoznačné, chybí potřebný kontext, nebo jsou požadavky nedostatečně specifikované.
  • Existuje zásadní blokátor, který vyřeší jen uživatel. Architektura potřebuje vyjasnit, rozsah je sporný, nebo je nedostupná externí služba způsobem, který vyžaduje explicitní potvrzení, než lze pokračovat.

Příklad: task selže, protože požadavky jsou v rozporu se stávající architekturou. AITM nemůže hádat, který návrh je správný — musí to vyjasnit člověk. V tuto chvíli:

  1. Task se označí jako failed.
  2. Vy (a Claude) proberete příčinu v chatu nebo brainstormu.
  3. Rozhodnete: znovu zařadit s jasnějším rozsahem? Nejdřív založit samostatný task na návrh architektury? Upravit přístup?
  4. Poté založíte nový task s upřesněným zadáním, nebo znovu zařadíte s upraveným promptem.

Ne každé selhání je bug — řadu z nich nelze legitimně vyřešit bez zásahu člověka. Selhání neznamená zmařenou práci — diagnostika a logy z neúspěšného běhu pořád přesně ukazují, kde to selhalo. A když task selže, je to bod k diskusi mezi vámi a AITM, ne slepá ulička.

Model větví

Každý projekt spravovaný AITM sleduje stejný dvouvětvový release model.

  • dev je výchozí / integrační větev. Každý pipeline task se slučuje do dev — sem průběžně přistává hotová, otestovaná práce (viz fronta slučování výše).
  • main je stabilní release větev. Aktualizuje se jen sloučením dev → main v čase vydání, ne jednotlivými tasky.
  • Větev master neexistuje. AITM ji nikdy nevytváří ani neočekává.
  • Importované projekty si mohou zachovat vlastní integrační větev. Pokud projekt, který onboardujete, už používá jiný název integrační větve, nastavte ho pomocí volby Integrační větev (defaultBranch) v nastavení projektu a pomocí kontroly Ověřit remote tam potvrďte, že odpovídá skutečnému git remote.
  • Zabudovaná Gitea v Docker vydání vytváří ukázková úložiště s dev jako výchozí větví, což odpovídá stejnému modelu už od začátku.

Pokud projekt tasku nemá použitelný git remote, task se zastaví s akční zprávou odkazující na Nastavení projektu → Ověřit remote místo zobrazení syrové git chyby.