---
title: "Praca ręczna w trakcie sprintu"
description: "Jak zrobić ticket sprintu ręcznie obok działających pętli: needs-local, poprawki po recenzji, odświeżenie brancha sprintu i zmiana wielu ticketów naraz."
url: "https://monolynx.com/blog/praca-reczna-w-sprincie-monolynx"
lang: "pl"
author: "Zespół Monolynx"
published: "2026-10-10T13:00:14.276428+00:00"
modified: "2026-10-10T13:12:55.026804+00:00"
last_verified: "2026-10-10"
tags: ["sprint", "plugin", "git"]
translations: []
reading_time_minutes: 9
word_count: 1777
---

> [!TLDR]
> - Dyspozytor uznaje za swój każdy ticket aktywnego sprintu. Ticket w statusie Backlog albo W trakcie bez sesji w tle dostaje jedno automatyczne uruchomienie.
> - Pracę ręczną nad ticketem sprintu robisz więc po odpięciu go od sprintu albo przy zatrzymanej pętli dyspozytora.
> - Ticket w statusie Review jest dla dyspozytora skończony. Poprawki po recenzji robisz na branchu ticketu, bez zmiany statusu.
> - Główny katalog repozytorium zostaje na branchu sprintu. Ręcznie pracujesz w osobnym katalogu roboczym git.
> - Branch sprintu odświeżasz z gałęzi głównej zwykłym merge, nigdy przez rebase.

## Jak dyspozytor traktuje ticket bez sesji w tle?

Dyspozytor przy każdym ticku czyta wszystkie tickety aktywnego sprintu i listę sesji w tle na komputerze, na którym działa. Twojej sesji interaktywnej na tej liście nie ma. Ticket, nad którym pracujesz ręcznie, wygląda więc dla niego jak ticket bez sesji.


**Porównanie**

| Status ticketu bez sesji w tle | Werdykt dyspozytora | Co robi dyspozytor |
| --- | --- | --- |
| Do zrobienia | `free` | startuje sesję, chyba że ticket ma niezamknięty bloker albo etykietę `needs-local` |
| Backlog, W trakcie | `needs_human` | dopisuje komentarz i raz uruchamia sesję sam; przy drugim razie zostawia ticket człowiekowi |
| Review, Gotowe | `done` | nic |


Z tej tabeli wynikają trzy zasady, na których opiera się reszta wpisu.


**Kroki**

1. **Status W trakcie bez sesji w tle oznacza dla dyspozytora awarię** Komenda `work` uruchomiona ręcznie ustawia ten status, więc następny tick wystartowałby drugą sesję nad tym samym ticketem.
2. **Status Review jest bezpieczny** Dyspozytor nie rusza ticketu, który czeka na merge.
3. **Ticket spoza sprintu jest niewidoczny** Dyspozytor czyta wyłącznie tickety przypisane do aktywnego sprintu.


> [!IMPORTANT]
> Etykieta `needs-local` chroni tylko ticket w statusie Do zrobienia: dyspozytor go nie startuje. Gdy sam zaczniesz nad nim pracę i status zmieni się na W trakcie, etykieta przestaje być sprawdzana. Dlatego sama etykieta nie wystarcza do pracy ręcznej przy działającej pętli.


**Dwie bezpieczne drogi do pracy ręcznej**

Pracę ręczną nad ticketem sprintu zaczynasz od jednej z dwóch decyzji. Albo odpinasz ticket od sprintu, albo zatrzymujesz pętlę dyspozytora. W obu przypadkach kolejka merge requestów może działać dalej.

```mermaid
flowchart TD
  A["Chcę zrobić ticket sprintu ręcznie"] --> B{"Pętla dyspozytora działa?"}
  B -- "tak, ma działać dalej" --> C["Odepnij ticket od sprintu"]
  B -- "mogę ją zatrzymać" --> D["Zatrzymaj pętlę dyspozytora"]
  C --> E["Pracuj w osobnym katalogu roboczym"]
  D --> E
  E --> F["Ticket ma status Review"]
  F --> G["Przypnij ticket do sprintu albo uruchom pętlę"]
```


