Teil 2/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.
Kontext: Alle Seiteninhalte sind Markdown aus PocketBase, gerendert über Shared/Markdown.cs
(aktuell nackte MarkdownPipelineBuilder().Build()). Ziel: Redakteure gestalten Seiten selbst,
ohne Code und ohne HTML.
1. Globale Klasse .markdown-body auf jedem gerenderten Body (ContentPage, PostDetail,
FAQ-Antworten, Seiten-Intros auf /posts und /events). Stilisiert alles, was die Redaktion
nutzt (Bestand: viele ##, Listen, nummerierte Listen, Links, ein Zitat; keine Bilder/
Tabellen): h2 mit kurzem grünen Strich davor, Listen mit grünen Punkten, Zitat mit
Akzentbalken, Links mit dezenter Unterstreichung. Externe Links (http…, nicht eigener Host)
bekommen per CSS ein kleines external-link-Symbol. Vorsorglich auch Tabellen (auf Mobil
horizontal scrollbar), Bilder und hr.
2. Markdig: UseCustomContainers() (und nur, was nötig ist, z. B. UsePipeTables) aktivieren –
begründe jede Erweiterung. Dazu CSS für diese Bausteine:
::: kennzahlen → Liste wird zu großen Zahlen-Kacheln („- **seit 1975** Gründung“)
::: aufruf → hervorgehobene Box; Links darin als Button
::: kacheln → Liste als Kachel-Grid
::: hinweis → dezente Info-Box mit info-Symbol
Die Namen sind deutsch, weil die Redaktion sie tippt (CLAUDE.md: Werte deutsch). Unbekannte
Namen sehen aus wie normaler Text, nichts bricht.
3. Links auf PDFs (a[href$=".pdf"]) im Body als Datei-Karte mit file-text-Symbol und Hinweis „PDF“
darstellen – rein per CSS. So wird /downloads schön, sobald PDFs unter wwwroot/dokumente/
liegen (AE-2) und im Body verlinkt sind.
4. Ein mailto-Link, der allein in einem Absatz steht, wird als Button dargestellt
(Kontakt-Seite).
5. docs/redaktion.md: neuer Abschnitt „Gestaltungsbausteine“ mit Beispielen zum Kopieren.
Gib außerdem Vorschläge für neue Bodies von /patrons, /contact und /downloads aus, die ich
selbst in PocketBase einfüge (nicht per Code/Seed in Produktion schreiben). Den Dev-Seed
darfst du damit aktualisieren.
Tests: Unit-Tests für Markdown.cs (Container rendert div mit Klasse, unbekannter Container
bleibt harmlos, kein rohes HTML durchgelassen, falls das bisher so ist – prüfen!). Smoke-Test:
/patrons enthält .markdown-body.
Teil 2/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.
Kontext: Alle Seiteninhalte sind Markdown aus PocketBase, gerendert über Shared/Markdown.cs
(aktuell nackte MarkdownPipelineBuilder().Build()). Ziel: Redakteure gestalten Seiten selbst,
ohne Code und ohne HTML.
1. Globale Klasse .markdown-body auf jedem gerenderten Body (ContentPage, PostDetail,
FAQ-Antworten, Seiten-Intros auf /posts und /events). Stilisiert alles, was die Redaktion
nutzt (Bestand: viele ##, Listen, nummerierte Listen, Links, ein Zitat; keine Bilder/
Tabellen): h2 mit kurzem grünen Strich davor, Listen mit grünen Punkten, Zitat mit
Akzentbalken, Links mit dezenter Unterstreichung. Externe Links (http…, nicht eigener Host)
bekommen per CSS ein kleines external-link-Symbol. Vorsorglich auch Tabellen (auf Mobil
horizontal scrollbar), Bilder und hr.
2. Markdig: UseCustomContainers() (und nur, was nötig ist, z. B. UsePipeTables) aktivieren –
begründe jede Erweiterung. Dazu CSS für diese Bausteine:
::: kennzahlen → Liste wird zu großen Zahlen-Kacheln („- **seit 1975** Gründung“)
::: aufruf → hervorgehobene Box; Links darin als Button
::: kacheln → Liste als Kachel-Grid
::: hinweis → dezente Info-Box mit info-Symbol
Die Namen sind deutsch, weil die Redaktion sie tippt (CLAUDE.md: Werte deutsch). Unbekannte
Namen sehen aus wie normaler Text, nichts bricht.
3. Links auf PDFs (a[href$=".pdf"]) im Body als Datei-Karte mit file-text-Symbol und Hinweis „PDF“
darstellen – rein per CSS. So wird /downloads schön, sobald PDFs unter wwwroot/dokumente/
liegen (AE-2) und im Body verlinkt sind.
4. Ein mailto-Link, der allein in einem Absatz steht, wird als Button dargestellt
(Kontakt-Seite).
5. docs/redaktion.md: neuer Abschnitt „Gestaltungsbausteine“ mit Beispielen zum Kopieren.
Gib außerdem Vorschläge für neue Bodies von /patrons, /contact und /downloads aus, die ich
selbst in PocketBase einfüge (nicht per Code/Seed in Produktion schreiben). Den Dev-Seed
darfst du damit aktualisieren.
Tests: Unit-Tests für Markdown.cs (Container rendert div mit Klasse, unbekannter Container
bleibt harmlos, kein rohes HTML durchgelassen, falls das bisher so ist – prüfen!). Smoke-Test:
/patrons enthält .markdown-body.
```
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 2/7 von „Design auffrischen“. Den Prompt unten komplett an Claude Code geben.
Gehört zu #37.