Run PocketBase as a compose stack, tests included, without Testcontainers

docs/redaktion.md

@@ -0,0 +1,122 @@
+# Redaktion
+
+Wie die sichtbaren Inhalte der Website gepflegt werden. Der Inhalt liegt in
+**PocketBase** — einem kleinen Server mit eigenem Admin-Login — und wird dort
+über die Weboberfläche bearbeitet. Keine Dateien, kein Commit, kein Rebuild: eine
+Änderung im Admin ist sofort live.
+
+> **Übergang (Stand #8).** Der Inhalt ist bereits vollständig in PocketBase; die
+> Blazor-App wird gerade darauf umgestellt, ihn von dort zu lesen (Issue #8).
+> Solange das läuft, kann die ausgelieferte Seite noch aus den alten Dateien
+> unter `Content/` stammen. Sobald #8 durch ist, ist PocketBase die einzige
+> Quelle und dieser Abschnitt der einzige Pflegeweg.
+
+> **Sprachkonvention.** Feldnamen und Slugs sind **englisch** (`title`, `slug`,
+> `board`, `posts`). Der Text, den ein Besucher liest, bleibt **deutsch** — also
+> der Wert eines Feldes (`title: Vorstandsteam`) und der Fließtext. Englische
+> Schlüssel, deutsche Werte.
+
+---
+
+## Anmelden
+
+Das Admin heißt „Redaktion Elternbeirat" und ist unter der PocketBase-Adresse
+erreichbar:
+
+- **Lokal:** <http://localhost:8090/_/> (Dev-Stack, siehe `entwicklung.md`).
+- **Auf dem Server:** über die NPM-Subdomain (Login von außen — noch offen, #9).
+
+Redakteure sind **Superuser**: jede vertraute Person aus dem Vorstand bekommt
+einen eigenen Superuser-Zugang (unter *Collections → System → `_superusers`*).
+Es gibt bewusst keinen eigenen Login und keinen Editor in der Website selbst —
+gepflegt wird nur im Admin.
+
+---
+
+## Die Inhaltsarten (Collections)
+
+Jede Inhaltsart ist eine **Collection**. Ein neuer Eintrag = ein neuer Record in
+der passenden Collection (Button *New record*).
+
+| Collection | Was | Öffentlich sichtbar über |
+|---|---|---|
+| `pages` | Feste Seiten (Vorstand, Impressum, Kontakt …) | Slug, z. B. `/board` |
+| `posts` | Neuigkeiten / Beiträge | `/posts`, neueste zuerst |
+| `events` | Termine (Kalender) | `/events` und der `.ics`-Feed |
+| `faqs` | Häufige Fragen | Werden auf der FAQ-Seite gruppiert angezeigt |
+
+Jede Collection hat als **letztes Feld `public`** (ja/nein). Nur Records mit
+`public = true` erscheinen auf der Website — so lässt sich ein Entwurf anlegen,
+ohne dass er schon sichtbar ist.
+
+---
+
+## Seiten (`pages`)
+
+Eine Seite hat `title` (Überschrift für Menschen, Umlaute erlaubt), `slug` (die
+URL, klein und **ohne Umlaute**: `board`, nicht `über-uns`) und `body` (der
+Text, als Editor-Feld).
+
+- **Slug bleibt englisch und ohne Umlaute.** `imprint`, `privacy`, `contact`,
+  `board`, `patrons`. Der `title` darf deutsch mit Umlauten sein (`Förderverein`).
+- **Menü:** Ob eine Seite ins Menü kommt, steht an der Seite selbst — die Felder
+  `location` (`header` oder `footer`) und `order` (Reihenfolge, ab 1). Die App
+  baut Kopf- und Fußnavigation daraus; nichts wird im Markup angefasst.
+- **Eingebettete Blöcke:** Das Feld `embed` (Mehrfachauswahl aus
+  `faqs`/`posts`/`events`) hängt unter den Text der Seite dynamische Blöcke. So
+  ist die Startseite (`home`) eine normale Seite mit `embed = [posts, events]`,
+  und `/faqs` eine Seite mit `embed = [faqs]`. Leeres `embed` = reine Textseite.
+
+> **Impressum und Datenschutz** hängen an ihren Slugs (`imprint`, `privacy`).
+> Diese Slugs nicht ändern — sonst laufen die rechtlich verlinkten Adressen ins
+> Leere (404).
+
+---
+
+## Beiträge (`posts`)
+
+Ein Beitrag hat `date`, `title`, `body`, `slug` und `public`. Er erscheint unter
+`/posts` (neueste zuerst) und unter `/posts/<slug>`; die neuesten werden auch auf
+der Startseite als Vorschau angeteasert.
+
+- `date` steuert Sortierung und angezeigtes Datum.
+- `slug` ist englisch, klein, ohne Umlaute (z. B. `new-sports-hall-opened`).
+
+---
+
+## Termine (`events`)
+
+Ein Termin hat `start` (Pflicht), `end` (optional, für mehrstündige oder
+mehrtägige), `title`, `location` (optional), `note` (optional) und `public`.
+Kein Slug.
+
+Die Übersicht `/events` trennt automatisch in kommende und vergangene Termine;
+die Reihenfolge der Records spielt keine Rolle. Besucher können `/events.ics` in
+ihrer Kalender-App abonnieren — der Feed entsteht aus denselben Records.
+
+> **Uhrzeit = Ortszeit.** Das Admin-Formular rechnet Datumsfelder in die
+> Browser-Zeitzone um und zeigt eine gespeicherte `19:30` je nach Sommer-/Winter-
+> zeit als 20:30/21:30 an. Das ist **kein** Fehler, nur zwei Bezugssysteme: der
+> gespeicherte Zahlenwert **ist** die Ortszeit (Europe/Berlin), die App zeigt ihn
+> unverändert. Trage die Uhrzeit ein, die auf der Seite stehen soll.
+
+---
+
+## Häufige Fragen (`faqs`)
+
+Eine Frage hat `question`, `answer` (Markdown), `topic` (eines von
+`mensa`/`schliessfach`/`elterneuro`/`elternarbeit`) und `public`. Die App baut
+die FAQ-Seite generiert: sie gruppiert die Fragen nach `topic`. Der Rahmentext
+oben auf `/faqs` ist eine eigene Seite in `pages` (Slug `faqs`).
+
+---
+
+## Regeln beim Speichern
+
+- **Nach dem Ändern einer Zugriffsregel** immer den Haupt-*Save* der Collection
+  drücken, sonst greift die Änderung nicht.
+- Die vier Collections sind öffentlich **lesbar** (List/View offen), aber nur
+  eingeloggt **schreibbar** — ein Schreibversuch ohne Login wird abgewiesen. Das
+  ist Absicht; nicht „vereinfachen".
+- **Backup:** Der gesamte Inhalt liegt in `pb_data`. Ein Backup dieses
+  Verzeichnisses (plus Restore-Test) ist der Sicherungsweg — eingerichtet in #9.