## Jak zrobić ręcznie ticket z etykietą needs-local?

Ticket z tą etykietą wymaga Twojego komputera albo Twojej decyzji, więc dyspozytor go pomija i wypisuje w raporcie z poleceniem do uruchomienia. Poniższa kolejność działa przy włączonych pętlach.


**Kroki**

1. **Odepnij ticket od sprintu** W panelu wyczyść pole sprintu w edycji ticketu albo użyj CLI. Status zostaw na Do zrobienia, bo za chwilę zaczynasz pracę. Status Backlog ustawiasz tylko wtedy, gdy ticket porzucasz albo odkładasz, jak we wpisie o sytuacjach awaryjnych.
2. **Utwórz osobny katalog roboczy** Odgałęź branch ticketu od brancha sprintu. Nazwa brancha ma zawierać numer ticketu.
3. **Uruchom komendę w tym katalogu** Ustaw `MONOLYNX_MR_TARGET` na branch sprintu, żeby merge request trafił tam, gdzie pozostałe.
4. **Przypnij ticket z powrotem** Gdy komenda ustawi status Review, przypisz ticket do sprintu. Dyspozytor policzy go jako skończony, a kolejka sama przejmie merge request.



**Ticket needs-local obok działających pętli**

```console
$ monolynx --project sklep ticket update SKL-15 --sprint ""

$ git fetch origin
$ git worktree add --no-track -b SKL-15-import-cennika ../sklep-SKL-15 origin/sprint/platnosci
$ cd ../sklep-SKL-15
$ export MONOLYNX_MR_TARGET=sprint/platnosci
$ claude
> /monolynx:work SKL-15

# po statusie Review
$ monolynx --project sklep sprint list
$ monolynx --project sklep ticket update SKL-15 --sprint <id sprintu>
```


W osobnym katalogu roboczym komenda `work` bierze komendy lintu i testów z sekcji `## Worktree` strony `toolchain`, tak samo jak sesja w tle.

> [!WARNING]
> Nie przełączaj brancha w głównym katalogu repozytorium, dopóki działa dyspozytor. Nowe sesje ticketów startują z commita, na którym stoi ten katalog. Po `git switch` na branch ticketu kolejne sesje odgałęziłyby się od Twojej niedokończonej pracy.

### Druga droga: zatrzymana pętla dyspozytora

Gdy w sprincie zostały same tickety do pracy ręcznej, prościej zatrzymać pętlę dyspozytora: zamknij sesję, w której działa `/loop`. Kolejka merge requestów może działać dalej. Ticket zostaje wtedy w sprincie przez cały czas, a pętlę uruchamiasz ponownie, gdy ticket ma status Review.

## Co zrobić, gdy recenzent odrzucił merge request?

Ticket z odrzuconym merge requestem ma status Review i tak ma zostać. Zmienia się tylko branch ticketu. Sesji, która go napisała, zwykle już nie ma: dyspozytor po zebraniu wyniku usuwa sesję razem z jej katalogiem roboczym. Branch zostaje na serwerze.


**Kroki**

1. **Przenieś uwagi do ticketu** Agent nie czyta komentarzy w merge requeście. Wklej je do komentarza ticketu, żeby zostały w historii.
2. **Pobierz branch ticketu do osobnego katalogu** Sesje w tle nazywają branch `worktree-<klucz>`.
3. **Popraw** Ręcznie albo w zwykłej sesji Claude Code, której opisujesz uwagi recenzenta jednym poleceniem.
4. **Wypchnij zwykłym pushem** Bez wymuszania i bez przepisywania historii.
5. **Poczekaj na kolejkę** Nowy commit uruchamia CI od nowa, a kolejka pyta o zatwierdzenie jeszcze raz, bo zgoda dotyczyła poprzedniego commita.
6. **Usuń katalog roboczy** Po merge nie jest już potrzebny.



