---
title: "Sesje w tle: jak obserwować pętle sprintu i odpowiadać agentom"
description: "Jak uruchomić pętle sprintu, czytać linię statusu, znaleźć sesję ticketu w tle i odpowiedzieć agentowi, który czeka. Werdykty waiting i needs_human, sloty i uprawnienia."
url: "https://monolynx.com/blog/sesje-w-tle-monolynx"
lang: "pl"
author: "Zespół Monolynx"
published: "2026-10-08T08:38:20.123070+00:00"
modified: "2026-10-09T07:10:56.524237+00:00"
last_verified: "2026-10-08"
tags: ["sprint", "claude-code", "agenci-ai", "plugin", "sesje-w-tle"]
translations: []
reading_time_minutes: 10
word_count: 1996
---

> [!TLDR]
> - Sprint z agentami to dwa rodzaje sesji: dwie sesje z pętlami, które widzisz, i sesje ticketów w tle, których nie widzisz, dopóki do nich nie wejdziesz.
> - Stan czytasz z jednej linii na tick: `SPRINT-RUN: remaining=... running=... waiting=... done=...`.
> - Sesję w tle znajdziesz komendą `claude agents`, a wejdziesz do niej komendą `claude attach <id>`.
> - Reakcji wymagają dwa werdykty: `waiting` (sesja pyta albo stoi) i `needs_human` (sesja skończyła się bez wyniku).
> - Dyspozytor nigdy nie odpowiada za Ciebie i nie kasuje sesji, która czeka. Odpowiedź wpisujesz sam, a następny tick ją zauważa.

## Jak uruchomić pętle i gdzie potem patrzeć?

Pętle uruchamiasz w dwóch zwykłych sesjach Claude Code, w dwóch oknach terminala, obu otwartych w katalogu projektu. Wszystko inne startuje samo.


**Dwa okna terminala w katalogu projektu**

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

# okno 2
$ claude
> /loop 10m /monolynx:mr-queue
```



**Porównanie**

| Rodzaj sesji | Kto ją startuje | Gdzie ją widać | Ile ich jest |
| --- | --- | --- | --- |
| Sesja pętli dyspozytora | Ty | okno terminala 1 | 1 |
| Sesja pętli kolejki | Ty | okno terminala 2 | 1 |
| Sesja ticketu | dyspozytor, w tle | `claude agents`, `claude attach` | tyle, ile slotów |



**Statystyki**

- **2** - domyślna liczba równoległych sesji ticketów
- **2** - domyślny limit sesji czekających na człowieka
- **1** - linia statusu na tick, którą wystarczy czytać



**Kto startuje kogo**

Człowiek uruchamia dwie pętle. Pętla dyspozytora co kwadrans startuje sesje ticketów w tle, każdą w osobnym worktree. Sesja ticketu kończy się merge requestem, który przejmuje pętla kolejki. Sesja, która nie może iść dalej, dostaje werdykt waiting i czeka, aż człowiek do niej wejdzie i odpowie.

```mermaid
flowchart TD
  H["Człowiek"] --> L1["Pętla sprint-run"]
  H --> L2["Pętla mr-queue"]
  L1 --> S1["Sesja ticketu w tle"]
  L1 --> S2["Sesja ticketu w tle"]
  S1 --> MR["Merge request"]
  MR --> L2
  S2 --> W["Werdykt waiting"]
  W --> H
  H -- "claude attach" --> S2
