Wniosek: zamrozić V5, ale nie ogłaszać gotowości V6

Proponowany kierunek dla BMRalph V6 to: orkiestrator bmad-loop, jeden framework wykonawczy Cline, zewnętrzne kontrole i niewielki plik z doświadczeniami z poprzednich zadań. Nie ma tu miejsca na drugi, równoległy system sterowania agentami.

To jednak plan architektury, a nie potwierdzenie, że system już działa. Nadal brakuje dowodów, że Cline da się podłączyć do cyklu życia bmad-loop, że audyt będzie rzeczywiście niezależny, że bramka Jev zadziała w praktyce i że VPS wykona kolejne kroki po rozłączeniu lokalnego IDE.

Raport opiera się na wskazanych plikach i historycznych wynikach. Nie zmieniano w nim planu, kodu ani testów; nie uruchamiano też modeli, instalacji, commitów ani próbnego przepływu na VPS.

Co wynika z analizy V5

Rozbudowany magazyn nie jest tym samym co działający proces

W sprawdzonym pliku bmad_control_store.py jest 315 linii kodu, a nie 1728. To dopisywany do pliku magazyn rekordów, nie baza SQL. Dla wersji liczącej 1728 linii ani odpowiadającego jej commitu nie przedstawiono dowodu.

Moduł pilnuje m.in. tożsamości katalogów, uprawnień plików i blokad, wersji żądań, ciągłości historii, limitu danych, odczytu po zapisie i odcisku treści. Jednocześnie jego wynik nie uwierzytelnia człowieka, nie przyznaje prawa do wykonania zadania, nie uruchamia go ani nie zapisuje postępu.

Problem nie polega więc na tym, że każda kontrola bezpieczeństwa jest zbędna. Chodzi o kolejność i proporcje: zbudowano rozbudowany protokół zapisu decyzji, zanim wykazano, że prowadzi on do rzeczywistego wykonania i domknięcia zadania.

Nie ma też podstaw, by stwierdzić, że ten magazyn sam powodował „eksplozję kontekstu”. Długi kod obciąża kontekst modelu dopiero wtedy, gdy jest regularnie do niego dołączany; nie przedstawiono pomiaru, który by to potwierdzał. Podobnie nie wykazano wystąpienia zakleszczenia: używana blokada jest nieblokująca i w razie konfliktu odrzuca operację. Wielowarstwowe blokady mogą utrudniać postęp, ale do stwierdzenia deadlocka potrzebny byłby dowód z działania systemu.

Ograniczenia wykonawcy i ryzyko rozjazdu stanu

Kod backendu Pi wyłącza umiejętności, rozszerzenia, MCP, szablony promptów i pliki kontekstu, a narzędzia ogranicza do jawnej listy. To oznacza, że nie może on natywnie odkrywać umiejętności BMAD. Jeśli ma z nich korzystać, otoczenie musi samo dostarczać ich treść i zależności oraz pilnować zgodności wersji.

Nie dowodzi to, że Pi nie mógł wykonać żadnego zadania związanego z BMAD. Pokazuje jednak, że część pracy, którą mogłoby wykonać natywne ładowanie umiejętności, przejmowałyby dodatkowe warstwy.

Także samo skopiowanie fragmentu umiejętności nie gwarantuje działania. Wejściowa umiejętność bmad-build-auto wymaga m.in. projektu z odpowiednim mechanizmem renderowania oraz obsługi błędów. Dawny projekt dopuszczał współistnienie Cline do planowania i Pi do kodowania, ale zidentyfikowane w nim ryzyka — takie jak dwie konkurujące ścieżki decyzyjne czy mylenie zapisu rozmowy z odzyskiwaniem stanu — nie są dowodem, że doszło do konkretnej awarii.

Zielone testy nie potwierdzają całego produktu

Plan odnotowuje 231 historycznych testów jednostkowych, które według wcześniejszego potwierdzenia zakończyły się powodzeniem. Równocześnie wskazuje, że nie sprawdzono prawdziwego backendu, niezależnego uwierzytelnienia, rozpoczęcia nowego kroku po zamknięciu klienta ani pełnego zdalnego przepływu. Testów nie uruchomiono ponownie na potrzeby tej analizy.