**Poprawki po recenzji na branchu ticketu**

```console
$ git fetch origin
$ git worktree add ../sklep-SKL-12 worktree-SKL-12
$ cd ../sklep-SKL-12

# poprawki, potem:
$ git add -A
$ git commit -m "SKL-12: uwagi z recenzji"
$ git push origin worktree-SKL-12

# po merge
$ cd ../sklep
$ git worktree remove ../sklep-SKL-12
```



**Porównanie**

| Sposób poprawki | Kiedy go wybrać | Na co uważać |
| --- | --- | --- |
| ręcznie albo w zwykłej sesji Claude Code | uwagi są drobne i konkretne | status ticketu zostaje Review |
| `/monolynx:work SKL-12` z całym zespołem agentów | uwagi zmieniają podejście | najpierw odepnij ticket od sprintu albo zatrzymaj pętlę dyspozytora; komenda zapyta, czy kontynuować ticket w statusie Review, i ustawi W trakcie |
| odpowiedź w sesji, która jeszcze istnieje | merge request odrzucono, zanim dyspozytor zebrał wynik | `claude attach <id>`; odpowiedź człowieka zdejmuje werdykt `waiting` |


> [!CAUTION]
> Nie cofaj ticketu z Review na Do zrobienia przy działającej pętli. Dyspozytor uzna go za wolny i wystartuje nową sesję od brancha sprintu, obok istniejącego merge requesta.

## Jak odświeżyć branch sprintu z gałęzi głównej?

Branch sprintu, który żyje dłużej niż kilka dni, rozjeżdża się z gałęzią główną: ktoś merguje tam poprawkę albo inną pracę. Im później to wyrównasz, tym większy konflikt w końcowym merge requeście.


**Kroki**

1. **Stań w głównym katalogu** Jest na branchu sprintu i jest czysty, bo tak pracują pętle.
2. **Wciągnij gałąź główną zwykłym merge** Konflikt rozwiązujesz tak jak każdy inny.
3. **Wypchnij** Od tej chwili nowe sesje ticketów startują z odświeżonego brancha.
4. **Zostaw otwarte merge requesty kolejce** Te, które po odświeżeniu mają konflikt, kolejka naprawi sama: wciągnie branch sprintu do brancha ticketu.



**Odświeżenie brancha sprintu**

```console
$ git branch --show-current
sprint/platnosci

$ git fetch origin
$ git merge origin/main
$ git push
```



**Porównanie**

| Kiedy odświeżać | Dlaczego |
| --- | --- |
| po każdej poprawce na gałęzi głównej, która dotyka plików sprintu | sesje ticketów od razu pracują na aktualnym kodzie |
| przed otwarciem końcowego merge requesta sprintu | konflikt rozwiązujesz u siebie, a nie w interfejsie platformy |
| raz na kilka dni w długim sprincie | mniejsze porcje zmian to mniejsze konflikty |


> [!WARNING]
> Nigdy nie rób rebase brancha sprintu. Branche ticketów i otwarte merge requesty są na nim oparte, więc przepisanie historii unieważniłoby je wszystkie. Kolejka z tego samego powodu używa wyłącznie merge.

## Jak zmienić wiele ticketów naraz?

Plan sprintu to często kilkanaście ticketów do przypisania i przestawienia na Do zrobienia. W panelu robisz to wiersz po wierszu, a w terminalu jedną komendą.


**Przypisanie do sprintu i status dla wielu ticketów**

```console
$ monolynx --project sklep sprint list
$ monolynx --project sklep ticket bulk-update SKL-12 SKL-13 SKL-14 \
    --sprint <id sprintu> --status todo
```


Komenda przyjmuje klucze albo identyfikatory ticketów, najwyżej sto w jednym wywołaniu. Statusy mają w niej nazwy techniczne: `backlog`, `todo`, `in_progress`, `in_review`, `done`. Pusty tekst w `--sprint` odpina tickety od sprintu.

