Jak AITM scala ukończoną pracę do dev, naprawia błędy testów po scaleniu „do przodu" zamiast je wycofywać oraz weryfikuje, że Task dotknął tylko tego, co miał dotknąć.

Scalanie, poprawki po scaleniu i Scope Gate

Jak działa scalanie

Każdy Task działa we własnej gałęzi git/Worktree. Gdy Pipeline się kończy (implementacja, review i testy są zielone), Task trafia do Merge queue AITM — szeregowej kolejki, dzięki której równoległe Tasks nigdy nie scalają się do dev w tym samym czasie i nie nadpisują nawzajem swoich zmian.

• Automatyczne uruchomienie scalania. Task z włączonym autoMergeDev scala się do dev automatycznie po zakończeniu Pipeline — bez ręcznego kroku zatwierdzenia, więc ukończona praca trafia do gałęzi w sposób ciągły, zamiast piętrzyć się w oczekiwaniu, aż człowiek kliknie scalanie.
• Bramka builda przed scaleniem. Gałąź Task jest najpierw aktualizowana do bieżącego dev, a następnie budowana i sprawdzana pod kątem typów w takiej postaci, jaką będzie miała po scaleniu. Jeśli sprawdzenie jest czerwone, Agent naprawczy dostaje ograniczoną liczbę prób; błędy, które już istnieją w dev, nie są przypisywane Task. Jeśli bramka pozostaje czerwona, Task nie jest scalany i kończy ze statusem conflict z dołączonym wynikiem builda.
• Obsługa konfliktów. Jeśli gałąź Task koliduje z tym, co już trafiło do dev, AITM ponawia scalanie z różnymi strategiami, a następnie przekazuje konfliktujące pliki rozwiązywaczowi konfliktów AI, który łączy obie zmiany i ponownie uruchamia bramkę builda. Task oczekujący w stanie conflict jest automatycznie sprawdzany ponownie; jeśli przyczyna w międzyczasie zniknęła, leczy się sam i przechodzi do scalania.
• Kontrolowane scalanie do dev. Scalenia odbywają się pojedynczo z kolejki, więc dev nigdy nie jest w stanie na wpół scalonym. Scalanie nie jest krokiem Pipeline: Task pokazuje finished ze znacznikiem Finalizing… i staje się archived, gdy scalenie się zakończy. Dopóki Task pozostaje w stanie conflict, inne Tasks z kolejki w tej samej karcie czekają za nim — warto więc rozwiązać go szybko.

Wykrywanie i naprawa błędów po scaleniu

Gdy gałąź Task zostanie scalona do dev, AITM ponownie uruchamia objęte testy względem nowego stanu dev. Jeśli teraz zawodzą, domyślną reakcją jest nie wycofywanie scalenia.

Przykład: Task dodaje nowe pole do współdzielonego modelu. Scala się czysto, a jego własne testy przechodzą. Ale inny Task, już w toku na innej gałęzi, zależał od starego kształtu tego modelu — gdy oba trafią do gałęzi, współdzielony test integracyjny zaczyna zawodzić. Zamiast wycofywać którekolwiek scalenie (co wyrzuciłoby także niezwiązaną, działającą połowę każdej zmiany), AITM:

1. Izoluje, które pliki/testy faktycznie zawodzą i zmiana którego Task za to odpowiada.
2. Naprawia do przodu na gałęzi — tworzony jest Task korygujący, który obejmuje tylko zawodzący obszar, pracując od bieżącego stanu dev (a nie od diffa któregokolwiek z pierwotnych Tasks).
3. Testuje ponownie poprawkę w izolacji, zanim będzie mogła w ogóle zbliżyć się do dev.
4. Scala poprawkę przez tę samą kolejkę co każdy inny Task.

Ta filozofia „naprawy do przodu" pozwala uniknąć szkód kaskadowych: wycofanie scalenia, gdy inna praca już się na nim oparła, wymusiłoby łańcuch kolejnych wycofań. Naprawa rzeczywistej usterki na miejscu, na jej własnej gałęzi, ogranicza zasięg skutków do jednego znalezionego problemu.

Ocena zakresu Task (Business Scope Gate)

Każdy Task z góry deklaruje, których plików zamierza dotknąć. Gdy Task się kończy, Business Scope Gate porównuje pliki, które faktycznie zmienił, z tą deklaracją.

