App Check ist jetzt vollständig live und gerätegetestet (Deploy 49b7f44,
Bestätigung durch Chris). Die Datenschutz-Hosting-Anleitung ersetzt den
vagen Platzhalter-Vorschlag durch Chris' konkretes Setup: eigene Domain
über Cloudflare vor dem Hetzner-VPS, inkl. Origin-Certificate und
nginx-Vorlage.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Chris meldete die Fehlermeldung trotz hinterlegtem Debug-Token — Ursache
ist eine bekannte Race im firebase_app_check-Plugin (nativer Standard-
Provider "deviceCheck" vor dem Dart-seitigen activate()-Aufruf), nicht
ein Konfigurationsfehler. Einmalig, ohne Funktionsauswirkung.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Umtopf-Flow (inkl. Nächstes-Fälligkeitsdatum-Nachbesserung) und
Stellplatz-Bewertung vom Nutzer bestätigt — damit ist Diagnose,
Umtopf-Erinnerungen und Stellplatz-Bewertung vollständig abgeschlossen.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Nutzer vermisste beim Umtopf-Test eine Info, wann das nächste Umtopfen
ansteht (Formular/Checkliste zeigten nur "alle X Monate"/"zuletzt am").
Berechnung aus due_tasks_provider public gemacht statt dupliziert.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Letzter Roadmap-Punkt von V3. Foto-basierte Lichtverhältnis-Analyse pro
Stellplatz (Cloud Function analyzeLocation) und darauf aufbauende, rein
textbasierte Eignungs-Bewertung einer Pflanze (assessPlantFit) — beides
ausschließlich auf Abruf, nicht automatisch (Kostenkontrolle, eigener
Anthropic-Key). Neue Stellplatz-Detailseite, Verlinkung im Pflanzen-Detail,
Erkennung veralteter Bewertungen bei Umzug/Neuanalyse.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Erledigte 🟡-Blöcke in den verifizierten Stand überführt (Auth komplett,
V3 Bausteine 1+2), offene Fäden gebündelt (Gerätetests, Stellplatz-
Bewertung mit Konzeptfragen), Session-Erkenntnisse zu den Stolperfallen
(Berechtigungsfilter/Deploys via Nutzer, Riverpod-3-Pausierung,
users-Doc vs. householdId, Anführungszeichen, Bash-cwd).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Dritter Aufgabentyp repotting im Intervall-Modell: optionales
repottingIntervalMonths + lastRepotted/By am Pflanzenprofil, Formular
mit Intervall-Feld und Datums-Auswahl, Umtopf-Zeile im Detail,
Aufgaben in Checkliste und Sammel-Push (reminders.ts gespiegelt),
Sitter dürfen bestätigen (Rules-Allowlist). Monats-Arithmetik kürzt
den 31. auf den Monatsletzten. Ende-zu-Ende-Widget-Test.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Neue Route /plants/:id/diagnoses mit PlantDiagnosesScreen; im Detail
ersetzt der Button „Frühere Untersuchungen" (deaktiviert bei leerer
Historie) die Inline-Liste. Ergebnis-Sheet nach diagnosis_sheet.dart
ausgelagert und von beiden Screens genutzt.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Jede Diagnose landet automatisch in households/{id}/plants/{id}/diagnoses;
das Pflanzen-Detail zeigt die Liste (Ampel-Icon, Kurzbefund, Datum),
Antippen öffnet das Ergebnis-Sheet mit Untersuchungsdatum, volle
Mitglieder können Einträge löschen. Rules: read/create für alle im
Haushalt (auch Sitter), delete nur member, update nie. Widget-Test
navigiert bis ins Sheet.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Neue Cloud Function diagnosePlant: Foto + optionale Art an Claude,
deutsches JSON-Ergebnis (Befund/Ursache/Behandlung/Vorbeugung).
App: PlantDiagnosisService + Untersuchen-Sektion im Pflanzen-Detail
mit Ergebnis-Bottom-Sheet und KI-Disclaimer. askClaude max_tokens
1024→2048 (adaptives Denken zählt mit ins Limit). Deploy steht aus.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Der Konsolen-Hinweis betrifft nur den nativen google_sign_in-Flow; unser
Browser-Flow braucht kein SHA-1. Debug-SHA-1/SHA-256 trotzdem per
firebase apps:android:sha:create registriert (für später, z. B. App Check).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Wie Apple über den eingebauten GoogleAuthProvider (Browser-Flow über den
Firebase-Auth-Handler, kein Zusatz-Paket). Gemeinsamer Provider-Handler
im Login-Screen, l10n-Strings, iOS-URL-Scheme (Encoded App ID) für den
Rückweg aus dem Browser, Doku Schritt 8. Der reaktive Haushalts-Bootstrap
deckt den ersten Google-Login automatisch ab. Offen: Google-Provider in
der Firebase-Konsole aktivieren + Gerätetest.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Das Umschalten vom Warte-Bildschirm auf die App remountete den ganzen
App-Baum, während Riverpod noch Provider-Abhängigkeiten nachzog — das
löste die 'setState() or markNeedsBuild() called during build'-Warnung
aus. Der Splash liegt jetzt als deckende Stack-Ebene über der durchgehend
gemounteten App. Handoff: Bug vom Nutzer als behoben bestätigt.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Die Push-Registrierung legt users/{uid} per merge selbst an (fcmTokens,
timezone) — beim kaputten Apple-Account existierte das Dokument daher
ohne householdId, und Gate + Bootstrap hielten den Account für fertig.
Jetzt prüfen beide auf householdId; der Bootstrap schreibt das
users-Dokument mit merge, damit die Push-Felder erhalten bleiben.
Neuer Test bildet exakt diesen Zustand ab.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Der Bootstrap hing an signInWithApple und lief erst, nachdem der Router
den Nutzer schon in die App geleitet hatte — Fehler blieben unsichtbar,
der Account blieb ohne users-Doc/Haushalt und alle Writes scheiterten an
den Rules. Jetzt beobachtet householdBootstrapProvider das users-Dokument
und legt Profil + Haushalt reaktiv an (alle Login-Wege); das BootstrapGate
hält die App so lange zurück und macht Fehler mit „Erneut versuchen"
sichtbar. Bestehende kaputte Accounts heilen beim nächsten Start selbst.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
- AuthRepository.signInWithApple() via eingebautem AppleAuthProvider
(nativ auf iOS, Web-Flow über Firebase-Handler auf Android, ohne Zusatzpaket)
- Haushalts-Bootstrap in gemeinsamen Helper _bootstrapHouseholdIfNeeded
ausgelagert; beim ersten Apple-Login wird Profil + Haushalt idempotent angelegt
- LoginScreen: "oder"-Trenner + "Mit Apple anmelden"-Button, Abbruch ohne Fehlermeldung
- l10n: signInWithApple, orDivider, authErrorAppleFailed
- iOS: Entitlement com.apple.developer.applesignin ergänzt
- Doku: firebase-einrichtung.md Schritt 7 (Apple-Login) mit Portal-/Console-Anleitung
Noch offen: Apple-Portal (Services-ID, Sign-in-Key), Firebase-Console-Provider,
Xcode-Capability — danach Ende-zu-Ende auf iOS+Android testen.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Haushalte aus der V1-Zeit haben keinen members-Eintrag für ihren Ersteller,
die Besitzer-Anzeige blieb dadurch leer. Die App trägt die eigene E-Mail
jetzt beim Start in allen eigenen Haushalten nach; die Rules erlauben dafür
nur den eigenen members-Eintrag ohne Rollenwechsel. Bis dahin zeigt die UI
„?" statt einer leeren Stelle.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
- ownerUid je Haushalt (Alt-Haushalte: erster memberUids-Eintrag = Ersteller);
Besitzer-Anzeige in Mitglieder- und Haushaltsliste
- Haushalt umbenennen (Dialog im Haushalts-Screen); Rules erlauben Clients am
Haushalts-Dokument nur noch das Namensfeld
- Cloud Functions leaveHousehold (selbst austreten, auch als Sitter) und
removeMember (nur Besitzer); beide biegen den aktiven Zeiger des Betroffenen
um und legen notfalls einen frischen eigenen Haushalt an
- Haushalts-Wechsler im Drawer (PopupMenu, ab zwei Haushalten)
- Tages-Checkliste und nächste Fälligkeit aggregieren über alle Haushalte,
mit Zwischenüberschrift je Haushalt; Bestätigen schreibt in den
Herkunfts-Haushalt der Aufgabe
- Widget-Tests: Gruppierung, Besitzer-Rechte, Umbenennen
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
- memberUids ist Quelle der Wahrheit, users.householdId nur noch aktiver Zeiger
- Haushalts-Screen: Liste „Meine Haushalte" mit Rolle, Aktiv-Markierung und Wechsel per Tipp
- Beitritts-Dialog warnt nicht mehr vor Datenverlust, sondern erklärt das Zurückwechseln
- sendDailyReminders sammelt fällige Aufgaben aus allen Haushalten des Nutzers
- FirebaseFunctions im HouseholdRepository lazy erzeugt (Widget-Tests ohne Firebase-Init)
- Drawer-Titel mit Ellipsis gegen Overflow auf schmalen Breiten
- Widget-Test für den Haushaltswechsel
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
- Einladen per einmaligem 6-stelligem Code (7 Tage gültig), wahlweise als Mitglied oder Pflanzen-Sitter
- Beitritt über Cloud Function joinHousehold (Transaktion, Admin-Rechte)
- Security Rules: Sitter dürfen an Pflanzen nur Bestätigungs-Felder ändern; invites nur erstellen, nie lesen
- Haushalts-Screen: Mitgliederliste mit Rollen, Einladen, Beitreten mit Wechsel-Warnung
- UI-Gating: Sitter sehen keine Anlegen-/Bearbeiten-/Löschen-Aktionen
- Bestätigungen speichern den Namen (lastWateredBy/lastFertilizedBy), Anzeige im Profil
- Tests: Members-Map im Seed, neuer Sitter-Test
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
- Function läuft alle 15 Min (europe-west3): prüft Erinnerungszeit pro Nutzer (Zeitzonen-korrekt), berechnet fällige Aufgaben, schickt eine Sammel-Push pro Tag, räumt ungültige Tokens auf
- App registriert Gerät nach Login (Berechtigung, Token, Zeitzone), Erinnerungszeit wird ins Nutzer-Dokument synchronisiert
- Doku Schritt 6 inkl. APNs-Anleitung für iOS (sobald Developer Account da ist)
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
- Cloud Function (europe-west3): PlantNet-Erkennung mit Claude-Fallback, deutsches Pflegeprofil von Claude, Keys als Secrets
- Pflanzen-Formular: Foto aufnehmen/wählen, Felder werden automatisch vorbefüllt
- Fotos in Storage unter households/{id}/plant-photos, Anzeige in Liste und Profil
- storage.rules mit Haushalts-Prinzip, iOS-Berechtigungstexte für Kamera/Fotos
- Doku Schritt 5: Storage aktivieren, PlantNet-Key, Secrets setzen
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
- pubspec, Paket-Imports, App-Klasse, ARB-Titel, iOS/Android-Konfiguration
- README und Doku auf neuen Namen und Repo leafittome umgestellt
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
