From bf89ef01c71c5f3a326777befa6a34767c9dfc66 Mon Sep 17 00:00:00 2001 From: "Christoph K." Date: Sun, 5 Apr 2026 20:59:23 +0200 Subject: [PATCH] Add hashtag requirements (REQ-TAG-*) and backlog tasks (T073-T087) Co-Authored-By: Claude Sonnet 4.6 --- README.md | 37 +++++++++++++++++++++++++++++++++++++ 1 file changed, 37 insertions(+) diff --git a/README.md b/README.md index ce4dccf..56c490f 100644 --- a/README.md +++ b/README.md @@ -114,6 +114,19 @@ REQ-OPENAPI-04: Cookie-basierte Auth für Web-Endpoints SOLL im OpenAPI über ty 3.11 Google Play / Transparenz REQ-PRIV-01: Bei Standortzugriff im Hintergrund MUSS eine klare In-App-Erklärung/Disclosure vorhanden sein; Background-Location ist zu begründen und sauber zu deklarieren. +3.13 Hashtags +REQ-TAG-01: Trackpoints und manuelle Punkte MÜSSEN mit einem oder mehreren Hashtags versehen werden können (z. B. `#restaurant`, `#aussicht`, `#hotel`). + +REQ-TAG-02: Hashtags MÜSSEN lokal in SQLite/Room gespeichert und beim Upload zum Server übertragen werden (als Teil des Trackpoint-Schemas, Feld `tags: string[]`). + +REQ-TAG-03: Der Server MUSS Hashtags persistieren und pro Trackpoint/Stop abfragbar machen. + +REQ-TAG-04: Die Webapp MUSS eine Filteransicht bieten, die alle Trackpoints eines Tages oder Trips nach einem oder mehreren Hashtags filtert. + +REQ-TAG-05: Hashtags SOLLEN bei der Eingabe in der App als Vorschläge angezeigt werden (aus bereits verwendeten Tags des Nutzers). + +REQ-TAG-06: Die Webapp SOLL eine Tag-Übersicht bieten, die alle verwendeten Hashtags des Nutzers mit Häufigkeit auflistet. + 3.12 Dokumentationsstil REQ-DOC-STYLE-01: Alle wesentlichen Anforderungen, Architekturentscheidungen, API-Contracts, Testanforderungen und Tasks MÜSSEN in diesem Markdown gepflegt werden. @@ -362,6 +375,10 @@ GET /v1/stops?date=YYYY-MM-DD GET /v1/suggestions?date=YYYY-MM-DD +GET /v1/tags (alle Tags des Nutzers mit Häufigkeit) + +GET /v1/trackpoints?tag=restaurant (Filter nach Hashtag) + Web UI Routes (serverseitig gerendert): GET /login @@ -391,6 +408,8 @@ source: "gps" | "manual" (optional; Default: gps) note (string, optional; nur bei manuellen Punkten) +tags (string[], optional; Hashtags ohne #-Präfix, z. B. ["restaurant", "aussicht"]) + optional: accuracy_m, speed_mps, bearing_deg, altitude_m Stop: @@ -550,6 +569,14 @@ REQ-TEST-GEO-02: Provider-Wechsel muss testbar sein (Config umstellen → andere T084: Tests: Unit Tests für Validierung + Mapping; Integrationstest: Manual point → Queue → Upload → Ack. +Hashtags (Android): + + T085: Room-Schema erweitern: tags-Feld (String-Array) in Trackpoint-Entity + Migration. + + T086: UI: Hashtag-Eingabe in Compose (manueller Punkt + GPS-Punkt nachträglich taggen), Vorschläge aus vorhandenen Tags. + + T087: Upload: tags-Feld in Batch-Payload einbeziehen. + 8.3 Server (Go, HTTP + Web UI) API / Persistenz: @@ -593,6 +620,16 @@ OpenAPI: T072: OpenAPI in CI validieren (Spec-Validation) und Änderungen nur via PR. +Hashtags (Server + Webapp): + + T073: DB-Schema: tags-Spalte (text[]) in trackpoints-Tabelle + Migration + Index (GIN für Array-Suche). + + T074: API: tags in Ingest-Endpoints annehmen und speichern; GET /v1/tags (Häufigkeit) und GET /v1/trackpoints?tag=... implementieren. + + T075: Webapp: Tag-Filter in Tagesdetail; Tag-Übersicht (/tags); Tags bei Trackpoints anzeigen. + + T076: OpenAPI: tags-Feld in Trackpoint-Schema + neue Endpoints dokumentieren. + 8.4 Tests T040: Use-Case-Matrix (Use Case → Testart).