Read-only PRD for a coding agent

Wanderer wollen eine Route planen und gleichzeitig passende Unterkünfte entlang der…

18 of 18 sections ready

What Malin learned

Ich fand es sehr cool zu lernen wie schnell es mit KI geht eine App zu bauen, v.a. mit dem prd help tool ist es viel einfacher als gedacht, da präzise Fragen abgefragt werden, die man als Nicht-Informatiker schnell vergisst. Bei meiner App ging es ziemlich gut anfangs voran, leider bin ich dann an dem Punkt ins stocken gekommen, als es darum ging, in der App meinen Standort anzeigen zu lassen und sie mit Booking.com zu koppeln, aber ich glaube selbst diese Probleme kann ich mit mehr Recherche lösen.

1. Problem, goal & success metric

Problem: Wanderer wollen eine Route planen und gleichzeitig passende Unterkünfte entlang der Strecke finden, ohne zwischen mehreren Apps zu wechseln.

Ziel: Eine iOS- und Android-App (React Native mit Expo), die Wanderrouten plant, Beispielwanderungen zeigt und Unterkünfte im Umkreis von max. 500 m zur Route anzeigt; Geltungsbereich Europa.

Erfolgsmetrik: Gesamtzahl abgeschlossener Wanderungen in Europa. Eine Wanderung gilt als abgeschlossen, wenn der Nutzer sie mit einem Haken bestätigt – im Live-Tracking oder manuell in der gespeicherten Route. Kein Zielwert festgelegt.

2. Users & roles

Hauptnutzer: Wanderer und Outdoor-Fans, die Tageswanderungen oder Mehrtagestouren planen.

Rollen (vorläufig): Gast (nur ansehen), registrierter Nutzer (eigene Routen speichern).

3. Core workflows

Kern-Workflow:

Nutzer startet entweder eine leere Route oder wählt eine Beispielwanderung als Vorlage.
Nutzer setzt Start- und Zielpunkt auf der Karte; Wegpunkte können hinzugefügt und verschoben werden.
Nutzer gibt seine gewünschte Tagesstrecke in km an (Standard 15 km).
Die App teilt die Route automatisch in Etappen nach dieser Tagesstrecke; jede Etappe endet an einem Ort mit Übernachtungsmöglichkeit.
Etappenenden können verschoben werden; danach werden die Unterkünfte neu geladen.
Pro Etappenende werden bis zu 20 Unterkünfte im Umkreis von max. 500 m zur Route angezeigt, sortiert nach Abstand, dann Bewertung.
Nutzer speichert die Route inklusive Etappen.

4. Features & requirements

Must-have:

Beispielwanderungen anzeigen (Liste + Karte)
Route auf Karte erstellen und bearbeiten (Start, Ziel, Wegpunkte ziehen)
Tagesstrecke in Kilometern eingeben (Standard 15 km)
Automatische Etappenteilung nach Tagesstrecke in km; jede Etappe endet an einem Ort mit Übernachtungsmöglichkeit. Höhenmeter fließen NICHT in die Teilung ein.
Etappenenden sind vorgeschlagen, vom Nutzer frei verschiebbar; nach Verschieben werden Unterkünfte neu geladen
Höhenprofil unter der Karte mit Höhenverlauf der Route, Etappen farblich abgegrenzt
Höhenmeter je Etappe und gesamt werden als Information angezeigt
Live-GPS-Tracking während einer aktiven Wanderung: aktuelle Position markiert im Höhenprofil und auf der Karte, bereits gegangene Kilometer und Höhenmeter werden angezeigt
Pro Etappenende Unterkünfte mit Abstand zur Route ≤ 500 m, Obergrenze 20 Stück, sortiert nach Abstand, dann Bewertung; Klick öffnet Booking-Suchlink
Routen speichern und laden (nur registrierte Nutzer, kostenlos)
Haken „abgeschlossen“ pro gespeicherter Route setzen und wieder entfernen; abgeschlossene Routen erscheinen im Bereich „Geschafft“ mit Abschlussdatum
Anzeige der Gesamtzahl abgeschlossener Wanderungen
Offline-Karte: Kacheln entlang der Route (ca. 1 km Korridor) vor der Wanderung herunterladen und wieder löschen

