Dzień sprintu: ściąga i tabela decyzji

Co robisz w dniu sprintu?

Sprint z pętlami prowadzą trzy strony: dyspozytor, kolejka merge requestów i Ty. Dyspozytor startuje sesje ticketów. Kolejka prowadzi ich merge requesty. Ty odpowiadasz sesjom, które czekają, i zatwierdzasz zmiany.

Jeden ticket w czasie: kto co robi

Dyspozytor startuje sesję ticketu. Sesja pisze kod, otwiera merge request i ustawia status Review. Kolejka sprawdza CI i pyta człowieka o zatwierdzenie. Po zgodzie merguje i ustawia status Gotowe. Dopiero wtedy dyspozytor startuje ticket, który na ten czekał.

sequenceDiagram
  participant C as Człowiek
  participant D as Dyspozytor sprint-run
  participant S as Sesja ticketu
  participant K as Kolejka mr-queue
  D->>S: start sesji dla ticketu Do zrobienia
  S->>S: plan, kod, lint, testy, ocena krytyka
  S-->>C: pytanie, jeśli czegoś nie wie
  C-->>S: odpowiedź przez claude attach
  S->>K: merge request, status Review
  D->>D: zbiera wynik, liczy done
  K->>K: konflikt i czerwone CI naprawia sama
  K-->>C: pytanie o zatwierdzenie
  C-->>K: tak
  K->>K: merge, status Gotowe
  D->>S: start ticketu zależnego

2pętle, które uruchamiasz rano

2rodzaje próśb do Ciebie: odpowiedź sesji i zatwierdzenie merge requesta

3warunki końca sprintu: dwie linie na zerze i tablica w Gotowe

Jak zacząć dzień?

Poranek to pięć poleceń w dwóch oknach terminala. Oba okna otwierasz w głównym katalogu repozytorium, który stoi na branchu sprintu.

Okno 1: dyspozytor

$ cd ~/sklep
$ git branch --show-current
sprint/platnosci
$ git status --short
$ export MONOLYNX_MR_TARGET=sprint/platnosci
$ claude
> /loop 15m /monolynx:sprint-run

Okno 2: kolejka

$ cd ~/sklep
$ export MONOLYNX_MR_TARGET=sprint/platnosci
$ claude
> /loop 10m /monolynx:mr-queue

Sprawdź branch i czystość katalogu
Główny katalog ma stać na branchu sprintu, a git status --short nie może nic wypisać. Sesje ticketów startują z commita, na którym stoi ten katalog.
Ustaw branch sprintu w obu oknach
Zmienna MONOLYNX_MR_TARGET mówi sesjom, dokąd mają trafić merge requesty.
Uruchom dyspozytora
Pierwszy tick wykona się od razu, kolejne co 15 minut.
Uruchom kolejkę w drugim oknie
Kolejka musi być w sesji interaktywnej, bo pyta Cię o zatwierdzenie.
Zostaw oba okna otwarte
Pętla /loop działa, dopóki sesja jest otwarta, a komputer nie śpi.

Jak czytać linię SPRINT-RUN?

Każdy tick dyspozytora kończy się linią z czterema licznikami. Tabela mówi, co zrobić przy każdym układzie.

Co widzisz	Co to znaczy	Co robisz
`running` większe od zera, `waiting=0`	sesje pracują	nic
`waiting` większe od zera	sesja pyta albo stoi	czytasz sekcję "Czekają na człowieka" w raporcie, wchodzisz przez `claude attach <id>` i odpowiadasz
`waiting=2` i nie startują nowe sesje	osiągnięty limit czekających sesji	odpowiadasz przynajmniej jednej; dyspozytor wznowi starty w następnym ticku
`remaining` większe od zera, `running=0`, `waiting=0` od kilku ticków	zostały tickety, których dyspozytor nie wystartuje	sprawdzasz w raporcie wiersze "pominięty": bloker czeka na merge albo ticket ma etykietę `needs-local`
werdykt `needs_human` przy tickecie	ticket bez żywej sesji, który nie jest ani Do zrobienia, ani Review, ani Gotowe: sesja padła bez wyniku albo ticket ma status Backlog lub W trakcie; jedno automatyczne uruchomienie już było	czytasz komentarz dyspozytora w tickecie i decydujesz: poprawiasz ticket albo odpinasz go od sprintu
`done` rośnie, a tablica nie ma ticketów Gotowe	`done` liczy też tickety w Review	patrzysz na kolejkę: to ona merguje i ustawia Gotowe
`remaining=0 running=0 waiting=0`	dyspozytor nie ma nic do zrobienia	patrzysz na linię kolejki

