Przegląd architektury

Julia to asystent głosowy AI dla kokpitu w MSFS 2024. Zadaniem nie jest „kolejna aplikacja”, lecz realne odciążenie pilota, gdy liczy się czas, skupienie i pewność danych. Odpowiedzi przy pytaniach o pogodę opierają się o METAR; przy pytaniach o lot — o plan lotu (SimBrief) i telemetrię (SimConnect). Wersja developerska jest przygotowana do komercjalizacji (US$9.90–US$19.90) z licencjonowaniem HWID i backendem (Firebase, Stripe, Make.com).

1. Symulator — Microsoft Flight Simulator 2024; źródło prawdy o stanie statku przez SimConnect.
2. Aplikacja Julia (Python) — GUI (CustomTkinter / Tkinter), audio (Whisper, pyttsx3 / SAPI5), logika wątków, integracje.
3. Usługi lotnicze (HTTP) — SimBrief (OFP), CheckWX (METAR).
4. AI w chmurze — Google Gemini (generacja odpowiedzi w kontrolowanym stylu; model nie jest jedynym „źródłem prawdy” — dostaje kontekst operacyjny).
5. Backend komercyjny — Firebase (auth, konfiguracja, logi, licencje), Stripe (płatności), Make.com (automatyzacja webhooków i pól isPaid).
6. Portal (osobny komponent repozytorium) — Pilot Hangar (Next.js, Firestore do widoku sesji/map — zgodnie z implementacją repo).

• METAR — źródło CheckWX, wyświetlenie w ZULU, ten sam materiał trafia do kontekstu LLM przy pytaniach o pogodę.
• Plan lotu — SimBrief (DEP/ARR, elementy OFP); spójność odpowiedzi z tym, co pilot zaplanował.
• Stan statku — SimConnect (pozycja, faza lotu, parametry — w dokumentacji >1000 zmiennych możliwych do odczytu w opisie produktowym).

Pilot Hangar nie zastępuje aplikacji desktopowej Julii przy stole symulacyjnym — to portal (dashboard, mapa, dokumentacja, i18n). W architekturze PDF MQTT nie występuje jako magistrala produktu Julia→MSFS; szczegóły w mqtt.md.

• HWID + weryfikacja w Firebase; Stripe + webhooki; brak „zaufania do samego LLM” bez danych operacyjnych.
• Sekrety — poza obrazami kontenerów i poza repozytorium; klucze API nie w kliencie przeglądarki (dla Hangara — zmienne NEXT_PUBLIC_* tylko dla konfiguracji Firebase safe-for-client).

• Poziomo: wiele użytkowników końcowych na współdzielonym backendzie (Firebase/Stripe/Make) — automatyzacja skaluje się bez liniowego wzrostu zatrudnienia (teza z dokumentacji).
• Pionowo: profil maszyny użytkownika (MSFS + Whisper lokalnie + GPU/CPU) vs tylko lekki UI — dokumentacja podkreśla niskie obciążenie GUI (CustomTkinter), by nie kradnąć FPS symulatora.

[Pilot PTT] → [Audio] → [Whisper] → [Intent]
                              ↓
        [SimConnect] ←→ [Kontekst lotu] → [Gemini] → [TTS] → [Pilot]
              ↓                    ↑
        [Telemetria]      [SimBrief OFP] + [CheckWX METAR]
              ↓                    ↓
           [GUI: ZULU, kafelki, log]     [Firebase / Stripe / Make.com]

• Rdzeń Python — wątki, biblioteki, konwencje modułów.
• Przepływ danych — potok PTT end-to-end i tory danych (głos, lot, METAR).
• Next.js i Firebase — portal Hangar + kontrakty backendowe Julii.
• Docker — pakietowanie i DevOps (PyInstaller/Nuitka vs kontenery).
• MQTT — rola w ekosystemie vs brak MQTT w opisie Julii (MSFS) z PDF.