leafittome/docs/handoff.md

Handoff: LeafItToMe (Pflanzenpflege-App)

Stand: 2026-07-24 (Session-Ende). Sprache mit dem Nutzer (Chris): Deutsch.

Projekt in einem Satz

Private Flutter-App (iOS+Android) zur Pflanzenpflege für Haushalt + Pflanzen-Sitter: Foto-Erkennung (PlantNet + Claude), Gieß-/Dünge-/Umtopfplan mit Tages-Checkliste, tägliche Sammel-Push, Krankheits-Diagnose per Foto mit Historie, Haushalt-Teilen per Einladungscode mit Rollen.

Wo alles liegt

• Code: ~/Documents/Projekte/Planty (Ordner heißt noch Planty, Projekt heißt seit Umbenennung leafittome, App-Name „LeafItToMe", Bundle-ID-Platzhalter dev.leafittome.app)
• Git-Remote: selbst gehostetes Forgejo https://git.cshomelabs.work/cschlaefke/leafittome.git (HTTPS + Token im macOS-Schlüsselbund, git push läuft ohne Abfrage)
• Doku (im Repo, deutsch, aktuell halten!): README.md, docs/architektur.md (inkl. Kernentscheidungen: berechnete Aufgaben, reaktiver Haushalts-Bootstrap, Umtopfen als Opt-in-Monatsintervall), docs/firebase-einrichtung.md (Schritt-für-Schritt-Historie aller Backend-Einrichtungen, zuletzt Schritt 8 Google-Login), docs/git-forgejo.md
• Claude-Memory: Projektplan, Nutzerprofil und Backlog liegen im persistenten Memory-Verzeichnis dieser Claude-Code-Installation (werden automatisch geladen)
• Firebase-Projekt: leaf-it-to-me-app (Blaze aktiv, Budget-Alarm eingerichtet; Firebase CLI ist eingeloggt)
• Functions: functions/ (TypeScript, Node 22, Region europe-west3): identifyPlant (PlantNet + Claude, Secrets PLANTNET_API_KEY/ANTHROPIC_API_KEY im Secret Manager), diagnosePlant (V3: Krankheits-Diagnose per Foto, Claude Vision, Modell claude-sonnet-5), analyzeLocation (V3: Standort-Analyse per Foto, Claude Vision, Lichtverhältnisse), assessPlantFit (V3: Eignungs-Bewertung einer Pflanze für ihren Stellplatz, rein textbasiert ohne Foto), sendDailyReminders (alle 15 Min, sammelt Gießen/Düngen/Umtopfen über alle Haushalte eines Nutzers), joinHousehold, leaveHousehold, removeMember
• Auth: E-Mail/Passwort + Apple (iOS nativ, Android Web-Flow) + Google (beide Plattformen Web-Flow, eingebauter GoogleAuthProvider) — Code in lib/features/auth/. Haushalts-Bootstrap läuft reaktiv über householdBootstrapProvider + BootstrapGate (Maßstab: householdId im users-Doc, NICHT Doc-Existenz — die Push-Registrierung legt das users-Doc nebenbei an!). Details der Entscheidung in docs/architektur.md.

Verifizierter Stand

• V1 komplett (Foto → Erkennung → Profil; Checkliste; Sammel-Push), auf Android + iOS Ende-zu-Ende getestet. iOS-Push seit 2026-07-20 eingerichtet und laufend (firebase-einrichtung.md Schritt 6).
• V2/V2.1/V2.2 komplett getestet und bestätigt: Einladungscodes member/sitter, Multi-Haushalt (memberUids = Quelle der Wahrheit, users.householdId = aktiver Zeiger), Besitzer-Konzept, Umbenennen, Haushalts-Wechsler, leaveHousehold/removeMember.
• Apple-Login: implementiert, Bug behoben, vom Nutzer bestätigt (2026-07-23). Der Bug (neuer Apple-Account konnte nichts speichern) hatte zwei Schichten: Bootstrap hing am Login-Aufruf und wurde vom Router-Redirect überholt; UND die Push-Registrierung hatte das users-Doc ohne householdId vorab angelegt, weshalb ein Existenz-Check nicht reichte. Fix: reaktiver Bootstrap + householdId-Maßstab + merge-Writes; selbstheilend für kaputte Accounts. Zusätzlich beseitigt: Riverpod-3-Warnung „markNeedsBuild during build" (BootstrapGate als Stack-Overlay statt Baum-Austausch + checklistWarmupProvider in app.dart gegen das Pausieren unbeobachteter Provider).
• Google-Login: implementiert und deployt (2026-07-23, firebase-einrichtung.md Schritt 8; Debug-SHA-1/SHA-256 per firebase apps:android:sha:create hinterlegt — der SHA-Konsolen-Hinweis betrifft nur den nativen Flow und ist für unseren Browser-Flow irrelevant). Konsolen-Schalter vom Nutzer aktiviert; expliziter Gerätetest nicht rückgemeldet.
• V3 Baustein 1 — Krankheits-Diagnose per Foto: komplett, deployt, vom Nutzer bestätigt („sieht richtig gut aus"). Function diagnosePlant + „Pflanze untersuchen" im Pflanzen-Detail (Kamera/Galerie → Ergebnis-Sheet mit Ampel-Icon, Behandlung, Vorbeugung, KI-Disclaimer; diagnosis_sheet.dart gemeinsam genutzt). Nachbesserungen aus Live-Tests, alle bestätigt: Art-Angabe ist unbestätigter Hinweis (matchesSpecies=false → Warnkasten „Foto zeigt andere Pflanze"), kein HTML/Markdown im Text, konsequentes Duzen. Untersuchungshistorie unter households/{id}/plants/{id}/diagnoses (Rules: read/create alle im Haushalt, delete nur member, update nie), auf eigener Seite /plants/:id/diagnoses; Button „Frühere Untersuchungen" im Detail ist bei leerer Historie deaktiviert.
• V3 Baustein 2 — Umtopf-Erinnerungen: implementiert und deployt (2026-07-23, Commit 81d990d). Dritter Aufgabentyp repotting, als Einziger opt-in (repottingIntervalMonths optional) und in Kalender-Monaten (31. → Monatsletzter; Logik gespiegelt in due_tasks_provider und reminders.ts). Formular mit Intervall-Feld + „Zuletzt umgetopft"-Datum, Checkliste + Push („Umtopfen: …"), Sitter dürfen bestätigen. Rules + sendDailyReminders sind deployt. Gerätetest steht aus.
• V3 Baustein 3 — Stellplatz-Bewertung: implementiert, noch NICHT deployt (2026-07-24). Konzept mit dem Nutzer abgestimmt: Standort-Daten nur per Foto (keine Zusatzfragen zu Himmelsrichtung), Eignungs-Sterne ausschließlich auf Abruf (Kostenkontrolle, eigener Anthropic-Key). Zwei neue Functions analyzeLocation (Foto → Lichtkategorie + Freitext, gespeichert auf PlantLocation) und assessPlantFit (textbasiert, Pflegeprofil + Standort-Analyse → 1-5 Sterne + Begründung, gespeichert auf Plant). Neue Seite LocationDetailScreen (/locations/:id, erreichbar per Tap in der Stellplätze-Liste): Foto/Analyse-Bereich (nur Mitglieder) + Liste zugeordneter Pflanzen mit Sternen oder „Eignung prüfen"-Button (auch für Sitter, informativ). Pflanzen-Detail zeigt den Stellplatz jetzt kompakt mit Sternen und verlinkt dorthin. Veraltete Bewertungen (Pflanze verschoben oder Stellplatz neu analysiert) werden erkannt und als solche markiert statt falscher Sterne. Firestore-Rules erweitert (Sitter dürfen die vier Fit-Felder schreiben). Details/Begründung der Entscheidungen in docs/architektur.md.
• Testabdeckung: 16 Widget-Tests grün (u. a. Bootstrap-Heilung, Untersuchungshistorie bis ins Sheet, Umtopf-Flow Ende-zu-Ende, Stellplatz-Bewertung inkl. Veraltet-Erkennung), Analyzer sauber, tsc kompiliert, Android-Debug-Build ok.

Offen / Nächstes

1. Deploy ausstehend (Nutzer, per ! <kommando>)

V3 Baustein 3 ist fertig implementiert und getestet, aber noch nicht auf Produktion. Nötig, bevor Gerätetests möglich sind:

firebase deploy --only functions:analyzeLocation,functions:assessPlantFit,firestore:rules --project leaf-it-to-me-app

(Frisch angelegte Functions können beim allerersten Aufruf HTTP 401 liefern — siehe Stolperfallen, dann einfach erneut deployen.)

2. Ausstehende Gerätetests (Nutzer, bei Rückmeldung ggf. nachbessern)

• Stellplatz-Bewertung: Stellplatz öffnen → Foto aufnehmen → Licht-Analyse erscheint (Kategorie-Chip + Text); bei einer zugeordneten Pflanze „Eignung prüfen" → Sterne + Begründung erscheinen; Pflanze auf anderen Stellplatz verschieben → alte Sterne werden als veraltet markiert; Pflanzen-Detail zeigt den Stellplatz samt Sternen kompakt an und verlinkt zur Stellplatz-Seite.
• Umtopf-Flow: Pflanze bearbeiten → Intervall 12 Monate + „Zuletzt umgetopft" vor >1 Jahr → Aufgabe „… umtopfen" in Checkliste → Erledigt; Push-Text „Umtopfen: …" beim nächsten regulären Slot.
• Historie-Seite: Button → Liste → Eintrag → Sheet; Löschen mit Rückfrage.
• Google-Login auf iPhone und Android (erster Login eines Google-Kontos muss kurz „Dein Haushalt wird eingerichtet …" zeigen — der reaktive Bootstrap deckt Google automatisch ab).

3. Backlog

Button „KI-Zweitmeinung" bei unbefriedigendem PlantNet-Ergebnis; Push-Anzeige auch bei App im Vordergrund; App Check vor App-Store-Release (firebase-einrichtung.md Schritt 9); Englisch (app_en.arb); firebase-functions-Paket-Upgrade (Deploy-Warnung, mit Breaking Changes — bei Gelegenheit).

Stolperfallen (teuer erkauft, nicht erneut zahlen)

• Deploys und Produktions-Datenzugriffe blockiert der Auto-Mode-Berechtigungsfilter der Session. Nicht dagegen anarbeiten: Kommando fertig vorbereiten und den Nutzer bitten, es per ! <kommando> in der Eingabezeile auszuführen — macht er zuverlässig und prompt.
• Frisch angelegte Gen-2-Functions können beim ersten Aufruf HTTP 401 liefern (fehlende Cloud-Run-Invoker-Berechtigung) → dieselbe Function einfach erneut deployen. Updates bestehender Functions sind nicht betroffen.
• firebase functions:log hinkt 15–20 Minuten hinterher — „keine Läufe" heißt meist nur Log-Verzögerung. Scheduler-Status in der Cloud-Scheduler-Console prüfen lassen.
• Android zeigt FCM-Pushes nur bei App im Hintergrund.
• flutter_timezone ≥5 liefert TimezoneInfo-Objekt → .identifier verwenden (Objekt crasht Firestore-Writes still).
• Die Push-Registrierung legt users/{uid} per merge selbst an (fcmTokens/timezone). Jede Logik, die „Profil existiert" prüfen will, muss auf das Feld householdId schauen, nie auf die Dokument-Existenz.
• Riverpod 3 pausiert Provider ohne aktive Zuhörer; beim Einhängen von Screens mitten im Provider-Update gibt das „setState() or markNeedsBuild() called during build". Gegenmittel im Repo: Overlay statt Baum-Austausch (BootstrapGate) und dauerhaftes Warmhalten kritischer Ketten (checklistWarmupProvider).
• Storage-Rules mit firestore.get() brauchen die IAM-Rolle „Firebase Rules Firestore Service Agent" fürs Storage-Dienstkonto (wurde manuell erteilt).
• Analyzer: build/ und ios/build/ sind in analysis_options.yaml ausgeschlossen (SwiftPM legt dort Fremdcode ab).
• iOS-Fehler „requires minimum platform version 15.0 … but this target supports 13.0": nach flutter clean oder beim Bauen direkt aus Xcode einmal flutter build ios --config-only ausführen (SwiftPM-Paket wird bei pub get mit iOS 13 erzeugt).
• In .arb-Dateien UND in deutschen Texten innerhalb von TS-Strings (Function-Prompts!) typografische Anführungszeichen „…“ verwenden — gerade " brechen das JSON bzw. den TS-String.
• Die Bash-Session wechselt das Arbeitsverzeichnis nicht zurück: nach cd functions && npm run build vor Flutter-Kommandos wieder explizit ins Projekt-Root.
• Nutzer wünscht zu jedem Backend-Baustein begleitende deutsche Doku in docs/ (keine Firebase-Vorerfahrung).

Arbeitsabläufe

• Prüfen vor jedem Commit: flutter analyze && flutter test (Tests mocken Firebase via firebase_auth_mocks/fake_cloud_firestore); bei TS-Änderungen zusätzlich npm run build in functions/; Android-Verifikation: flutter build apk --debug
• Texte: nur in lib/l10n/app_de.arb, danach flutter gen-l10n
• Deploy (führt der Nutzer aus, s. Stolperfallen): firebase deploy --only functions|firestore|storage --project leaf-it-to-me-app
• Nach jedem Arbeitsstand: committen + git push + dieses Handoff aktualisieren (deutsche Commit-Messages, Muster siehe Git-Log)
• Der Nutzer testet auf echten Geräten gegen das Produktions-Firebase und meldet präzise Beobachtungen; gezielte Diagnosefragen (AskUserQuestion) haben sich bewährt

Suggested skills

• /verify — nach nichttrivialen Änderungen den echten Flow treiben (Gerät/Simulator), nicht nur Tests
• /code-review — vor größeren Merges über den Diff laufen lassen
• /run — App starten/screenshotten, wenn Änderungen sichtbar geprüft werden sollen
• claude-api — vor Änderungen an den Claude-Aufrufen in functions/src/ laden (Modell-IDs, Vision, Prompt-Konventionen)