Testy mogą potwierdzać działanie blokad, limitów i obsługi symulowanych błędów. Nie dowodzą jednak automatycznie, że prawdziwy model poprawnie obsłuży umiejętności, że wydarzenie kończące zadanie będzie wiarygodne ani że audyt, zatrzymanie, wznowienie i commit zadziałają razem na VPS.

Rozliczenie dotychczasowej pracy: zachować reguły analizy, metodę trzech przebiegów czytania i historyczne dowody; zamrozić warstwę wykonawczą V5; nie traktować jej testów jako domyślnej bramki ani jako wyniku testów V6.

Podział odpowiedzialności w proponowanym V6

Element	Jedno główne zadanie	Granica, której nie powinien przekraczać
bmad-loop	Wybór Story, prowadzenie sesji, weryfikacja, limity prób, commit i stan przebiegu	Nie zmienia samodzielnie celu ani nie uruchamia drugiej pętli sterującej
Cline CLI	Wykonanie pojedynczego zadania programistycznego lub audytowego w określonym katalogu	Nie przejmuje planowania całego projektu ani działania w tle jako drugi orkiestrator
BMAD-METHOD	Dostarczanie umiejętności i przepływów pracy	Nie jest prywatnie kopiowany ani ładowany w całości do każdego zadania
Zewnętrzna bramka Jev	Pomoc w ocenie zgodności semantycznej i klasyfikacji problemów	Nie modyfikuje kodu, nie wybiera kolejnego Story i nie unieważnia wyniku prawdziwego testu
Doświadczenia inspirowane Harness²	Zapisywanie krótkich, możliwych do sprawdzenia wniosków dla przyszłych zadań	Nie zmieniają uprawnień i nie zastępują twardych bramek

„Brak LLM w pętli sterującej” nie oznacza systemu bez modeli. Oznacza, że to program — a nie model — decyduje o wyborze Story, limitach, wymaganych kontrolach i warunkach ukończenia. Samo generowanie kodu i recenzja nadal mogą być zadaniami dla modeli.

Dokumentacja bmad-loop opisuje przepływ od pracy programistycznej przez weryfikację i niezależny przegląd po ponowną weryfikację oraz commit. Trzeba jednak uwzględnić ustawienia domyślne: niezależna recenzja nie zawsze jest obowiązkowa, wyczerpanie części limitów recenzji może dopuścić commit, a limit tokenów dla Story ma charakter ostrzegawczy, nie twardo zatrzymujący. Wymagane bramki trzeba więc dopasować przez oficjalne punkty rozszerzeń, zamiast kopiować cały mechanizm orkiestratora.

Największa niewiadoma: zgodność Cline z bmad-loop

Proponowane profile DEV i REVIEW mają być dwiema konfiguracjami tego samego frameworku, a nie dwoma autonomicznymi systemami.

• DEV: osobna konfiguracja i katalog sesji, dostęp do zapisu w zatwierdzonym obszarze pracy; docelowo model Sonnet 5.5.
• REVIEW: odrębna konfiguracja i sesja, dostęp tylko do kryteriów akceptacji, zamrożonej zmiany i dowodów; docelowo GPT-6-Sol.

Te nazwy modeli są celami ról, a nie potwierdzonymi identyfikatorami dostawcy. Trzeba zweryfikować ich dokładne ID, sposób uwierzytelniania i rzeczywisty wynik wywołania.

Dokumentacja Cline wskazuje m.in. katalogi konfiguracji i stanu, wybór modelu oraz katalog roboczy. Nie znaleziono jednak potwierdzonego natywnego polecenia tworzącego profile o nazwach DEV i REVIEW. Są one na razie konwencją projektową.

Istotniejsza przeszkoda: lista wbudowanych CLI bmad-loop nie obejmuje Cline, a udokumentowane adaptery ogólne oczekują zdarzeń cyklu życia, których dialektu dokumentacja nie przypisuje Cline. Samo wpisanie mapowania zdarzeń do konfiguracji nie dowiedzie, że adapter działa.

Przed uruchomieniem zadań trzeba wykazać, że integracja potrafi uruchomić nową sesję w określonym katalogu, rozpoznać jej początek i prawdziwe zakończenie, odróżnić zwykłą wiadomość od końca zadania oraz skutecznie zatrzymać procesy po anulowaniu. Jeśli nie da się odczytać zużycia, system powinien pokazywać je jako nieznane — nie sugerować, że działa twardy limit kosztów.

