Teil 4/7 von „Design auffrischen“. Den Prompt unten komplett an Claude Code geben.
Lies vorher CLAUDE.md und die dort verlinkten Dokumente, die für diese Aufgabe relevant sind
(mindestens docs/architektur.md und docs/redaktion.md). Halte dich an Coding und Documentation
Convention. Erst Plan vorstellen, auf mein OK warten, dann umsetzen.
Design-Leitplanken für alle Design-Aufgaben:
- Bestehende Tokens in wwwroot/app.css erweitern, keine Hardcode-Farben; jede neue Farbe mit
Dark-Mode-Variante im bestehenden prefers-color-scheme-Block; WCAG AA.
- Keine Hover-Bewegung (transform/translate) – bewusst entfernt in c67c71e. Hover = Farbe,
Schatten, Rahmen.
- Kommentarstil von app.css beibehalten (erklärt das Warum).
- Layout muss mit beliebigem Redaktions-Markdown und leeren/fehlenden Feldern funktionieren.
- UI-Texte deutsch, ohne Anglizismen.
- Tests: xUnit + Shouldly. Reine Logik als Unit-Test; Darstellung über RouteSmokeTests
(HTML der gerenderten Route prüfen) gegen den PocketBaseFixture. Keine neuen Test-Pakete
(bUnit, Playwright …) ohne Begründung und Rückfrage.
- KEINE Änderung am PocketBase-Datenmodell: keine neuen Collections, Felder, Select-Werte
oder Regeln, collections_schema.json bleibt unverändert. Grund: Es gibt noch keinen Weg,
Schemaänderungen nach Produktion zu übertragen. Wenn eine Lösung nur mit Schemaänderung
ginge: anhalten, Alternative ohne Schemaänderung vorschlagen und die Schema-Variante nur als
Notiz für später ausgeben. Neue Records im Dev-Seed und im Fixture sind erlaubt.
Befund: Features/Home/Home.razor rendert h1 und Intro fest im Markup und ignoriert den Body des
home-Records („# Willkommen beim Elternbeirat der IGMH“). Das verletzt „Inhalte gehören nach
PocketBase“. Der Kommentar in Home.razor.cs begründet es mit dem Ausfall-Fall – diese Absicht
erhalten: Ist PocketBase nicht erreichbar, bleibt ein statischer Titel als Rückfallebene.
Aufgabe:
1. Kopfbereich: volle Breite, --gradient-brand mit dezentem Inline-SVG-Muster. Inhalt = Body
des home-Records (erste # wird zur großen Überschrift, Rest zum Einleitungstext). Zwei Buttons:
„Kommende Termine“ und „Kontakt aufnehmen“ – entweder Links aus dem Body (letzter Absatz mit
Links wird zur Buttonleiste) oder fest, begründe die Wahl. Führe dabei globale .btn,
.btn-primary, .btn-secondary ein (inkl. :focus-visible, Dark Mode).
2. Ohne Schemaänderung (pages.embed ist ein Select mit festen Werten, also keine neuen
Embed-Schlüssel). Kopfbereich, „Nächster Termin“ und Kacheln sind deshalb feste Struktur
der Startseite in Home.razor. Das ist Struktur, kein Inhalt, und daher zulässig:
- „Nächster Termin“: Karte mit Kalenderblatt im Kopfbereich, nur wenn ein kommender
Termin existiert.
- Kacheln: eine je öffentlicher header-Seite außer home, aus NavBuilder/PocketBase.
Beschreibung = erster Satz des Seiten-Bodys (Markdown entfernt, gekürzt), leer → nur
Titel. Icon über eine kleine Zuordnung slug → Icon im Code mit Standard-Icon für
unbekannte Slugs (reine Darstellung). Neue Seiten erscheinen so automatisch.
- Notiz für später (nicht umsetzen): Felder pages.teaser/pages.icon und eigene
Embed-Schlüssel würden das redaktionell steuerbar machen.
3. Die bestehenden Embeds (posts, events) bleiben vom embed-Feld gesteuert, ab Desktop zweispaltig.
Tests: Unit-Test für „erster Satz aus Markdown“ und die Icon-Zuordnung inkl. Standard.
Smoke-Test: / zeigt den Body-Titel aus dem Fixture (nicht mehr den festen Text); Kacheln
enthalten genau die öffentlichen header-Seiten; „nächster Termin“ erscheint nur mit
kommendem Termin. Fixture-Records entsprechend ergänzen.
Teil 4/7 von „Design auffrischen“. Den Prompt unten komplett an Claude Code geben.
```
Lies vorher CLAUDE.md und die dort verlinkten Dokumente, die für diese Aufgabe relevant sind
(mindestens docs/architektur.md und docs/redaktion.md). Halte dich an Coding und Documentation
Convention. Erst Plan vorstellen, auf mein OK warten, dann umsetzen.
Design-Leitplanken für alle Design-Aufgaben:
- Bestehende Tokens in wwwroot/app.css erweitern, keine Hardcode-Farben; jede neue Farbe mit
Dark-Mode-Variante im bestehenden prefers-color-scheme-Block; WCAG AA.
- Keine Hover-Bewegung (transform/translate) – bewusst entfernt in c67c71e. Hover = Farbe,
Schatten, Rahmen.
- Kommentarstil von app.css beibehalten (erklärt das Warum).
- Layout muss mit beliebigem Redaktions-Markdown und leeren/fehlenden Feldern funktionieren.
- UI-Texte deutsch, ohne Anglizismen.
- Tests: xUnit + Shouldly. Reine Logik als Unit-Test; Darstellung über RouteSmokeTests
(HTML der gerenderten Route prüfen) gegen den PocketBaseFixture. Keine neuen Test-Pakete
(bUnit, Playwright …) ohne Begründung und Rückfrage.
- KEINE Änderung am PocketBase-Datenmodell: keine neuen Collections, Felder, Select-Werte
oder Regeln, collections_schema.json bleibt unverändert. Grund: Es gibt noch keinen Weg,
Schemaänderungen nach Produktion zu übertragen. Wenn eine Lösung nur mit Schemaänderung
ginge: anhalten, Alternative ohne Schemaänderung vorschlagen und die Schema-Variante nur als
Notiz für später ausgeben. Neue Records im Dev-Seed und im Fixture sind erlaubt.
Befund: Features/Home/Home.razor rendert h1 und Intro fest im Markup und ignoriert den Body des
home-Records („# Willkommen beim Elternbeirat der IGMH“). Das verletzt „Inhalte gehören nach
PocketBase“. Der Kommentar in Home.razor.cs begründet es mit dem Ausfall-Fall – diese Absicht
erhalten: Ist PocketBase nicht erreichbar, bleibt ein statischer Titel als Rückfallebene.
Aufgabe:
1. Kopfbereich: volle Breite, --gradient-brand mit dezentem Inline-SVG-Muster. Inhalt = Body
des home-Records (erste # wird zur großen Überschrift, Rest zum Einleitungstext). Zwei Buttons:
„Kommende Termine“ und „Kontakt aufnehmen“ – entweder Links aus dem Body (letzter Absatz mit
Links wird zur Buttonleiste) oder fest, begründe die Wahl. Führe dabei globale .btn,
.btn-primary, .btn-secondary ein (inkl. :focus-visible, Dark Mode).
2. Ohne Schemaänderung (pages.embed ist ein Select mit festen Werten, also keine neuen
Embed-Schlüssel). Kopfbereich, „Nächster Termin“ und Kacheln sind deshalb feste Struktur
der Startseite in Home.razor. Das ist Struktur, kein Inhalt, und daher zulässig:
- „Nächster Termin“: Karte mit Kalenderblatt im Kopfbereich, nur wenn ein kommender
Termin existiert.
- Kacheln: eine je öffentlicher header-Seite außer home, aus NavBuilder/PocketBase.
Beschreibung = erster Satz des Seiten-Bodys (Markdown entfernt, gekürzt), leer → nur
Titel. Icon über eine kleine Zuordnung slug → Icon im Code mit Standard-Icon für
unbekannte Slugs (reine Darstellung). Neue Seiten erscheinen so automatisch.
- Notiz für später (nicht umsetzen): Felder pages.teaser/pages.icon und eigene
Embed-Schlüssel würden das redaktionell steuerbar machen.
3. Die bestehenden Embeds (posts, events) bleiben vom embed-Feld gesteuert, ab Desktop zweispaltig.
Tests: Unit-Test für „erster Satz aus Markdown“ und die Icon-Zuordnung inkl. Standard.
Smoke-Test: / zeigt den Body-Titel aus dem Fixture (nicht mehr den festen Text); Kacheln
enthalten genau die öffentlichen header-Seiten; „nächster Termin“ erscheint nur mit
kommendem Termin. Fixture-Records entsprechend ergänzen.
```
Gehört zu #37.
Tom
added this to the Elternbeirat-Website milestone 2026-10-01 11:06:49 +02:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Teil 4/7 von „Design auffrischen“. Den Prompt unten komplett an Claude Code geben.
Gehört zu #37.