Jak działa /monolynx:sprint-run: dyspozytor, który przerabia sprint sesjami w tle

Po co dyspozytor, skoro ticket można uruchomić ręcznie?

Jeden ticket uruchamia się jedną komendą. Sprint z dziesięcioma ticketami to już pilnowanie: który jest wolny, który czeka na merge innego, która sesja skończyła, a która stanęła na pytaniu. Dyspozytor przejmuje to pilnowanie i nic poza nim.

Skill sprint-run jest celowo cienki. Nie czyta kodu, nie edytuje plików, nie commituje. Jego praca to start sesji roboczych i księgowość wokół nich.

# zalecane: pętla co 15 minut
/loop 15m /monolynx:sprint-run

# jeden tick ręcznie
/monolynx:sprint-run

# jeden tick z trzema równoległymi sesjami
/monolynx:sprint-run 3

Dlaczego zalecamy pętlę co 15 minut?

Jedno uruchomienie skilla to jeden tick. Sesja startuje w jednym ticku, a jej wynik zbiera dopiero któryś z następnych, bo dyspozytor po starcie nie czeka i nie zagląda do logu. Pętla jest więc częścią projektu, tylko trzymaną poza skillem.

/loop 15m /monolynx:sprint-run

Piętnaście minut pasuje do tempa, w jakim zmienia się stan sprintu. Praca nad ticketem trwa znacznie dłużej niż jeden interwał, więc częstsze ticki widziałyby głównie to samo: sesje nadal pracują. Rzadsze zostawiałyby wolny slot pusty po zakończonej sesji i odkładały raport o sesji, która czeka na człowieka.

Dyspozytor dobrze pracuje w parze z drugą pętlą. Sesje robocze kończą się merge requestem, a te przeprowadza do brancha docelowego mr-queue, kolejka merge uruchamiana co 10 minut. Po merge blokera następny tick dyspozytora sam startuje ticket, który na niego czekał.

Co dzieje się w jednym ticku?

1. Kontrola wstępna

   Skrypt sprawdza klienta, repozytorium, slug projektu i flagi autonomii. Bez kompletu tick nie startuje żadnej sesji.

2. Stan sprintu

   Skill pobiera aktywny sprint i jego tickety.

3. Stan sesji

   Skrypt zestawia tickety z żywymi sesjami w tle i z ogonami ich logów, po czym liczy werdykt dla każdego ticketu.

4. Zbiór

   Zakończone sesje dostają komentarz i są sprzątane, padnięte dostają jedno wznowienie, czekające trafiają do raportu.

5. Dispatch

   Wolne sloty obsadzają tickety w kolejności priorytetu, z pominięciem zablokowanych.

6. Raport i linia statusu

   Tabela ticketów, sekcja "Czekają na człowieka" i jedna zamrożona linia dla pętli.

flowchart TD
  A["Kontrola wstępna"] --> B[Aktywny sprint i tickety]
  B --> C[Sesje w tle i ogony logów]
  C --> D{Werdykt ticketu}
  D -->|done| E[Komentarz i sprzątnięcie sesji]
  D -->|needs_human| F[Ogon logu do komentarza, jedno wznowienie]
  D -->|waiting| G[Raport: czeka na człowieka]
  D -->|running| H[Bez zmian]
  D -->|free| I{Bloker albo needs-local?}
  I -->|tak| J[Pominięty, zostaje w kolejce]
  I -->|nie| K[Start sesji work w worktree]
  E --> L[Raport i linia statusu]
  F --> L
  G --> L
  H --> L
  J --> L
  K --> L

Jakie werdykty liczy skrypt?

Werdykt daje skrypt z listy sesji, statusów ticketów i ogonów logów. Model nie ocenia stanu sesji z prozy.

Skąd dyspozytor wie, że sesja czeka na człowieka?

Sesja waiting nie zajmuje slotu, więc jedno pytanie nie blokuje połowy przepustowości na całą noc. Ma za to własny limit: gdy czeka zbyt wiele sesji naraz (domyślnie dwie), tick przestaje startować nowe, zamiast mnożyć worktree czekające na odpowiedź.

Które tickety startują, a które czekają?

Kandydatami są tylko tickety z werdyktem free. Kolejność jest deterministyczna: priorytet malejąco, a przy równym priorytecie rosnąco po kluczu. Dwa ticki pod rząd wybierają to samo.

Pominięty ticket nie dostaje komentarza, bo pominięcie powtarza się w każdym ticku. Ślad jest w raporcie, z powodem w rodzaju "czeka na merge MON-166". Po zamknięciu blokera następny tick startuje ticket bez niczyjej interwencji.

Jak wygląda start sesji?

Sesja robocza dostaje nazwę z projektu, klucza ticketu i modelu, na przykład monolynx-MON-167-opus, oraz worktree nazwany kluczem ticketu. Model jest podany jawnie, bo sesja bez niego wzięłaby domyślny model konta, który bywa najdroższy. Po starcie tick dopisuje do ticketu komentarz z identyfikatorem sesji. To jedyny trwały ślad, po którym człowiek trafi do właściwej sesji następnego dnia.

Co dostaję po każdym ticku?

Raport ma tabelę ticketów z werdyktem i działaniem, sekcję "Czekają na człowieka" z powodem i komendą dla każdej pozycji oraz jedną linię statusu na samym końcu:

SPRINT-RUN: remaining=3 running=2 waiting=0 done=1

Linia jest kontraktem dla pętli: remaining=0 i running=0 oznacza, że sprint jest przerobiony.

Gdy linia pokaże zero pozostałych, przychodzi pora na sprint-end, który zamyka sprint i aktualizuje wiki.

Najczęstsze pytania

Słownik i następny krok

Tick

jedno uruchomienie dyspozytora: odczyt stanu, start i zbiór sesji, raport

Slot

miejsce na jedną pracującą sesję roboczą

Worktree

osobny katalog roboczy gita dla jednego ticketu

Werdykt

stan ticketu policzony przez skrypt z sesji, statusu i ogona logu

Marker STOP

linia, którą sesja w tle kończy turę, gdy potrzebuje człowieka

needs-local

etykieta ticketu, którego nie wolno uruchamiać w tle

Dispatch

obsadzenie wolnych slotów nowymi sesjami