Jev jako dodatkowa bramka, nie wyrocznia

Jev przyjmuje stan i typowane pytania, a zwraca uporządkowane odpowiedzi. Dokumentacja opisuje m.in. użycie API i modelu do podejmowania ustrukturyzowanych decyzji; nie jest to narzędzie do pisania kodu ani prowadzenia rozmowy.12 Nie dowodzi to jednak, że Jev niezawodnie rozstrzygnie każdy przypadek naruszenia zakresu lub przyczynę błędu testu.

Proponowana kontrola powinna mieć dwie części:

1. Kontrola deterministyczna: sprawdza wszystkie zmienione pliki, w tym nowe, i odrzuca niedozwolone ścieżki. Tego rozstrzygnięcia nie należy oddawać modelowi.
2. Ocena semantyczna: Jev otrzymuje ograniczony diff, kryteria akceptacji i dowody z testów. Może pomóc ocenić, czy zmiana wykracza poza zadanie i czy problem wygląda na błąd implementacji, środowiska czy pozostaje nieznany.

W proponowanym kontrakcie kod wyjścia 0 oznacza pozytywną kontrolę, 1 — naruszenie zakresu lub kryteriów, a 75 — niedostępność usługi, uwierzytelniania albo środowiska. Ten ostatni przypadek powinien wstrzymać zadanie, a nie udawać błąd kodu.

Bramka działa po przygotowaniu zmiany, więc nie może cofnąć skutków wcześniejszych działań agenta. Dlatego nadal ważne są izolacja katalogu roboczego, ograniczenia uprawnień i brak produkcyjnych danych dostępowych.

Harness²: inspiracja, nie pełna implementacja

Opis Harness² przedstawia dwa poziomy doskonalenia: poprawianie sposobu działania w obrębie zadania oraz wykorzystywanie wniosków w kolejnych zadaniach, bez zmiany wag modelu. Według przytoczonego opisu projektu wskazanymi wykonawcami są OpenCode i Codex, nie Cline.

Dlatego rozsądny zakres V6 to skromny mechanizm inspirowany tą ideą, a nie deklaracja pełnej implementacji Harness². Plik experience.md mógłby przechowywać tylko warunek zastosowania, konkretną lekcję, odnośnik do Story i dowodu oraz przypadek, w którym wniosek nie obowiązuje.

Nowa notatka powinna wynikać z rzeczywistego błędu lub przeglądu. Nie należy dopisywać „doświadczeń” dla samego wrażenia, że system się uczy, ani pozwalać im zmieniać uprawnienia czy kryteria akceptacji.

Jak miałby wyglądać jeden przebieg zadania

Przykładem może być Story dotyczące zapobiegania wielokrotnemu wysłaniu tego samego zamówienia. Zakładamy przy tym, że zachowanie zostało wcześniej jasno opisane, a zakres zmian zatwierdzony.

1. bmad-loop wybiera zatwierdzone Story i tworzy osobny Worktree.
2. Nowa sesja Cline DEV otrzymuje kryteria akceptacji, odpowiednie umiejętności BMAD, powiązane doświadczenia i potrzebny fragment kodu.
3. Agent przygotowuje zmianę i testy. Samo zakończenie sesji nie oznacza zaliczenia zadania.
4. Zewnętrzna kontrola sprawdza listę zmienionych plików, uruchamia wymagane testy i — jeśli jest dostępna — ocenia zakres z Jev.
5. Kandydat do przeglądu zostaje zamrożony wraz z kryteriami, testami i ich rzeczywistymi wynikami. Audyt musi uwzględnić również nowe pliki.
6. Nowa sesja Cline REVIEW ocenia kandydata bez dostępu do rozmowy programistycznej i uzasadnień autora. Zwraca wynik: akceptacja, odrzucenie albo brak pewności; nie poprawia kodu.
7. Po decyzji można przygotować uzasadnioną dowodami notatkę do experience.md.
8. Przed commitem system ponownie sprawdza, czy kandydat się nie zmienił i czy nadal ma ważne wyniki testów, kontroli zakresu oraz niezależnego przeglądu.
9. Commit i merge wykonuje wyłącznie orkiestrator. Jeśli zmieni się kod po audycie, wcześniejsza akceptacja przestaje obowiązywać.
10. Kolejne Story startuje w nowym kontekście i może odczytać zatwierdzone, powiązane doświadczenia.

