--- title: "Statusy ticketu w Monolynx: co znaczą i kto je zmienia" description: "Pięć statusów ticketu w Monolynx: nazwy w panelu i w komendach, kto zmienia który status, kiedy ticket jest Gotowy i czym różni się status done od licznika done." url: "https://monolynx.com/blog/statusy-ticketu-w-monolynx" lang: "pl" author: "Zespół Monolynx" published: "2026-10-09T07:15:22.522619+00:00" modified: "2026-10-09T18:11:29.078524+00:00" last_verified: "2026-10-09" tags: ["monolynx", "scrum", "ticket", "sprint"] translations: [] reading_time_minutes: 7 word_count: 1326 --- > [!TLDR] > - Ticket ma pięć statusów: Backlog, Do zrobienia, W trakcie, Review i Gotowe. W komendach i w API nazywają się `backlog`, `todo`, `in_progress`, `in_review` i `done`. > - Agent sam zmienia tylko dwa: na W trakcie przy starcie pracy i na Review po jej zakończeniu. > - Status Gotowe znaczy "zmergowane". Ustawia go kolejka merge requestów albo człowiek, nigdy agent na koniec swojej pracy. > - Licznik `done=` w linii statusu dyspozytora to co innego niż status `done`: liczy też tickety w review. > - Dyspozytor sprintu bierze tylko tickety Do zrobienia z aktywnego sprintu, których blokery są Gotowe. ## 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. **Porównanie** | 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. ```mermaid 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 ``` **Statystyki** - **5** - statusów ticketu - **2** - zmiany statusu, które agent robi sam - **1** - status, 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. **Porównanie** | 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 | > [!IMPORTANT] > Agent nigdy nie ustawia statusu Gotowe na koniec swojej pracy. Zatrzymuje się na Review, bo zmiana, której nikt nie zatwierdził i nie zmergował, nie jest gotowa. ### Skąd dyspozytor wie, który ticket wziąć? Dyspozytor `sprint-run` patrzy na trzy rzeczy naraz. Ticket musi spełniać wszystkie. **Kroki** 1. **Aktywny sprint** Ticket jest przypisany do sprintu, który wystartowałeś w panelu. 2. **Status Do zrobienia** Ticket w statusie Backlog jest pomijany, nawet gdy należy do sprintu. 3. **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](https://monolynx.com/blog/jak-dziala-monolynx-sprint-run). > [!WARNING] > Najczęstsza przyczyna "dyspozytor nic nie startuje": tickety są w sprincie, ale mają status Backlog. Komenda `ticket-create` zostawia nowy ticket w tym statusie, więc po planowaniu przestaw tickety na Do zrobienia. ## Kiedy dokładnie ticket jest Gotowy? Status Gotowe zależy od tego, dokąd trafia merge. Kolejka `mr-queue` rozróżnia dwa przypadki. **Porównanie** | 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** ```console 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ć. **Porównanie** | 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. > [!TIP] > Przed zamknięciem sprintu patrz na tablicę, a nie na linię statusu dyspozytora. Linia `done=5` może oznaczać pięć ticketów w review, z których żaden nie jest jeszcze zmergowany. ## 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. **Porównanie** | 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 **FAQ** ### 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 **Słownik** - **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](https://monolynx.com/blog/sprint-w-panelu-monolynx). Jeden ticket krok po kroku prowadzi wpis [Pierwszy ticket ręcznie](https://monolynx.com/blog/pierwszy-ticket-recznie-monolynx). Zatwierdzanie i merge opisuje wpis [Zatwierdzanie i merge: co zawsze robi człowiek](https://monolynx.com/blog/zatwierdzanie-i-merge-w-monolynx). **Wezwanie do działania** Chcesz zobaczyć tablicę, na której te statusy są kolumnami? [Zobacz moduł Scrum w Monolynx](https://monolynx.com/features/scrum)