Baza wiedzy
ROADMAP
Mapa drogowa (Roadmap)
Hierarchiczny widok architektury Julii: powiązania Silnika Julii (Julia Core), mostka HTTP, dashboardu Next.js oraz sieci zewnętrznych. Rozwiń gałęzie, aby zobaczyć logikę „pod maską”.
Drzewo systemu
SYSTEM JULIA — centrum dowodzenia
Ekosystem łączy lokalny silnik głosowy i logiki lotu (Julia Core) z panelem webowym (Next.js). Użytkownik steruje Julką z kokpitu i z dashboardu; mostek przenosi żądania HTTPS → Silnik Julii na hoście lokalnym (domyślnie port 8766).
Dashboard agreguje telemetrię, licencje, radar strategiczny i bazę wiedzy — bez zastępowania real-time SimConnect, który pozostaje po stronie aplikacji desktopowej.
Architektura logiczna
Julia Core to główny silnik Julii na desktopie: pętla zdarzeń, integracja z mostkiem, głos (Whisper / TTS), reguły agenta i wywołania narzędzi. Mostek (julia-bridge) wystawia HTTP; Hangar proxy’uje go przez /api/julia-bridge/[...], aby uniknąć mixed content (HTTPS → localhost).
Decyzje agenta opierają się na kontekście lotu, historii rozmowy i politykach w silniku — frontend nie zastępuje reasoning, tylko wysyła komendy i odbiera stany.
Silnik AI (Julia Core)
Agent przetwarza tekst i audio użytkownika, planuje odpowiedzi i może wywoływać funkcje (np. odczyt L-Varów, zmiana scen OBS przez mostek). „Osobowość” wynika z promptów systemowych, szablonów odpowiedzi i ograniczeń bezpieczeństwa w Pythonie.
Komendy głosowe i przyciski dashboardu konwergują do tego samego kanału mostka — spójny model: żądanie → walidacja → efekt uboczny (SimConnect / plik / sieć).
Komunikacja i sterowanie (SimConnect / L-Vary)
Symulator (MSFS) dostarcza dane przez SimConnect i ewentualnie SimBridge; Julia odczytuje i zapisuje zmienne (L-Vary) oraz parametry lotu w czasie rzeczywistym. Panel „Oficer” / Smart Officer na dashboardzie odzwierciedla wybrane kafelki i L-Vary zsynchronizowane z mostkiem.
Sterowanie systemami maszyny (np. przełączniki) odbywa się przez warstwę Julia Core zmapowaną na konkretne adresy SimConnect — Hangar pokazuje stan, lecz nie zastępuje natywnej pętli RT w silniku.
Awionika i dane (PDF, nawigacja)
Dokumentacja PDF (checklisty, procedury) jest wczytywana i przetwarzana po stronie silnika / narzędzi pomocniczych; korelacja z pozycją i fazą lotu wymaga danych GPS/SimConnect z mostka.
Dashboard może wyświetlać wyniki (np. podpowiedzi), ale źródłem prawdy dla pozycji i planu lotu pozostaje symulator + logika Pythona.
Integracja radarowa
Hangar pobiera floty z route’ów API: VATSIM, IVAO, OpenSky (ADS-B), PilotEdge, POSCON, MSFS Live itd. Klient scala źródła, deduplikuje ICAO24 i rysuje ślady na Leaflet.
Serwer Next.js może proxy’ować i buforować ślady (/api/radar/*, /api/internal/radar-ingest); brak bezpośredniego renderu w Pythonie — radar to warstwa webowa zasilana JSON-em.
Warstwy pogodowe (Wiatr, Chmury, Opady)
Nakładki na mapie: RainViewer (opady, bez klucza), OpenWeatherMap (wiatr i zachmurzenie) przez kafle URL. Model BYOK: klucz użytkownika w localStorage (owm_api_key) lub NEXT_PUBLIC_OPENWEATHERMAP_API_KEY; bez klucza warstwy OWM się nie ładują.
Menu warstw (Mapy bazowe) otwiera modal magenta przy pierwszym włączeniu wiatru/chmur bez klucza.
Mostek — przepływ Dashboard ↔ Python
Przeglądarka woła /api/julia-bridge/… na tym samym hoście co Next.js; route Node przekazuje żądanie na JULIA_LOCAL_BRIDGE_URL (domyślnie http://127.0.0.1:8766). Mostek w Pythonie mapuje ścieżki na funkcje Julii (głos, konfiguracja, telemetry bridge).
Julia „rozmawia” z kokpitem przez SimConnect w procesie lokalnym; dashboard widzi tylko to, co mostek zwróci jako JSON/tekst. Timeouty i błędy sieci są obsługiwane po stronie Next (np. komunikaty w UI).
Interfejs (Dashboard — Next.js)
Aplikacja App Router (src/app), komponenty klientowe dla map, laboratoriów i profilu pilota. Firebase: auth, Firestore (profil, licencje), ewentualnie RTDB dla legacy.
Dashboard nie musi być uruchomiony, aby Julia latała lokalnie — ale bez mostka i sesji użytkownika część funkcji (sync ustawień, radar online) jest ograniczona.
Interfejs dowodzenia (Baza wiedzy, sesje, Szefuncio)
Baza wiedzy (ten panel): markdown w src/content/docs, manifest nawigacji w docsManifest.ts. Sesja pilota: PilotSessionProvider + Firestore — stan Julii ONLINE/OFFLINE widoczny na pulpicie.
Ustawienia „Szefuncia” (layout, kafelki, most) są zapisywane per użytkownik tam, gdzie to zaimplementowano (Firestore / localStorage) — szczegóły w kodzie komponentów dashboardu.
Struktura frontendu (skrót)
src/components — UI (radar, labs, pilot, docs). src/lib — logika (radar, julia bridge, firebase). src/app/api — route’y serverless (proxy, licencje, radar). Middleware next-intl dla locale.
Mapy: react-leaflet + warstwy w RadarMapOverlayLayers; głos Julii: juliaVoiceBridge + endpointy /api/labs/*.
Zasoby zewnętrzne (API)
Sieci lotnicze i pogoda wymagają kont u dostawców. Poniżej: instrukcje BYOK (OpenWeatherMap i OpenSky) oraz skrót pozostałych API używanych przez radar.
Instrukcja paliwowa — OpenWeatherMap (BYOK)
1) Wejdź na https://openweathermap.org/api i załóż darmowe konto.
2) W panelu użytkownika przejdź do „API keys” (klucze API) i wygeneruj klucz do Map Tiles / Current weather (kafle map).
3) W Hangarze: Mapa radaru → menu „Mapy bazowe” → sekcja Pogoda → włącz Wiatr lub Zachmurzenie. Przy pierwszym użyciu pojawi się modal „Dane API OpenWeatherMap” — wklej ten sam klucz w oba pola i Zatwierdź.
4) Klucz trafia do localStorage pod nazwą owm_api_key (priorytet nad zmienną NEXT_PUBLIC_OPENWEATHERMAP_API_KEY w deployu). Możesz zmienić klucz, usuwając go z pamięci przeglądarki i wprowadzając ponownie.
5) Opady (RainViewer) działają bez klucza OWM — osobne API publiczne.
Instrukcja paliwowa — OpenSky Network (MSFS Live / ADS-B)
1) Zarejestruj się na https://opensky-network.org/ (konto użytkownika).
2) W profilu wygeneruj dane Basic Auth (login + hasło) do API OpenSky.
3) W Hangarze: panel filtrów sieci (Labs / radar) → MSFS Live. Przy pierwszym włączeniu pojawi się modal „Dane API OpenSky” — wpisz login i hasło; aplikacja zapisuje sesję Basic w pamięci przeglądarki (RAM) na potrzeby fetchy ADS-B.
4) OpenSky ma limity dla użytkowników anonimowych; konto zwiększa dostępność. Dane trafiają do /api/radar/opensky i są łączone z innymi sieciami w StrategicTrailRadarProvider.
5) Nie commituj haseł do repozytorium — tylko wpis w UI lub sekrety serwera tam, gdzie to przewidziano.
Inne API radarowe (skrót)
VATSIM: /api/vatsim/data (proxy JSON). IVAO, PilotEdge, POSCON, Infinite Flight: dedykowane route’y w src/app/api/radar/*. Sieci włączane checkboxami; preferencje sieci w localStorage (julia-strategic-radar-networks-v1).
Ślady historyczne: mergeTrailHistoriesUnified + opcjonalny magazyn serwerowy .data/radar-tracks.json przy ingest cron.
Przyszły rozwój
Coming soon: rozszerzenia agenta, dodatkowe sieci ATN, głębsza integracja checklist PDF z fazami lotu, oraz dalsza optymalizacja bundli serverless dla wdrożeń chmurowych.
Nowe moduły będą dodawane do tej mapy po stabilizacji API.