Dwuroli workflow Codex

W skrócie

Specyfikacja jest kontraktem.
Review nie powinien być samooceną implementatora.
CI zamyka pętlę dowodem zewnętrznym.

Dlaczego dwie role

Agent, który napisał zmianę, ma ten sam kontekst i te same założenia, gdy ocenia własny wynik. Druga rola nie gwarantuje poprawności, ale wymusza osobny moment krytyki oparty na specyfikacji i artefaktach.

Podział ma sens tylko wtedy, gdy role mają różne kontrakty. Dwa okna wykonujące tę samą ogólną instrukcję nie tworzą kontroli jakości.

Kontrakt pracy

Rola implementacyjna otrzymuje zakres, kryteria akceptacji i listę dozwolonych zmian. Rola weryfikacyjna otrzymuje te same kryteria, ale nie założenia autora. Jej zadaniem jest wskazać dowód: test, diff, log albo reprodukowalny scenariusz.

specyfikacja → implementacja → niezależny review → CI → decyzja człowieka

Co powinno przechodzić przez CI

formatowanie, lint i typy;
testy jednostkowe zachowania krytycznego;
walidacja kontraktów danych;
test ścieżki użytkownika w przeglądarce;
zapis wersji i ograniczeń.

CI nie ocenia wartości produktu. Dostarcza zewnętrzny, powtarzalny dowód, że konkretna wersja spełnia techniczny kontrakt.

Typowe failure modes

Najczęstszy błąd to rozszerzanie zakresu podczas implementacji. Kolejny pojawia się, gdy review komentuje styl, ale nie wykonuje scenariusza akceptacyjnego. Trzeci to zielone CI oparte na testach, które nie dotykają zmienionej ścieżki.

Kiedy ten wzorzec pomaga

Workflow jest użyteczny w zadaniach z czytelnym kontraktem i możliwością automatycznej weryfikacji. Przy nieokreślonym kierunku produktu potrzebna jest najpierw decyzja właściciela, a nie więcej agentów.

01 / METHOD

Pytanie, które test powinien rozstrzygnąć

Dwuroli workflow nie polega na rozmowie dwóch postaci. Oddziela kontrakt implementacji od niezależnego sprawdzenia artefaktu, dzięki czemu opis „gotowe” nie zastępuje testu, przeglądu ani decyzji o merge. Wartość publikacji polega na tym, że czytelnik może odróżnić pytanie użytkownika od wygodnej metryki narzędzia i wskazać moment, w którym wynik przestaje być wystarczający do dalszej pracy.

02 / METHOD

Materiał i kontrprzykłady

Specyfikacja określa wejście, wynik, granice, test i właściciela akceptacji. Handoff przekazuje stan oraz dowody, a nie prywatną narrację wykonawcy lub niejawne dane z sesji. Materiał kontrolny nie ma potwierdzać tezy autora; jego zadaniem jest ujawnić przypadek, w którym prawdopodobny wynik jest niebezpiecznie mylący dla danego workflow.

03 / METHOD

Metoda kontroli

Sekwencja jest prosta: specyfikacja, implementacja, pull request, CI, niezależny review i decyzja. Dodatkowy agent nie jest celem; jego rola musi wnosić odrębne kryterium kontroli. Opis obejmuje kolejność kroków, wejście i ślad wyniku, aby niezależna osoba mogła sprawdzić, co zostało zmierzone oraz czego procedura w ogóle nie mierzy.

04 / METHOD

Macierz akceptacji

Evidence packet dla PR zawiera diff, wyniki testów, ograniczenia, decyzję reviewerа i rollback point. Gdy gate nie przechodzi, zmiana wraca do odpowiedzialnej roli zamiast przechodzić na podstawie pewnego opisu. Kryteria są jawne przed odczytaniem rezultatu, dzięki czemu pojedynczy udany przykład nie może zastąpić kontroli nad krytycznym typem błędu.

05 / METHOD

Przekazanie i ponowny test

Minimalny runbook opisuje, jak uruchomić test, gdzie znaleźć artefakt, jak odtworzyć defekt i kiedy użyć rollbacku. To pozwala kontynuować pracę bez zależności od autora promptu. Reprodukowalność obejmuje też możliwość pokazania, dlaczego następne uruchomienie różni się od poprzedniego i kto podejmuje decyzję o użyciu nowej wersji.

06 / METHOD

Granice wniosku

Rozdzielenie ról nie tworzy automatycznej niezależności: wspólne źródło błędu lub nieprzejrzysty test może osłabić oba role. Proces wymaga prawdziwego gate’u poza narracją agenta. Z tego powodu materiał ma charakter metodyczny i nie udaje uniwersalnej recepty ani niezależnego potwierdzenia, którego nie przeprowadzono.

07 / METHOD

Przykład kontroli

Minimalny przebieg można sprawdzić na jednym pull requeście: specyfikacja nazywa wymaganie i test, implementacja dostarcza diff, CI weryfikuje artefakt, a reviewer zapisuje niezależne kryterium oraz decyzję. Gdy test lub review nie przechodzi, work wraca do roli odpowiedzialnej zamiast do kolejnego opisu tekstowego.

08 / METHOD

Zapis źródła i review

Evidence packet ma zawierać tylko odtwarzalne ślady: link do PR, zakres diffu, wynik CI, ograniczenia, decyzję reviewera i rollback point. Nie trzeba publikować prywatnych promptów, danych sesji ani haseł, aby inna osoba mogła odróżnić wykonanie od zatwierdzenia.

LIM

Ograniczenia i zakres

Jeden eksperyment nie dowodzi przewagi w każdym repozytorium ani dla każdego rodzaju pracy.

SRC

Źródła i wersja zewnętrzna

Oryginalny lub wcześniejszy materiał na Medium

Narzędzia AI wspierały przygotowanie struktury i redakcję. Ostateczna wersja przeszła human editorial review faktów, źródeł, wniosków i przypisania autorstwa.

LOG

Historia zmian

05 mar 2026Pierwsza rozszerzona wersja we własnym archiwum.
02 sie 2026Przegląd struktury, ograniczeń i powiązań dowodowych.