5. Scope: must / later / never

Must:

Routenplanung mit selbst gesetztem Start und Ziel, Wegpunkten
Beispielwanderungen als anpassbare Vorlagen
Etappenteilung der Route, Unterkünfte am Etappenende
Unterkünfte ≤ 500 m zur Route (Booking-Verlinkung im Prototyp)
Europa als Geltungsbereich

Later:

Booking-Partner-API mit direkter Buchungsübersicht
Mehrtagestouren mit Übernachtungsplanung, Etappen-Feinsteuerung

Never:

Eigene Buchungsabwicklung für Unterkünfte
Eigene Kartendaten oder Komoots proprietäres Routing

6. Screens & UI

Hauptansicht: Wie im Screenshot „images/Bildschirmfoto-2026-10-21-um-15.02.00.jpg“ gezeigt: Karte im Wanderkarten-Stil (OpenTopoMap), Route in Grün, nummerierte Wegpunkt-Marker, Start-/Ziel-Marker, verschiebbare Wegpunkte und Etappenenden.
Seitenleiste / Bedienung: Tabs „Route“, „Unterkünfte“, „Etappen“; Übersicht mit Distanz, Gehzeit, Etappen, Aufstieg, Abstieg; Eingabe der Tagesstrecke in km.
Höhenprofil: unter der Karte, Etappen farblich abgegrenzt, Klick auf das Profil setzt Etappengrenze.
Live-Modus: aktuelle Position im Höhenprofil und auf der Karte markiert; bereits gegangene Strecke grau (#9E9E9E), verbleibende Strecke in Routenfarbe; Anzeige gegangener km und Höhenmeter. images/Bildschirmfoto-2026-10-21-um-15.02.00.jpg

7. Design system & visual style

Komponentenbibliothek: React Native Paper

Farben (Hex):

Primär: #2E7D32 (helles Waldgrün, bestätigt)
Akzent: #FF8F00
Hintergrund: #FFFFFF
Text: #1B1B1B
Bereits gegangene Strecke: grau (#9E9E9E)

Schrift: Inter
Eckenradius: 12 px
Abstand: 8-px-Raster
Karte und Höhenprofil: wie im Screenshot „images/Bildschirmfoto-2026-10-21-um-15.02.00.jpg“ (OpenTopoMap-Stil, Route grün, Höhenprofil mit Etappenfarben); Darstellung bleibt unverändert im Design.
Ton: sachlich und outdoor-orientiert, Komoot-ähnliche Bedienung.
Light/Dark Mode: Light Mode zuerst, Dark Mode später.

8. Data model

Nutzer (Supabase Auth)

field	type	required
id	uuid	ja
email	text	ja
created_at	timestamp	ja

Beispielwanderung

field	type	required
id	uuid	ja
name	text	ja
description	text	ja
why_good	text	ja
waypoints	jsonb (Reihenfolge, lat/lng)	ja
default_daily_km	numeric (Standard 15)	ja
region	text	ja

Nur lesbar für alle Nutzer.

Route

field	type	required
id	uuid	ja
user_id	uuid (FK Nutzer)	ja
name	text	ja
daily_km	numeric (Standard 15)	ja
waypoints	jsonb (Reihenfolge, lat/lng)	ja
completed	boolean (Standard false)	ja
completed_at	timestamp (leer, wenn nicht abgeschlossen)	nein
created_at	timestamp	ja
updated_at	timestamp	ja

Etappe

field	type	required
id	uuid	ja
route_id	uuid (FK Route)	ja
number	integer	ja
start_lat	numeric	ja
start_lng	numeric	ja
end_lat	numeric	ja
end_lng	numeric	ja
distance_km	numeric	ja
ascent_m	integer	ja
descent_m	integer	ja
moved_by_user	boolean (Standard false)	ja

Unterkünfte: nicht gespeichert, bei jeder Anfrage live geladen.

Offline-Kacheln: nur lokal auf dem Gerät, pro Route, nicht im Backend.

9. APIs & integrations

Unterkünfte: Verlinkung auf Booking.com-Suchergebnisse entlang der Route im Prototyp (keine API, keine Buchungsabwicklung). Partner-API später.
Karte: OpenTopoMap-Kacheln (OpenStreetMap-Daten) im Outdoor-/Komoot-ähnlichen Stil, Höhenprofil unter der Route.
Routing: OSRM für Wanderwege (Vorschlag, noch zu bestätigen).
Geltungsbereich: Europa.

10. Auth, permissions & security

Registrierung: kostenlos, E-Mail mit Passwort, Passwort-Zurücksetzen per E-Mail.
Rollen: Gast (nur ansehen, Beispielwanderungen, Karte, Unterkünfte), registrierter Nutzer (zusätzlich Routen speichern und laden).
Standort: Berechtigung wird vor Start einer Wanderung erfragt; ohne Berechtigung bleibt die Route nutzbar, nur das Live-Tracking ist aus.

11. Performance, privacy & accessibility

Standort (GPS): Position wird nur während einer aktiven Wanderung erfasst, nur auf dem Gerät gehalten und nach Ende nicht gespeichert.
Akku: Tracking nur mit Hinweis auf Akkuverbrauch, manuell beendbar.
Offline: Pro Route herunterladbar, Korridor 1 km (je 500 m links und rechts der Route); Speicherbedarf wird vor dem Download angezeigt; Kacheln lassen sich pro Route wieder löschen.
Datenschutz: Gespeichert werden nur Routen (Wegpunkte, Etappenenden, Tagesstrecke) und Kontodaten; keine GPS-Historie.
Plattformen: iOS und Android.

12. Edge cases & errors

Keine Unterkünfte im 500-m-Korridor: Meldung 'Keine Unterkünfte im Umkreis von 500 m gefunden', Route bleibt nutzbar.
Keine Route gefunden (OSRM nicht erreichbar): Meldung mit Wiederholen-Button, Wegpunkte bleiben erhalten.
Kein GPS-Signal während Wanderung: Hinweis anzeigen, letzte bekannte Position bleibt markiert, Tracking läuft weiter sobald Signal da ist.
Keine Standortberechtigung: Route bleibt nutzbar, nur Live-Tracking ist deaktiviert.
Offline-Download abgebrochen: Teilstand wird verworfen, Route bleibt online nutzbar, Hinweis zum erneuten Download.
Netz fehlt beim Laden von Unterkünften: letzte geladene Liste bleibt sichtbar mit Hinweis 'Stand von ...'.
Verschobenes Etappenende außerhalb der Route: Verschieben wird auf die Route eingerastet, Etappenende bleibt auf dem Weg.

13. Stack & constraints

Plattform: Native iOS- und Android-App aus einer Codebasis.
Framework: React Native mit Expo, TypeScript.
Karte: MapLibre Native, OpenTopoMap-Kacheln als Quelle.
Routing: OSRM (Wanderwege), Aufruf über eigenes Backend-Wrapper oder direkt.
Backend: Supabase (Postgres, Auth mit E-Mail/Passwort).
Offline: Kachel-Cache lokal auf dem Gerät pro Route (1 km Korridor).

14. Existing code & do-not-change

Stand: Der Nutzer hat mit OpenCode begonnen. Es liegt noch kein Repository vor; der Stand existiert nur lokal im OpenCode-Projekt.

Vorgehen: Der Coding-Agent prüft den OpenCode-Stand zuerst und übernimmt nur, was zu React Native mit Expo und TypeScript passt. Danach wird ein Git-Repository angelegt.

Darf verändert werden: alles, insbesondere Projektstruktur und Code.
Nicht verändern (Design-Vorgaben): Design-System (Farben, Schrift, Radius), Höhenprofil und Kartenansicht in ihrer festgelegten Darstellung.

15. Build order

Karte und Beispielwanderungen: Karte im Outdoor-Stil (wie Screenshot) mit Beispielwanderungen als Liste und Karte, Auswahl öffnet Route als Vorlage.
Routenplanung: Start, Ziel, Wegpunkte setzen und verschieben, Routing über OSRM.
Etappen und Höhenprofil: Tagesstrecke in km, automatische Etappenteilung, verschiebbare Etappenenden, Höhenprofil mit Höhenmetern.
Unterkünfte: Abfrage im 500-m-Korridor pro Etappenende, Liste bis 20 Stück, Booking-Suchlink.
Konto und Speichern: E-Mail-Registrierung, Passwort-Reset, Routen speichern und laden, Bereich „Geschafft“.
Live-Tracking und Offline-Karte: GPS während Wanderung, gegangene Strecke farblos, Kachel-Download pro Route, Löschen.

16. Acceptance criteria & tests

Route mit mind. zwei Wegpunkten lässt sich auf der Karte erstellen, verschieben und speichern; nach Neuladen identisch.
Eingabe einer Tagesstrecke von 15 km teilt eine 40-km-Route in drei Etappen; jede Etappe endet an einem Ort mit Übernachtungsmöglichkeit.
Verschobenes Etappenende lädt die Unterkünfte für diese Etappe neu; Liste enthält maximal 20 Einträge, sortiert nach Abstand, dann Bewertung.
Jede angezeigte Unterkunft liegt höchstens 500 m von der Route entfernt.
Klick auf eine Unterkunft öffnet den Booking-Suchlink.
Höhenprofil zeigt Höhenverlauf, Etappen farblich abgegrenzt, Höhenmeter je Etappe und gesamt; Darstellung entspricht dem Screenshot.
Während einer aktiven Wanderung wird die aktuelle Position im Höhenprofil und auf der Karte markiert; bereits gegangene Strecke ist grau, gegangene km und Höhenmeter werden angezeigt.
Ohne Anmeldung lassen sich Routen nicht speichern; mit Anmeldung lassen sie sich speichern und laden.
Haken „abgeschlossen“ lässt sich in einer gespeicherten Route setzen; die Route erscheint im Bereich „Geschafft“ mit Abschlussdatum; die Gesamtzahl abgeschlossener Wanderungen wird angezeigt.
Offline-Download einer Route zeigt vorher den Speicherbedarf und lädt Kacheln im 1-km-Korridor; die Route ist danach ohne Netz sichtbar, inkl. Höhenprofil.
Offline-Download lässt sich nur von registrierten Nutzern starten.
Routen lassen sich nach dem Speichern wieder löschen (Kacheln werden entfernt).
Beispielwanderungen erscheinen als Liste und auf der Karte, inkl. Begründung; Auswahl übernimmt die Route als bearbeitbare Vorlage.
Ein Coding-Agent-Build verbindet sich nur mit dem Entwicklungs-Supabase-Projekt, nicht mit Produktion.

17. Deployment, environments & secrets

Umgebungen: Entwicklung und Produktion, jeweils eigenes Supabase-Projekt.
Repository: Git-Repository wird vor Start des Coding-Agenten angelegt.
Entwicklung: Test mit Expo Go.
Testversionen: EAS Build, TestFlight (iOS) und Google Play Internal Testing (Android).
Secrets: Supabase-URL und Anon-Key über Umgebungsvariablen (.env), nicht im Repository.
Veröffentlichung: Nach Abnahme über App Store und Google Play.

18. Open questions & assumptions

Default: OpenTopoMap plus OSRM als Karten- und Routing-Basis, Komoots eigene Karte wird nicht übernommen.
Default: Unterkünfte im Prototyp über Booking-Verlinkung statt Partner-API.
Offen: Region zum Start innerhalb Europas (Vorschlag: Deutschland und Alpen).

Images

images/Bildschirmfoto-2026-10-21-um-15.02.00.jpg