Sesje w tle: jak obserwować pętle sprintu i odpowiadać agentom

Jak uruchomić pętle i gdzie potem patrzeć?

Pętle uruchamiasz w dwóch zwykłych sesjach Claude Code, w dwóch oknach terminala, obu otwartych w katalogu projektu. Wszystko inne startuje samo.

Dwa okna terminala w katalogu projektu

# okno 1
$ claude
> /loop 15m /monolynx:sprint-run

# okno 2
$ claude
> /loop 10m /monolynx:mr-queue

Rodzaj sesji	Kto ją startuje	Gdzie ją widać	Ile ich jest
Sesja pętli dyspozytora	Ty	okno terminala 1	1
Sesja pętli kolejki	Ty	okno terminala 2	1
Sesja ticketu	dyspozytor, w tle	`claude agents`, `claude attach`	tyle, ile slotów

2domyślna liczba równoległych sesji ticketów

2domyślny limit sesji czekających na człowieka

1linia statusu na tick, którą wystarczy czytać

Kto startuje kogo

Człowiek uruchamia dwie pętle. Pętla dyspozytora co kwadrans startuje sesje ticketów w tle, każdą w osobnym worktree. Sesja ticketu kończy się merge requestem, który przejmuje pętla kolejki. Sesja, która nie może iść dalej, dostaje werdykt waiting i czeka, aż człowiek do niej wejdzie i odpowie.

flowchart TD
  H["Człowiek"] --> L1["Pętla sprint-run"]
  H --> L2["Pętla mr-queue"]
  L1 --> S1["Sesja ticketu w tle"]
  L1 --> S2["Sesja ticketu w tle"]
  S1 --> MR["Merge request"]
  MR --> L2
  S2 --> W["Werdykt waiting"]
  W --> H
  H -- "claude attach" --> S2

Jak czytać linię statusu?

Każdy tick dyspozytora kończy się raportem i jedną zamrożoną linią. Raport mówi, co się stało, linia mówi, czy masz coś do zrobienia.

Trzy ticki tego samego sprintu

SPRINT-RUN: remaining=6 running=2 waiting=0 done=1
SPRINT-RUN: remaining=4 running=1 waiting=1 done=3
SPRINT-RUN: remaining=0 running=0 waiting=0 done=7

Pole	Znaczenie	Kiedy reagować
`remaining`	tickety sprintu, które nie mają jeszcze sesji ani wyniku	gdy od kilku ticków nie maleje
`running`	sesje, które żyją i pracują	nie reaguj
`waiting`	sesje, które żyją, ale nie posuwają pracy	zawsze, gdy większe od zera
`done`	tickety z zakończoną sesją i zebranym wynikiem	nie reaguj

Pięć werdyktów ticketu

Dyspozytor nie zgaduje stanu z opisu. Werdykt liczy skrypt z listy sesji, statusu ticketu i końcówki logu sesji.

Werdykt	Co oznacza	Co robi dyspozytor	Co robisz Ty
`free`	ticket bez sesji, gotowy do startu	startuje sesję, gdy jest wolny slot	nic
`running`	sesja pracuje	nic, sesja zajmuje slot	nic
`waiting`	sesja żyje, ale stoi	zostawia ją nietkniętą i raportuje powód	wchodzisz do sesji
`done`	sesja zakończona, ticket ma wynik	dopisuje komentarz i sprząta sesję	nic
`needs_human`	sesja skończyła się bez wyniku	po jednym automatycznym wznowieniu oddaje ticket człowiekowi	sprawdzasz, co poszło źle

Skąd bierze się waiting?

Werdykt waiting ma kilka źródeł i nie każde oznacza pytanie do Ciebie. Powód jest zawsze przepisany dosłownie do raportu ticka.

Sygnał	Jak wygląda w sesji	Czy na pewno czeka na człowieka
Prośba o zgodę na narzędzie	sesja stoi na pytaniu o uprawnienie	tak
Marker `SPRINT-RUN STOP: <powód>`	sesja sama zakończyła turę i podała powód	tak
Pytanie na końcu odpowiedzi	ostatnia wypowiedź kończy się pytajnikiem	tak
Lista opcji z prośbą o decyzję	numerowane opcje i zdanie w rodzaju "wybierz"	tak
Fraza oczekiwania	ostatnie zdanie odpowiedzi zaczyna się od "Czekam"	niekoniecznie
Brak postępu	końcówka logu nie zmieniła się przez dwa kolejne ticki	niekoniecznie

