--- title: "Test dymny przed pierwszym sprintem" description: "Trzy kontrole i jeden ticket na jednym slocie: jak sprawdzić połączenie, strażnika komend i zgody, zanim włączysz pętle sprintu w Monolynx." url: "https://monolynx.com/blog/test-dymny-przed-sprintem-monolynx" lang: "pl" author: "Zespół Monolynx" published: "2026-10-10T13:00:12.031982+00:00" modified: "2026-10-10T13:12:53.635273+00:00" last_verified: "2026-10-10" tags: ["sprint", "plugin", "konfiguracja"] translations: [] reading_time_minutes: 11 word_count: 2141 --- > [!TLDR] > - Test dymny to jeden mały ticket puszczony na jednym slocie, tickami uruchamianymi ręcznie, zanim włączysz pętle na cały sprint. > - Najpierw trzy kontrole bez sesji w tle: czy komenda widzi projekt, czy działa strażnik komend i czy zgody dotrą do sesji ticketu. > - Potem dyspozytor i kolejka po jednym ticku naraz. Każdy krok ma oczekiwany wynik. > - Inny wynik niż oczekiwany wskazuje konkretną przyczynę. Tabela objawów jest na końcu wpisu. > - Po teście znasz czas i zużycie modelu dla jednego ticketu, więc możesz oszacować cały sprint. ## Po co test dymny przed pierwszym sprintem? Sprint z pętlami łączy kilka mechanizmów: połączenie z platformą, strażnika komend, zgody w pliku ustawień, stronę `toolchain`, branch sprintu i narzędzie `glab` albo `gh`. Błąd w jednym z nich przy dziesięciu ticketach wychodzi w dziesięciu sesjach naraz. Test dymny pokazuje go na jednym tickecie, w kilkanaście minut. **Statystyki** - **3** - kontrole przed uruchomieniem czegokolwiek w tle - **1** - ticket i jeden slot w teście - **0** - pętli: każdy tick uruchamiasz sam **Kolejność testu dymnego** Test idzie od rzeczy najtańszych do najdroższych. Trzy kontrole nie uruchamiają żadnej sesji w tle. Dopiero po nich dyspozytor startuje jedną sesję ticketu, a kolejka prowadzi jeden merge request. ```mermaid flowchart LR A["Kontrola 1: projekt"] --> B["Kontrola 2: strażnik komend"] B --> C["Kontrola 3: zgody w repozytorium"] C --> D["Jeden tick dyspozytora"] D --> E["Sesja ticketu kończy pracę"] E --> F["Jeden tick kolejki"] F --> G["Ticket Gotowy"] ``` Test zakłada, że projekt przeszedł jednorazową konfigurację, a jeden ticket zrobiłeś już ręcznie. Jeśli nie, zacznij od wpisu [Zacznij tutaj: czym jest Monolynx i czego potrzebujesz](https://monolynx.com/blog/zacznij-tutaj-monolynx). ## Kontrola 1: czy komenda widzi Twój projekt? Komendy pluginu znajdują projekt po slugu. Slug biorą ze zmiennej `MONOLYNX_PROJECT_SLUG`, potem z konfiguracji klienta albo z pliku `.env` projektu. Gdy nie ma go nigdzie, komenda nie zgaduje, tylko pyta o slug i zatrzymuje pracę. W sesji w tle nikt na to pytanie nie odpowie, dlatego slug musi być zapisany, zanim uruchomisz dyspozytora. **Raport setup: slug i połączenie** ```console > /monolynx:setup | Punkt | Stan | | 1. Slug projektu | OK (sklep, źródło: środowisko) | | 2. Strona wiki toolchain | OK | | ... ``` **Porównanie** | Objaw | Przyczyna | Co zrobić | | --- | --- | --- | | komenda pyta o slug | slug nie jest nigdzie zapisany | ustaw `MONOLYNX_PROJECT_SLUG` w polu `env` śledzonego `.claude/settings.json` | | komenda zgłasza, że projekt nie istnieje albo nie jesteś jego członkiem | slug z literówką albo z innego projektu | ustaw `MONOLYNX_PROJECT_SLUG` na slug z adresu panelu, czyli z `/dashboard//` | | agent nie ma narzędzi Monolynx albo prosi o logowanie | połączenie MCP nie jest zalogowane | w Claude Code otwórz `/mcp` i zaloguj połączenie `monolynx` | | odpowiedź `Brak uprawnienia scrum:write` | Twoja rola w projekcie tylko czyta | właściciel zmienia rolę w ustawieniach projektu, w sekcji członków | | linia `TRANSPORT: mode=mcp ... auth=missing` | CLI `monolynx` jest zainstalowane, ale niezalogowane | to nie błąd, komendy idą przez MCP; `monolynx auth login` włączy szybszy kanał | > [!NOTE] > Linia `TRANSPORT:` pojawia się na starcie komendy, w wyniku skryptu, który wybiera kanał. Wartość `mode=cli` oznacza pracę przez CLI, `mode=mcp` przez serwer MCP. Oba kanały prowadzą do tych samych danych, więc żaden nie jest błędem. ## Kontrola 2: czy strażnik komend działa? Strażnik komend to hook pluginu, który przed każdym poleceniem powłoki odmawia agentom pomocniczym zapisu w git i testów, a sesję główną pyta o zgodę. Sama instalacja pluginu go nie włącza: klient musi go załadować, a Ty musisz nadać zaufanie. Bez strażnika zgody pilnuje tylko rozmowa z agentem. Strażnik zostawia ślad po każdym poleceniu, które sprawdził. Ten ślad jest najprostszym dowodem, że działa. **Kroki** 1. **Otwórz sesję w repozytorium** Uruchom `claude` w katalogu projektu. Przy pierwszym uruchomieniu klient pyta o zaufanie do katalogu. 2. **Wywołaj komendę, która czyta repozytorium** Na przykład `/monolynx:next`. Uruchamia ona kilka poleceń git, a każde przechodzi przez strażnika. 3. **Sprawdź ślad w drugim terminalu** Katalog `~/.cache/monolynx/hook-active/` powinien zawierać plik z bieżącą godziną. **Ślad strażnika komend** ```console $ ls -lt ~/.cache/monolynx/hook-active/ -rw-r--r-- 1 ty staff 78 10 paź 09:14 3f6c1a2e-... $ cat ~/.cache/monolynx/hook-active/3f6c1a2e-... {"subagent_identification": false, "checked_at": "2026-10-10T09:14:02"} ``` **Porównanie** | Stan | Co widać | Co to znaczy | | --- | --- | --- | | potwierdzona | plik ze znacznikiem `"subagent_identification": true` | strażnik działa i rozpoznał już agenta pomocniczego; twarde odmowy są pewne | | niepełna | plik jest, ale ze znacznikiem `false` | strażnik działa, ale w tej sesji żaden agent pomocniczy nie uruchomił jeszcze polecenia; to normalny stan w tej kontroli i na starcie każdej komendy | | brak potwierdzenia | brak pliku po pierwszym poleceniu | strażnik nie jest załadowany albo nie ma zaufania | Komendy `work`, `work-simple` i `mr-queue` czytają ten sam ślad dwa razy: na starcie i po pracy agentów pomocniczych. Stan końcowy wpisują do podsumowania. Sesja w tle, której stan końcowy nie jest "potwierdzona", nie udaje blokady. W chwili, gdy potrzebna byłaby zgoda, kończy turę linią `SPRINT-RUN STOP: brak potwierdzonej ochrony hooka`. > [!WARNING] > Gdy pliku nie ma, sprawdź po kolei: czy plugin jest włączony na liście `/plugin`, czy lista `/hooks` pokazuje hook pluginu przed poleceniem powłoki i czy `python3 --version` działa w tym terminalu. Po nadaniu zaufania otwórz sesję od nowa. ## Kontrola 3: czy zgody dotrą do sesji ticketu? Sesja ticketu pracuje w osobnym katalogu roboczym. Katalog ten zawiera tylko pliki śledzone przez git, w wersji z commita, na którym stoi główny katalog repozytorium. Stąd dwie zasady, które sprawdzasz jedną komendą. **Porównanie** | Co ustawiasz | Wspierane miejsce | Dlaczego tam | | --- | --- | --- | | zgody `MONOLYNX_AUTOTEST`, `MONOLYNX_AUTOCOMMIT`, `MONOLYNX_AUTOPUSH`, `MONOLYNX_AUTOMR` | śledzony `.claude/settings.json` albo środowisko procesu, który uruchamia tick | mają obowiązywać każdą sesję w każdym katalogu roboczym; kontrola wstępna dyspozytora szuka ich tylko tam | | branch sprintu `MONOLYNX_MR_TARGET` | `export` w terminalu albo `.claude/settings.local.json` | to ustawienie tymczasowe; w pliku śledzonym trafiłoby na gałąź główną | **Sprawdzenie przed startem dyspozytora** ```console $ git branch --show-current sprint/platnosci $ git status --short $ git show HEAD:.claude/settings.json { "env": { "MONOLYNX_AUTOTEST": "true", "MONOLYNX_AUTOCOMMIT": "true", "MONOLYNX_AUTOPUSH": "true", "MONOLYNX_AUTOMR": "true" } } $ echo $MONOLYNX_MR_TARGET sprint/platnosci ``` Trzy rzeczy muszą się zgadzać. Stoisz na branchu sprintu. Katalog jest czysty, czyli `git status --short` nic nie wypisuje. Commit, na którym stoisz, zawiera plik ustawień ze zgodami. > [!IMPORTANT] > Commit ze zgodami musi być na branchu, z którego startuje dyspozytor. Najprościej dodać go na gałęzi głównej przed odgałęzieniem brancha sprintu. Jeśli branch sprintu powstał wcześniej, dodaj commit bezpośrednio na nim. ## Jak uruchomić jeden ticket na jednym slocie? Dyspozytor czyta wszystkie tickety aktywnego sprintu, dlatego na czas testu w sprincie ma być tylko jeden. **Kroki** 1. **Wybierz mały ticket** Jeden lub dwa story pointy, bez migracji bazy i bez etykiety `needs-local`. 2. **Zostaw resztę poza sprintem** Do aktywnego sprintu przypisz tylko ten ticket i ustaw mu status Do zrobienia. Pozostałe dopiszesz po teście. 3. **Uruchom jeden tick z jednym slotem** Liczba po nazwie komendy to liczba slotów. 4. **Sprawdź sesję** Komenda `claude agents` pokazuje ją z nazwą złożoną ze sluga, klucza ticketu i modelu. **Jeden tick dyspozytora, jeden slot** ```console > /monolynx:sprint-run 1 | Ticket | Sesja | Werdykt | Działanie | | SKL-12 | a1b2c3d4 | free -> running | start sesji | SPRINT-RUN: remaining=0 running=1 waiting=0 done=0 ``` **Kontrola sesji ticketu** ```console $ claude agents sklep-SKL-12-opus a1b2c3d4 running $ git worktree list /home/ty/sklep 4f2a9c1e [sprint/platnosci] /home/ty/sklep/.claude/worktrees/SKL-12 4f2a9c1e [worktree-SKL-12] $ claude logs a1b2c3d4 ... BRANCH_MODE=ticket AUTOTEST=true AUTOCOMMIT=true AUTOPUSH=true CONTRACT=ask SPRINT_RUN=1 AUTOMR=true ... ``` Linia konfiguracji na początku logu jest drugim dowodem z kontroli 3. Wartości `true` przy czterech zgodach i `SPRINT_RUN=1` znaczą, że sesja widzi to, co ustawiłeś. Wartość `false` przy którejkolwiek zgodzie oznacza, że commit z plikiem ustawień nie jest na branchu sprintu. > [!NOTE] > Ścieżka katalogu roboczego w przykładzie jest poglądowa. Rzeczywistą pokazuje `git worktree list`. Nazwa brancha ticketu ma zawsze postać `worktree-`. ### Jak doprowadzić ticket do końca? Bez pętli tick uruchamiasz sam, co kilka minut. Każdy tick kończy się jedną z trzech sytuacji. **Porównanie** | Ostatnia linia | Co się dzieje | Co robisz | | --- | --- | --- | | `running=1` | sesja pracuje | czekasz i ponawiasz tick | | `waiting=1` | sesja pyta albo stoi | wchodzisz przez `claude attach ` i odpowiadasz | | `done=1` | sesja skończyła, ticket ma status Review | przechodzisz do kolejki | **Jeden tick kolejki i zatwierdzenie** ```console > /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 ``` Drugi tick kolejki merguje merge request i ustawia ticket jako Gotowy. Gdy CI jeszcze biegnie, kolejka czeka: ponów tick po zakończeniu pipeline'u. ## Co oznacza inny wynik niż oczekiwany? Każde odstępstwo w teście ma jedną najczęstszą przyczynę. Tabela prowadzi od objawu do poprawki. **Porównanie** | Objaw | Przyczyna | Poprawka | | --- | --- | --- | | tick kończy się przed startem sesji komunikatem o brakujących flagach | zgód nie ma w pliku śledzonym ani w środowisku | kontrola 3 | | sesja kończy turę linią `SPRINT-RUN STOP` o lincie albo testach | brak strony `toolchain` albo jej sekcji `## Worktree` | `/monolynx:project-toolchain` | | linia konfiguracji w logu pokazuje `AUTOTEST=false` | commit ze zgodami nie jest na branchu sprintu | dodaj commit na branchu sprintu i wypchnij | | sesja od razu ma werdykt `waiting` z pytaniem o zgodę | tryb `auto` odrzucił polecenie albo strażnik nie jest potwierdzony | `claude attach `, przeczytaj powód, wróć do kontroli 2 | | merge request celuje w gałąź główną zamiast w branch sprintu | zmienna `MONOLYNX_MR_TARGET` nie była ustawiona w terminalu dyspozytora | ustaw zmienną, zmień cel merge requesta na platformie | | komentarz ticketu mówi, że merge request nie powstał | brak `glab`, niezalogowany `glab` albo repozytorium na GitHubie | otwórz merge request albo pull request sam | | kolejka daje werdykt `needs_human` z prośbą o uruchomienie CI | merge request nie ma pipeline'u | uruchom CI na branchu albo zmerguj sam | | `remaining` większe od zera i nic nie biegnie | ticket ma niezamknięty bloker albo etykietę `needs-local` | zdejmij bloker albo zrób ticket ręcznie | Sytuacje spoza tabeli opisuje wpis [Gdy coś nie działa w Monolynx](https://monolynx.com/blog/gdy-cos-nie-dziala-w-monolynx). ## Ile kosztował jeden ticket? Test dymny daje pierwszy własny pomiar. Wpisy nie podają kwot, bo zależą od planu, modelu i wielkości ticketu, ale sposób pomiaru jest zawsze ten sam. **Kroki** 1. **Zapisz zużycie przed testem** W Claude Code komenda `/usage` pokazuje, ile limitu planu zostało wykorzystane. 2. **Zrób test** Jeden ticket, od ticku dyspozytora do statusu Gotowe. 3. **Zapisz zużycie po teście** Różnica to koszt jednego ticketu razem z tickami dyspozytora i kolejki. 4. **Odczytaj czas** Moduł Pipelines w panelu pokazuje czas każdego etapu: `research`, `coding` i `wrap-up`. 5. **Przemnóż** Liczba ticketów razy koszt jednego daje górne oszacowanie sprintu. Czas całości dziel przez liczbę slotów i dodaj czas CI. > [!TIP] > Dwa ustawienia zmieniają koszt najbardziej. Liczba slotów decyduje, ile sesji pracuje naraz, a zmienna `MONOLYNX_SPRINT_MODEL` wybiera model sesji ticketu. Jeden ticket zmierzony przed sprintem i po zmianie modelu pokazuje różnicę wprost. ## Najczęstsze pytania **FAQ** ### Czy test dymny trzeba powtarzać przed każdym sprintem? Nie. Powtórz go po zmianie komputera, po aktualizacji klienta albo pluginu i po zmianie strony `toolchain`. Przed zwykłym kolejnym sprintem wystarczy kontrola 3. ### Czy mogę zrobić test bez brancha sprintu? Tak. Bez zmiennej `MONOLYNX_MR_TARGET` merge request trafia do domyślnego brancha repozytorium. Test jest wtedy prostszy, ale nie sprawdza ustawienia, którego użyjesz w sprincie. ### Co zrobić z ticketem testowym po teście? Nic. To zwykły ticket sprintu ze statusem Gotowe. Dopisz do sprintu pozostałe tickety, ustaw im status Do zrobienia i uruchom pętle. ### Czy test działa w Codex? Kontrole 1 i 3 są takie same. Ślad strażnika komend powstaje także w Codex, ale ten klient nie przekazuje informacji o agencie pomocniczym, więc stan zostaje "niepełna". Sesję ticketu uruchamia tam skrypt `sprint_run.sh` ze zmienną `MONOLYNX_SPRINT_RUNTIME=codex`. ## Słownik i następny krok **Słownik** - **Test dymny** - krótki przebieg całej ścieżki na jednym tickecie, który sprawdza, czy wszystkie elementy są połączone - **Strażnik komend** - hook pluginu sprawdzający każde polecenie powłoki agenta - **Ślad strażnika** - plik w katalogu `~/.cache/monolynx/hook-active/`, zapisywany po każdym sprawdzonym poleceniu - **Slot** - miejsce na jedną równoległą sesję ticketu - **Tick** - jedno uruchomienie komendy dyspozytora albo kolejki - **Linia konfiguracji** - pierwsza linia logu sesji ticketu z wartościami zgód, które sesja widzi Test przeszedł, więc pora na pełny sprint. Kroki w jednej liście podaje wpis [Sprint od zera: lista kontrolna i tabela zgodności](https://monolynx.com/blog/sprint-lista-kontrolna-monolynx). Pracę ręczną nad ticketem przy działających pętlach opisuje wpis [Praca ręczna w trakcie sprintu](https://monolynx.com/blog/praca-reczna-w-sprincie-monolynx). **Wezwanie do działania** Chcesz zobaczyć czas każdego etapu pracy agentów nad ticketem? [Zobacz moduł Pipelines w Monolynx](https://monolynx.com/features/pipelines)