Bez CLI to samo zrobi agent. Wystarczy polecenie w rozmowie, na przykład "przypisz SKL-12, SKL-13 i SKL-14 do aktywnego sprintu i ustaw im status Do zrobienia". Agent użyje jednej operacji zbiorczej zamiast trzech osobnych.

## Najczęstsze pytania


**FAQ**

### Dyspozytor już wystartował drugą sesję nad moim ticketem. Co teraz?
Zachowaj tę samą kolejność co zawsze: najpierw odepnij ticket od sprintu, potem zatrzymaj sesję. Znajdziesz ją komendą `claude agents`, a zatrzymasz przez `claude stop <id>`. Automatyczne uruchomienie zdarza się raz na ticket, więc dyspozytor nie powtórzy go, nawet gdy ticket wróci do sprintu.

### Czy kolejka merge requestów może działać, gdy dyspozytor stoi?
Tak. To dwie niezależne pętle. Kolejka prowadzi otwarte merge requesty bez względu na to, czy dyspozytor startuje nowe sesje.

### Czy mogę zamiast pracy ręcznej po prostu odpowiedzieć sesji w tle?
Tak, i to jest pierwsza rzecz do sprawdzenia. Sesja z werdyktem `waiting` czeka na odpowiedź, a `claude attach <id>` pozwala ją dać. Praca ręczna jest potrzebna dopiero wtedy, gdy ticket wymaga czegoś, czego sesja w tle nie zrobi.

### Gdzie widzę identyfikator aktywnego sprintu?
W wyniku `monolynx sprint list`: sprint aktywny ma stan `active`, a jego identyfikator stoi w polu `id`.

### Skąd bierze się etykieta needs-local?
Nadajesz ją sam, w formularzu ticketu w panelu. Jeśli projekt jej jeszcze nie ma, utwórz etykietę o dokładnie takiej nazwie na liście etykiet projektu. Komendy `ticket-create` i `ticket-review` nie nadają jej automatycznie.

### Czy muszę przypinać ticket z powrotem do sprintu?
Nie musisz, żeby merge request został zmergowany: kolejka nie patrzy na sprint. Przypięcie ma znaczenie dla tablicy, wykresu spalania i dla `sprint-end`, który podsumowuje tickety sprintu.


## Słownik i następny krok


**Słownik**

- **Praca ręczna** - praca nad ticketem w Twojej sesji interaktywnej albo bez agenta, a nie w sesji uruchomionej przez dyspozytora
- **Automatyczne uruchomienie** - jednorazowe wznowienie ticketu, który według dyspozytora utknął; w raportach nazywane auto-wznowieniem
- **Katalog roboczy git** - osobny katalog z własnym branchem tego samego repozytorium, tworzony przez `git worktree add`
- **Etykieta needs-local** - oznaczenie ticketu, którego dyspozytor nie startuje w tle
- **Odpięcie od sprintu** - wyczyszczenie pola sprintu w tickecie; ticket przestaje być widoczny dla dyspozytora


Zatrzymanie całego sprintu i sprzątanie po awarii opisuje wpis [Awaryjnie: jak zatrzymać sprint, wyjąć ticket i posprzątać](https://monolynx.com/blog/awaryjne-zatrzymanie-sprintu-monolynx). Znaczenie każdego statusu wyjaśnia wpis [Statusy ticketu w Monolynx](https://monolynx.com/blog/statusy-ticketu-w-monolynx). Zasady zatwierdzania po poprawkach zbiera wpis [Zatwierdzanie i merge: co zawsze robi człowiek](https://monolynx.com/blog/zatwierdzanie-i-merge-w-monolynx).


**Wezwanie do działania**

Chcesz zobaczyć stan sprintu na tablicy, zanim zdecydujesz, który ticket robisz sam?

[Zobacz moduł Scrum w Monolynx](https://monolynx.com/features/scrum)