Sprint od zera: lista kontrolna i tabela zgodności

Co musi być gotowe przed sprintem?

Lista zakłada projekt po jednorazowej konfiguracji. Jeśli któregoś punktu brakuje, zacznij od wpisu Zacznij tutaj: czym jest Monolynx i czego potrzebujesz.

Jakie branche występują w sprincie?

W sprincie są trzy rodzaje branchy. Pozostałe nazwy spotykane we wpisach i w zmiennych to określenia tych samych trzech.

flowchart LR
  M["Gałąź główna: main"] -- "Ty: git switch -c" --> S["Branch sprintu"]
  S -- "sesja ticketu" --> T1["Branch ticketu SKL-12"]
  S -- "sesja ticketu" --> T2["Branch ticketu SKL-13"]
  T1 -- "mr-queue: merge" --> S
  T2 -- "mr-queue: merge" --> S
  S -- "Ty: merge na końcu" --> M

Branch sprintu ma cztery przymiotniki, bo pełni cztery role naraz. Sesje biorą z niego kod, więc jest bazowy i źródłowy. Merge requesty ticketów trafiają do niego, więc jest docelowy. Zbiera pracę wszystkich ticketów, więc jest integracyjny. Wskazuje go jedna zmienna: MONOLYNX_MR_TARGET.

Jak wygląda sprint krok po kroku?

Każdy krok ma jedno polecenie albo jedną czynność w panelu. Kolejność jest istotna: pętle sprawdzają stan z kroków wcześniejszych.

1. Włącz zgody w repozytorium

   Do śledzonego pliku .claude/settings.json dopisz MONOLYNX_AUTOTEST, MONOLYNX_AUTOCOMMIT, MONOLYNX_AUTOPUSH i MONOLYNX_AUTOMR z wartością true, zrób commit i wypchnij go. Trzy pierwsze są warunkiem startu dyspozytora.

2. Napisz i sprawdź tickety

   Dla każdego: /monolynx:ticket-create "opis", potem /monolynx:ticket-review KLUCZ.

3. Utwórz sprint i przypisz tickety

   W panelu, w module Scrum. Każdy ticket przypisz do sprintu i przestaw z Backlog na Do zrobienia.

4. Wystartuj sprint

   Przycisk Wystartuj przy sprincie. Aktywny może być tylko jeden.

5. Ustaw blokery

   /monolynx:ticket-review sprint porównuje pliki ticketów i proponuje, który ma czekać na który.

6. Utwórz branch sprintu

   Odgałęź go od gałęzi głównej, wypchnij i zostań na nim. Krok jest zalecany, ale nieobowiązkowy: bez brancha sprintu pomijasz go razem ze zmienną z kroku 7, a merge requesty idą wprost do gałęzi głównej.

7. Uruchom dwie pętle

   W dwóch osobnych sesjach Claude Code, z tego samego katalogu i z ustawioną zmienną MONOLYNX_MR_TARGET.

8. Zatwierdzaj i odpowiadaj

   Kolejka pyta o zatwierdzenie każdego merge requesta. Sesje z werdyktem waiting czekają na Twoją odpowiedź.

9. Zmerguj i zamknij

   Gdy obie linie statusu pokazują zero: merge brancha sprintu do gałęzi głównej, potem /monolynx:sprint-end.

$ git switch main
$ git pull
$ git switch -c sprint/platnosci
$ git push -u origin sprint/platnosci
$ export MONOLYNX_MR_TARGET=sprint/platnosci

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

# okno 2, ten sam katalog, ta sama zmienna
$ claude
> /loop 10m /monolynx:mr-queue

# merge request sprint/platnosci -> main: otwierasz, czekasz na CI, mergujesz
$ git switch main
$ git pull
$ unset MONOLYNX_MR_TARGET
$ claude
> /monolynx:sprint-end

Co działa na której platformie?

Pełny autopilot zakłada GitLab i CI. W innych układach sprint też działa, ale część kroków wraca do człowieka.

W GitHubie sesja ticketu kończy pracę normalnie: wypycha branch, ustawia status Review i zapisuje w komentarzu, że merge request nie powstał. Pull request otwierasz sam, a kolejka przejmuje go przy następnym ticku.

Sprint w Codex zamiast Claude Code

Plugin instaluje się w Codex z tego samego repozytorium, a komendy mają prefiks $monolynx: zamiast /monolynx:. Dyspozytor ma dla Codex osobny tryb, wybierany zmienną MONOLYNX_SPRINT_RUNTIME=codex.

$ git clone https://gitlab.com/piotrkrych/monolynx.git
$ cd monolynx
$ codex plugin marketplace add .
$ codex plugin add monolynx@monolynx

Wpisy na tym blogu opisują obsługę sesji w Claude Code. W Codex mechanika pętli, werdykty i linia statusu są te same, a różni się tylko sposób podglądania sesji.

