Teil 6/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.
Voraussetzung: Prompt 2 (Markdown-Bausteine) ist umgesetzt.
Aufgabe: /board zeigt die 10 Personen als Markdown-Liste. Ohne Schemaänderung wird daraus ein
Personen-Grid. Die Daten bleiben im Body der Seite, die Redaktion pflegt weiter Markdown.
1. Neuer Baustein „::: team“. Jeder Listeneintrag darin wird eine Personenkarte nach der
Konvention, die der Body heute schon nutzt:
- **Name** (Rolle) → Name groß, Rolle als Chip
*Zuständigkeit, Zuständigkeit* → kleine Tags (an Komma getrennt)
weitere Zeile → Notiz
Die ## davor (Vorsitz, Schriftführung, Beisitz) bleiben normale Überschriften. Der
Vorsitz darf per Modifikator größer werden (z. B. „::: team gross“), begründe die Syntax.
2. Initialen-Avatar: Initialen und Farbe (stabil aus dem Namen, 4–5 Token-Farben, Kontrast AA)
werden beim Rendern berechnet, als kleine Markdig-Erweiterung oder Nachbearbeitung nur für
::: team. Keine Fotos, siehe docs/recht.md. Fehlt die Konvention in einem Eintrag
(z. B. kein Fettdruck), wird er als schlichte Karte mit dem Text dargestellt, ohne Fehler.
3. Doku-Beispiel in docs/redaktion.md („Gestaltungsbausteine“). Gib mir den angepassten
/board-Body aus; ich trage ihn selbst in Produktion ein. Dev-Seed und Fixture darfst du
anpassen.
4. Notiz für später (nicht umsetzen): eine eigene Collection board_members wäre die saubere
Lösung, sobald Schemaänderungen nach Produktion übertragen werden können.
Tests: Unit-Tests Initialen (Doppelnamen „Reger-Stilgenbauer“, Umlaute, ein Wort), stabile
Farbe, Parsing eines Eintrags mit und ohne Rolle/Zuständigkeiten, Eintrag ohne Konvention.
Smoke-Test /board mit Fixture-Body.
Teil 6/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.
Voraussetzung: Prompt 2 (Markdown-Bausteine) ist umgesetzt.
Aufgabe: /board zeigt die 10 Personen als Markdown-Liste. Ohne Schemaänderung wird daraus ein
Personen-Grid. Die Daten bleiben im Body der Seite, die Redaktion pflegt weiter Markdown.
1. Neuer Baustein „::: team“. Jeder Listeneintrag darin wird eine Personenkarte nach der
Konvention, die der Body heute schon nutzt:
- **Name** (Rolle) → Name groß, Rolle als Chip
*Zuständigkeit, Zuständigkeit* → kleine Tags (an Komma getrennt)
weitere Zeile → Notiz
Die ## davor (Vorsitz, Schriftführung, Beisitz) bleiben normale Überschriften. Der
Vorsitz darf per Modifikator größer werden (z. B. „::: team gross“), begründe die Syntax.
2. Initialen-Avatar: Initialen und Farbe (stabil aus dem Namen, 4–5 Token-Farben, Kontrast AA)
werden beim Rendern berechnet, als kleine Markdig-Erweiterung oder Nachbearbeitung nur für
::: team. Keine Fotos, siehe docs/recht.md. Fehlt die Konvention in einem Eintrag
(z. B. kein Fettdruck), wird er als schlichte Karte mit dem Text dargestellt, ohne Fehler.
3. Doku-Beispiel in docs/redaktion.md („Gestaltungsbausteine“). Gib mir den angepassten
/board-Body aus; ich trage ihn selbst in Produktion ein. Dev-Seed und Fixture darfst du
anpassen.
4. Notiz für später (nicht umsetzen): eine eigene Collection board_members wäre die saubere
Lösung, sobald Schemaänderungen nach Produktion übertragen werden können.
Tests: Unit-Tests Initialen (Doppelnamen „Reger-Stilgenbauer“, Umlaute, ein Wort), stabile
Farbe, Parsing eines Eintrags mit und ohne Rolle/Zuständigkeiten, Eintrag ohne Konvention.
Smoke-Test /board mit Fixture-Body.
```
Gehört zu #37.
Tom
added this to the Elternbeirat-Website milestone 2026-10-01 11:06:50 +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 6/7 von „Design auffrischen“. Den Prompt unten komplett an Claude Code geben.
Gehört zu #37.