Jeden prompt staje się zrecenzowaną, przetestowaną, udokumentowaną i scaloną zmianą — podczas gdy użytkownik robi coś innego. Pipeline ma 12 kroków i zajmuje się wszystkimi.

Pipeline

Co to daje

  • Każdy Task pracuje na własnym izolowanym branchu, więc równoległe Taski nigdy się nie zderzają, a główny kod pozostaje bezpieczny.
  • Recenzja AI i automatyczne poprawki odbywają się, zanim użytkownik zobaczy wynik.
  • Testy jednostkowe i end-to-end są uruchamiane automatycznie.
  • Wynik jest sprawdzany względem podanych kryteriów akceptacji.
  • Dokumentacja i Behavioral Contracts są aktualizowane automatycznie.
  • Scalanie odbywa się w kolejce, a build musi przejść, zanim zmiana trafi do kodu.
  • Gdy coś zawiedzie, AITM sam się odzyskuje, a wznowienie jest możliwe od dowolnego kroku.
  • Każdy Task zostawia czytelne podsumowanie wyniku i historię.

12 kroków

  1. Branch — Task dostaje własną bezpieczną przestrzeń roboczą, która nie koliduje z innymi Taskami. Efekt: główny kod pozostaje nietknięty do czasu, aż praca będzie gotowa.
  2. Architect — AI czyta prompt i istotny kod, a następnie planuje rozwiązanie. Efekt: przemyślany plan tego, które części projektu się zmieniają.
  3. Code — plan zamienia się w rzeczywiste zmiany w plikach. Efekt: gotowa implementacja.
  4. Compliance-check — niezależnie porównuje diff z wymaganiami dla złożonych Tasków. Pomija prostsze Taski, a ewentualne ustalenia przekazuje do Review. Efekt: wczesna informacja o pominiętych wymaganiach.
  5. Review — AI sprawdza pracę jak współpracownik i wydaje werdykt. Efekt: druga para oczu bez czekania na człowieka.
  6. Fix — naprawia wszystko, co zgłosił Review; może kilka razy zapętlić się z Review. Efekt: oczyszczony wynik.
  7. Test — uruchamia zautomatyzowane testy jednostkowe projektu. Efekt: pewność, że zmiana nie zepsuła istniejącego zachowania.
  8. E2E — uruchamia testy, które obsługują aplikację jak prawdziwy użytkownik. Działa tylko wtedy, gdy projekt ma testy end-to-end, równolegle z Test. Efekt: zweryfikowana cała ścieżka użytkownika.
  9. Verify — porównuje wynik z kryteriami akceptacji Taska; każde kończy się jako passed, failed lub unverifiable. Efekt: jasna odpowiedź, czy Task robi to, o co poproszono.
  10. Snapshot — opcjonalny krok, który przechwytuje zrzuty ekranu UI. Efekt: wizualny zapis zmiany.
  11. Docs — aktualizuje dokumentację i Behavioral Contracts, aby odzwierciedlały zmiany. Zawsze się wykonuje. Efekt: dokumentacja, która się nie starzeje.
  12. Chain-audit — działa tylko na ostatnim Tasku łańcucha zależnych Tasków, ponownie sprawdzając kryteria każdego wcześniejszego Taska. Efekt: pewność, że cały łańcuch jest spójny.

Scalanie nie jest krokiem Pipeline — po ostatnim kroku Task trafia do Merge queue, która scala go z gałęzią dev. Do tego czasu zakończony Task pokazuje znacznik Finalizing…. Szczegóły w Merging, Post-Merge Fixes & Scope Gate.

Konsola Pipeline
Widok Develop z dwoma Taskami działającymi równolegle — każda karta ma własną konsolę Pipeline z wyjściem na żywo.
Zakończony Task w trakcie finalizacji i scalania
Zakończony Task w trakcie finalizacji i scalania z dev.

Kiedy potrzebna jest interwencja

  • Wynik Taska podlega przeglądowi — patrz Odczyt wyników i Archive.
  • Prompt należy zmienić, jeśli wynik nie odpowiada zamiarowi.
  • Wznowienie od wybranego kroku lub ponowne zakolejkowanie Taska jest potrzebne, gdy Pipeline się zatrzymał.

Gdy krok się nie powiedzie

Zawieszony krok jest ponawiany automatycznie; liczbę ponowień ustawia się w Settings → Pipeline. Jeśli po synchronizacji z dev build jest czerwony, podejmowana jest próba naprawy, a konflikty scalania są najpierw rozwiązywane przy pomocy AI. Jeśli to nie wystarcza, Task pozostaje oflagowany i widać przyczynę. Karta Taska zakończonego niepowodzeniem lub konfliktem oferuje wtedy przycisk z sugestią odzyskania.

Warto wiedzieć

  • Gdy trzeba powtórzyć tylko późniejszy krok, lepiej wznowić od niego, niż uruchamiać cały Pipeline od nowa.
  • Wyniki każdego Taska można przeczytać w Odczyt wyników i Archive.
  • Niezależne Taski działają równolegle, a zależne można łączyć w łańcuchy.
  • Poprawki błędów muszą być udowodnione względem rzeczywistego objawu, a zmiany poza zadeklarowanym Scope Taska są oflagowywane.
  • Build musi przejść przed scaleniem, aby zepsuty kod nie trafił do dev.