admin-mrrm/mrrmlabapp

Fork 0

[Epic] Public Roadmap + Changelog — interaktiv in der App #378

New issue

Open

opened 2026-05-21 23:27:56 +02:00 by admin-mrrm · 2 comments

admin-mrrm commented

2026-05-21 23:27:56 +02:00

Owner

Vision

End-User können direkt in der App (web + mobile) interaktiv die Roadmap einsehen — was als nächstes kommt, was gerade läuft, was bereits geliefert wurde (= Changelog). Texte sind user-freundlich, keine internen Issue-Titel.

Ziel

Transparenz für den User: er weiß was passiert / passieren wird
Single-Source-of-Truth vom PM gepflegt, kein Engineer-Eingriff nötig zum Aktualisieren
Done-Section ersetzt klassische Changelog-Files

Architektur-Skizze

PM pflegt → roadmap.json (Repo) → API liest → /roadmap UI (web + mobile)

roadmap.json im Repo-Root von mrrmlabapp
API-Endpoint GET /roadmap (NestJS) liest JSON, transformiert, serviert
UI-Route /roadmap in Web + Mobile, drei Sektionen: Erledigt (Changelog), Aktuell, Geplant

Datenmodell (Entwurf — arch-question folgt)

{
  "version": 1,
  "items": [
    {
      "id": "einkaufen-feature",
      "title": "Einkaufen-Bereich",
      "summary": "Eigener Bereich für Einkaufslisten mit Einkaufs-Modus.",
      "status": "now",                    // "done" | "now" | "next"
      "plannedRelease": "2026-Q2",
      "releasedAt": null,                  // ISO date when status==done
      "linkedIssues": ["mrrmlabapp#112"]   // optional, für Transparenz
    }
  ]
}

Phasen

Roadmap-Datenmodell + Schema-Validation — Schema festlegen, roadmap.json initial befüllen (PM-Arbeit + Schema-Validation als arch-question).
Read-API — NestJS-Endpoint GET /roadmap, liest JSON aus File-System oder Repo. (arch-question: File vs. DB-Cache? Auth? Public-endpoint ja/nein?)
UI Web — Route /roadmap, drei Sektionen, Cards mit Status-Badge.
UI Mobile — gleiches in Expo, Drawer-Eintrag.
Filter / Detail — Klick auf Item zeigt linkedIssues + Details. (Optional)
Auto-Sync — Wenn ein verknüpfter Issue auf Gitea geschlossen wird, könnte releasedAt auto-gesetzt werden. (Optional, später)

Was kein Scope ist (für jetzt)

Voting / Kommentar-Funktion für User auf Roadmap-Items (separates Future-Feature)
Mehrsprachigkeit (Deutsch reicht)
Bidirektionale Sync mit Gitea-Milestones (zu fragil, manuelle Kuration ist sauberer)

Offene arch-questions (werden separat geöffnet)

Datenhaltung: roadmap.json im Repo vs. DB-gepflegt? PM-Edit-Flow?
Auth: Public-Endpoint (ohne Keycloak) oder eingeloggte User?
Schema-Validation: Zod im API + Build-Time-Check im CI?
Wo lebt das JSON-File deployment-seitig (Repo-checkout im Container vs. Bundling)?

Akzeptanz (Epic-Ebene)

User kann unter /roadmap in Web + Mobile die drei Sektionen sehen
PM kann roadmap.json mit einem Commit ändern → erscheint nach Deploy in der App
Changelog ist rückblickend auswertbar (alle status: "done" Items mit releasedAt-Datum, absteigend sortiert)

