Next.js i Firebase

• Struktura src/app/[locale]/… — prefiksy /pl, /en.
• setRequestLocale na stronach serwerowych dla stabilnego SSR tłumaczeń dokumentacji i UI.

Z dokumentacji produktowej i architektury PL:

• Baza użytkowników i uprawnień — m.in. pole isPaid, powiązanie z HWID.
• Auth / token — zdalna autoryzacja; możliwość odcięcia dostępu bez aktualizacji exe.
• Synchronizacja ustawień — głos, interwały edukacyjne, mapowanie PTT (przy limicie jednego HWID na licencję w opisie produktowym).
• Logi „czarnej skrzynki” / telemetria szkoleniowa — zgodnie z polityką retencji.

• Płatności i subskrypcje — po zaksięgowaniu płatności webhook (przetwarzany przez Make.com lub backend) aktualizuje isPaid w Firebase.
• Klucze sekretne Stripe — tylko po stronie serwera (Route Handlers / Cloud Functions / Make) — nigdy w bundle klienta Hangar.

• Orkiestracja między Stripe a Firebase:
  • automatyczne nadawanie uprawnień po opłacie,
  • monitoring wygaśnięcia subskrypcji,
  • powiadomienia o koncie,
  • limity tokenów API (opis kosztów operacyjnych w PDF).

import { initializeApp, getApps } from "firebase/app";
import { getFirestore } from "firebase/firestore";

const app = getApps()[0] ?? initializeApp({
  apiKey: process.env.NEXT_PUBLIC_FIREBASE_API_KEY,
  projectId: process.env.NEXT_PUBLIC_FIREBASE_PROJECT_ID,
  authDomain: process.env.NEXT_PUBLIC_FIREBASE_AUTH_DOMAIN,
});

export const db = getFirestore(app);

• Zmienne NEXT_PUBLIC_* są widoczne w przeglądarce — nie umieszczaj tam sekretów backendowych Julii (klucze Gemini, CheckWX itd.).

• Dostęp do dokumentów sesji / użytkownika tylko dla uwierzytelnionych tożsamości zgodnych z regułami organizacji.
• Odrzuć domyślne reguły testowe (allow read, write: if true) przed produkcją.
• Indeksy złożone pod zapytania geograficzne/czasowe — monitoruj komunikaty w konsoli Firebase.

• Nasłuch Firestore na dokumentach sesji (zgodnie z implementacją repo).
• Stan: online/offline, ostatnia znana pozycja, znaczniki czasu.
• Odporność: brak uprawnień / błąd sieci nie powinien crashować UI.

• Kontener z klasą wymuszającą wysokość (hangar-leaflet-root).
• Warstwy kafelków: jałowy / satelita — logika w komponentach projektu.
• Markery zsynchronizowane z Firestore (w architekturze Hangar); nie z MQTT Julii z PDF.

• Server Components tam, gdzie brak interakcji; Client Components dla mapy i providerów.
• dynamic import dla ciężkich modułów mapy w razie potrzeby.

• Reguły Firestore przetestowane w emulatorze.
• i18n kompletne dla etykiet dashboardu.
• Brak sekretów w bundle klienta.
• Webhook Stripe weryfikowany podpisem.
• Rozdzielone konta kluczy: Hangar (public config) vs Julia desktop (sekretne).