Pierwszy ticket ręcznie: od brancha do merge

Kiedy pracować ręcznie, bez sprintu?

Praca ręczna to jeden ticket w jednej sesji, w której siedzisz i odpowiadasz na pytania. To najlepszy pierwszy kontakt z pluginem: widzisz każdy krok, niczego nie musisz konfigurować poza projektem i w każdej chwili możesz przerwać.

Cecha	Praca ręczna	Sprint z pętlami
Ile ticketów	jeden naraz	wiele równolegle
Kto odpowiada agentowi	Ty, na bieżąco	Ty, gdy sesja czeka
Flagi autonomii	niepotrzebne	wymagane
Commit i push	Ty, z gotowych poleceń	agent
Kiedy wybrać	pierwszy ticket, hotfix, zadanie z decyzjami	wiele dobrze opisanych ticketów

6kroków od pomysłu do merge

0flag autonomii potrzebnych do startu

3punkty story points, do których wystarcza work-simple

82próg oceny krytyka, od którego ticket trafia do review

Jak wygląda cały obieg?

Jeden ticket ręcznie: od pomysłu do wiki

Najpierw powstaje ticket, potem jego recenzja. Komenda work sprawdza branch, a agenci piszą kod i testy. Krytyk ocenia wynik i ticket trafia do review. Ty wykonujesz commit, push i otwierasz merge request. Po zatwierdzeniu i merge ustawiasz status Gotowe, a komenda wiki-sync-merge przenosi wiedzę do wiki.

flowchart TD
  A["ticket-create"] --> B["ticket-review"]
  B --> C["work: branch i plan"]
  C --> D["Agenci: kod i testy"]
  D --> E["Krytyk: ocena"]
  E --> F["Ticket w review"]
  F --> G["Ty: commit, push, merge request"]
  G --> H["Ty: merge i status Gotowe"]
  H --> I["wiki-sync-merge"]

Załóż ticket
Komenda /monolynx:ticket-create zbiera kontekst i pokazuje gotowy opis do akceptacji.
Zrecenzuj ticket
Komenda /monolynx:ticket-review sprawdza, czy opis zgadza się z kodem i wiki.
Uruchom pracę
Komenda /monolynx:work albo /monolynx:work-simple sprawdza branch i prowadzi agentów.
Wykonaj testy, commit i push
Bez flag agent wypisuje polecenia, a Ty je uruchamiasz.
Zmerguj
Otwierasz merge request, czekasz na CI i mergujesz.
Zamknij ticket i zapisz wiedzę
Ustawiasz status Gotowe i uruchamiasz /monolynx:wiki-sync-merge.

Krok 1 i 2: ticket i recenzja

Ticket jest kontraktem dla agenta. Im dokładniej mówi, co zmienić i czego nie ruszać, tym mniej pytań w trakcie pracy.

Ticket i jego recenzja

> /monolynx:ticket-create Dodaj eksport zamówień do CSV

Ticket SKL-12 utworzony (3 SP, status: Backlog)

> /monolynx:ticket-review SKL-12

Forma: OK | Zgodność z wiki: OK | Zgodność z kodem: 1 uwaga

Nowy ticket dostaje status Backlog. W pracy ręcznej nie musisz go przestawiać na Do zrobienia ani przypisywać do sprintu: komenda work przyjmuje klucz ticketu wprost.

Szczegóły obu komend opisują wpisy Jak działa /monolynx:ticket-create i Jak działa /monolynx:ticket-review.

Krok 3: branch i praca agenta

Którą komendę wybrać?

Cecha	`work-simple`	`work`
Wielkość ticketu	do 3 story points	powyżej 3 story points
Zespół	jeden programista i krytyk	kilku agentów i krytyk
Rozpoznanie kodu	na życzenie	zawsze
Gdy ticket okazuje się większy	przekazuje go do `work`	nie dotyczy

Kto tworzy branch?

Ty, ale komenda Cię prowadzi. Agent nie pracuje bezpośrednio na branchu bazowym, czyli na tym, z którego startują inni. Gdy stoisz na branchu bazowym albo nazwa Twojego brancha nie zawiera numeru ticketu, komenda proponuje nowy branch i podaje polecenie.

Branch roboczy proponowany przez komendę work

> /monolynx:work-simple SKL-12

Jesteś na branchu main, który jest branchem bazowym.
Proponuję nowy branch z aktualnego main:

git checkout main && git pull origin main && git checkout -b feature-12-eksport-csv

Jak komenda sprawdza nazwę brancha

Domyślnie nazwa brancha musi zawierać numer ticketu jako osobną część: feature-12-eksport pasuje do ticketu SKL-12, a feature-112-eksport nie.

Zachowanie zmienia zmienna MONOLYNX_BRANCH_MODE. Wartość sprint dopuszcza dowolny branch poza bazowym, co przydaje się przy pracy nad kilkoma ticketami na jednym branchu. Wartość off wyłącza kontrolę nazwy. Zakaz pracy wprost na branchu bazowym obowiązuje zawsze.

Co robi agent?

