--- title: "Awaryjnie: jak zatrzymać sprint, wyjąć ticket i posprzątać" description: "Jak zatrzymać pętle i sesje w tle, wyjąć ticket ze sprintu, odblokować kolejkę merge requestów i co się dzieje w projekcie bez CI albo po awarii komputera." url: "https://monolynx.com/blog/awaryjne-zatrzymanie-sprintu-monolynx" lang: "pl" author: "Zespół Monolynx" published: "2026-10-10T12:04:54.810409+00:00" modified: "2026-10-10T13:13:02.312637+00:00" last_verified: "2026-10-10" tags: ["monolynx", "sprint", "plugin", "agenci-ai"] translations: [] reading_time_minutes: 9 word_count: 1765 --- > [!TLDR] > - Zatrzymanie pętli nie zatrzymuje sesji, które już pracują. To dwie osobne czynności. > - Sesję ticketu zatrzymujesz komendą `claude stop `. Rozmowa zostaje i można do niej wrócić. > - Ticket odpinasz od sprintu, zanim zatrzymasz jego sesję. W odwrotnej kolejności dyspozytor wznowi go sam. > - Kolejka merge requestów nie przeskakuje pozycji. Odblokowujesz ją, zamykając merge request albo oznaczając pozycję jako zamkniętą. > - Jedna para pętli na sprint, na jednym komputerze. Druga para na innej maszynie zdubluje sesje. ## 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. **Porównanie** | Warstwa | Co to jest | Jak zatrzymać | | --- | --- | --- | | Pętla dyspozytora | `/loop 15m /monolynx:sprint-run` albo skrypt `sprint_run.sh` | zamknij sesję z pętlą albo przerwij skrypt | | Pętla kolejki | `/loop 10m /monolynx:mr-queue` | zamknij sesję z pętlą | | Sesje ticketów | osobne sesje w tle, po jednej na ticket | `claude stop ` dla każdej | | Sprint w panelu | stan Aktywny | zostaje bez zmian, dopóki nie uruchomisz `sprint-end` | **Kroki** 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 `. 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. **Zatrzymanie jednej sesji ticketu** ```console $ claude agents sklep-SKL-12-opus a1b2c3d4 running sklep-SKL-14-opus e5f6a7b8 running $ claude stop a1b2c3d4 ``` > [!TIP] > Pętle można uruchomić ponownie w dowolnej chwili. Tick jest idempotentny: czyta stan sprintu i sesji od nowa, więc niczego nie dubluje ani nie gubi. ## 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. **Porównanie** | Cecha | `claude stop ` | `claude rm ` | | --- | --- | --- | | Proces sesji | zatrzymany | usunięty | | Rozmowa | zostaje; wracasz przez `claude attach ` | usunięta | | Katalog roboczy ticketu | zostaje | usunięty razem z sesją | | Niewypchnięte zmiany | zostają | komenda odmawia, dopóki ich nie wypchniesz albo świadomie nie porzucisz | > [!CAUTION] > Flagi `--discard-unpushed` i `--force-remove-worktree` komendy `claude rm` kasują pracę, której nikt jeszcze nie widział. Dyspozytor nigdy ich nie używa. Sięgaj po nie tylko wtedy, gdy na pewno chcesz wyrzucić zmiany ticketu. ## 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. **Kroki** 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 `. 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 `. 4. **Zamknij merge request, jeśli powstał** Otwarty merge request trafiłby do kolejki przy następnym ticku. > [!WARNING] > Jedno automatyczne wznowienie na ticket to limit dyspozytora. Gdy sesja padnie drugi raz, ticket trafia do sekcji "Czekają na człowieka" w raporcie i nikt go już nie rusza bez Ciebie. ### 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. **Porównanie** | Sytuacja | Co robi kolejka | Co robisz Ty | | --- | --- | --- | | brak zatwierdzenia | pyta w rozmowie, w tle kończy turę linią `MR-QUEUE STOP` | odpowiadasz "tak" albo zatwierdzasz w GitLabie lub GitHubie | | dwie nieudane rundy naprawy CI | oddaje sprawę człowiekowi | poprawiasz branch sam albo zamykasz merge request | | merge request bez pipeline'u | werdykt `needs_human`, pozycja czeka | uruchamiasz CI na branchu albo mergujesz ręcznie | | pipeline anulowany albo ręczny | werdykt `needs_human`, bez ponawiania | ponawiasz pipeline albo uruchamiasz jego ręczne zadania | | merge request oznaczony jako draft | pozycja czeka | zdejmujesz status draft albo zamykasz merge request | | merge request, którego już nie chcesz | nadal jest pierwszy w kolejce | zamykasz go na platformie | 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. **Cofnięcie jednego merge na branchu sprintu** ```console $ git switch sprint/platnosci $ git pull $ git log --merges --oneline -5 $ git revert -m 1 $ git push ``` **Kroki** 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. > [!NOTE] > Komendy `claude agents`, `claude attach`, `claude stop` i `claude rm` należą do Claude Code. Wpisy sprawdzono na wersji 2.1.273 i nowszych; starszych nie testowano. ## 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. **Porównanie** | Element | Z CI | Bez CI | | --- | --- | --- | | `work` i `work-simple` | lint i testy lokalnie, potem merge request | bez zmian | | `sprint-run` | startuje sesje ticketów | bez zmian; dyspozytor nie zależy od CI | | `mr-queue` | merguje po zielonym CI | każda pozycja dostaje werdykt `needs_human`; mergujesz sam | | Status Gotowe | ustawia kolejka po merge | ustawiasz sam po merge | > [!NOTE] > Kolejka obsługuje GitLab przez narzędzie `glab` i GitHub przez narzędzie `gh`. Na innej platformie merge requesty otwierasz i mergujesz ręcznie, a status Gotowe ustawiasz w panelu. ## 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. **Porównanie** | Układ | Czy działa | | --- | --- | | jedna osoba prowadzi obie pętle, reszta zatwierdza merge requesty | tak | | jedna osoba prowadzi pętle, druga robi pojedynczy ticket komendą `work` | tak, o ile ticket nie jest przypisany do aktywnego sprintu | | dwie osoby prowadzą dyspozytora na dwóch komputerach | nie; sesje się dublują | 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. **Kroki** 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 `. ## Najczęstsze pytania **FAQ** ### Czy zatrzymanie pętli psuje sprint? Nie. Pętla tylko uruchamia ticki. Stan sprintu, ticketów i kolejki jest zapisany poza nią, więc po ponownym uruchomieniu wszystko idzie dalej. ### Czy mogę zamknąć sprint z niedokończonymi ticketami? Tak. Komenda `sprint-end` pyta o potwierdzenie, a niedokończone tickety tracą przypisanie do sprintu i dostają status Backlog. Tego kroku nie da się cofnąć. ### Sesja czeka na moją odpowiedź. Mogę ją po prostu usunąć? Lepiej nie. Sesja czekająca ma zwykle niewypchnięte zmiany. Wejdź do niej przez `claude attach `, odpowiedz albo każ jej zakończyć pracę. ### Dyspozytor wznowił ticket, który sam zatrzymałem. Dlaczego? Ticket został przypisany do aktywnego sprintu, a jego sesja zniknęła. Dla dyspozytora to awaria. Odepnij ticket od sprintu, zanim zatrzymasz sesję. ### Skąd wiem, że nic już nie pracuje? Komenda `claude agents` nie pokazuje żadnej sesji z nazwą Twojego projektu, a linia statusu dyspozytora ma `running=0`. ## Słownik i następny krok **Słownik** - **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](https://monolynx.com/blog/praca-reczna-w-sprincie-monolynx). Objawy i przyczyny typowych usterek zbiera wpis [Gdy coś nie działa w Monolynx](https://monolynx.com/blog/gdy-cos-nie-dziala-w-monolynx). Jak czytać raporty pętli i odpowiadać sesjom, opisuje wpis [Sesje w tle: jak obserwować pętle sprintu](https://monolynx.com/blog/sesje-w-tle-monolynx). Wymagania i dostęp zbiera wpis [Zacznij tutaj: czym jest Monolynx i czego potrzebujesz](https://monolynx.com/blog/zacznij-tutaj-monolynx). **Wezwanie do działania** Chcesz widzieć, co każda sesja robi w danej chwili? [Zobacz moduł Pipelines w Monolynx](https://monolynx.com/features/pipelines)