Worktree izoluje zmiany w kodzie, ale sam z siebie nie izoluje procesów działających na tym samym koncie ani dostępu do sekretów. Należy też odróżnić pracę po rozłączeniu lokalnego IDE od pracy przy całkowitym braku sieci: w pierwszym przypadku VPS ma kontynuować, w drugim powinien bezpiecznie się zatrzymać i zachować stan.

Zamrożenie V5 i warunki startu V6

Plan V5 powinien zachować dotychczasowe identyfikatory, niedokończone zadania i historyczne potwierdzenia. Proponowana rekomendacja to oznaczenie go jako zawieszonego oraz jasna informacja, że warstwa wykonawcza V5 nie będzie dalej rozwijana. Nie należy oznaczać niewykonanych zadań jako ukończonych ani przedstawiać dawnych testów jako weryfikacji V6.

Powiązany ADR powinien pozostać historyczną propozycją, a nowy dokument V6 powinien jawnie zastąpić decyzje o wykonawcy, magazynie i orkiestracji. Zachować warto metody analizy, granice uprawnień i wymóg dowodów z rzeczywistego działania.

Samo zamrożenie dokumentacji nie zatrzymuje procesów działających na serwerze. Dezaktywacja starego wejścia, sprawdzenie procesów i fizyczne archiwizowanie wymagają osobnego upoważnienia.

Minimalne środowisko opisane dla bmad-loop obejmuje Python 3.11 lub nowszy, Git 2.34 lub nowszy i tmux 3.2 lub nowszy. Potrzebne mogą być także Cline, umiejętności BMAD wraz z mechanizmem inicjalizacji projektu oraz zależności wymagane przez testy. Nie ma uzasadnienia, by dokładać bazę danych, drugi framework wykonawczy, dodatkową kolejkę czy własną tablicę zadań.

Przed uruchomieniem Story trzeba jednak sprawdzić konfigurację Cline, integrację z bmad-loop, działanie umiejętności w Worktree, zachowanie w razie awarii Jev oraz zatrzymanie procesów. Wymagane kontrole muszą działać w trybie fail-closed: odmowa, brak pewności, brak usługi lub zmiana kandydata po audycie nie mogą prowadzić do commitu.

Kryteria, które powinien spełnić MVP

• Jedno rzeczywiste, zatwierdzone Story przechodzi przez implementację, wymagane testy, bramkę Jev, niezależny audyt i natywny commit.
• Po rozłączeniu lokalnego klienta VPS wykonuje kolejny rzeczywisty etap i zapisuje jego wynik; samo działające tmux nie wystarcza.
• Audytor nie korzysta z rozmowy programistycznej. Jeśli izolację zapewnia tylko instrukcja w promptcie, należy określić ją jako miękką, a nie twardą.
• Naruszenie zakresu, błąd testu, odmowa audytu, brak pewności lub awaria usługi blokują commit.
• Nowa sesja potrafi odczytać zatwierdzone doświadczenie. Pełne sprawdzenie przenoszenia wniosków wymaga drugiego małego Story — jednego zadania nie należy przedstawiać jako dowodu ciągłości.
• Zatrzymanie kończy sesję i jej procesy, a przy awarii zachowany zostaje stan potrzebny do dalszej analizy.
• Nie powstaje drugi orkiestrator, baza danych, zależność od starego wykonawcy ani równoległy rejestr postępu.

Ostateczna rekomendacja: zamrozić warstwę wykonawczą V5 i zachować jej użyteczne ustalenia. Kierunek V6 jest spójny, ale o uruchomieniu nie powinien decydować kolejny dokument ani zielone testy jednostkowe. Najpierw trzeba udowodnić zgodność Cline z cyklem pracy bmad-loop oraz skuteczność niezależnego, zamykającego drogę do commitu audytu. Jeśli tej integracji nie da się potwierdzić, należy zatrzymać projekt na tym etapie — nie odbudowywać pod inną nazwą rozbudowanych warstw V5.

