docs: Offene Punkte und Deploy-Schritte in TODO.md festhalten

Vier Entscheidungen stehen aus (Rollenmodell mit Superadmin, appweite
Flag-Typen, Melderecht fuer den Trail-Status, Kader statt Event-Fahrer) und
drei Dinge passieren ausserhalb des Repos: PUBLIC_CARTO_API_KEY in Coolify,
die drei neuen Migrationen samt Datenverlust bei events.status, und einmal
Typen neu erzeugen.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014dh9W1i7aLSdPYJzQPid5o

TODO.md

@@ -0,0 +1,115 @@
+# Offene Punkte
+
+Stand: 2026-09-02. Was hier steht, ist bewusst nicht erledigt — entweder weil
+es eine Entscheidung braucht oder weil es außerhalb des Repos passiert.
+
+## Entscheidungen
+
+### Rollenmodell: Superadmin appweit
+
+Geplant sind drei Rollen: **Superadmin** (appweit, über alle Teams),
+**Team-Admin** (Owner/Admins eines Teams, gibt es schon) und **Mitglied**.
+
+Umsetzung, sobald die zwei Fragen unten geklärt sind:
+
+- `users.superadmin` als Bool-Feld.
+- Die `updateRule` der users-Collection muss dabei
+  `@request.body.superadmin:isset = false` ergänzen — sonst kann sich jeder
+  Nutzer selbst befördern, denn er darf seinen eigenen Datensatz ändern.
+
+Offen:
+
+1. **Vorhandene Team-Flags.** Flag-Typen sollen appweit gelten (siehe unten).
+   Heute hat jedes Team seinen eigenen Satz. Zusammenführen und Duplikate von
+   Hand aufräumen, oder alle behalten und ab sofort global sichtbar machen?
+2. **Erster Superadmin.** Den kann nur jemand direkt im PocketBase-Admin
+   setzen. Reicht ein Hinweis im Migrationskommentar, oder soll es eine
+   Superadmin-Verwaltung in den Einstellungen geben?
+
+### Flag-Typen appweit statt pro Team
+
+Hängt am Rollenmodell. Heute ist `trail_flags` team-gebunden: Das Feld `team`
+existiert, der Store filtert danach, lesen darf das Team, schreiben Owner und
+Admins.
+
+Ziel: `team` entfällt, lesen für alle Eingeloggten, schreiben nur Superadmin.
+Die Typen werden damit App-weite Vorschläge, aus denen jedes Team auswählt.
+
+### Trail-Status: dürfen Mitglieder melden?
+
+Anzeige und Herkunft (`status_changed`, `status_by`) sind fertig. Ändern darf
+den Status weiterhin nur, wer Pate oder Team-Admin ist — `trails.updateRule`
+lässt nichts anderes zu.
+
+Sollen alle Teammitglieder melden dürfen, braucht es eine Regel, die genau ein
+Feld freigibt: `team.users.id ?= @request.auth.id` kombiniert mit
+`@request.body.<feld>:isset = false` für **jedes** andere Feld. Das
+funktioniert, wird aber lang und bricht still, sobald ein Feld dazukommt.
+Deshalb erst nach ausdrücklicher Entscheidung.
+
+### Fahrer: Kader oder Event-Teilnehmer?
+
+`riders.event` bindet einen Fahrer an genau ein Event. Ein in den Einstellungen
+angelegter Fahrer ohne Event steht deshalb nur im Verzeichnis und taucht in
+keiner Zeitnahme auf; der Dialog hat dafür ein optionales Event-Feld.
+
+Ein echter Team-Kader, aus dem man Fahrer in Events übernimmt, wäre eine
+n:m-Beziehung — also eine Schema-Änderung, keine Oberflächenfrage.
+
+### Mitglied per E-Mail einladen
+
+Die alte Einladung über eine E-Mail-Suche ist entfallen und durch „Mitglied
+anlegen" ersetzt. Sie konnte nie funktionieren: `users.listRule` gibt nur den
+eigenen Datensatz frei, die Suche lief immer ins Leere.
+
+Ein **bestehendes** fremdes Konto in ein Team zu holen braucht eine offenere
+`listRule` (z. B. `@request.auth.id != ""`). Das erlaubt allerdings, alle
+Konten der Instanz aufzulisten — deshalb bewusst nicht ohne Rücksprache.
+
+## Vor dem nächsten Deploy
+
+### `PUBLIC_CARTO_API_KEY` in Coolify setzen
+
+Die Kartenkacheln kommen von CARTO. Der Schlüssel muss den Browser erreichen,
+deshalb das `PUBLIC_`-Präfix — ohne das reicht SvelteKit ihn nicht weiter.
+
+Gelesen wird er über `$env/dynamic/public`, das heißt: Die Variable muss in der
+**Laufzeitumgebung** des `node build`-Prozesses stehen, nicht nur zur Buildzeit.
+In Coolify als normale Umgebungsvariable eintragen genügt. Fehlt sie, laufen die
+Kacheln ohne Schlüssel weiter — die Karte bleibt also sichtbar.
+
+### Migrationen greifen beim nächsten Start
+
+Drei neue Migrationen liegen in `backend/pb_migrations/`:
+
+- `1754500500_riders_user_and_admin_rules.js`
+- `1754500600_events_dates_instead_of_status.js`
+- `1754500700_trail_status_meta.js`
+
+**Achtung:** Die mittlere entfernt `events.status` **samt seiner Werte**. Das
+ist so gewollt (Events werden datiert statt bewertet), aber es ist ein
+Datenverlust und nicht zurückzunehmen.
+
+Ebenfalls neu: Fahrer anlegen, ändern und löschen darf ab dann nur noch die
+Teamleitung. Mitglieder ohne Admin-Rolle verlieren diese Möglichkeit auch auf
+der Event-Seite.
+
+### Typen einmal neu erzeugen
+
+`frontend/src/lib/types.d.ts` wurde bei den letzten Schema-Änderungen von Hand
+ergänzt (`riders.user`, `trails.status_by`/`status_changed`,
+`events.starts`/`ends` statt `status`). Grund: `pocketbase-typegen` braucht
+native sqlite3-Bindings, die in der Arbeitsumgebung nicht gebaut werden durften.
+
+```bash
+cd frontend && npm run generate-pocketbase-types
+```
+
+Die Datei sollte danach unverändert bleiben. Tut sie es nicht, gilt das Ergebnis
+des Generators.
+
+## Kleinigkeiten
+
+- Der Melder eines Trail-Markers („wer") zeigt bis zum Deploy „Unbekannt". Die
+  gelockerte `users.viewRule` kommt mit `1754500500`.
+- `NAMING.md` und `frontend/static/pedaler.svg` liegen bewusst nur lokal.