Dwuroli workflow Codex: od specyfikacji do CI

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.