Kto zatwierdza, gdy pracujesz sam?

Kolejka potrzebuje Twojej zgody na każdy merge request. Wystarczy odpowiedź "tak" w rozmowie, o ile repozytorium nie wymaga formalnych zatwierdzeń.

Agent pracuje na Twoim koncie glab albo gh, więc autorem merge requestów jesteś Ty. W projekcie jednoosobowym regułę wymaganych zatwierdzeń najprościej wyłączyć, bo nie ma kto jej spełnić.

Co zrobić z uwagami recenzenta?

Agent nie czyta komentarzy w merge requeście sam. Wklej uwagi do komentarza ticketu, a poprawki zrób na branchu ticketu. Status ticketu zostaje Review: dyspozytor uznaje taki ticket za skończony i go nie rusza. Po Twoim pushu kolejka uruchamia CI od nowa i pyta o zatwierdzenie jeszcze raz.

Jak wygląda sprint z trzema ticketami?

Poniżej przebieg przykładowego sprintu w projekcie sklep. Ticket SKL-13 zależy od SKL-12, a sesja SKL-14 utknie na pytaniu. Wyniki są przykładowe, ale mają dokładnie taki format jak prawdziwe.

> /monolynx:sprint-run

| Ticket | Sesja | Werdykt | Działanie |
| SKL-12 | a1b2c3d4 | free -> running | start sesji |
| SKL-14 | e5f6a7b8 | free -> running | start sesji |
| SKL-13 | - | free -> pominięty | czeka na merge SKL-12 (todo) |

SPRINT-RUN: remaining=1 running=2 waiting=0 done=0

| SKL-12 | a1b2c3d4 | done | komentarz + claude rm |
| SKL-14 | e5f6a7b8 | waiting | pytanie w ostatniej odpowiedzi |
| SKL-13 | - | free -> pominięty | czeka na merge SKL-12 (in_review) |

Czekają na człowieka:
- SKL-14: sesja pyta, czy eksport ma obejmować zamówienia anulowane
  claude attach e5f6a7b8

SPRINT-RUN: remaining=1 running=0 waiting=1 done=1

Dwie rzeczy czekają teraz na Ciebie. Sesja SKL-14 potrzebuje odpowiedzi, a merge request SKL-12 zatwierdzenia.

$ claude attach e5f6a7b8
> Tak, eksport obejmuje też zamówienia anulowane, z osobną kolumną statusu.

> /monolynx:mr-queue

!42 SKL-12: eksport zamówień do CSV
CI: zielone | konflikt: brak | zatwierdzenie: brak

Approve !42 (SKL-12: eksport zamówień do CSV, SHA 4f2a9c1e)? tak / nie
> tak

MR-QUEUE: remaining=1 current=!42 verdict=needs_approval done=0

Następny tick kolejki merguje !42 i ustawia SKL-12 jako Gotowy. Kolejny tick dyspozytora widzi zamknięty bloker i startuje SKL-13.

SPRINT-RUN: remaining=0 running=0 waiting=0 done=3

Kolejka pokazuje w tym samym czasie remaining=0 w swojej linii MR-QUEUE.

Gdzie patrzeć w trakcie sprintu?

Trzy miejsca pokazują ten sam sprint z trzech stron. Na co dzień wystarcza pierwsze.

Lista w module Pipelines ma jeden wiersz na przebieg pracy nad ticketem. Po wejściu w wiersz widzisz trzy kolumny etapów: research, coding i wrap-up. Każda zawiera karty zadań poszczególnych agentów ze statusem i czasem trwania. Karta otwiera log zadania. Widok odświeża się sam co 15 sekund, a przebieg bez zmian od ponad sześciu godzin jest oznaczony jako zawieszony.

Najczęstsze pytania

Słownik i następny krok

Gałąź główna

domyślny branch repozytorium, zwykle main

Branch sprintu

branch zbierający pracę całego sprintu; wskazuje go MONOLYNX_MR_TARGET

Branch ticketu

branch jednej sesji, mergowany do brancha sprintu

Pętla

komenda powtarzana co stały czas: dyspozytor sprint-run albo kolejka mr-queue

Tick

jedno uruchomienie komendy pętli

Slot

miejsce na jedną równoległą sesję ticketu

Codzienną obsługę pętli, czyli co wpisać rano i jak czytać obie linie statusu, zbiera wpis Dzień sprintu: ściąga i tabela decyzji. Uzasadnienie każdego kroku i warianty opisuje przewodnik Sprint z Monolynx krok po kroku. Flagi i pliki, w których je ustawiasz, zbiera wpis Konfiguracja: która zmienna w którym pliku. Raporty pętli uczy czytać wpis Sesje w tle: jak obserwować pętle sprintu.