• Poza zakresem oznacza, że zmieniony plik nie został zadeklarowany i nie ma wiarygodnego związku z deklarowanym celem Task — na przykład Task dotyczący strony zamówienia edytuje też niezwiązany plik ustawień administracyjnych.
• Poprawki zakresu (scope amendments). Czasem dotknięcie niezadeklarowanego pliku jest uzasadnione — musiał się zmienić współdzielony typ albo stała znajduje się w sąsiednim pliku. W takim przypadku Task zapisuje krótkie, jawne uzasadnienie dodatkowego pliku („scope amendment"), zamiast po cichu wychodzić poza granice. Uzasadniona poprawka jest akceptowana; niewyjaśniony dodatkowy plik nie jest.
• Naruszenia blokujące i doradcze. Nie każdy niezadeklarowany plik jest traktowany tak samo:
  • Blocking — zmieniony plik jest naprawdę obcy dla Task (inny obszar funkcji, brak wspólnej zależności, brak podanego uzasadnienia). To zatrzymuje scalanie, dopóki nie zostanie rozwiązane.
  • Advisory — zmieniony plik znajduje się w tym samym katalogu/module co zadeklarowany zakres i jest wiarygodnie powiązany (np. sąsiedni plik w tym samym folderze funkcji). Jest to oznaczane do przeglądu, ale samo w sobie nie blokuje scalania.

Co staje się błędem, a co nowym Task

Gdy krok review znajdzie coś wykraczającego poza bezpośredni diff, AITM rozstrzyga między dwoma wynikami:

• Staje się błędem, gdy ustalenie jest blokującym naruszeniem zakresu lub prawdziwą wadą niezwiązaną z tym, co Task miał robić — czymś, co już jest zepsute i wymaga własnego cyklu naprawy, niezależnie od wyniku bieżącego Task.
• Staje się nowym Task (następczym), gdy ustalenie jest doprecyzowaniem, usprawnieniem „miło mieć" lub uzasadnionym, lecz wykraczającym poza zakres pomysłem, który pojawił się przy pracy nad czymś innym — trafia do kolejki na własnych zasadach, zamiast rozszerzać zakres bieżącego Task.

Ten podział utrzymuje diff każdego Task skupiony na tym, o co go poproszono, a jednocześnie zachowuje wszystko, co recenzent zauważy po drodze — nic zaobserwowanego podczas review nie jest po cichu odrzucane, ale też nie jest przemycane do niezwiązanej zmiany.

Gdy Task zawodzi i wymaga interwencji człowieka

Nie każda awaria jest automatycznie odwracalna. Mechanizmy Watchdog i samonaprawy AITM same radzą sobie z przejściowymi problemami infrastruktury i rutynowymi błędami kompilacji/testów, ale niektóre błędy są terminalne — wymagają decyzji człowieka, a nie kolejnego ponowienia. Task kończy w terminalnym stanie failed, gdy:

• Konfiguracja jest błędna. Nieprawidłowe klucze API, niepoprawne ustawienia, uszkodzony JSON — żaden kod nie naprawi zepsutego środowiska.
• AI brakuje danych. Prompt Task jest niekompletny lub niejednoznaczny, wymagany kontekst nie został dostarczony albo wymagania są niedookreślone.
• Istnieje zasadnicza przeszkoda, którą może rozwiązać tylko użytkownik. Architektura wymaga wyjaśnienia, zakres jest sporny albo usługa zewnętrzna nie działa w sposób, który wymaga jawnego potwierdzenia, zanim praca będzie mogła być kontynuowana.

Przykład: załóżmy, że Task zawodzi, ponieważ wymagania kolidują z istniejącą architekturą. AITM nie może zgadnąć, który projekt jest poprawny — człowiek musi to wyjaśnić. W tym momencie:

1. Task zostaje oznaczony jako failed.
2. Użytkownik (i Claude) omawiają przyczynę źródłową w Chat lub Brainstorm.
3. Użytkownik decyduje: ponowić z jaśniejszym zakresem? Najpierw założyć osobny Task projektu architektury? Zmienić podejście?
4. Następnie tworzy nowy Task z doprecyzowanym rozumieniem lub ponawia z zaktualizowanym promptem.

Nie wszystkie awarie są błędami — wiele z nich jest zasadnie nierozwiązywalnych bez udziału człowieka. Niepowodzenie nie oznacza zmarnowanej pracy — diagnostyka i logi z nieudanego uruchomienia nadal pokazują dokładnie, gdzie coś poszło nie tak. A gdy Task zawodzi, jest to punkt rozmowy między użytkownikiem a AITM, a nie ślepy zaułek.

Model gałęzi

Każdy projekt zarządzany przez AITM stosuje ten sam dwugałęziowy model wydań.

• dev jest gałęzią domyślną / integracyjną. Każdy Task Pipeline scala się do dev — tu w sposób ciągły trafia ukończona, przetestowana praca (zob. Merge queue powyżej).
• main jest stabilną gałęzią wydań. Jest aktualizowana tylko przez scalenie dev → main w momencie wydania, a nie przez pojedyncze Tasks.
• Nie ma gałęzi master. AITM nigdy jej nie tworzy ani nie oczekuje.
• Importowane projekty mogą zachować własną gałąź integracyjną. Jeśli wdrażany projekt już używa innej nazwy dla gałęzi integracyjnej, należy ją ustawić w opcji Integration branch (defaultBranch) w ustawieniach projektu i użyć tam kontroli Verify remote, aby potwierdzić, że nazwa rozwiązuje się względem rzeczywistego zdalnego repozytorium git.
• Wbudowany Gitea w wydaniu Docker tworzy repozytoria demo z dev jako gałęzią domyślną, zgodnie z tym samym modelem od razu po instalacji.

Jeśli projekt Task nie ma użytecznego zdalnego repozytorium git, Task zatrzymuje się z komunikatem, który wskazuje, co zrobić — Project settings → Verify remote — zamiast wyświetlać surowy błąd git.