Wniosek: zamrozić V5, ale nie ogłaszać gotowości V6

Proponowany kierunek dla BMRalph V6 to: orkiestrator bmad-loop, jeden framework wykonawczy Cline, zewnętrzne kontrole i niewielki plik z doświadczeniami z poprzednich zadań. Nie ma tu miejsca na drugi, równoległy system sterowania agentami.

To jednak plan architektury, a nie potwierdzenie, że system już działa. Nadal brakuje dowodów, że Cline da się podłączyć do cyklu życia bmad-loop, że audyt będzie rzeczywiście niezależny, że bramka Jev zadziała w praktyce i że VPS wykona kolejne kroki po rozłączeniu lokalnego IDE.

Raport opiera się na wskazanych plikach i historycznych wynikach. Nie zmieniano w nim planu, kodu ani testów; nie uruchamiano też modeli, instalacji, commitów ani próbnego przepływu na VPS.

Co wynika z analizy V5

Rozbudowany magazyn nie jest tym samym co działający proces

W sprawdzonym pliku bmad_control_store.py jest 315 linii kodu, a nie 1728. To dopisywany do pliku magazyn rekordów, nie baza SQL. Dla wersji liczącej 1728 linii ani odpowiadającego jej commitu nie przedstawiono dowodu.

Moduł pilnuje m.in. tożsamości katalogów, uprawnień plików i blokad, wersji żądań, ciągłości historii, limitu danych, odczytu po zapisie i odcisku treści. Jednocześnie jego wynik nie uwierzytelnia człowieka, nie przyznaje prawa do wykonania zadania, nie uruchamia go ani nie zapisuje postępu.

Problem nie polega więc na tym, że każda kontrola bezpieczeństwa jest zbędna. Chodzi o kolejność i proporcje: zbudowano rozbudowany protokół zapisu decyzji, zanim wykazano, że prowadzi on do rzeczywistego wykonania i domknięcia zadania.

Nie ma też podstaw, by stwierdzić, że ten magazyn sam powodował „eksplozję kontekstu”. Długi kod obciąża kontekst modelu dopiero wtedy, gdy jest regularnie do niego dołączany; nie przedstawiono pomiaru, który by to potwierdzał. Podobnie nie wykazano wystąpienia zakleszczenia: używana blokada jest nieblokująca i w razie konfliktu odrzuca operację. Wielowarstwowe blokady mogą utrudniać postęp, ale do stwierdzenia deadlocka potrzebny byłby dowód z działania systemu.

Ograniczenia wykonawcy i ryzyko rozjazdu stanu

Kod backendu Pi wyłącza umiejętności, rozszerzenia, MCP, szablony promptów i pliki kontekstu, a narzędzia ogranicza do jawnej listy. To oznacza, że nie może on natywnie odkrywać umiejętności BMAD. Jeśli ma z nich korzystać, otoczenie musi samo dostarczać ich treść i zależności oraz pilnować zgodności wersji.

Nie dowodzi to, że Pi nie mógł wykonać żadnego zadania związanego z BMAD. Pokazuje jednak, że część pracy, którą mogłoby wykonać natywne ładowanie umiejętności, przejmowałyby dodatkowe warstwy.

Także samo skopiowanie fragmentu umiejętności nie gwarantuje działania. Wejściowa umiejętność bmad-build-auto wymaga m.in. projektu z odpowiednim mechanizmem renderowania oraz obsługi błędów. Dawny projekt dopuszczał współistnienie Cline do planowania i Pi do kodowania, ale zidentyfikowane w nim ryzyka — takie jak dwie konkurujące ścieżki decyzyjne czy mylenie zapisu rozmowy z odzyskiwaniem stanu — nie są dowodem, że doszło do konkretnej awarii.

Zielone testy nie potwierdzają całego produktu

Plan odnotowuje 231 historycznych testów jednostkowych, które według wcześniejszego potwierdzenia zakończyły się powodzeniem. Równocześnie wskazuje, że nie sprawdzono prawdziwego backendu, niezależnego uwierzytelnienia, rozpoczęcia nowego kroku po zamknięciu klienta ani pełnego zdalnego przepływu. Testów nie uruchomiono ponownie na potrzeby tej analizy.

