Statusy ticketu w Monolynx: co znaczą i kto je zmienia

Jakie statusy ma ticket?

Każdy status ma dwie nazwy. W panelu widzisz polską etykietę, a w komendach, w liniach statusu i w wynikach CLI nazwę techniczną. Poniższa tabela jest jedynym mapowaniem, którego potrzebujesz.

W panelu	W komendach i API	Co znaczy
Backlog	`backlog`	ticket istnieje, ale nie jest zaplanowany do pracy
Do zrobienia	`todo`	ticket jest gotowy do podjęcia
W trakcie	`in_progress`	ktoś nad nim pracuje: człowiek albo sesja agenta
Review	`in_review`	praca skończona, zmiana czeka na merge
Gotowe	`done`	zmiana jest zmergowana

Droga ticketu przez statusy

Nowy ticket zaczyna w statusie Backlog. Człowiek przestawia go na Do zrobienia. Sesja work bierze go i ustawia W trakcie, a po zielonych testach i ocenie krytyka ustawia Review. Po merge kolejka albo człowiek ustawia Gotowe. Ticket niedokończony przy zamknięciu sprintu wraca do backlogu.

flowchart LR
  A["Backlog"] -- "człowiek" --> B["Do zrobienia"]
  B -- "work" --> C["W trakcie"]
  C -- "work" --> D["Review"]
  D -- "mr-queue albo człowiek" --> E["Gotowe"]
  C -. "zamknięcie sprintu" .-> A
  D -. "zamknięcie sprintu" .-> A

5statusów ticketu

2zmiany statusu, które agent robi sam

1status, który zdejmuje blokadę z ticketów zależnych: Gotowe

Kto zmienia który status?

Każde przejście ma jednego właściciela. W pracy ręcznej jest nim częściej człowiek, w sprincie z pętlami częściej automat.

Przejście	Praca ręczna	Sprint z pętlami
nowy ticket	Backlog, ustawiany przy utworzeniu	Backlog, ustawiany przy utworzeniu
Backlog na Do zrobienia	niepotrzebne; `work` przyjmuje klucz wprost	człowiek przy planowaniu
Do zrobienia na W trakcie	komenda `work` na starcie	sesja `work` w tle na starcie
W trakcie na Review	komenda `work` po testach i ocenie	sesja `work` w tle po testach i ocenie
Review na Gotowe	osoba, która merguje	kolejka `mr-queue` po merge

Skąd dyspozytor wie, który ticket wziąć?

Dyspozytor sprint-run patrzy na trzy rzeczy naraz. Ticket musi spełniać wszystkie.

Aktywny sprint
Ticket jest przypisany do sprintu, który wystartowałeś w panelu.
Status Do zrobienia
Ticket w statusie Backlog jest pomijany, nawet gdy należy do sprintu.
Brak otwartych blokerów
Każdy ticket, od którego ten zależy, ma status Gotowe.

Dwa wyjątki dotyczą ticketów, które spełniają wszystkie trzy warunki. Ticket z etykietą needs-local nie startuje w tle nigdy, a ticket z migracją bazy startuje tylko wtedy, gdy nie biegnie żadna inna sesja. Oba opisuje wpis Jak działa /monolynx:sprint-run.

Kiedy dokładnie ticket jest Gotowy?

Status Gotowe zależy od tego, dokąd trafia merge. Kolejka mr-queue rozróżnia dwa przypadki.

Merge do	Kiedy kolejka ustawia Gotowe	Dlaczego
brancha sprintu	od razu po merge	wystarcza zielone CI samego merge requesta; całość sprawdzi później merge brancha sprintu
domyślnego brancha repozytorium	po zielonym CI tego brancha	zmiana trafia wprost do gałęzi głównej, więc kolejka czeka na jej wynik

Bez kolejki status ustawia osoba, która merguje: zmienia go na liście backlogu, przeciąga kartę na tablicy aktywnego sprintu albo prosi o to agenta.

Dlaczego Review nie odblokowuje ticketów zależnych?