Marker SPRINT-RUN STOP

Sesja ticketu działa w trybie, w którym nie wolno jej czekać na odpowiedź w nieskończoność. Gdy trafia na decyzję spoza swojego kontraktu, kończy turę jedną linią z powodem.

Przykładowe powody zatrzymania

SPRINT-RUN STOP: fast-forward do origin/sprint/platnosci odrzucony
SPRINT-RUN STOP: kolizja testów
SPRINT-RUN STOP: pełny przebieg ci bez MR

Linia STOP nie jest awarią. To sesja, która zamiast zgadywać, oddała decyzję człowiekowi i zachowała całą dotychczasową pracę w swoim worktree.

Jak wejść do sesji i odpowiedzieć?

Do sesji w tle wchodzisz trzema komendami z osobnego okna terminala. Identyfikator sesji jest krótki, ma osiem znaków, i znajdziesz go w raporcie ticka oraz na liście sesji.

Znajdź sesję
Komenda claude agents wypisuje sesje w tle. Sesja ticketu ma nazwę złożoną ze sluga projektu, klucza ticketu i modelu, na przykład sklep-SKL-12-opus.
Podejrzyj log
Komenda claude logs <id> pokazuje końcówkę rozmowy bez wchodzenia do sesji.
Wejdź do sesji
Komenda claude attach <id> otwiera sesję tak, jakbyś sam ją prowadził.
Odpowiedz
Wpisz decyzję zwykłym zdaniem. Sesja podejmuje pracę od miejsca, w którym stanęła.
Wyjdź i zostaw
Sesja pracuje dalej w tle. Następny tick dyspozytora zobaczy Twoją odpowiedź w logu i zdejmie werdykt waiting.

Terminal

claude agents
claude logs a1b2c3d4
claude attach a1b2c3d4

Co zrobić z needs_human?

Werdykt needs_human oznacza sesję, która już nie żyje, a ticket nie ma wyniku. Dyspozytor raz próbuje ją wznowić sam. Jeśli druga próba też kończy się niczym, ticket trafia do Ciebie.

Przeczytaj komentarz w tickecie
Dyspozytor dopisuje tam identyfikator sesji i powód.
Zajrzyj do logu
Komenda claude logs <id> pokaże, na czym sesja się skończyła.
Zdecyduj
Popraw ticket i pozwól dyspozytorowi wystartować go ponownie, albo dokończ pracę ręcznie komendą /monolynx:work w zwykłej sesji.

Sloty, limity i uprawnienia

Przepustowość sprintu zależy od dwóch liczb, a bezpieczeństwo od trybu uprawnień sesji.

Ustawienie	Domyślnie	Co zmienia
argument `[sloty]` albo `MONOLYNX_SPRINT_PARALLEL`	2	ile sesji ticketów pracuje naraz
`MONOLYNX_SPRINT_MAX_WAITING`	2	po ilu czekających sesjach dyspozytor przestaje startować nowe
`MONOLYNX_SPRINT_STALL_TICKS`	2	po ilu tickach bez zmiany logu sesja dostaje `waiting`
`MONOLYNX_SPRINT_PERMISSION_MODE`	`auto`	tryb uprawnień sesji ticketów
`MONOLYNX_SPRINT_MODEL`	`opus`	model sesji ticketów

Przykład: wolne sloty przy 2 slotach i różnej liczbie pracujących sesji

Dane wykresu

Pracujące sesje	Wolne sloty
0	2
1	1
2	0

Slot zajmuje tylko sesja running. Sesja waiting slotu nie blokuje, więc jedno pytanie zadane wieczorem nie zabiera połowy przepustowości do rana. Żeby sprint nie zamienił się w kolejkę samych pytań, czekające sesje mają własny limit: po jego osiągnięciu dyspozytor wstrzymuje start nowych i pisze to w raporcie.

Co hook pluginu blokuje w sesji w tle

Sesja ticketu ma do pomocy subagentów: programistę, testera, recenzenta. Hook pluginu pilnuje, żeby żaden z nich nie zrobił czegoś poza swoją rolą.

