# PersoEnt: Google Health-Daten-Anbindung — Entscheidung (2026-08-07)

## Verhindert Wiederholung
Nur damit starten zu wollen "Google Health Connect per REST abgiechen" ist ein **totes Pferd** — die nächste Session würde sonst denselben toten Weg vorschlagen.

## Autoreitative Fakten (verifiziert 2026-08-07, Rechen-Agent SwitchHermes + Master)
1. **Google Fit REST API ist DEPRECATED** und wird abgeschaltet. Eine Neuentwicklung darauf ist nicht zukunftssicher.
2. **Google Health Connect** (der Android-Nachfolger) hat **KEINE Server-/REST-Schnittstelle** — nur die Android-App-Erweiterung (SDK auf dem Gerät). Kein serverseitiger Datenpull wie bei alter REST-API.
3. Apple-Pendant: **HealthKit** (iOS, nativ).

## Konsequenz für die Architektur
Um deine (Nutzer-)echten Google-Gesundheitsdaten automatisch zu bekommen, muss PersoEnt **eine native App** sein, nicht nur eine Website:
- **Android:** Health-Connect-SDK nativ in der App → Daten vom Handy lesen
- **iOS:** HealthKit nativ
- App synchronisiert zu unserem **PocketBase**-Backend (VPS) über REST.

## Entscheidung (Nutzerwunsch, 08-07)
**Zuerst ein Android-Prototyp (APK), iOS später.** Nutzer testet APK auf seinem Handy.

## Baustraße / Toolchain-Status
- VPS (Master): Flutter ❌, Java ❌, Android-SDK ❌, adb ❌ — aber reichlich Ressourcen (15 GB RAM, 278 GB frei).
- LaptopHermes (172.24.178.202, RTX 2060): ebenfalls keine Flutter/Java-Toolchain.
- VPS ist headless → APK-Build möglich (Gradle/Build-Tools), aber KEIN Android-Emulator zum In-Test; Nutzer testet die APK direkt am Handy.
- Option A: Flutter auf dem VPS aufsetzen (Master-kontrolliert, DSGVO-sauber, alles unter uns). Option B: auf LaptopHermes bauen.
- Backend + PocketBase laufen bereits (persoent.perfekt-ohne-en.de); das bleibt.

## Nächster Schritt (unentschieden zum Stand des Sessions-Ende)
Baustraße wählen (A: VPS vs B: LaptopHermes), Flutter-SDK + Android-SDK + Gradle installieren, leeren APK-Prototyp bauen, Health-Connect-SDK + PocketBase-Sync danach.