Poniżej realny kształt przebiegu w AI SDLC na przykładzie jednego zadania: PRJ-1042 — zdarzenia audytowe przy wygaśnięciu sesji. Łącznie z momentem, w którym weryfikacja zawraca pracę — bo to właśnie wtedy widać, że proces działa. Nazwy są przykładowe, mechanika jest prawdziwa.
Wszystko zaczyna się od potrzeby wyrażonej po ludzku — bez specyfikacji, bez żargonu. Proces nadaje jej identyfikator i od tej chwili każdy artefakt będzie powiązany z PRJ-1042.
„Audytor zapytał, czy widzimy w logach moment, w którym sesja użytkownika wygasła sama z siebie. Dziś tego nie ma. Potrzebujemy zdarzenia audytowego przy każdym wygaśnięciu sesji — z powodem."
Agent Analityk zamienia potrzebę w sprawdzalne kryteria akceptacji. Bramka analizy przepuszcza dalej tylko wymagania, które da się zweryfikować.
Kryteria akceptacji:
Zmiana jest mała, ale dotyka ścieżki audytu — dlatego architekt oznacza ją flagą bezpieczeństwa: na końcu weryfikacji będzie wymagany dodatkowy werdykt Agenta Security.
Decyzja: rozszerzamy istniejący emiter zdarzeń audytowych o dwa nowe typy — bez zmian schematu, bez nowych zależności. Zmiana dotyka komponentu audytu → dodaję wymóg sec-verify-required.
Przed napisaniem pierwszej linii kodu powstaje plan: które pliki, jakie testy, co jest poza zakresem. Plan jest kontraktem — jeśli w trakcie pracy przestanie się zgadzać, praca wraca do tego etapu.
Plan: 2 pliki produkcyjne (emiter audytu, obsługa cyklu życia sesji), 1 plik testów. Testy: jednostkowe dla obu powodów wygaśnięcia + test integracyjny strumienia audytu. Poza zakresem: retencja logów, eksport, UI.
Implementacja w izolowanej gałęzi. Dowód ukończenia to nie deklaracja agenta, tylko zielone testy i PR powiązany z dokładną rewizją kodu.
Agent QA testuje przypadki brzegowe z kryteriów akceptacji — i znajduje lukę: sesja przedłużona tuż przed limitem maksymalnym wygasa bez zdarzenia audytowego. Werdykt jest przypięty do dokładnej rewizji i praca wraca do developmentu. Nie ma dyskusji z bramką.
Scenariusz: przedłużenie sesji 5 s przed osiągnięciem limitu maksymalnego → sesja wygasa ścieżką max_lifetime, zdarzenie audytowe nie zostaje wyemitowane. Narusza kryterium 2.
Poprawka trafia na tę samą gałąź — powstaje nowa rewizja, więc wszystkie werdykty muszą zostać wydane od nowa dla nowej rewizji. Stare dowody nie przechodzą. Tym razem: komplet.
Wszystkie 4 kryteria spełnione, w tym scenariusz przedłużenia przed limitem. Testy: 218 przechodzi, 0 pada.
Zdarzenia nie zawierają danych wrażliwych; format zgodny ze strumieniem audytu; brak nowych zależności.
Tak wygląda kompletny pakiet dowodów, który bramka merge zobaczy w następnym kroku — każda linia przypięta do tej samej rewizji:
Każda z tych linii działa według tej samej, jednej reguły. Rozłóżmy ją na części:
Merge wykonuje wyłącznie skrypt bramki — żaden agent nie ma prawa scalić PR ręcznie. Skrypt sprawdza komplet dowodów dla dokładnej rewizji i dopiero wtedy scala.
Wynik wraca do człowieka w języku celu, nie technologii. Dopiero akceptacja operatora zamyka zadanie — a retrospektywa zamienia zwrot z kroku 06 w trwałe usprawnienie procesu.
„Sprawdziłem na środowisku: wygaśnięcia widoczne w audycie z powodami. Audytor ma to, o co prosił. Akceptuję."
Lekcja: scenariusze „tuż przed limitem" dodane do stałej listy kontrolnej QA dla zmian w cyklu życia sesji.
Zwrot z weryfikacji to nie porażka procesu — to proces, który działa. Luka została znaleziona przez maszynę przed wdrożeniem, naprawiona w godzinach, a wiedza z niej została w procesie. Bez bramek ta sama luka wyszłaby na audycie.