Po ustaleniu brancha sesja staje się koordynatorem. Czyta ticket, pokazuje plan i listę decyzji, przed którymi się zatrzyma, a potem zleca pracę agentom. Ticket przechodzi wtedy na status W trakcie.

Krok 4: testy, commit i push

Bez flag autonomii agent niczego nie uruchamia i niczego nie zapisuje w gicie. Wypisuje polecenia i czeka.

Moment	Co robi agent	Co robisz Ty
Lint i testy	wypisuje polecenia ze strony `toolchain`	uruchamiasz je i wklejasz wynik
Czerwone testy	poprawia kod	uruchamiasz ponownie
Ocena krytyka	poprawia uwagi poniżej progu	czytasz ocenę
Commit	wypisuje gotowe polecenie z opisem	uruchamiasz je
Push i merge request	nic	robisz to sam

.claude/settings.json: praca ręczna z automatycznymi testami

{
  "env": {
    "MONOLYNX_PROJECT_SLUG": "sklep",
    "MONOLYNX_AUTOTEST": "true"
  }
}

Gdy lint i testy są zielone, a krytyk wystawi co najmniej 82 punkty na 100, ticket dostaje status Review. Na tickecie zostają komentarze: plan, raporty agentów i ocena.

Koniec pracy agenta i Twoje polecenia

Ticket SKL-12: status Review, ocena krytyka 91/100

Do wykonania:
git add src/eksport.py tests/test_eksport.py
git commit -m "SKL-12: eksport zamówień do CSV"

$ git push -u origin feature-12-eksport-csv

Krok 5 i 6: merge, status i wiki

Merge request otwierasz tak jak zawsze: w interfejsie GitLaba albo GitHuba, albo poleceniem glab mr create lub gh pr create. Czekasz na zielone CI, ktoś zatwierdza zmianę i mergujesz.

Po merge zostają dwie czynności.

Ustaw status Gotowe
Zmień status na liście backlogu albo poproś agenta. Tablica pokazuje tylko aktywny sprint, więc kartę przeciągniesz na niej dopiero w sprincie. Agent nie robi tego sam, bo "gotowe" znaczy "zmergowane".
Przenieś wiedzę do wiki
Przełącz się na branch główny, pobierz zmiany i uruchom /monolynx:wiki-sync-merge SKL-12.

Co zrobić, gdy coś przerwie pracę?

Sytuacja	Co zrobić
Zamknąłeś sesję w połowie	`/monolynx:resume SKL-12` odtwarza stan z ticketu, komentarzy i gita
Nie wiesz, co dalej	`/monolynx:next` czyta stan i poleca następną komendę
Mały ticket urósł	`work-simple` sam przekazuje go do `work`
Chcesz zmienić zakres	powiedz to koordynatorowi przed akceptacją planu
Agent pyta o decyzję	odpowiedz w tej samej sesji; praca rusza dalej

Najczęstsze pytania

Czy muszę mieć aktywny sprint, żeby uruchomić work?

Nie. Komenda przyjmuje klucz ticketu i nie wymaga, żeby ticket należał do sprintu.

Czy agent może sam zrobić commit i push?

Tak, po Twojej zgodzie wyrażonej flagami MONOLYNX_AUTOCOMMIT i MONOLYNX_AUTOPUSH. Domyślnie obie są wyłączone.

Co się stanie, gdy krytyk oceni pracę poniżej progu?

Uwagi wracają do agenta, który je poprawia. Liczba rund poprawek jest ograniczona. Po jej wyczerpaniu koordynator pokazuje Ci stan i pyta, co dalej.

Czy mogę pracować na branchu, który już mam?

Tak, jeśli nie jest branchem bazowym. Gdy jego nazwa nie zawiera numeru ticketu, komenda zapyta, czy mimo to kontynuować.

Kiedy przejść z pracy ręcznej na sprint?

Gdy masz kilka dobrze opisanych ticketów, które nie wymagają Twoich decyzji w trakcie. Wtedy pętle robią to, co tutaj robisz ręcznie.

Słownik i następny krok

Branch bazowy: branch, z którego powstają branche robocze, zwykle główny branch repozytorium
Branch roboczy: branch jednego ticketu, na którym agent zapisuje zmiany
Koordynator: sesja prowadząca ticket: planuje, zleca pracę agentom i pilnuje jakości
Krytyk: agent oceniający wynik pracy w skali do 100 punktów
Kontrakt autonomii: lista decyzji, przed którymi agent zatrzyma się i zapyta
Flagi autonomii: zmienne, którymi dajesz agentowi zgodę na testy, commit, push i merge request

Co znaczy każdy status i kto go zmienia, opisuje wpis Statusy ticketu w Monolynx. Zatwierdzanie i merge, także z kolejką, opisuje wpis Zatwierdzanie i merge: co zawsze robi człowiek. Pełny opis komendy znajdziesz we wpisie Jak działa /monolynx:work.

Chcesz zobaczyć, gdzie trafia ticket i jego komentarze po pracy agenta?

Zobacz moduł Scrum w Monolynx