Testy mogą potwierdzać działanie blokad, limitów i obsługi symulowanych błędów. Nie dowodzą jednak automatycznie, że prawdziwy model poprawnie obsłuży umiejętności, że wydarzenie kończące zadanie będzie wiarygodne ani że audyt, zatrzymanie, wznowienie i commit zadziałają razem na VPS.

Rozliczenie dotychczasowej pracy: zachować reguły analizy, metodę trzech przebiegów czytania i historyczne dowody; zamrozić warstwę wykonawczą V5; nie traktować jej testów jako domyślnej bramki ani jako wyniku testów V6.

Podział odpowiedzialności w proponowanym V6

Element	Jedno główne zadanie	Granica, której nie powinien przekraczać
bmad-loop	Wybór Story, prowadzenie sesji, weryfikacja, limity prób, commit i stan przebiegu	Nie zmienia samodzielnie celu ani nie uruchamia drugiej pętli sterującej
Cline CLI	Wykonanie pojedynczego zadania programistycznego lub audytowego w określonym katalogu	Nie przejmuje planowania całego projektu ani działania w tle jako drugi orkiestrator
BMAD-METHOD	Dostarczanie umiejętności i przepływów pracy	Nie jest prywatnie kopiowany ani ładowany w całości do każdego zadania
Zewnętrzna bramka Jev	Pomoc w ocenie zgodności semantycznej i klasyfikacji problemów	Nie modyfikuje kodu, nie wybiera kolejnego Story i nie unieważnia wyniku prawdziwego testu
Doświadczenia inspirowane Harness²	Zapisywanie krótkich, możliwych do sprawdzenia wniosków dla przyszłych zadań	Nie zmieniają uprawnień i nie zastępują twardych bramek

„Brak LLM w pętli sterującej” nie oznacza systemu bez modeli. Oznacza, że to program — a nie model — decyduje o wyborze Story, limitach, wymaganych kontrolach i warunkach ukończenia. Samo generowanie kodu i recenzja nadal mogą być zadaniami dla modeli.

Dokumentacja bmad-loop opisuje przepływ od pracy programistycznej przez weryfikację i niezależny przegląd po ponowną weryfikację oraz commit. Trzeba jednak uwzględnić ustawienia domyślne: niezależna recenzja nie zawsze jest obowiązkowa, wyczerpanie części limitów recenzji może dopuścić commit, a limit tokenów dla Story ma charakter ostrzegawczy, nie twardo zatrzymujący. Wymagane bramki trzeba więc dopasować przez oficjalne punkty rozszerzeń, zamiast kopiować cały mechanizm orkiestratora.

Największa niewiadoma: zgodność Cline z bmad-loop

Proponowane profile DEV i REVIEW mają być dwiema konfiguracjami tego samego frameworku, a nie dwoma autonomicznymi systemami.

• DEV: osobna konfiguracja i katalog sesji, dostęp do zapisu w zatwierdzonym obszarze pracy; docelowo model Sonnet 5.5.
• REVIEW: odrębna konfiguracja i sesja, dostęp tylko do kryteriów akceptacji, zamrożonej zmiany i dowodów; docelowo GPT-6-Sol.

Te nazwy modeli są celami ról, a nie potwierdzonymi identyfikatorami dostawcy. Trzeba zweryfikować ich dokładne ID, sposób uwierzytelniania i rzeczywisty wynik wywołania.

Dokumentacja Cline wskazuje m.in. katalogi konfiguracji i stanu, wybór modelu oraz katalog roboczy. Nie znaleziono jednak potwierdzonego natywnego polecenia tworzącego profile o nazwach DEV i REVIEW. Są one na razie konwencją projektową.

Istotniejsza przeszkoda: lista wbudowanych CLI bmad-loop nie obejmuje Cline, a udokumentowane adaptery ogólne oczekują zdarzeń cyklu życia, których dialektu dokumentacja nie przypisuje Cline. Samo wpisanie mapowania zdarzeń do konfiguracji nie dowiedzie, że adapter działa.

Przed uruchomieniem zadań trzeba wykazać, że integracja potrafi uruchomić nową sesję w określonym katalogu, rozpoznać jej początek i prawdziwe zakończenie, odróżnić zwykłą wiadomość od końca zadania oraz skutecznie zatrzymać procesy po anulowaniu. Jeśli nie da się odczytać zużycia, system powinien pokazywać je jako nieznane — nie sugerować, że działa twardy limit kosztów.