Operacja	Subagent	Sesja główna ticketu
`git add`, `git commit`, `git push`	odmowa	według flag `MONOLYNX_AUTO*`
lint i testy	odmowa, poza lintem tylko do odczytu	według `MONOLYNX_AUTOTEST`
otwarcie merge requesta	odmowa	według `MONOLYNX_AUTOMR`
zatwierdzenie merge requesta	odmowa	zawsze pytanie do człowieka
usuwanie poza katalogiem projektu	odmowa	odmowa

W sesji w tle nikt nie odpowie na pytanie hooka, więc każde pytanie zamienia się w odmowę z instrukcją: użyj wariantu, który niczego nie niszczy, albo zakończ turę linią SPRINT-RUN STOP.

A jeśli nie chcę trzymać otwartych okien?

Pętlę dyspozytora może prowadzić skrypt sprint_run.sh, dostarczany z pluginem. Każdy tick uruchamia w świeżym procesie, więc nadaje się do tmuxa, serwera albo crona.

Terminal, katalog projektu

bash /pelna/sciezka/skilla/scripts/sprint_run.sh --interval 15m --slots 2

Pełną ścieżkę skryptu wypisuje sam dyspozytor w raporcie ticku, razem z gotowymi wierszami dla tmuxa i crona. Uruchom raz /monolynx:sprint-run w Claude Code i skopiuj wiersz z raportu.

Kod wyjścia skryptu	Znaczenie
`0`	sprint wykonany, nic nie czeka na człowieka
`2`	trzy ticki pod rząd bez poprawnej linii statusu, dyspozytor nie działa
`3`	osiągnięto limit ticków, domyślnie 96
`4`	zostały wyłącznie sesje `waiting`, do dokończenia ręcznie

Log pętli trafia do pliku .git/monolynx/sprint-run.log. Skrypt domyślnie zatrzymuje się przed zamknięciem sprintu, bo merge requesty przegląda człowiek.

Najczęstsze pytania

Czy mogę zamknąć okno terminala z pętlą?

Sesje ticketów w tle będą pracować dalej, ale nikt nie wystartuje nowych ani nie zbierze zakończonych. Pętlę możesz uruchomić ponownie w dowolnej chwili: tick jest idempotentny i nie zdubluje sesji.

Skąd wiem, że sesja naprawdę pracuje, a nie stoi?

Z dwóch źródeł: werdykt running w raporcie ticka i komenda claude logs <id>, która pokazuje końcówkę rozmowy. Po dwóch tickach bez zmiany logu dyspozytor sam zgłosi sesję jako waiting z powodem "brak postępu".

Czy dyspozytor odpowie za mnie na proste pytanie?

Nie. Sesji czekającej nie wznawia, nie kasuje i nie odpowiada za człowieka. To celowe: pytanie pojawiło się dlatego, że decyzja wykracza poza kontrakt ticketu.

Ile to kosztuje?

Każda sesja ticketu to osobny proces z własnym modelem, domyślnie opus, a jej subagenci mają modele przypisane do ról. Koszt rośnie z liczbą slotów i wielkością ticketów. Model sesji zmienisz zmienną MONOLYNX_SPRINT_MODEL.

Co, jeśli ta sama pętla zostanie uruchomiona dwa razy?

Dla pętli w sesji nic złego: drugi tick zobaczy żywe sesje i niczego nie zdubluje. Skrypt sprint_run.sh pilnuje tego sam plikiem blokady i nie wystartuje drugiej pętli dla tego samego repozytorium.

Słownik i następny krok

Sesja w tle: sesja Claude Code uruchomiona bez okna terminala, do której można wejść później
Tick: jedno wykonanie pętli: odczyt stanu, najwyżej jeden krok na ticket, linia statusu
Slot: miejsce na jedną pracującą sesję ticketu
Werdykt: stan ticketu policzony przez skrypt: free, running, waiting, done albo needs_human
Tryb uprawnień: ustawienie Claude Code, które decyduje, o co sesja musi pytać
Hook: skrypt pluginu uruchamiany przed komendą agenta, który może ją przepuścić, zablokować albo zamienić w pytanie

Ten wpis rozwija jeden etap przewodnika Sprint z Monolynx krok po kroku. Mechanikę dyspozytora opisuje Jak działa /monolynx:sprint-run, a to, co dzieje się w sesji ticketu, Jak działa /monolynx:work.

Chcesz śledzić sprint także w panelu, a nie tylko w terminalu?

Zobacz moduł Scrum w Monolynx