Abgrenzung des Funktionsumfangs und die geplanten Phasen. Grundsatz: MVP zuerst, radikale Scope-Reduktion; neue Wuensche wandern in den Backlog mit Phasen-Zuordnung, statt den aktuellen Umfang zu verwaessern. DACH-Strukturen sind vorbereitet, aber DE-first fuer den ersten Release.
Stand: 2026-07-05 (aktualisiert: Wettbewerbsanalyse Jagdgefaehrte, PO-Entscheidungen GPS-Grenzerfassung + R5 Erfassungsart).
| Phase |
Inhalt |
Status |
| 0 Fundament |
Stack/Architektur, Datenmodell, Rollen-/Rechtemodell, Offline-/Sync-Geruest |
erledigt (Backend) |
| 1 Revier abbilden |
Benutzer-/Revierverwaltung, digitale Revierkarte + Fotos, Jagdzeiten-Basis |
Backend umgesetzt |
| 2 Reviereinsatz |
Wildbeobachtungen, Streckenliste, Abschussplan Soll/Ist |
Backend teils umgesetzt |
| 3 Team & Betrieb |
Aufgaben/Wartung, Einsatz-/Gemeinschaftsjagdplanung, Chat, Push, Kalender, Mailings, Teilen |
geplant |
| 4 Kontext |
Wettermodul |
geplant |
Hinweis: Das Backend ist mit Claude Code ueber den urspruenglichen Sprint-0-Umfang hinaus fachlich breit gewachsen (Auth, Reviere, Karte, Wild, Regelwerke, Medien, Sync, Auswertung, Abo, Loeschkonzept 105 Tests). Der erste Client (Flutter-Mobile-App) ist seit Sprint 1 in Arbeit, siehe Abschnitt Aktueller Stand (Client).
¶ Aktueller Stand (Backend)
Umgesetzt und getestet: Auth (Keycloak/OIDC), Reviere + Mitglieder + Grenze, Kartenobjekte, Beobachtung + Strecke, Regelwerke/Jagdzeiten mit Legalitaetspruefung, Medien (MinIO, EXIF-Stripping, Share-Links), Sync (inkrementell, Konflikte), Auswertung, Abo/Free-Limits, DSGVO-Loeschkonzept. Details: siehe docs/STATUS.md im Repo und die Seite Architektur & ADRs.
¶ Aktueller Stand (Client, Sprint 1)
Erstes Frontend = Flutter-Mobile-App (Zielarchitektur). Entwicklung und Vorschau im Browser (Web-Server-Modus, Port 8090, --release); native Handy-Builds folgen spaeter am Mac. Einrichtung: siehe Seite Entwicklungsumgebung.
- Etappe 1 erledigt: Flutter SDK (stable 3.44.4, WSL2) + Projektgeruest app/ im Repo (android/ios/web).
- Etappe 2 erledigt: App-Skelett mit Demo-Daten (Revier-Auswahl mit Rolle, Bottom-Navigation, Beobachtungs- und Strecken-Listen). Demo-Daten liegen hinter einer Repository-Schnittstelle und werden in Etappe 4 ohne UI-Aenderung gegen die echte API getauscht.
- Designsystem V1.0 vom PO verabschiedet (2026-07-04): "Modernes Outdoor-Design trifft professionelle GIS-Software"; Farbwelt Deep Forest / Copper, Manrope als lokale Font-Assets (kein Google-Runtime-Fetch, DSGVO/Autarkie), Bottom-Navigation mit 5 Tabs (Karte / Beobachtung / Strecke / Aufgaben-Platzhalter / Mehr), 8 Designprinzipien. Verbindliche Quelle: docs/design/designsystem-v1.md im Repo (plus Mockups unter docs/design/).
- Etappe 2b beauftragt: zentrales Theme (app/lib/theme/), Umstellung des Skeletts auf das Designsystem.
- Naechste Etappen: 3 = Kartenscreen MapLibre (Autarkie-Pruefpunkt: V1.0 fordert Hybridstil mit Satellit, OpenMapTiles liefert keine Orthofotos – freie Landesquellen pruefen), 4 = Backend-Anbindung (Keycloak-Login, echte Revierliste), 5 = Offline/Sync-Fundament.
- UI-Titel bleibt neutral "Revier-App", Bundle-IDs unveraendert (Marktname offen).
- Boundary-Import (Premium) mit expliziter Quelle / Flurstueck-Uebernahme.
- Konflikt-/Tombstone-Cleanup mit privilegierter Wartungsrolle.
- CI-Pipeline (Forgejo Actions + Runner).
- Web-Portal (Flutter Web vs. React – ADR weiter offen; der Mobile-Client laeuft bereits als Sprint 1, siehe Aktueller Stand Client).
- Server-seitige Mailings (autarkiekonformer SMTP-Weg, ADR offen).
- Externes Teilen via natives Share-Sheet (rollen-/rechtebeschraenkt).
- Jagdboerse (ADR-0006).
- KI/LLM-Funktionen (dedizierter ADR offen; Grundsatz: Schema an LLM senden, nie echte Standort-/Beobachtungsdaten).
- Wildkamera-Funktionen (Haftungsfragen offen).
- AT/CH-Aktivierung (Strukturen vorhanden, Daten fehlen).
- Konkrete Free-Limits (aktuell Platzhalter 6 Kartenobjekte / 50 Beobachtungen).
- Downgrade-Verhalten fuer premium-erstellte Inhalte.
- Web-Frontend Flutter Web vs. React; Message Queue RabbitMQ vs. NATS; Payment-Provider (Mollie/SEPA-Tendenz); Hosting-Provider.
| Datum |
Aenderung |
| 2026-07-04 |
Erstfassung: Phasen, aktueller Backend-Stand, Backlog, offene Entscheidungen. |
| 2026-07-05 |
Nachtrag: Wettbewerbsanalyse Jagdgefaehrte/Revierwelt, PO-Entscheidungen GPS-Grenzerfassung + R5 Erfassungsart. |
¶ Stand & offene Punkte (Nachtrag 2026-07-04)
An diesem Tag getan: PO-Entscheidungen bestaetigt (Auth = Keycloak festgelegt, ADR-0011 geschlossen; Free-Limits und Downgrade-Verhalten bewusst auf Pilotphase vertagt). Wiki-Dokumentation vollstaendig aufgesetzt. Namensfindung fuer den Marktnamen begonnen. CI-Pipeline versucht, aber vertagt.
Die Einrichtung des Forgejo Actions Runners wurde NICHT abgeschlossen. Ursache: Forgejo 15 nutzt ein neues Runner-Registrierungsverfahren (Web-UI erzeugt UUID + Token), das von den verfuegbaren Runner-Images (4.0.0 und 11) nicht passend umgesetzt wird (alter register-Weg -> "token not found"; neuer daemon-Weg -> "unknown flag: --url" bzw. "registration file not found"). Ausgeschlossen als Ursache: Token, URL, Volume, Actions-Aktivierung, Signin-View. Aufgeraeumt: Runner/DinD entfernt, Compose auf Forgejo+DB zurueckgesetzt, Actions serverseitig bleibt aktiviert. NAECHSTER SCHRITT: exakt zueinander passende Forgejo/Runner-Versionen ermitteln ODER Forgejo auf v14 fuer den bewaehrten register-Weg. CI ist Komfort, kein Blocker (Backend + 105 Tests laufen manuell via pytest).
Marktname "RevierManager" ist im Zielmarkt besetzt (direkter Wettbewerber WW Reviermanager GmbH). Interner Repo-Name bleibt. Strategie: Kunstwoerter. Favoriten zur Registrar-Pruefung: Revira, Revio, Hego (je .de/.com/.at). Nach Namenswahl: Markenregister-Check DPMA + EUIPO. Bis dahin laeuft die Entwicklung namensunabhaengig weiter.
¶ Stand & offene Punkte (Nachtrag 2026-07-05)
An diesem Tag getan: Wettbewerbsanalyse Jagdgefaehrte (Hunter & Co. / MyHunt) inkl. Web-App-Inspektion und Nutzerfeedback-Recherche; PO-Entscheidungen zu GPS-Grenzerfassung, Apple Watch und Erfassungsart Streckenliste (R5). Autoritative Quellen im Repo: docs/wettbewerb/2026-07-05-jagdgefaehrte.md und docs/entscheidungen/2026-07-05-r5-erfassungsart-streckenliste.md.
- Jagdgefaehrte: Platzhirsch (500k+ Downloads, Verbandspartnerschaften, Garmin-Integration, eigene WildCam-Hardware). Web-Version nur PRO (69,99 EUR/Jahr); Google-Maps-Basiskarte (Fremd-Cloud, laufende API-Kosten). Belegte Schwaechen: Offline unzuverlaessig, dokumentierte Datenverlust-Faelle, falsche Jagdzeiten trotz Bezahlversion, Waldreviere kaum kartierbar, nachtraeglich verschaerfte Free-Limits mit Nutzer-Backlash.
- Revierwelt: zweiter Wettbewerber und Preisanker (5 Jaeger ab ca. 42 EUR/Jahr); funktional stark beim Abschussplan; Streckenlisten-UI dient uns als Vorbild. Eigenes Kurz-Briefing noch offen.
- Ableitung: unsere Kernprinzipien (Offline-First in allen Tarifen, sichtbare Konfliktbehandlung, versionierte Jagdzeiten mit Rechtsfreigabe, autarke Kartenbasis) adressieren exakt die belegten Schwaechen.
- GPS-Grenzerfassung im MVP-Grenzen-Editor: Eckpunkt-Modus UND Abgeh-Modus (bewusste Scope-Erweiterung; akzeptierte Risiken Android-Hintergrund-GPS, Track-Glaettung, Akku sind im Repo-Briefing dokumentiert). Ergaenzend: Kartenobjekte am aktuellen Standort (Ansitz, Erlegestelle, Falle, ...), Erlegestelle mit Strecken-Eintrag verknuepft; Feld-UI mit grossem Vollbild-Button (handschuhtauglich).
- Apple Watch / Wear OS: nur Zielbild-Notiz, kein Backlog-Item (Flutter unterstuetzt watchOS/Wear OS nicht; eigene native Plattform waere unverhaeltnismaessig).
- R5 Erfassungsart Streckenliste: Pflicht-Enum abschuss / hegeabschuss / fallwild / verkehrsverlust / unfallwild_sonstig; Erleger nur bei Abschussarten Pflicht (Erfasser immer protokolliert); Foto-Aufnahme in allen drei Erfassungswegen (Strecke, Beobachtung, Kartenobjekt) ueber die separate Upload-Queue (ADR-0003 Klasse 3).
- Rechts-Check Orientierungsgrenze: UI-Hinweis + Nutzungsbedingungen, dass GPS-erfasste Grenzen keine amtliche Vermessung sind (Formulierungspflicht, kein Blocker).
- Anrechnung der Erfassungsarten auf den Abschussplan je Bundesland -> bestehender Rechts-Check Modul 5/6/13.
- Schema-Check harvest_entry (traegt es die Erfassungsart bereits?) -> Arbeitsauftrag nach Etappe-5-Abnahme, ggf. additive Migration.
- Backlog-Kandidaten neu: Blur-Preview-Pattern fuer Free-Limits, Karte drucken, private revierunabhaengige Marker (Pruefung vs. Mandantenmodell), Fotos in allen Erfassungswegen.
- PRO-Testmonat Jagdgefaehrte: vertagt bis vor Umsetzung des eigenen Grenzen-Editors (dann gezielt mit Testprotokoll).