README: Ausblick durch den tatsaechlichen Stand ersetzt

Alle 15 Typen sind gebaut — der Abschnitt beschrieb noch die Planung. Statt
dessen: wie ein weiterer Typ dazukommt, und was als Naechstes sinnvoll waere.

README.md

@@ -30,7 +30,7 @@ entscheidet die Verwaltung — nicht gebrauchte lassen sich ausblenden.
 - [Technischer Aufbau](#technischer-aufbau)
 - [Entwicklung ohne Docker](#entwicklung-ohne-docker)
 - [API](#api)
-- [Ausblick Version 2](#ausblick-version-2)
+- [Einen weiteren Typ ergänzen](#einen-weiteren-typ-ergänzen)
 
 ---
 
@@ -860,25 +860,39 @@ curl -X POST http://localhost:3000/api/codes \
 
 ---
 
-## Ausblick Version 2
+## Einen weiteren Typ ergänzen
 
-Geplant sind die übrigen 14 Typen: vCard, App-Link, Mehrere Links, Social
-Media, WhatsApp, PDF, Bild, Video, E-Mail, SMS, Standort, Zahlung, WLAN und
-Feedback.
-
-Die Architektur ist darauf ausgelegt — ein neuer Typ besteht aus:
+Alle 15 vorgesehenen Typen sind gebaut. Kommt ein sechzehnter dazu, besteht er
+aus:
 
 1. **einem Modul** in `src/lib/qr/types/` (Zod-Schema, Kodierung, Kurzfassung),
 2. **einer Formular-Komponente** in `src/components/qr-forms/`,
-3. **je einem Eintrag** in `src/lib/qr/registry.ts` (ersetzt dort den
-   `defineComingSoonType`-Platzhalter) und in
-   `src/components/qr-forms/index.ts`.
+3. **je einem Eintrag** in `src/lib/qr/registry.ts` und in
+   `src/components/qr-forms/index.ts`,
+4. **einer Landingpage** in `src/components/landing/`, falls er `hasLandingPage`
+   meldet.
 
-Am bestehenden Code aus Version 1 ist dafür nichts zu ändern: Vorschau,
-Download, Gestaltung, Speicherung dynamischer Codes und die Weiterleitung
-arbeiten für alle Typen gleich.
+Am übrigen Code ist dafür nichts zu ändern: Vorschau, Download, Gestaltung,
+Speicherung, Weiterleitung, Liste und Verwaltung arbeiten für alle Typen
+gleich. Die Kennung gehört zusätzlich in `QR_TYPE_IDS` in
+`src/lib/qr/type-module.ts`.
 
-Typen, die statt einer Weiterleitung eine eigene Landingpage brauchen (etwa
-„Mehrere Links“ oder „Feedback“), setzen dafür `redirectTarget` auf eine
-interne Adresse — auch dafür ist keine Änderung am Datenmodell nötig, weil
-`data` als JSONB gespeichert wird.
+Für einen angekündigten, aber noch nicht gebauten Typ gibt es
+`defineComingSoonType`: Er erscheint als Kachel mit dem Badge „Bald
+verfügbar“ und lässt sich nicht öffnen.
+
+Braucht der Typ eine hochgeladene Datei, meldet er ihre Ids über `uploadIds` —
+daran hängt, was beim Löschen des Codes mitgeht und was als verwaist
+weggeräumt wird.
+
+### Was als Nächstes sinnvoll wäre
+
+- **Gruppen aus dem Verzeichnis übernehmen.** Die OIDC-Anbindung übernimmt
+  heute bewusst nur die Identität. Eine Zuordnung von Verzeichnisgruppen zu
+  Gruppen dieser Anwendung wäre möglich, braucht aber eine klare Regel dafür,
+  was mit von Hand vergebenen Rollen passiert.
+- **Statistik über die Zeit.** Der Zähler weiß heute nur, wie oft und wann
+  zuletzt. Ein Verlauf je Tag wäre eine eigene Tabelle — und die Frage, wie
+  lange man ihn aufbewahrt.
+- **Codes exportieren.** Eine CSV aller Codes einer Gruppe, für die Übergabe
+  an Druckereien.