Bloker jest zamknięty dopiero przy statusie Gotowe. Ticket w review ma kod na osobnym branchu, którego ticket zależny jeszcze nie widzi. Gdyby dyspozytor ruszył go wcześniej, sesja pracowałaby na starej wersji kodu.

Ticket zależny czeka na merge blokera

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

Czekają na człowieka:
- SKL-15 czeka na merge SKL-12 (status: in_review)

Czym różni się status done od licznika done?

Słowo done ma w Monolynx trzy znaczenia i łatwo je pomylić.

Gdzie	Co znaczy `done`
Status ticketu	zmiana jest zmergowana
Licznik `done=` w linii `SPRINT-RUN`	sesja ticketu skończyła pracę: ticket jest w review albo zamknięty
Licznik `done=` w linii `MR-QUEUE`	merge request przeszedł przez kolejkę do końca

Dyspozytor liczy ticket jako done, gdy jego sesja nie ma już nic do zrobienia. Dla dyspozytora to koniec, dla sprintu jeszcze nie: zmiana czeka w kolejce.

Co się dzieje ze statusami przy zamknięciu sprintu?

Zamknięcie sprintu dzieli tickety na dwie grupy według jednego kryterium: status Gotowe albo każdy inny.

Status w chwili zamknięcia	Co się dzieje
Gotowe	ticket zostaje w zamkniętym sprincie, w historii
Review, W trakcie, Do zrobienia	ticket wraca do backlogu

Statusy sprintu, dla porównania

Sprint ma własne trzy stany, niezależne od statusów ticketów.

W panelu	Co znaczy
Planowanie	sprint utworzony, jeszcze nie wystartowany
Aktywny	sprint trwa; w projekcie może być tylko jeden taki
Zakończony	sprint zamknięty; tego nie da się cofnąć

Najczęstsze pytania

Czy mogę ręcznie ustawić Gotowe na tablicy?

Tak. W pracy ręcznej to normalny krok po merge. W sprincie z kolejką lepiej zostawić to kolejce, bo status Gotowe od razu odblokowuje tickety zależne.

Ticket jest W trakcie, ale nikt nad nim nie pracuje. Co zrobić?

Sprawdź komendą claude agents, czy istnieje sesja tego ticketu. Jeśli nie, uruchom /monolynx:resume z kluczem ticketu, żeby odtworzyć stan, albo przestaw ticket na Do zrobienia.

Czy ticket może wrócić z Review do W trakcie?

Tak. Dzieje się tak, gdy merge request wymaga poprawek większych niż naprawa CI. Przestawiasz status ręcznie albo uruchamiasz work ponownie na tym tickecie.

Dlaczego licznik done rośnie, a na tablicy nie ma ticketów Gotowe?

Licznik dyspozytora liczy sesje, które skończyły pracę. Tickety są wtedy w review i czekają na kolejkę merge requestów albo na Twoje zatwierdzenie.

Gdzie zobaczę historię zmian statusu?

W komentarzach ticketu. Każda komenda zostawia ślad: plan, raporty agentów, ocenę krytyka, a kolejka dopisuje identyfikator commita merge.

Słownik i następny krok

Status ticketu: etap, na którym jest ticket: od Backlog do Gotowe
Bloker: ticket, który musi być Gotowy, zanim ruszy ticket zależny
Aktywny sprint: sprint wystartowany w panelu; jedyny, z którego dyspozytor bierze tickety
Linia statusu: ostatnia linia raportu pętli, z licznikami w stałym formacie
Kolejka: komenda mr-queue, która prowadzi merge requesty do merge jeden po drugim

Tablicę i backlog w panelu opisuje wpis Sprint w panelu Monolynx. Jeden ticket krok po kroku prowadzi wpis Pierwszy ticket ręcznie. Zatwierdzanie i merge opisuje wpis Zatwierdzanie i merge: co zawsze robi człowiek.

Chcesz zobaczyć tablicę, na której te statusy są kolumnami?

Zobacz moduł Scrum w Monolynx