Jev jako dodatkowa bramka, nie wyrocznia

Jev przyjmuje stan i typowane pytania, a zwraca uporządkowane odpowiedzi. Dokumentacja opisuje m.in. użycie API i modelu do podejmowania ustrukturyzowanych decyzji; nie jest to narzędzie do pisania kodu ani prowadzenia rozmowy.12 Nie dowodzi to jednak, że Jev niezawodnie rozstrzygnie każdy przypadek naruszenia zakresu lub przyczynę błędu testu.

Proponowana kontrola powinna mieć dwie części:

1. Kontrola deterministyczna: sprawdza wszystkie zmienione pliki, w tym nowe, i odrzuca niedozwolone ścieżki. Tego rozstrzygnięcia nie należy oddawać modelowi.
2. Ocena semantyczna: Jev otrzymuje ograniczony diff, kryteria akceptacji i dowody z testów. Może pomóc ocenić, czy zmiana wykracza poza zadanie i czy problem wygląda na błąd implementacji, środowiska czy pozostaje nieznany.

W proponowanym kontrakcie kod wyjścia 0 oznacza pozytywną kontrolę, 1 — naruszenie zakresu lub kryteriów, a 75 — niedostępność usługi, uwierzytelniania albo środowiska. Ten ostatni przypadek powinien wstrzymać zadanie, a nie udawać błąd kodu.

Bramka działa po przygotowaniu zmiany, więc nie może cofnąć skutków wcześniejszych działań agenta. Dlatego nadal ważne są izolacja katalogu roboczego, ograniczenia uprawnień i brak produkcyjnych danych dostępowych.

Harness²: inspiracja, nie pełna implementacja

Opis Harness² przedstawia dwa poziomy doskonalenia: poprawianie sposobu działania w obrębie zadania oraz wykorzystywanie wniosków w kolejnych zadaniach, bez zmiany wag modelu. Według przytoczonego opisu projektu wskazanymi wykonawcami są OpenCode i Codex, nie Cline.

Dlatego rozsądny zakres V6 to skromny mechanizm inspirowany tą ideą, a nie deklaracja pełnej implementacji Harness². Plik experience.md mógłby przechowywać tylko warunek zastosowania, konkretną lekcję, odnośnik do Story i dowodu oraz przypadek, w którym wniosek nie obowiązuje.

Nowa notatka powinna wynikać z rzeczywistego błędu lub przeglądu. Nie należy dopisywać „doświadczeń” dla samego wrażenia, że system się uczy, ani pozwalać im zmieniać uprawnienia czy kryteria akceptacji.

Jak miałby wyglądać jeden przebieg zadania

Przykładem może być Story dotyczące zapobiegania wielokrotnemu wysłaniu tego samego zamówienia. Zakładamy przy tym, że zachowanie zostało wcześniej jasno opisane, a zakres zmian zatwierdzony.

1. bmad-loop wybiera zatwierdzone Story i tworzy osobny Worktree.
2. Nowa sesja Cline DEV otrzymuje kryteria akceptacji, odpowiednie umiejętności BMAD, powiązane doświadczenia i potrzebny fragment kodu.
3. Agent przygotowuje zmianę i testy. Samo zakończenie sesji nie oznacza zaliczenia zadania.
4. Zewnętrzna kontrola sprawdza listę zmienionych plików, uruchamia wymagane testy i — jeśli jest dostępna — ocenia zakres z Jev.
5. Kandydat do przeglądu zostaje zamrożony wraz z kryteriami, testami i ich rzeczywistymi wynikami. Audyt musi uwzględnić również nowe pliki.
6. Nowa sesja Cline REVIEW ocenia kandydata bez dostępu do rozmowy programistycznej i uzasadnień autora. Zwraca wynik: akceptacja, odrzucenie albo brak pewności; nie poprawia kodu.
7. Po decyzji można przygotować uzasadnioną dowodami notatkę do experience.md.
8. Przed commitem system ponownie sprawdza, czy kandydat się nie zmienił i czy nadal ma ważne wyniki testów, kontroli zakresu oraz niezależnego przeglądu.
9. Commit i merge wykonuje wyłącznie orkiestrator. Jeśli zmieni się kod po audycie, wcześniejsza akceptacja przestaje obowiązywać.
10. Kolejne Story startuje w nowym kontekście i może odczytać zatwierdzone, powiązane doświadczenia.

