pingu-concerts/docs/wiki/Firebase-Setup-Prompt.md

ChatGPT-Prompt: Firebase-E2E-Wiederholung für MetalCircle

Den folgenden Prompt in einen neuen Chat kopieren. Keine Secret-Dateien mitgeben.

Hilf mir, den bereits eingerichteten serverseitigen Firebase-Zugang für MetalCircle
im lokalen Entwicklungs-/Testbetrieb zu prüfen oder den lokalen FCM-E2E-Test zu
wiederholen. Verwende aktuelle offizielle Firebase-/Google-Cloud-Dokumentation,
falls IAM-Fehler untersucht werden müssen.

Ausgangslage:
- Privates Projekt MetalCircle, Repository historisch kai/pingu-concerts.
- Android: Capacitor 6, Package ID dauerhaft de.pinguholic.concerts.
- Firebase-Projekt-ID: `metalcircle-30d9b`.
- Android-google-services.json ist vorhanden. Tokenregistrierung und manuelle
  Firebase-Testnachrichten/Kampagnen funktionieren bereits.
- Backend: FastAPI, PostgreSQL, Docker Compose, firebase-admin Python 7.1.0.
- Pushs für Freundschaftsanfragen, Direktnachrichten und Einladungen sind implementiert.
  Kategorien und DE/EN werden pro Empfänger beachtet; Nachrichteninhalt bleibt privat.
- Lokaler Versand wurde mit einem echten Android-Gerät über FCM HTTP v1 erfolgreich
  getestet. Falls der HTTP-403 `PERMISSION_DENIED` erneut auftritt, wurde für den
  dedizierten Test-Service-Account diese Rolle als erforderlich bestätigt:
  `roles/firebasecloudmessaging.admin` (Firebase Cloud Messaging API Admin).
- Der lokale Service Account ist
  `metalcircle-push-local@metalcircle-30d9b.iam.gserviceaccount.com`.
- Die Service-Account-Datei wird lokal schreibgeschützt als
  `/run/secrets/firebase-service-account.json` eingebunden.

Bitte begleite mich bei:
1. Den bestehenden Projekt-, Service-Account- und read-only-Mount-Status anhand
   ungefährlicher Metadaten prüfen; keine neue Rolle oder Schlüsseldatei anlegen.
2. Nur bei einem erneuten Versandfehler die FCM HTTP-v1-Aktivierung und die
   Zuweisung von `roles/firebasecloudmessaging.admin` für genau diesen lokalen
   Service Account im Projekt `metalcircle-30d9b` prüfen.
3. Lokale `.env`-Konfiguration nur auf gesetzte Werte prüfen, nie Inhalte ausgeben:
   PUSH_ENABLED=true
   FIREBASE_PROJECT_ID=<echte Projekt-ID>
   FIREBASE_SERVICE_ACCOUNT_FILE=<absoluter Pfad zur Secret-Datei>
4. Lokaler Start mit `compose.yml` plus `compose.push.yml`. Dieses Override mountet die Datei
   read-only unter /run/secrets/firebase-service-account.json und setzt im Backend
   GOOGLE_APPLICATION_CREDENTIALS auf diesen Pfad.
   Lokal HTTP: COOKIE_SECURE=false docker compose -f compose.yml -f compose.push.yml up -d --build web
   Auf einem HTTPS-Testserver bleibt COOKIE_SECURE=true.
5. Falls erforderlich, gezielten lokalen E2E-Test mit Testkonten ausführen:
   Freundschaftsanfrage, Nachricht, Veranstaltungseinladung und echter Android-
   Empfang. Bei erneutem HTTP 403 zuerst die bereinigte Fehlerantwort, Zielprojekt,
   aktive Service-Account-Identität und Projektrollen prüfen; bei Erfolg keine
   unnötigen Tests, Builds oder Cloud-Änderungen ausführen.

Grenzen:
- Niemals Schlüssel, Tokens, vollständige .env oder JSON-Inhalte im Chat anfordern.
- google-services.json ist Client-Konfiguration, kein Backend-Service-Account.
- Keine Legacy-Server-Keys und keine Admin-Credentials in der Android-App.
- kai = persönlicher Gitea-Account; codex-bot = Git; metalcircle-bot = Issue-API.
  Keinen dieser Zugänge für Firebase verwenden.
- PinguCore ist lokal. Cloud-Staging betreue ich separat. Kein automatischer
  Cloud-/Produktionszugriff oder Produktionsdeployment.
- Test und Produktion bekommen getrennte Credentials.
- Verbietet eine Organisationsrichtlinie JSON-Schlüssel, umgehe sie nicht.
  Erkläre die vorgesehenen Alternativen und welche Code-Anpassung nötig wäre.

Frage zuerst nur nach der Ziel-Testumgebung und gehe dann schrittweise vor.
Prüfe Ergebnisse anhand ungefährlicher Statusangaben, niemals Secret-Inhalte.