Jak czytać linię MR-QUEUE?

Kolejka prowadzi jeden merge request naraz i w każdym ticku wykonuje jedno działanie. Jej linia podaje pozycję, przy której stoi, i werdykt.

Co widzisz	Co to znaczy	Co robisz
pytanie "Approve ... ? tak / nie" i `verdict=needs_approval`	merge request ma zielone CI i czeka na zgodę	czytasz zmianę i odpowiadasz "tak" albo "nie"
`verdict=wait`	CI jeszcze biegnie	nic
kolejka pisze, że wciąga branch docelowy albo naprawia CI	konflikt albo czerwone CI; kolejka radzi sobie sama, najwyżej dwie rundy	nic
`verdict=needs_human`	kolejka nie poprowadzi tej pozycji: brak pipeline'u, pipeline anulowany, draft albo dwie nieudane naprawy	czytasz linię "Potrzebne" i robisz to, o co prosi
linia `MR-QUEUE STOP`	kolejka działa bez człowieka i trafiła na pytanie	uruchamiasz ją w sesji interaktywnej
`remaining=0`	kolejka jest pusta	sprawdzasz warunki końca sprintu

Kiedy sprint jest skończony?

Sprint kończysz Ty. Żadna pętla nie zamyka sprintu sama i żadna nie merguje brancha sprintu do gałęzi głównej.

Warunek	Gdzie go sprawdzasz
dyspozytor: `remaining=0 running=0 waiting=0`	ostatnia linia ticku w oknie 1
kolejka: `remaining=0`	ostatnia linia ticku w oknie 2
wszystkie tickety sprintu mają status Gotowe	tablica w panelu

Zamknij oba okna z pętlami
Pętle nie są już potrzebne.
Otwórz merge request brancha sprintu do gałęzi głównej
Poczekaj na pełne CI i zmerguj go sam, zgodnie z zasadami repozytorium. Kolejka w tym nie uczestniczy, bo jej pętla jest już zamknięta. Otwarty przy działającej kolejce trafiłby do niej jak każdy inny merge request, dlatego kolejność jest właśnie taka.
Przejdź na gałąź główną
git switch main, potem git pull.
Zdejmij zmienną sprintu
unset MONOLYNX_MR_TARGET.
Uruchom zamknięcie
/monolynx:sprint-end przenosi wiedzę do wiki, proponuje opcjonalne retro i po Twoim potwierdzeniu zamyka sprint w panelu.

Sprint, w którym część ticketów nie zdążyła, zamykasz tak samo. Tickety bez statusu Gotowe wracają do backlogu i tracą przypisanie do sprintu. Przypisujesz je do następnego sprintu i ustawiasz im status Do zrobienia.

Jak zakończyć dzień?

Wieczorem masz dwie możliwości i obie są bezpieczne. Stan sprintu jest na platformie i w branchach, a nie w pętlach.

Decyzja	Co robisz	Co się dzieje w nocy
pętle zostają	zostawiasz oba okna i komputer, który nie zasypia	dyspozytor startuje kolejne sesje; kolejka staje na pierwszym pytaniu o zatwierdzenie
pętle stają	zamykasz oba okna	sesje ticketów, które już pracują, kończą ticket i ustawiają Review; nowe nie startują

Sprint zatrzymany na noc: tak ma wyglądać

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

# rano, po ponownym uruchomieniu pętli
SPRINT-RUN: remaining=2 running=0 waiting=0 done=3

Rano uruchamiasz obie pętle tak samo jak pierwszego dnia. Tick czyta stan od nowa, więc niczego nie dubluje.

Gdzie uruchamiać pętle?

Miejsce zależy od tego, czy chcesz, żeby sprint szedł bez otwartego laptopa.

Miejsce	Jak	Ograniczenie
laptop	`/loop` w dwóch oknach Claude Code	działa, dopóki sesje są otwarte, a komputer nie śpi
serwer albo stale włączony komputer	skrypt `sprint_run.sh` w tmux dla dyspozytora	kolejka w tle staje na pytaniu o zatwierdzenie, więc odpowiadasz jej w sesji interaktywnej