```


## Jak czytać linię statusu?

Każdy tick dyspozytora kończy się raportem i jedną zamrożoną linią. Raport mówi, co się stało, linia mówi, czy masz coś do zrobienia.


**Trzy ticki tego samego sprintu**

```console
SPRINT-RUN: remaining=6 running=2 waiting=0 done=1
SPRINT-RUN: remaining=4 running=1 waiting=1 done=3
SPRINT-RUN: remaining=0 running=0 waiting=0 done=7
```



**Porównanie**

| Pole | Znaczenie | Kiedy reagować |
| --- | --- | --- |
| `remaining` | tickety sprintu, które nie mają jeszcze sesji ani wyniku | gdy od kilku ticków nie maleje |
| `running` | sesje, które żyją i pracują | nie reaguj |
| `waiting` | sesje, które żyją, ale nie posuwają pracy | zawsze, gdy większe od zera |
| `done` | tickety z zakończoną sesją i zebranym wynikiem | nie reaguj |


> [!TIP]
> Nie musisz czytać całego raportu co kwadrans. Wystarczy rzut oka na pole `waiting`. Zero oznacza, że sprint idzie bez Ciebie.

### Pięć werdyktów ticketu

Dyspozytor nie zgaduje stanu z opisu. Werdykt liczy skrypt z listy sesji, statusu ticketu i końcówki logu sesji.


**Porównanie**

| Werdykt | Co oznacza | Co robi dyspozytor | Co robisz Ty |
| --- | --- | --- | --- |
| `free` | ticket bez sesji, gotowy do startu | startuje sesję, gdy jest wolny slot | nic |
| `running` | sesja pracuje | nic, sesja zajmuje slot | nic |
| `waiting` | sesja żyje, ale stoi | zostawia ją nietkniętą i raportuje powód | wchodzisz do sesji |
| `done` | sesja zakończona, ticket ma wynik | dopisuje komentarz i sprząta sesję | nic |
| `needs_human` | sesja skończyła się bez wyniku | po jednym automatycznym wznowieniu oddaje ticket człowiekowi | sprawdzasz, co poszło źle |


## Skąd bierze się waiting?

Werdykt `waiting` ma kilka źródeł i nie każde oznacza pytanie do Ciebie. Powód jest zawsze przepisany dosłownie do raportu ticka.


**Porównanie**

| Sygnał | Jak wygląda w sesji | Czy na pewno czeka na człowieka |
| --- | --- | --- |
| Prośba o zgodę na narzędzie | sesja stoi na pytaniu o uprawnienie | tak |
| Marker `SPRINT-RUN STOP: <powód>` | sesja sama zakończyła turę i podała powód | tak |
| Pytanie na końcu odpowiedzi | ostatnia wypowiedź kończy się pytajnikiem | tak |
| Lista opcji z prośbą o decyzję | numerowane opcje i zdanie w rodzaju "wybierz" | tak |
| Fraza oczekiwania | ostatnie zdanie odpowiedzi zaczyna się od "Czekam" | niekoniecznie |
| Brak postępu | końcówka logu nie zmieniła się przez dwa kolejne ticki | niekoniecznie |


> [!NOTE]
> Sesja, która długo czeka na pipeline CI albo na pełny przebieg testów, wygląda dla skryptu tak samo jak sesja, która utknęła. Taki werdykt jest odwracalny: gdy log się zmieni, następny tick pokaże znowu `running`. Dlatego najpierw zajrzyj do sesji, a dopiero potem uznaj ją za zablokowaną.

### Marker SPRINT-RUN STOP

Sesja ticketu działa w trybie, w którym nie wolno jej czekać na odpowiedź w nieskończoność. Gdy trafia na decyzję spoza swojego kontraktu, kończy turę jedną linią z powodem.


**Przykładowe powody zatrzymania**

```console
SPRINT-RUN STOP: fast-forward do origin/sprint/platnosci odrzucony
SPRINT-RUN STOP: kolizja testów
SPRINT-RUN STOP: pełny przebieg ci bez MR
```


Linia STOP nie jest awarią. To sesja, która zamiast zgadywać, oddała decyzję człowiekowi i zachowała całą dotychczasową pracę w swoim worktree.

## Jak wejść do sesji i odpowiedzieć?

Do sesji w tle wchodzisz trzema komendami z osobnego okna terminala. Identyfikator sesji jest krótki, ma osiem znaków, i znajdziesz go w raporcie ticka oraz na liście sesji.


**Kroki**

1. **Znajdź sesję** Komenda `claude agents` wypisuje sesje w tle. Sesja ticketu ma nazwę złożoną ze sluga projektu, klucza ticketu i modelu, na przykład `sklep-SKL-12-opus`.
2. **Podejrzyj log** Komenda `claude logs <id>` pokazuje końcówkę rozmowy bez wchodzenia do sesji.
3. **Wejdź do sesji** Komenda `claude attach <id>` otwiera sesję tak, jakbyś sam ją prowadził.
4. **Odpowiedz** Wpisz decyzję zwykłym zdaniem. Sesja podejmuje pracę od miejsca, w którym stanęła.
5. **Wyjdź i zostaw** Sesja pracuje dalej w tle. Następny tick dyspozytora zobaczy Twoją odpowiedź w logu i zdejmie werdykt `waiting`.


```bash title="Terminal"
claude agents
claude logs a1b2c3d4
claude attach a1b2c3d4
```

> [!WARNING]
> Nie usuwaj sesji, która czeka. Jej worktree może zawierać pracę, której nikt jeszcze nie wypchnął. Dyspozytor sam sprząta sesje zakończone i robi to ostrożnie: gdy w worktree zostały niewypchnięte zmiany, zostawia sesję i zgłasza ją do ręcznego sprzątnięcia.

### Co zrobić z needs_human?

Werdykt `needs_human` oznacza sesję, która już nie żyje, a ticket nie ma wyniku. Dyspozytor raz próbuje ją wznowić sam. Jeśli druga próba też kończy się niczym, ticket trafia do Ciebie.


**Kroki**

1. **Przeczytaj komentarz w tickecie** Dyspozytor dopisuje tam identyfikator sesji i powód.
2. **Zajrzyj do logu** Komenda `claude logs <id>` pokaże, na czym sesja się skończyła.
3. **Zdecyduj** Popraw ticket i pozwól dyspozytorowi wystartować go ponownie, albo dokończ pracę ręcznie komendą `/monolynx:work` w zwykłej sesji.


## Sloty, limity i uprawnienia

Przepustowość sprintu zależy od dwóch liczb, a bezpieczeństwo od trybu uprawnień sesji.


**Porównanie**

| Ustawienie | Domyślnie | Co zmienia |
| --- | --- | --- |
| argument `[sloty]` albo `MONOLYNX_SPRINT_PARALLEL` | 2 | ile sesji ticketów pracuje naraz |
| `MONOLYNX_SPRINT_MAX_WAITING` | 2 | po ilu czekających sesjach dyspozytor przestaje startować nowe |
| `MONOLYNX_SPRINT_STALL_TICKS` | 2 | po ilu tickach bez zmiany logu sesja dostaje `waiting` |
| `MONOLYNX_SPRINT_PERMISSION_MODE` | `auto` | tryb uprawnień sesji ticketów |
| `MONOLYNX_SPRINT_MODEL` | `opus` | model sesji ticketów |



**Przykład: wolne sloty przy 2 slotach i różnej liczbie pracujących sesji**

| Pracujące sesje | Wolne sloty |
| --- | --- |
| 0 | 2 |
| 1 | 1 |
| 2 | 0 |


Slot zajmuje tylko sesja `running`. Sesja `waiting` slotu nie blokuje, więc jedno pytanie zadane wieczorem nie zabiera połowy przepustowości do rana. Żeby sprint nie zamienił się w kolejkę samych pytań, czekające sesje mają własny limit: po jego osiągnięciu dyspozytor wstrzymuje start nowych i pisze to w raporcie.

> [!IMPORTANT]
> Sesje w tle startują w trybie uprawnień `auto`. Tryb omijający wszystkie zgody jest odrzucany już w kontroli wstępnej, zanim powstanie jakakolwiek sesja. Zgody na lint, testy, commit i push dajesz świadomie, flagami `MONOLYNX_AUTO*` w konfiguracji projektu.


**Co hook pluginu blokuje w sesji w tle**

Sesja ticketu ma do pomocy subagentów: programistę, testera, recenzenta. Hook pluginu pilnuje, żeby żaden z nich nie zrobił czegoś poza swoją rolą.

| Operacja | Subagent | Sesja główna ticketu |
| --- | --- | --- |
| `git add`, `git commit`, `git push` | odmowa | według flag `MONOLYNX_AUTO*` |
| lint i testy | odmowa, poza lintem tylko do odczytu | według `MONOLYNX_AUTOTEST` |
| otwarcie merge requesta | odmowa | według `MONOLYNX_AUTOMR` |
| zatwierdzenie merge requesta | odmowa | zawsze pytanie do człowieka |
| usuwanie poza katalogiem projektu | odmowa | odmowa |

W sesji w tle nikt nie odpowie na pytanie hooka, więc każde pytanie zamienia się w odmowę z instrukcją: użyj wariantu, który niczego nie niszczy, albo zakończ turę linią `SPRINT-RUN STOP`.


## A jeśli nie chcę trzymać otwartych okien?

Pętlę dyspozytora może prowadzić skrypt `sprint_run.sh`, dostarczany z pluginem. Każdy tick uruchamia w świeżym procesie, więc nadaje się do tmuxa, serwera albo crona.

```bash title="Terminal, katalog projektu"
bash /pelna/sciezka/skilla/scripts/sprint_run.sh --interval 15m --slots 2
```

Pełną ścieżkę skryptu wypisuje sam dyspozytor w raporcie ticku, razem z gotowymi wierszami dla tmuxa i crona. Uruchom raz `/monolynx:sprint-run` w Claude Code i skopiuj wiersz z raportu.


**Porównanie**

| Kod wyjścia skryptu | Znaczenie |
| --- | --- |
| `0` | sprint wykonany, nic nie czeka na człowieka |
| `2` | trzy ticki pod rząd bez poprawnej linii statusu, dyspozytor nie działa |
| `3` | osiągnięto limit ticków, domyślnie 96 |
| `4` | zostały wyłącznie sesje `waiting`, do dokończenia ręcznie |


Log pętli trafia do pliku `.git/monolynx/sprint-run.log`. Skrypt domyślnie zatrzymuje się przed zamknięciem sprintu, bo merge requesty przegląda człowiek.

## Najczęstsze pytania


**FAQ**

### Czy mogę zamknąć okno terminala z pętlą?
Sesje ticketów w tle będą pracować dalej, ale nikt nie wystartuje nowych ani nie zbierze zakończonych. Pętlę możesz uruchomić ponownie w dowolnej chwili: tick jest idempotentny i nie zdubluje sesji.

### Skąd wiem, że sesja naprawdę pracuje, a nie stoi?
Z dwóch źródeł: werdykt `running` w raporcie ticka i komenda `claude logs <id>`, która pokazuje końcówkę rozmowy. Po dwóch tickach bez zmiany logu dyspozytor sam zgłosi sesję jako `waiting` z powodem "brak postępu".

### Czy dyspozytor odpowie za mnie na proste pytanie?
Nie. Sesji czekającej nie wznawia, nie kasuje i nie odpowiada za człowieka. To celowe: pytanie pojawiło się dlatego, że decyzja wykracza poza kontrakt ticketu.

### Ile to kosztuje?
Każda sesja ticketu to osobny proces z własnym modelem, domyślnie `opus`, a jej subagenci mają modele przypisane do ról. Koszt rośnie z liczbą slotów i wielkością ticketów. Model sesji zmienisz zmienną `MONOLYNX_SPRINT_MODEL`.

### Co, jeśli ta sama pętla zostanie uruchomiona dwa razy?
Dla pętli w sesji nic złego: drugi tick zobaczy żywe sesje i niczego nie zdubluje. Skrypt `sprint_run.sh` pilnuje tego sam plikiem blokady i nie wystartuje drugiej pętli dla tego samego repozytorium.


## Słownik i następny krok


**Słownik**

- **Sesja w tle** - sesja Claude Code uruchomiona bez okna terminala, do której można wejść później
- **Tick** - jedno wykonanie pętli: odczyt stanu, najwyżej jeden krok na ticket, linia statusu
- **Slot** - miejsce na jedną pracującą sesję ticketu
- **Werdykt** - stan ticketu policzony przez skrypt: `free`, `running`, `waiting`, `done` albo `needs_human`
- **Tryb uprawnień** - ustawienie Claude Code, które decyduje, o co sesja musi pytać
- **Hook** - skrypt pluginu uruchamiany przed komendą agenta, który może ją przepuścić, zablokować albo zamienić w pytanie


Ten wpis rozwija jeden etap przewodnika [Sprint z Monolynx krok po kroku](https://monolynx.com/blog/sprint-z-monolynx-krok-po-kroku). Mechanikę dyspozytora opisuje [Jak działa /monolynx:sprint-run](https://monolynx.com/blog/jak-dziala-monolynx-sprint-run), a to, co dzieje się w sesji ticketu, [Jak działa /monolynx:work](https://monolynx.com/blog/jak-dziala-monolynx-work).


**Wezwanie do działania**

Chcesz śledzić sprint także w panelu, a nie tylko w terminalu?

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