Test dymny przed pierwszym sprintem

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.

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.

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.

> /monolynx:setup

| Punkt | Stan |
| 1. Slug projektu | OK (sklep, źródło: środowisko) |
| 2. Strona wiki toolchain | OK |
| ...

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.

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ą.

$ 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"}

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.

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ą.

$ 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.

Jak uruchomić jeden ticket na jednym slocie?

Dyspozytor czyta wszystkie tickety aktywnego sprintu, dlatego na czas testu w sprincie ma być tylko jeden.

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.

> /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

$ 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.

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.

> /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.

Sytuacje spoza tabeli opisuje wpis Gdy coś nie działa 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.

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.

Najczęstsze pytania

Słownik i następny krok

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. Pracę ręczną nad ticketem przy działających pętlach opisuje wpis Praca ręczna w trakcie sprintu.