## Vision End-User können direkt in der App (web + mobile) **interaktiv die Roadmap einsehen** — was als nächstes kommt, was gerade läuft, was bereits geliefert wurde (= Changelog). Texte sind user-freundlich, keine internen Issue-Titel. ## Ziel - Transparenz für den User: er weiß was passiert / passieren wird - Single-Source-of-Truth vom PM gepflegt, kein Engineer-Eingriff nötig zum Aktualisieren - Done-Section ersetzt klassische Changelog-Files ## Architektur-Skizze ``` PM pflegt → roadmap.json (Repo) → API liest → /roadmap UI (web + mobile) ``` - **`roadmap.json`** im Repo-Root von `mrrmlabapp` - API-Endpoint `GET /roadmap` (NestJS) liest JSON, transformiert, serviert - UI-Route `/roadmap` in Web + Mobile, drei Sektionen: **Erledigt** (Changelog), **Aktuell**, **Geplant** ## Datenmodell (Entwurf — arch-question folgt) ```jsonc { "version": 1, "items": [ { "id": "einkaufen-feature", "title": "Einkaufen-Bereich", "summary": "Eigener Bereich für Einkaufslisten mit Einkaufs-Modus.", "status": "now", // "done" | "now" | "next" "plannedRelease": "2026-Q2", "releasedAt": null, // ISO date when status==done "linkedIssues": ["mrrmlabapp#112"] // optional, für Transparenz } ] } ``` ## Phasen 1. **Roadmap-Datenmodell + Schema-Validation** — Schema festlegen, `roadmap.json` initial befüllen (PM-Arbeit + Schema-Validation als arch-question). 2. **Read-API** — NestJS-Endpoint `GET /roadmap`, liest JSON aus File-System oder Repo. (arch-question: File vs. DB-Cache? Auth? Public-endpoint ja/nein?) 3. **UI Web** — Route `/roadmap`, drei Sektionen, Cards mit Status-Badge. 4. **UI Mobile** — gleiches in Expo, Drawer-Eintrag. 5. **Filter / Detail** — Klick auf Item zeigt linkedIssues + Details. (Optional) 6. **Auto-Sync** — Wenn ein verknüpfter Issue auf Gitea geschlossen wird, könnte `releasedAt` auto-gesetzt werden. (Optional, später) ## Was *kein* Scope ist (für jetzt) - Voting / Kommentar-Funktion für User auf Roadmap-Items (separates Future-Feature) - Mehrsprachigkeit (Deutsch reicht) - Bidirektionale Sync mit Gitea-Milestones (zu fragil, manuelle Kuration ist sauberer) ## Offene arch-questions (werden separat geöffnet) - [ ] Datenhaltung: `roadmap.json` im Repo vs. DB-gepflegt? PM-Edit-Flow? - [ ] Auth: Public-Endpoint (ohne Keycloak) oder eingeloggte User? - [ ] Schema-Validation: Zod im API + Build-Time-Check im CI? - [ ] Wo lebt das JSON-File deployment-seitig (Repo-checkout im Container vs. Bundling)? ## Akzeptanz (Epic-Ebene) - User kann unter `/roadmap` in Web + Mobile die drei Sektionen sehen - PM kann `roadmap.json` mit einem Commit ändern → erscheint nach Deploy in der App - Changelog ist rückblickend auswertbar (alle `status: "done"` Items mit `releasedAt`-Datum, absteigend sortiert)

admin-mrrm added this to the Backlog — Ideas & Vision milestone

2026-05-21 23:27:56 +02:00

admin-mrrm added the

labels

2026-05-21 23:27:56 +02:00

pm-bot referenced this issue

2026-05-25 22:30:22 +02:00

[Sprint-Queue] v0.4.6 — Hotfix-Reihenfolge für Devs #405

pm-bot referenced this issue

2026-05-27 22:43:32 +02:00

Portfolio-Status KW 2026-W22 #412

pm-bot referenced this issue

2026-06-06 15:42:30 +02:00

Portfolio-Status KW 2026-W23 #436

pm-bot referenced this issue

2026-06-06 16:01:23 +02:00

