Awaryjnie: jak zatrzymać sprint, wyjąć ticket i posprzątać

Jak zatrzymać sprint w trakcie?

Sprint prowadzony pętlami składa się z trzech warstw i każdą zatrzymujesz osobno. Pętle uruchamiają pracę, sesje ją wykonują, a status sprintu w panelu jest od nich niezależny.

1. Zatrzymaj obie pętle

   Zamknij sesje, w których działa /loop. Od tej chwili nie wystartuje żadna nowa sesja i żaden merge request nie zostanie zmergowany.

2. Sprawdź, co jeszcze pracuje

   Komenda claude agents pokazuje sesje w tle razem z identyfikatorami.

3. Zatrzymaj sesje, których nie chcesz

   Użyj claude stop <id>. Sesje, które mają dokończyć pracę, zostaw: skończą ticket i ustawią status Review bez pętli.

4. Zostaw sprint aktywny

   Stanu w panelu nie zmieniaj. Po przerwie uruchamiasz pętle ponownie i sprint idzie dalej.

$ claude agents
sklep-SKL-12-opus   a1b2c3d4   running
sklep-SKL-14-opus   e5f6a7b8   running

$ claude stop a1b2c3d4

Czym różni się stop od rm?

Obie komendy należą do Claude Code i dotyczą sesji w tle. Różnią się tym, co zostaje po ich użyciu.

Jak wyjąć jeden ticket ze sprintu?

Kolejność ma znaczenie. Dyspozytor czyta wszystkie tickety przypisane do aktywnego sprintu. Ticket bez żywej sesji i w statusie innym niż Do zrobienia, Review albo Gotowe uznaje za awarię i raz wznawia pracę sam. Dotyczy to także statusu Backlog, dlatego sam status nie wystarczy: ticket trzeba odpiąć od sprintu.

1. Odepnij ticket od sprintu

   W panelu otwórz edycję ticketu, wyczyść pole sprintu i ustaw status Backlog. Ticket znika z listy, którą czyta dyspozytor, i przestaje się liczyć w remaining.

2. Zatrzymaj sesję ticketu

   Znajdź ją w claude agents i użyj claude stop <id>.

3. Zdecyduj o zmianach

   Branch ticketu zostaje w repozytorium. Możesz go porzucić, dokończyć ręcznie albo wrócić do sesji przez claude attach <id>.

4. Zamknij merge request, jeśli powstał

   Otwarty merge request trafiłby do kolejki przy następnym ticku.

Co z ticketami, które od niego zależą?

Ticket zależny czeka, aż jego bloker dostanie status Gotowe. Jeśli wyjmujesz bloker ze sprintu, zdejmij relację blokowania z ticketów zależnych albo wyjmij je razem z nim. Inaczej zostaną w sprincie jako praca, której nikt nie zacznie, a linia statusu dyspozytora nigdy nie dojdzie do remaining=0.

Jak odblokować kolejkę merge requestów?

Kolejka mr-queue prowadzi merge requesty po kolei i nie przeskakuje pozycji. Gdy pierwsza stoi, stoi cała kolejka.

Zamknięty merge request kolejka pomija sama przy następnym ticku. Listę pozycji trzyma plik .git/monolynx/mr-queue.json w repozytorium. Pozycję możesz też oznaczyć w nim jako closed, prosząc o to sesję kolejki.

Jak poprawić listę kolejki?

Pliku .git/monolynx/mr-queue.json nie edytuj ręcznie: jego format pilnuje skrypt kolejki. W sesji, w której działa kolejka, napisz zwykłym zdaniem, co ma się stać, na przykład "oznacz !42 jako zamknięty w kolejce". Sesja wykona operację skryptem i pokaże nową listę.

Jak cofnąć zły merge do brancha sprintu?

Zmergowany ticket, który okazał się błędny, cofasz zwykłym poleceniem git na branchu sprintu. Historii nie przepisujesz, bo opierają się na niej branche pozostałych ticketów.

$ git switch sprint/platnosci
$ git pull
$ git log --merges --oneline -5
$ git revert -m 1 <skrót commita merge>
$ git push

1. Cofnij merge

   Polecenie git revert dodaje nowy commit, który odwraca zmianę. Poprzednie commity zostają.

2. Załóż nowy ticket na poprawkę

   Ticket cofniętej zmiany ma status Gotowe i zamkniętą historię. Poprawioną wersję opisz w nowym tickecie i dodaj go do sprintu.

3. Sprawdź tickety zależne

   Sesje, które wystartowały po złym merge, mają tę zmianę w swoich branchach. Ich merge requesty po cofnięciu mogą mieć konflikt, a kolejka rozwiąże go, wciągając branch sprintu.

Co się dzieje w projekcie bez CI?

Praca nad ticketem nie wymaga CI. Komenda work uruchamia lint i testy lokalnie, z komend zapisanych na stronie wiki toolchain. Dopiero kolejka opiera decyzję o merge na wyniku CI.

Czy dwie osoby mogą prowadzić pętle na jednym sprincie?

Nie powinny. Dyspozytor czyta listę sesji w tle z komputera, na którym działa. Sesji uruchomionych na innej maszynie nie widzi, więc ticket W trakcie wygląda dla niego jak porzucony i dostaje wznowienie. Efekt to dwie sesje nad jednym ticketem.

Agent pracuje na koncie osoby, która go uruchomiła. Komentarze, statusy i zapisy w wiki mają więc jej autora, a zakres tego, co agent może zrobić, wyznacza jej rola w projekcie.

Co po awarii komputera albo zamknięciu terminala?

Pętla /loop żyje tak długo jak sesja, w której działa. Po restarcie komputera nie ma ani pętli, ani sesji ticketów. Stan projektu jest jednak na platformie, a kod na branchach.

1. Uruchom pętle ponownie

   Z tego samego katalogu i z tym samym MONOLYNX_MR_TARGET w środowisku.

2. Przeczytaj raport pierwszego ticku

   Tickety W trakcie bez sesji dostaną jedno automatyczne wznowienie.

3. Sprawdź sekcję "Czekają na człowieka"

   Trafiają tam tickety, które wznowienie już wykorzystały.

4. Posprzątaj katalogi robocze

   Komenda git worktree list pokazuje kopie repozytorium, które zostały po sesjach. Te należące do zakończonych ticketów usuwa claude rm <id>.

Najczęstsze pytania

Słownik i następny krok

Pętla

komenda powtarzana co stały czas: dyspozytor albo kolejka

Sesja w tle

osobny proces agenta pracujący nad jednym ticketem

Katalog roboczy ticketu

osobna kopia repozytorium dla jednej sesji; po angielsku worktree

Automatyczne wznowienie

jednorazowe ponowne uruchomienie sesji ticketu przez dyspozytora

Werdykt

stan ticketu albo merge requesta policzony przez skrypt, na przykład needs_human

Pracę nad jednym ticketem obok działających pętli, poprawki po recenzji i odświeżanie brancha sprintu opisuje wpis Praca ręczna w trakcie sprintu. Objawy i przyczyny typowych usterek zbiera wpis Gdy coś nie działa w Monolynx. Jak czytać raporty pętli i odpowiadać sesjom, opisuje wpis Sesje w tle: jak obserwować pętle sprintu. Wymagania i dostęp zbiera wpis Zacznij tutaj: czym jest Monolynx i czego potrzebujesz.