# Offene Punkte Stand: 2026-09-02, abgeglichen mit der produktiven Instanz. Die fachlichen Entscheidungen sind gefallen und gebaut; was hier steht, passiert außerhalb des Repos oder wartet auf den nächsten Deploy. ## 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: sechs gelaufen, fünf offen Abgeglichen mit `api.stammtisch-hersbruck.de` (nur gelesen): Der Backend-Deploy hat alles bis `1754500900` mitgenommen, ab `1754501000` steht es noch aus. | Datei | Was sie tut | Stand | |---|---|---| | `1754500500_riders_user_and_admin_rules` | `riders.user`, Fahrerpflege nur Teamleitung, `users.viewRule`/`createRule` | gelaufen | | `1754500600_events_dates_instead_of_status` | `events.status` raus, `starts`/`ends` rein | gelaufen | | `1754500700_trail_status_meta` | `trails.status_changed`, `status_by` | gelaufen | | `1754500800_trail_markers_custom` | `trail_markers.label`/`icon`, `flag` optional | gelaufen | | `1754500900_users_superadmin` | `users.superadmin` samt Schutz vor Selbstbeförderung | gelaufen | | `1754501000_teams_logo` | `teams.logo` | **offen** | | `1754501100_trails_status_report` | Mitglieder dürfen den Trail-Zustand melden | **offen** | | `1754501200_users_list_for_invites` | `users.listRule` gelockert (Kontosuche) | **offen** | | `1754501300_event_participants` | neue Collection, **verschiebt Daten**, entfernt `riders.event`/`number` | **offen** | | `1754501400_events_timing_participation` | `events.timing`/`participation` | **offen** | | `1754501500_event_series` | `event_series`, `events.series` | **offen** | Bis zum nächsten Deploy laufen deshalb ins Leere: Team-Logo, Zustandsmeldung durch Mitglieder, Kontosuche per E-Mail, Teilnehmerlisten, die Event-Schalter und die Serien. Die Oberfläche dafür ist da und wird beim Speichern eine Fehlermeldung von PocketBase zeigen. **Zwei Dinge sind beim Nachziehen nicht zurückzunehmen:** 1. `1754501300` legt für jeden Fahrer mit Event einen Teilnehmer an und entfernt danach `riders.event` und `riders.number`. Eine Startnummer an einem Fahrer **ohne** Event hat danach keinen Platz mehr und geht verloren — sie war ohnehin nirgends sichtbar, weil alle Listen nach Event filterten. 2. Bestehende Events werden auf `timing = true` und `participation = geschlossen` gesetzt. Genau so wurden sie bisher benutzt; wer einen Stammtisch daraus machen will, schaltet die Zeitnahme im Dialog ab. Ebenfalls bewusst so: Nach `1754501200` kann jeder Eingeloggte Konten auflisten, damit sich bestehende Konten per E-Mail ins Team holen lassen. E-Mail-Adressen bleiben über `emailVisibility` verborgen. ### Typen einmal neu erzeugen `frontend/src/lib/types.d.ts` wurde bei allen Schema-Änderungen von Hand gepflegt. 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. ### Regeln einmal durchspielen Die Zugriffsregeln der neuen Collections konnten nirgends laufen — weder Docker noch eine lokale PocketBase-Instanz standen zur Verfügung. Sie sind nach dem Muster der vorhandenen Collections geschrieben, aber ungetestet. Nach dem Deploy einmal ausprobieren: - Ein einfaches Teammitglied trägt sich bei einem **offenen** Event selbst ein. - Dasselbe bei einem Event **mit Bestätigung** — es muss als „Angefragt" landen, nicht als „Dabei". - Bei einem **geschlossenen** Event darf es gar nicht gehen. - Ein Mitglied meldet einen Trail-Zustand (muss gehen) und versucht, den Namen des Trails zu ändern (darf nicht gehen). Der Selbsteintrag setzt außerdem voraus, dass das Konto der Person mit einem Fahrer verknüpft ist (Einstellungen → Fahrer & Konten). Ohne Verknüpfung erscheint der Knopf gar nicht erst. ### Logo des Stammtischs zuordnen `teams.logo` gibt es ab `1754501000`. Solange nichts hinterlegt ist, zeigt die App weiterhin das Wappen aus `static/` — für den Stammtisch Hersbruck sieht es also unverändert aus. Wer es als Datei am Team haben will, lädt es nach dem Deploy unter Einstellungen → Team → Logo hoch. ## Kleinigkeiten - Wer Regeln direkt im PocketBase-Admin ändert, hinterlässt keine Spur im Repo. Die Migrationen bleiben die Quelle: Sie setzen dieselben Werte noch einmal und überschreiben eine abweichende Handänderung stillschweigend. - Die Rolle **Superadmin** ist gesetzt, gibt in der App aber noch keine besonderen Rechte. Sie ist bewusst nur in PocketBase vergebbar: Die `updateRule` der users-Collection schließt `superadmin` vom Selbstsetzen aus. Sobald klar ist, was sie dürfen soll, kommen die Regeln dazu. - Flag-Typen sind **teamspezifisch**. Ein neues Team bekommt beim Anlegen den hartkodierten Standardsatz aus `trailFlags.svelte.ts` und kann ihn frei ändern. - „Jedes Teammitglied ist ein Fahrer" hält die Oberfläche ein, das Backend erzwingt es nicht: Ein Konto kann im Team sein, ohne an einem Fahrer zu hängen. Solche Fälle stehen unter „Fahrer & Konten" mit dem Vermerk „kein Fahrer" und lassen sich per Knopf übernehmen. - „Als Fahrer übernehmen" rät den Namen aus dem Kontonamen und setzt ihn als Vornamen. „Max Mustermann" auf zwei Felder aufzuteilen wäre geraten und läge bei Doppelnamen daneben; der Name lässt sich danach korrigieren. Wenn das zu grob ist, müsste der Knopf stattdessen nach Vor- und Nachname fragen. - Serien erzeugen bis zu zwölf Termine je Klick und überspringen, was schon angelegt ist. Ein Termin, der ausfällt, wird als Event gelöscht oder verschoben — die Serie bleibt davon unberührt. - `NAMING.md` und `frontend/static/pedaler.svg` liegen bewusst nur lokal.