MCP + SKILLS: GRUPOWY VIBECODING W JEDNYM REPO

Rój równoległych agentów potrzebował wspólnego stanu, ale każdy pisał do niego ze swojej sesji — przy nieudanym git pull stan potrafił się rozjechać i agenci pracowali na różnych wersjach architektury. Zamiast wymyślać własny protokół synchronizacji, oparłem sync o git z cooldownem 3 sekund przeciw spamowi commitów i retry po stronie klienta, a serwer „brain” zrobiłem jedynym źródłem prawdy: każdy agent zaczyna od get_all, zanim czegokolwiek dotknie. Cała klasa konfliktów zniknęła, bo nikt nie pracuje na przeterminowanym stanie.

Nocna pętla działa na kilku komputerach naraz, każdy nad swoim modułem — a nie ma żadnego serwera koordynującego, backendu ani kolejki. Kto i kiedy odpala merge? Jak nie zrobić go dwa razy? Co, gdy jeden PC nie skończy do rana? Całą koordynację zbudowałem na prymitywach, które zespół i tak ma, czyli na plikach w gicie: każdy PC po skończeniu pisze marker done/<moduł>.json i pushuje; koordynatora wybiera zasada „ostatni gasi światło” — kto policzy komplet markerów albo doczeka timeoutu pobudki, ten merguje; przed podwójnym merge chroni plik merge.lock commitowany do repo, a przy timeoucie merger scala tylko moduły z markerem, jawnie odnotowując urwane w SUMMARY.md zamiast wciągać potencjalnie zepsute gałęzie. Uczciwie: lock przez git to best-effort mutex, nie sekcja krytyczna — przy 2–5 komputerach wyścig kończy się co najwyżej odrzuconym pushem, i ten kompromis świadomie przyjąłem.

Każdy researcher startował z pełnym kontekstem hackathonu, więc koszt tokenów rósł liniowo z liczbą modułów — a w transkryptach i treściach z weba czaiło się ryzyko prompt injection. Przyciąłem konteksty: skill podaje researcherowi tylko 3–5 pól jego modułu, a narzędzie get_all zwraca kompaktowe podsumowanie ~1K tokenów zamiast pełnego JSON-a stanu. Samego agenta zahartowałem — ignoruje instrukcje osadzone w treści, trzyma się whitelisty źródeł (Context7 > GitHub > Playwright) i niczego z weba nie wykonuje.

Pętla nocna trzyma zmianę tylko wtedy, gdy nie psuje testów — ale testy generuję ze specyfikacji, zanim powstanie kod. Naiwnie: pierwszej nocy baseline jest w 100% czerwony, więc każda zmiana wygląda na „bez regresji” i pętla trzyma śmieci, a import nieistniejącego modułu potrafi wysadzić cały przebieg. Rozbroiłem to dwoma sprzężonymi mechanizmami: testy w trybie spec-only zaczynają się blokiem auto-aktywacji, który pinguje pierwszy endpoint modułu i przełącza it na it.skip, dopóki moduł nie żyje — baseline to 0 porażek, a testy same się włączają, gdy endpoint zaczyna odpowiadać; do tego bramka liczy regresję, nie porażkę: przed pętlą zapisuję listę już-czerwonych testów i odrzucam eksperyment tylko wtedy, gdy test wcześniej zielony robi się czerwony. Trzecia reguła jest twarda: pętla nie tyka niczego wizualnego, bo w nocy nikt nie robi screenshotów — logika, typy i testy only.