Dyspozytora na jednym sprincie prowadzi jedna osoba na jednym komputerze. Dyspozytor widzi tylko sesje ze swojej maszyny, więc druga osoba z własną pętlą zdublowałaby sesje ticketów. Pozostali członkowie zespołu zatwierdzają merge requesty i odpowiadają na pytania.

Które słowa znaczą kilka rzeczy?

Trzy grupy nazw mylą się najczęściej w trakcie sprintu. Tabela zestawia je w jednym miejscu.

Nazwa	Gdzie	Co znaczy
`done`	status ticketu	zmiana jest zmergowana; w panelu Gotowe
`done=`	linia `SPRINT-RUN`	tickety, których sesja skończyła pracę; liczy też Review
`done=`	linia `MR-QUEUE`	merge requesty zmergowane przez kolejkę
gałąź główna	repozytorium	domyślny branch, zwykle `main`; tam trafia skończony sprint
branch sprintu	repozytorium	branch zbierający tickety sprintu; we wpisach także bazowy, docelowy i integracyjny
`MONOLYNX_MR_TARGET`	zmienna	nazwa brancha sprintu; ustawiasz tylko ją
`MONOLYNX_BASE_BRANCH`	zmienna	to samo dla punktu startu sesji; pusta przyjmuje wartość `MONOLYNX_MR_TARGET`
`MONOLYNX_TOKEN`	CLI `monolynx`	token API zamiast logowania, przydatny w CI
`MONOLYNX_MCP_TOKEN`	ręczna konfiguracja MCP i skrypt `cicd/wiki_post_merge.py`	token połączenia z serwerem MCP
`MONOLYNX_GRAPH_TOKEN`	skrypt `cicd/sync_graph.py`	osobny token synchronizacji grafu kodu

Do codziennej pracy z pluginem nie potrzebujesz żadnego z trzech tokenów: plugin loguje się przez przeglądarkę. Tokeny służą skryptom CI i ręcznej konfiguracji.

Najczęstsze pytania

Jakie uprawnienia musi mieć konto, na którym pracuje agent?

Agent działa na Twoim koncie. Domyślna rola członka projektu czyta i zapisuje tickety oraz strony wiki, więc wystarcza do work, dyspozytora i kolejki. Usuwanie stron wiki, potrzebne do czyszczenia logów w sprint-end, wymaga roli właściciela albo administratora.

Co, jeśli nie wiem, czy sesja pracuje, czy stoi?

Dyspozytor sam to sprawdza. Sesja, której log nie zmienia się przez dwa kolejne ticki, dostaje werdykt waiting z powodem "brak postępu". Wtedy wchodzisz do niej przez claude attach <id>.

Czy mogę uruchomić tick ręcznie, nie czekając na pętlę?

Tak. Wpisz /monolynx:sprint-run albo /monolynx:mr-queue w dowolnej sesji w tym samym katalogu. Tick jest bezpieczny do powtórzenia.

Ile ticketów naraz prowadzi dyspozytor?

Domyślnie dwa. Liczbę slotów podajesz po nazwie komendy, na przykład /monolynx:sprint-run 3.

Co zrobić, gdy chcę jeden ticket zrobić sam?

Nie zmieniaj tylko statusu. Kolejność podaje wpis Praca ręczna w trakcie sprintu.

Słownik i następny krok

Dyspozytor: komenda sprint-run; startuje sesje ticketów i zbiera ich wyniki
Kolejka: komenda mr-queue; prowadzi merge requesty do merge jeden po drugim
Tick: jedno uruchomienie komendy pętli
Linia statusu: ostatnia linia ticku: SPRINT-RUN: ... albo MR-QUEUE: ...
Werdykt: stan ticketu albo merge requesta policzony przez skrypt
Slot: miejsce na jedną równoległą sesję ticketu

Jeśli to Twój pierwszy kontakt z Monolynx, zacznij od wpisu Zacznij tutaj: czym jest Monolynx i czego potrzebujesz: podaje kolejność czytania dla jednego ticketu i dla sprintu. Przed pierwszym sprintem zrób Test dymny przed pierwszym sprintem. Gdy coś pójdzie źle, sięgnij po wpis Awaryjnie: jak zatrzymać sprint, wyjąć ticket i posprzątać.

Chcesz widzieć stan sprintu na tablicy obok linii statusu pętli?

Zobacz moduł Scrum w Monolynx