--- title: "Dzień sprintu: ściąga i tabela decyzji" description: "Ściąga na dzień sprintu w Monolynx: co wpisać rano, jak czytać linie SPRINT-RUN i MR-QUEUE, kiedy sprint jest skończony i jak zatrzymać pętle na noc." url: "https://monolynx.com/blog/dzien-sprintu-monolynx" lang: "pl" author: "Zespół Monolynx" published: "2026-10-10T13:07:16.255418+00:00" modified: "2026-10-10T13:12:56.601132+00:00" last_verified: "2026-10-10" tags: ["sprint", "plugin"] translations: [] reading_time_minutes: 10 word_count: 1912 --- > [!TLDR] > - Ten wpis to ściąga na dzień sprintu: co wpisać rano, jak czytać dwie linie statusu i kiedy sprint jest skończony. > - Dzień ma trzy części: start dwóch pętli, reagowanie na dwa rodzaje próśb i wieczorne zatrzymanie albo zostawienie pętli. > - Każda kombinacja liczników w liniach `SPRINT-RUN` i `MR-QUEUE` ma w tabeli jedno działanie. > - Sprint jest skończony, gdy obie linie pokazują zero, a tablica same tickety Gotowe. Dopiero wtedy mergujesz branch sprintu i uruchamiasz `sprint-end`. > - Jesteś tu pierwszy raz? Kolejność czytania całego bloga podaje wpis "Zacznij tutaj", podlinkowany na końcu. ## 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ł. ```mermaid 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 ``` **Statystyki** - **2** - pętle, które uruchamiasz rano - **2** - rodzaje próśb do Ciebie: odpowiedź sesji i zatwierdzenie merge requesta - **3** - warunki 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** ```console $ 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** ```console $ cd ~/sklep $ export MONOLYNX_MR_TARGET=sprint/platnosci $ claude > /loop 10m /monolynx:mr-queue ``` **Kroki** 1. **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. 2. **Ustaw branch sprintu w obu oknach** Zmienna `MONOLYNX_MR_TARGET` mówi sesjom, dokąd mają trafić merge requesty. 3. **Uruchom dyspozytora** Pierwszy tick wykona się od razu, kolejne co 15 minut. 4. **Uruchom kolejkę w drugim oknie** Kolejka musi być w sesji interaktywnej, bo pyta Cię o zatwierdzenie. 5. **Zostaw oba okna otwarte** Pętla `/loop` działa, dopóki sesja jest otwarta, a komputer nie śpi. > [!NOTE] > Pierwszy dzień sprintu ma jeszcze kroki wcześniejsze: zgody w pliku ustawień, sprint w panelu i branch sprintu. Podaje je wpis [Sprint od zera: lista kontrolna i tabela zgodności](https://monolynx.com/blog/sprint-lista-kontrolna-monolynx). Ten wpis zaczyna się w chwili, gdy to wszystko już jest. ## 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. **Porównanie** | 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 ` 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. **Porównanie** | 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 | > [!IMPORTANT] > Kolejka stoi na pierwszej pozycji i nie przeskakuje do następnej. Jeden merge request bez Twojej odpowiedzi zatrzymuje wszystkie za nim, a przez blokery także starty kolejnych ticketów. ## 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. **Porównanie** | 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 | **Kroki** 1. **Zamknij oba okna z pętlami** Pętle nie są już potrzebne. 2. **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. 3. **Przejdź na gałąź główną** `git switch main`, potem `git pull`. 4. **Zdejmij zmienną sprintu** `unset MONOLYNX_MR_TARGET`. 5. **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. > [!WARNING] > Zamknięcia sprintu nie da się cofnąć. Jeśli zamknąłeś sprint za wcześnie, utwórz nowy, przypisz do niego tickety, które wróciły do backlogu, i wystartuj go. Praca na branchach i otwarte merge requesty zostają nietknięte. ## 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. **Porównanie** | 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ć** ```console $ 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. **Porównanie** | 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. **Porównanie** | 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 **FAQ** ### 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 `. ### 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](https://monolynx.com/blog/praca-reczna-w-sprincie-monolynx). ## Słownik i następny krok **Słownik** - **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](https://monolynx.com/blog/zacznij-tutaj-monolynx): podaje kolejność czytania dla jednego ticketu i dla sprintu. Przed pierwszym sprintem zrób [Test dymny przed pierwszym sprintem](https://monolynx.com/blog/test-dymny-przed-sprintem-monolynx). Gdy coś pójdzie źle, sięgnij po wpis [Awaryjnie: jak zatrzymać sprint, wyjąć ticket i posprzątać](https://monolynx.com/blog/awaryjne-zatrzymanie-sprintu-monolynx). **Wezwanie do działania** Chcesz widzieć stan sprintu na tablicy obok linii statusu pętli? [Zobacz moduł Scrum w Monolynx](https://monolynx.com/features/scrum)