arch-q: Public Roadmap (#378) — Datenhaltung, Auth, Schema-Validation, Deployment #437

pm-bot commented

2026-06-06 16:01:49 +02:00

Collaborator

Audit 2026-06-06 — Epic-Stand

Nach 2 Wochen ohne Aktivität ein Stand-Check. Was existiert, was offen ist, was zuerst kommen muss.

Implementiert (Phase 1 teilweise)

roadmap.json im Repo-Root mit releases[]-Feld, gepflegt beim Release-Cut (zuletzt v0.6.5).
scripts/extract-changelog.mjs liest releases[] und erzeugt Markdown für den Drone-gitea-release-Step.
items[]-Feld existiert in der Struktur, ist aber leer — Roadmap-Items (Now/Next/Done) im Sinne des Epics sind noch nicht gepflegt.
$schema-Verweis in roadmap.json zeigt auf ./roadmap.schema.json — Datei existiert nicht, Schema-Validation fehlt komplett.

Offen

Phase 1 vollständig: Schema (Zod oder JSON-Schema) anlegen, items[] initial befüllen.
Phase 2: NestJS GET /roadmap-Endpoint.
Phase 3: Web-Route /roadmap mit drei Sektionen.
Phase 4: Mobile-Route /roadmap mit Drawer-Eintrag.
Phase 5: Filter/Detail (optional).
Phase 6: Auto-Sync Gitea→releasedAt (optional, später).

Blocker

Die vier im Body skizzierten arch-questions (Datenhaltung, Auth, Schema-Validation, JSON-Deployment) sind bisher nicht eröffnet worden. Sie sind strukturell für Phase 1+2 und damit für alles Weitere.

→ Gebündelt eröffnet als #437 (arch-q) — wartet auf @arch-bot.

Nächste Schritte (PM-Plan)

Antwort auf #437 abwarten und in Produkt-Entscheidungen übersetzen.
Phase 1 abschließen: Schema + items[] initial befüllen (kleines Sub-Issue).
Phase 2: API-Endpoint (Sub-Issue).
Phasen 3+4: UI parallel (web + mobile, Sub-Issues).
Phasen 5+6 später optional.

Das Epic bleibt offen; Sub-Issues folgen nach #437-Antwort.

## Audit 2026-06-06 — Epic-Stand Nach 2 Wochen ohne Aktivität ein Stand-Check. Was existiert, was offen ist, was zuerst kommen muss. ### Implementiert (Phase 1 teilweise) - `roadmap.json` im Repo-Root mit `releases[]`-Feld, gepflegt beim Release-Cut (zuletzt v0.6.5). - `scripts/extract-changelog.mjs` liest `releases[]` und erzeugt Markdown für den Drone-`gitea-release`-Step. - `items[]`-Feld existiert in der Struktur, ist aber **leer** — Roadmap-Items (Now/Next/Done) im Sinne des Epics sind noch nicht gepflegt. - `$schema`-Verweis in `roadmap.json` zeigt auf `./roadmap.schema.json` — **Datei existiert nicht**, Schema-Validation fehlt komplett. ### Offen - **Phase 1 vollständig:** Schema (Zod oder JSON-Schema) anlegen, `items[]` initial befüllen. - **Phase 2:** NestJS `GET /roadmap`-Endpoint. - **Phase 3:** Web-Route `/roadmap` mit drei Sektionen. - **Phase 4:** Mobile-Route `/roadmap` mit Drawer-Eintrag. - **Phase 5:** Filter/Detail (optional). - **Phase 6:** Auto-Sync Gitea→`releasedAt` (optional, später). ### Blocker Die vier im Body skizzierten arch-questions (Datenhaltung, Auth, Schema-Validation, JSON-Deployment) sind bisher **nicht eröffnet** worden. Sie sind strukturell für Phase 1+2 und damit für alles Weitere. → Gebündelt eröffnet als **#437 (arch-q)** — wartet auf @arch-bot. ### Nächste Schritte (PM-Plan) 1. Antwort auf #437 abwarten und in Produkt-Entscheidungen übersetzen. 2. Phase 1 abschließen: Schema + `items[]` initial befüllen (kleines Sub-Issue). 3. Phase 2: API-Endpoint (Sub-Issue). 4. Phasen 3+4: UI parallel (web + mobile, Sub-Issues). 5. Phasen 5+6 später optional. Das Epic bleibt offen; Sub-Issues folgen nach #437-Antwort.

pm-bot commented

2026-06-06 16:08:16 +02:00

Collaborator

Produkt-Entscheidung (Decision Record 2026-06-06)

Nach Architekt-Antwort in #437 die folgenden Entscheidungen für die Public-Roadmap-Epic-Umsetzung. Beziehe mich auf die dort begründeten Empfehlungen.

Entscheidung 1 — Datenhaltung: JSON-File im Repo ✅

roadmap.json bleibt Single-Source-of-Truth. PM pflegt per Commit. Kein DB-Modell, kein Edit-UI. Git übernimmt Audit/Diff/Revert.

Entscheidung 2 — Auth: Public-Endpoint mit Rate-Limit + Cache-Header ✅

GET /api/v1/roadmap ohne Keycloak-Guard. @nestjs/throttler mit ~60 req/min/IP. Cache-Control: public, max-age=300.

Entscheidung 3 — Schema-Validation: Zod als SoT + generiertes JSON-Schema für CI ✅

apps/api/src/roadmap/roadmap.schema.ts enthält Zod-Definition (kanonisch).
scripts/sync-roadmap-schema.mjs generiert daraus roadmap.schema.json (über zod-to-json-schema).
CI-Step validate-roadmap lintet roadmap.json gegen die Schema-Datei (ajv).
API parst beim Boot via Zod — bei Drift: kein Start, klares Log.

Entscheidung 4 — Deployment: Bundling via COPY ins Image ✅

apps/api/Dockerfile kopiert roadmap.json ins Image. API liest beim Boot, In-Memory-Cache TTL=Infinity. Re-Deploy bei Roadmap-Änderung.

Übernommene Folge-Punkte aus #437

items[] und releases[] bleiben beide im Schema — komplementäre Semantik. releases[] für extract-changelog.mjs (Release-Notes); items[] für UI-Now/Next/Done.
API-Output wird transformiert (nach Status gruppiert, releases absteigend sortiert) — nicht das rohe JSON 1:1.
linkedIssues[] als String-Array ({repo}#{number}-Format, Schema-validiert).
i18n out-of-scope für jetzt — title/summary als plain string.
Phase 1.5 als eigenes Sub-Issue: items[] initial mit ~10–15 Roadmap-Items aus aktuellem Backlog befüllen.

Sub-Issues, die jetzt aufgemacht werden

Phase 1: Schema (Zod + JSON-Schema-Gen + CI-Validate) — Sub-Issue folgt
Phase 1.5: items[] initial befüllen — Sub-Issue folgt
Phase 2: GET /api/v1/roadmap NestJS-Endpoint — Sub-Issue folgt
Phase 3: Web-Route /roadmap — Sub-Issue folgt
Phase 4: Mobile-Route /roadmap — Sub-Issue folgt
Phase 5 (Filter/Detail) und Phase 6 (Auto-Sync): optional, später entscheiden

#437 schließe ich als beantwortet.

## Produkt-Entscheidung (Decision Record 2026-06-06) Nach Architekt-Antwort in #437 die folgenden Entscheidungen für die Public-Roadmap-Epic-Umsetzung. Beziehe mich auf die dort begründeten Empfehlungen. ### Entscheidung 1 — Datenhaltung: **JSON-File im Repo** ✅ `roadmap.json` bleibt Single-Source-of-Truth. PM pflegt per Commit. Kein DB-Modell, kein Edit-UI. Git übernimmt Audit/Diff/Revert. ### Entscheidung 2 — Auth: **Public-Endpoint mit Rate-Limit + Cache-Header** ✅ `GET /api/v1/roadmap` ohne Keycloak-Guard. `@nestjs/throttler` mit ~60 req/min/IP. `Cache-Control: public, max-age=300`. ### Entscheidung 3 — Schema-Validation: **Zod als SoT + generiertes JSON-Schema für CI** ✅ - `apps/api/src/roadmap/roadmap.schema.ts` enthält Zod-Definition (kanonisch). - `scripts/sync-roadmap-schema.mjs` generiert daraus `roadmap.schema.json` (über `zod-to-json-schema`). - CI-Step `validate-roadmap` lintet `roadmap.json` gegen die Schema-Datei (ajv). - API parst beim Boot via Zod — bei Drift: kein Start, klares Log. ### Entscheidung 4 — Deployment: **Bundling via COPY ins Image** ✅ `apps/api/Dockerfile` kopiert `roadmap.json` ins Image. API liest beim Boot, In-Memory-Cache TTL=Infinity. Re-Deploy bei Roadmap-Änderung. ### Übernommene Folge-Punkte aus #437 1. `items[]` und `releases[]` bleiben **beide** im Schema — komplementäre Semantik. `releases[]` für `extract-changelog.mjs` (Release-Notes); `items[]` für UI-Now/Next/Done. 2. API-Output wird transformiert (nach Status gruppiert, releases absteigend sortiert) — nicht das rohe JSON 1:1. 3. `linkedIssues[]` als String-Array (`{repo}#{number}`-Format, Schema-validiert). 4. i18n out-of-scope für jetzt — `title`/`summary` als plain string. 5. **Phase 1.5** als eigenes Sub-Issue: `items[]` initial mit ~10–15 Roadmap-Items aus aktuellem Backlog befüllen. ### Sub-Issues, die jetzt aufgemacht werden - [ ] **Phase 1:** Schema (Zod + JSON-Schema-Gen + CI-Validate) — Sub-Issue folgt - [ ] **Phase 1.5:** `items[]` initial befüllen — Sub-Issue folgt - [ ] **Phase 2:** `GET /api/v1/roadmap` NestJS-Endpoint — Sub-Issue folgt - [ ] **Phase 3:** Web-Route `/roadmap` — Sub-Issue folgt - [ ] **Phase 4:** Mobile-Route `/roadmap` — Sub-Issue folgt - Phase 5 (Filter/Detail) und Phase 6 (Auto-Sync): optional, später entscheiden #437 schließe ich als beantwortet.

pm-bot referenced this issue

2026-06-06 16:08:19 +02:00

arch-q: Public Roadmap (#378) — Datenhaltung, Auth, Schema-Validation, Deployment #437

No milestone

No project

No assignees

2 participants

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

admin-mrrm/mrrmlabapp#378

No description provided.

Rows
Columns