Worktree izoluje zmiany w kodzie, ale sam z siebie nie izoluje procesów działających na tym samym koncie ani dostępu do sekretów. Należy też odróżnić pracę po rozłączeniu lokalnego IDE od pracy przy całkowitym braku sieci: w pierwszym przypadku VPS ma kontynuować, w drugim powinien bezpiecznie się zatrzymać i zachować stan.

Zamrożenie V5 i warunki startu V6

Plan V5 powinien zachować dotychczasowe identyfikatory, niedokończone zadania i historyczne potwierdzenia. Proponowana rekomendacja to oznaczenie go jako zawieszonego oraz jasna informacja, że warstwa wykonawcza V5 nie będzie dalej rozwijana. Nie należy oznaczać niewykonanych zadań jako ukończonych ani przedstawiać dawnych testów jako weryfikacji V6.

Powiązany ADR powinien pozostać historyczną propozycją, a nowy dokument V6 powinien jawnie zastąpić decyzje o wykonawcy, magazynie i orkiestracji. Zachować warto metody analizy, granice uprawnień i wymóg dowodów z rzeczywistego działania.

Samo zamrożenie dokumentacji nie zatrzymuje procesów działających na serwerze. Dezaktywacja starego wejścia, sprawdzenie procesów i fizyczne archiwizowanie wymagają osobnego upoważnienia.

Minimalne środowisko opisane dla bmad-loop obejmuje Python 3.11 lub nowszy, Git 2.34 lub nowszy i tmux 3.2 lub nowszy. Potrzebne mogą być także Cline, umiejętności BMAD wraz z mechanizmem inicjalizacji projektu oraz zależności wymagane przez testy. Nie ma uzasadnienia, by dokładać bazę danych, drugi framework wykonawczy, dodatkową kolejkę czy własną tablicę zadań.

Przed uruchomieniem Story trzeba jednak sprawdzić konfigurację Cline, integrację z bmad-loop, działanie umiejętności w Worktree, zachowanie w razie awarii Jev oraz zatrzymanie procesów. Wymagane kontrole muszą działać w trybie fail-closed: odmowa, brak pewności, brak usługi lub zmiana kandydata po audycie nie mogą prowadzić do commitu.

Kryteria, które powinien spełnić MVP

• Jedno rzeczywiste, zatwierdzone Story przechodzi przez implementację, wymagane testy, bramkę Jev, niezależny audyt i natywny commit.
• Po rozłączeniu lokalnego klienta VPS wykonuje kolejny rzeczywisty etap i zapisuje jego wynik; samo działające tmux nie wystarcza.
• Audytor nie korzysta z rozmowy programistycznej. Jeśli izolację zapewnia tylko instrukcja w promptcie, należy określić ją jako miękką, a nie twardą.
• Naruszenie zakresu, błąd testu, odmowa audytu, brak pewności lub awaria usługi blokują commit.
• Nowa sesja potrafi odczytać zatwierdzone doświadczenie. Pełne sprawdzenie przenoszenia wniosków wymaga drugiego małego Story — jednego zadania nie należy przedstawiać jako dowodu ciągłości.
• Zatrzymanie kończy sesję i jej procesy, a przy awarii zachowany zostaje stan potrzebny do dalszej analizy.
• Nie powstaje drugi orkiestrator, baza danych, zależność od starego wykonawcy ani równoległy rejestr postępu.

Ostateczna rekomendacja: zamrozić warstwę wykonawczą V5 i zachować jej użyteczne ustalenia. Kierunek V6 jest spójny, ale o uruchomieniu nie powinien decydować kolejny dokument ani zielone testy jednostkowe. Najpierw trzeba udowodnić zgodność Cline z cyklem pracy bmad-loop oraz skuteczność niezależnego, zamykającego drogę do commitu audytu. Jeśli tej integracji nie da się potwierdzić, należy zatrzymać projekt na tym etapie — nie odbudowywać pod inną nazwą rozbudowanych warstw V5.