Goldebek/goldebek_website_briefing/goldebek_codex_masterprompt.md

# Codex-Masterprompt: Neue Website der Gemeinde Goldebek

Du arbeitest als Senior Full-Stack-Engineer, UX-Designer und Accessibility-Engineer. Deine Aufgabe ist, auf Basis dieses Repositories eine neue offizielle Website für die **Gemeinde Goldebek, Schleswig-Holstein** zu erstellen.

Die Website ersetzt inhaltlich die bisherige Jimdo-Seite. Sie soll **nicht** deren Gestaltung kopieren, sondern Inhalte und Funktionen sauber migrieren, aktualisieren und in eine moderne, langfristig pflegbare Struktur überführen.

## 0. Arbeitsweise

1. Untersuche zuerst das vorhandene Repository:
   - Framework, Package Manager, Lockfile, Buildsystem, bestehende Komponenten, CI/CD und Deployment.
   - Wenn bereits ein funktionierender Stack vorhanden ist, bleibe darin und passe dich ihm an.
   - Wenn das Repository leer bzw. nur ein Grundgerüst ist, verwende eine aktuelle stabile Version von **Next.js mit App Router, TypeScript und Tailwind CSS**.
2. Entferne keine funktionierenden CI/CD-Pipelines oder Deployment-Konfigurationen.
3. Arbeite end-to-end: Informationsarchitektur, Datenmodell, Komponenten, Seiten, responsive Darstellung, Accessibility, SEO, Tests und Dokumentation.
4. Erfinde **keine** Telefonnummern, Namen, Termine, Gebühren, Satzungen, Öffnungszeiten, Rechtstexte oder Projektstände.
5. Alle dynamischen Daten müssen eine Quelle und `lastVerified` besitzen.
6. Wenn sich Quellen widersprechen, verwende die in `goldebek_data_2026-09-18.json` dokumentierte Entscheidung. Offene Punkte bleiben offen und werden nicht stillschweigend „gelöst“.
7. Übernimm keine privaten Gastgeberadressen aus alten Veranstaltungskalendern.
8. Übernimm keine fremden Fotos ohne geklärte Nutzungsrechte.
9. Verwende keine Tracker, externen Marketing-Skripte oder unnötige Third-Party-Einbindungen.
10. Liefere am Ende eine vollständig bau- und testbare Anwendung.

## 1. Verbindliche Datenbasis

Im Projekt liegt die Datei:

`goldebek_data_2026-09-18.json`

Behandle diese Datei als primären Content-Seed. Zusätzlich liegt eine ausführliche Recherche in:

`goldebek_recherche_2026-09-18.md`

Für Fakten mit `status: "needs-verification"` darfst du im öffentlichen Produktions-UI **keine ungeprüfte Behauptung** erzeugen. Solche Inhalte entweder:
- ausblenden,
- nur als redaktionellen TODO in einer Entwickler-/Preview-Ansicht markieren,
- oder auf die offizielle externe Quelle verlinken.

## 2. Zielbild

Die Website soll sich anfühlen wie ein **hochwertiges, modernes norddeutsches Gemeindeportal**:

- vertrauenswürdig
- unaufgeregt
- lokal
- freundlich
- offiziell
- sehr gut auf Mobilgeräten
- schnell
- barrierearm/barrierefrei
- redaktionell leicht pflegbar

Nicht erwünscht:
- generische „KI“-Optik
- übertriebene Gradients
- Glasmorphismus
- große animierte 3D-Effekte
- touristische Stockfoto-Ästhetik
- unnötige Carousels
- aggressive Animationen
- Marketing-Sprech

## 3. Visuelles System

Orientiere die Akzentfarben am Gemeindewappen:

- tiefes Blau
- natürliches Grün
- warmes Gold
- Weiß / Off-White / sehr helle neutrale Flächen

Wichtig:
- Das Wappen selbst niemals stilisieren, umfärben, nachzeichnen oder als dekoratives Pattern verfremden.
- Verwende nur eine von der Gemeinde freigegebene offizielle Wappengrafik.
- Falls aktuell keine freigegebene Datei im Repo liegt, nutze einen klar markierten Asset-Platzhalter im Code und dokumentiere ihn in `CONTENT_CHECKLIST.md`.

Visuelle Idee:
- ruhige horizontale oder leicht wellige Linien können dezent den Goldebeker Mühlenstrom zitieren
- moderne serifenlose Typografie
- klare Raster
- großzügiger Weißraum
- robuste Card-Komponenten
- dezente Schatten
- deutlich sichtbare Fokuszustände
- keine Informationen ausschließlich über Farbe vermitteln

Nutze möglichst Systemfonts oder lokal eingebundene freigegebene Fonts. Keine externen Google-Font-Aufrufe.

## 4. Informationsarchitektur

Erstelle folgende Hauptnavigation:

### Startseite
### Aktuelles
### Termine
### Gemeinde
- Über Goldebek
- Zahlen & Fakten
- Geschichte
- Wappen
- Dorfchronik

### Leben & Gemeinschaft
- Dörpshuus
- Spielplatz
- Vereine
- Freiwillige Feuerwehr
- Kulturausschuss
- Senioren
- Alltagshilfe Osterdörfer

### Politik & Verwaltung
- Bürgermeister & Gemeindevertretung
- Sitzungen & Protokolle
- Satzungen & Steuern
- Bauleitplanung
- Projekte & Entwicklung

### Service
- Ansprechpartner
- Mobilität
- Fahrbücherei
- Abfall & Abwasser
- Bildung / Kita / Schule
- Wichtige Links

### Kontakt

Footer:
- Impressum
- Datenschutz
- Erklärung zur Barrierefreiheit
- Amt Mittleres Nordfriesland
- Quellen-/Stand-Hinweis, wo sinnvoll

## 5. Startseite

### Hero

Eyebrow:
`Gemeinde Goldebek · Nordfriesland`

H1:
`Moin in Goldebek`

Einleitung:
`Goldebek liegt im nordöstlichen Nordfriesland zwischen Bredstedt und Wanderup. Landwirtschaft, Ehrenamt, Vereine und gemeinschaftliche Projekte prägen das Dorf.`

CTA:
- `Aktuelle Termine`
- `Goldebek entdecken`

### Faktenleiste

- 381 Einwohner – Stand 31.03.2026
- 10,18 km²
- Kreis Nordfriesland
- PLZ 25862

### Danach

1. **Aktuelles** – maximal drei aktuelle Meldungen
2. **Nächste Termine** – die nächsten 3–5 bestätigten Termine
3. **Schnellzugriffe**
   - Dörpshuus
   - Gemeindevertretung
   - Alltagshilfe
   - Fahrbücherei
4. **Goldebek entdecken**
   - Geschichte
   - Mühlenstrom
   - Dorfchronik
   - Wappen
5. **Gemeinschaft**
   - Vereine
   - Feuerwehr
   - Kulturausschuss
6. **Projekte & Entwicklung**
   - Spielplatz
   - Wärmeplanung
   - Bauleitplanung
7. **Kontakt / Amt**

## 6. Inhalte, die bereits als verifiziert gelten

### Basisdaten

- Name: Goldebek
- Bundesland: Schleswig-Holstein
- Kreis: Nordfriesland
- Amt: Mittleres Nordfriesland
- AGS: 01054037
- PLZ: 25862
- Fläche: 10,18 km²
- Einwohner: 381 zum 31.03.2026
- Dichte: 37 Einwohner/km²

Siedlungsteile:
- Goldebek
- Heinsbek
- Kolonie
- Süderhuus
- Goldebekfeld

### Geschichte

- erste urkundliche Erwähnung: 1321
- Gemeinde seit 1934 selbstständig
- Mühle 1948 abgebrochen
- Namenswechsel Goldebeck → Goldebek mit Wirkung 01.11.1961
- Dörpshuus 2000 errichtet
- Dorfchronik Band 1: 1992
- Dorfchronik Band 2: April 2022
- Spielplatz am Langbarg: eröffnet 02.08.2026

### Bürgermeister

Peter Jessen  
Am Mühlenstrom 14  
25862 Goldebek  
Telefon 04673/962229  
Fax 04673/962688

### Gemeindevertretung

- Peter Jessen
- Hauke Jensen
- Volker Hansen
- Timo Jensen
- Catarina Tudsen
- Stefan Christiansen
- Rainer Bakker
- Finn Christiansen
- Nils Hörner

Achtung: Bei „Nils Hörner“ besteht eine Schreibweisen-Differenz zu einzelnen Sitzungsunterlagen. Im öffentlichen Seed die Amt-Schreibweise verwenden, aber in `CONTENT_CHECKLIST.md` als zu bestätigenden Punkt führen.

### Hebesätze / Hundesteuer

- Grundsteuer A: 595 v.H.
- Grundsteuer B: 517 v.H.
- Gewerbesteuer: 400 v.H.
- 1. Hund: 90 €/Jahr
- 2. Hund: 110 €/Jahr
- jeder weitere Hund: 110 €/Jahr

Mit Stand-Datum und Quelle darstellen.

### Dörpshuus

Adresse:
`Am Brodersberg 16, 25862 Goldebek`

Service-Telefon:
`0173 3826343`

Errichtet:
`2000`

Gebühren, zuletzt aus Ratsunterlagen 02.12.2025 bestätigt:
- Einwohner: 150 €
- Feuerwehr-Kameradschaftsraum: 60 €
- Auswärtige: 300 €
- Endreinigung: 70 €
- Fehlbenutzung Notausgang: 50 €

Kapazität laut Flyer April 2025:
- 80 Dörpshuus
- 20 Kameradschaftsraum
- maximal 100 insgesamt

Kaution NICHT veröffentlichen, solange der aktuelle Wert nicht bestätigt wurde.

### Spielplatz

- Name: Spielplatz am Langbarg
- eröffnet: 02.08.2026
- Projektvolumen: rund 145.000 €
- VR Bank Nord Stiftung: 10.000 € Spende
- Bürgerwindpark Veer Dörper: 500 € Spende
- Zweck: Treffpunkt für Kinder, Familien und Dorf

### Alltagshilfe Osterdörfer

Seit 01.01.2026 für:
- Goldebek
- Goldelund
- Joldelund
- Högel
- Kolkerheide

Beispiele:
- Einkäufe
- Fahrten zu Arztterminen
- kurze Kinderbetreuung
- kleine Alltagshilfen

Kein Ersatz für professionelle Pflege-, Handwerks-, Garten- oder Taxileistungen.

Kosten:
- 5 € je angefangener Stunde
- 0,50 €/km

Kontakt Goldebek:
Peter Jessen, 0151/70089673

### Mobilität

Aktuell verwendete ÖPNV-Linie:
`130`

Halte laut Betreiberseite:
- Goldebek Kreuzung
- Goldebek Dorfstraße
- Süderhuuser Straße 5
- Süderhuus

Keine Fahrzeiten in den Code kopieren. Link zur aktuellen Betreiberseite.

### Fahrbücherei

Haltestelle:
`Dorfstraße 12`

Zeit:
`15:55–16:20`

Noch kommende Termine ab Recherche-Stand 18.09.2026:
- 09.10.2026
- 06.11.2026
- 04.12.2026

## 7. Events

Baue ein sauberes Event-System.

Erforderliche Eigenschaften:

```ts
type Event = {
  id: string
  slug: string
  title: string
  summary?: string
  startDate: string
  startTime?: string
  endDate?: string
  endTime?: string
  timezone: "Europe/Berlin"
  location?: string
  organizer?: string
  sourceUrl?: string
  sourceName?: string
  lastVerified: string
  status: "verified" | "dynamic" | "needs-verification" | "archived"
  privacyApproved?: boolean
}
```

Funktionen:
- kommende Termine
- Terminarchiv
- Detailseite
- ICS-Download pro Termin
- optional ein Gesamt-ICS-Feed
- schema.org/Event JSON-LD
- Datumsausgabe deutsch
- Zeitzone Europe/Berlin
- Wochentag immer aus dem Datum berechnen
- Vergangenes automatisch ins Archiv einordnen
- keine privaten Adressen ausgeben, wenn `privacyApproved !== true`

Seed die bestätigten Events aus `goldebek_data_2026-09-18.json`.

## 8. News

News-Datenmodell:

```ts
type NewsItem = {
  id: string
  slug: string
  title: string
  teaser: string
  body: string
  publishedAt: string
  updatedAt?: string
  image?: {
    src: string
    alt: string
    copyright?: string
  }
  sourceUrl?: string
  sourceName?: string
  lastVerified: string
  status: "published" | "draft" | "archived"
}
```

Lege als erste aktuelle Meldung den neuen Spielplatz an. Textlich nüchtern und lokal, nicht werblich überziehen.

## 9. Content-System

Ziel: keine Inhalte hart in React-Komponenten verstreuen.

Bevorzugt:
- `/content`
- `/data`
- JSON/YAML/MDX
- Schema-Validierung mit Zod

Beispielstruktur:

```text
content/
  news/
  pages/
  events/
data/
  municipality.json
  council.json
  services.json
  clubs.json
  sources.json
lib/
  content/
  dates/
  validation/
```

Baue einen Validierungsschritt, z. B.:

`pnpm data:validate`

Prüfungen:
- doppelte Slugs
- ungültige ISO-Daten
- Event-Datum/Wochentag-Konsistenz
- fehlendes `lastVerified` bei dynamischen Daten
- fehlende Quelle bei politischen/administrativen Fakten
- abgelaufene `validUntil`-Einträge
- `needs-verification` darf nicht versehentlich als verifiziert angezeigt werden
- private Adressen nur mit Freigabeflag

## 10. Quellenkonzept

Pflege Quellen zentral in `data/sources.json`.

Jeder volatile oder verwaltungsbezogene Inhalt kann auf eine `sourceId` referenzieren.

Im öffentlichen UI:
- nicht jede Seite muss mit Quellen überladen sein
- bei Steuern, Fahrplänen, Verwaltung, Projekten und aktuellen Daten einen dezenten `Stand: …`-Hinweis und „Amtliche Quelle“ anbieten
- externe Links klar kennzeichnen

## 11. Bilder und Rechte

Die Recherche hat auf der Amt-Seite hochwertige Ortsbilder gefunden, die dort mit Fotografen-Copyright gekennzeichnet sind. Diese Bilder sind **nur Referenz**, nicht automatisch nutzbare Website-Assets.

Daher:
- keine Bilder von der Amt-Seite herunterladen oder kopieren
- keine Bild-URLs hotlinken
- im Projekt saubere Platzhalter/Asset-Slots vorsehen
- benötigte Motive in `CONTENT_CHECKLIST.md` aufführen:
  - Luft-/Ortsansicht
  - Dörpshuus
  - Spielplatz
  - Ortseingang/Wappenstein
  - Landschaft/Mühlenstrom
  - Vereinsleben
  - Feuerwehr
  - Streuobstwiese/Feste

Jedes Bildmodell soll `alt` und optional `copyright` enthalten.

## 12. Karte

Keine Google-Maps- oder externe OSM-Iframe-Einbindung standardmäßig laden.

Bevorzugt:
- kleine statische Lagekarte als eigenes Asset, wenn vorhanden, oder
- gut gestaltete Standortkarte mit Link `In OpenStreetMap öffnen`

So bleibt die Startseite ohne Third-Party-Requests datenschutzfreundlich.

## 13. Politik und Verwaltung

Die Website ist eine kommunale Informationsseite, keine politische Kampagnenseite.

Darstellung:
- neutral
- sachlich
- keine Rankings oder wertenden Beschreibungen
- keine parteipolitische Gestaltung
- Ratsmitglieder gleichartig darstellen

Sitzungen und Protokolle:
- eine übersichtliche Einstiegsseite
- möglichst auf die amtliche bzw. aktuelle Dokumentquelle verlinken
- keine veralteten Protokollkopien als „aktuell“ ausgeben

Satzungen:
- nur Titel und Link zur aktuellen Amt-Version
- keine alte PDF-Kopie im Repo pflegen, wenn das Amt die maßgebliche Fassung bereitstellt

Bauleitplanung:
- auf die aktuelle Seite des Amtes verlinken
- keine Statusaussage aus alten Ratsprotokollen ableiten

## 14. Barrierefreiheit

Ziel mindestens WCAG 2.2 AA und gute Praxis für kommunale Websites.

Pflicht:
- semantisches HTML
- Skip-Link
- vollständig tastaturbedienbar
- sichtbare Fokuszustände
- ausreichende Kontraste
- Form-Labels
- sinnvolle Überschriftenhierarchie
- `aria-*` nur dort, wo semantisches HTML nicht reicht
- `prefers-reduced-motion`
- Alt-Texte
- keine Auto-Play-Medien
- keine Informationen ausschließlich über Farbe
- Touch Targets ausreichend groß
- 200-%-Zoom ohne Funktionsverlust
- verständliche Linktexte

Erstelle eine Seite `Barrierefreiheit`, aber **erfinde keine rechtsverbindliche Erklärung**. Nutze einen klar markierten, nicht als final ausgegebenen Redaktionsplatzhalter.

## 15. Datenschutz

Standard:
- kein Google Analytics
- kein Meta Pixel
- keine Marketing-Cookies
- keine automatisch geladenen externen Karten/Videos
- keine Drittanbieter-Schriftarten
- kein Cookie-Banner nur „vorsichtshalber“

Falls später Analyse benötigt wird:
- Architektur für datenschutzfreundliche, ggf. selbst gehostete Lösung offen halten
- erst nach rechtlicher Freigabe aktivieren

Kontaktformular nur bauen, wenn ein sinnvoller Backend-/Mailweg und Spam-Schutz vorhanden sind. Sonst lieber gut gestaltete `mailto:`-/`tel:`-Kontakte.

## 16. SEO und strukturierte Daten

Implementieren:
- individuelle Titles/Descriptions
- Canonicals
- OpenGraph
- Sitemap
- robots.txt
- sprechende deutsche Slugs
- locale `de_DE`
- JSON-LD für Gemeinde/Organisation
- JSON-LD für Events
- Breadcrumbs

Keine Keyword-Spam-Texte.

## 17. Performance

Ziele:
- Lighthouse möglichst >95 in Performance/Accessibility/Best Practices/SEO
- sehr wenig Client-JavaScript
- Server Components / statische Seiten bevorzugen
- Bilder optimieren
- keine Layout Shifts
- keine unnötigen Animation-Libraries
- keine schweren Icon-Pakete, wenn wenige SVGs reichen

## 18. Suchfunktion

Wenn mit vertretbarem Aufwand möglich:
- kleine clientseitige Suche über Seiten, News, Termine und Vereine
- kein externer Suchdienst
- Suchindex beim Build generieren

Wenn es die Komplexität unnötig erhöht, sauber weglassen und dokumentieren.

## 19. Rechtliche Seiten

Erstelle Routen und Layout für:
- Impressum
- Datenschutz
- Barrierefreiheit

Aber:
- keine juristischen Inhalte erfinden
- im Entwicklungsstand klare Platzhalter
- in Produktionskonfiguration keine erfundenen Texte als final ausgeben

## 20. Migration alter URLs

Lege eine Redirect-Matrix an, soweit alte Pfade bekannt sind, z. B.:

```text
/die-gemeinde/ueber-uns/        -> /gemeinde/ueber-goldebek
/die-gemeinde/doerpshuus/       -> /leben/doerpshuus
/die-gemeinde/dorfchronik/      -> /gemeinde/dorfchronik
/die-gemeinde/kulturausschuss/  -> /leben/kulturausschuss
/termine/                       -> /termine
/gemeindevertretung/            -> /politik/gemeindevertretung
/vereine/                       -> /leben/vereine
```

Wenn das Hosting Redirects anders konfiguriert, passe die technische Umsetzung an den Stack an.

## 21. Tests und Qualitätschecks

Mindestens:
- TypeScript typecheck
- ESLint
- Produktions-Build
- Unit-Tests für Eventsortierung und Archivierung
- Unit-Test für Europe/Berlin-Datumslogik
- Unit-Test der Content-Schema-Validierung
- Link-Prüfung für interne Links
- Accessibility-Smoke-Test mit axe oder gleichwertig, wenn Stack geeignet
- keine Console-Errors

## 22. Dokumentation

Erstelle:

### `README.md`
- Setup
- lokale Entwicklung
- Build
- Deployment
- Content-Struktur
- neue News anlegen
- neuen Termin anlegen
- Ratsmitglieder aktualisieren
- Quelle/lastVerified pflegen
- Bild mit Copyright pflegen
- jährliche Updates

### `CONTENT_CHECKLIST.md`

Mindestens diese offenen Punkte:
- [ ] Heimatmuseum-Telefon bestätigen
- [ ] Schreibweise Nils Hörner/Höner bestätigen
- [ ] aktuelle Dörpshuus-Kaution bestätigen
- [ ] vollständige aktuelle Dörpshuus-Nutzungsbedingungen prüfen
- [ ] freigegebene Wappen-Datei bereitstellen
- [ ] Bildrechte / Originalbilder bereitstellen
- [ ] aktueller Abfall-Link
- [ ] aktueller Abwasser-Link
- [ ] B-Plan-5-/Baugrundstücksstatus bestätigen
- [ ] Windparkdaten nur bei gewünschter Veröffentlichung aktualisieren
- [ ] Rechtstexte bereitstellen/freigeben
- [ ] Fahrbücherei-Fahrplan für Folgejahr aktualisieren
- [ ] Veranstaltungskalender für Folgejahr aktualisieren

## 23. Wichtige Datenkonflikte – niemals falsch übernehmen

1. **Einwohner:** 381 zum 31.03.2026 verwenden. Alte Zahl 350 verwerfen.
2. **Bus:** aktuelle Betreiberseite = Linie 130. Alte Angabe R125 nicht verwenden.
3. **Spielplatz:** seit 02.08.2026 eröffnet. Alte OEK-Aussage „kein Spielplatz“ ist überholt.
4. **Heimatmuseum:** Telefonnummer widersprüchlich. Nicht veröffentlichen.
5. **Nils Hörner/Höner:** Amt-Schreibweise verwenden und als Prüfpunkt dokumentieren.
6. **Dörpshuus-Kaution:** nicht veröffentlichen, bis bestätigt.
7. **Windpark:** keine statische Anlagenzahl wegen Repowering.
8. **Private Adventsadressen:** nicht ungeprüft migrieren.

## 24. Definition of Done

Die Aufgabe ist fertig, wenn:

- die neue Informationsarchitektur umgesetzt ist
- Startseite und alle Hauptbereiche existieren
- alle bestätigten Seed-Daten strukturiert vorliegen
- Events automatisch kommende/vergangene Termine unterscheiden
- Quellen- und Prüfstatus technisch abgebildet sind
- mobile und Desktopdarstellung hochwertig sind
- Wappen-/Bildrechte nicht verletzt werden
- keine ungeprüften Fakten erfunden wurden
- `typecheck`, `lint`, Tests und Produktions-Build erfolgreich laufen
- README und CONTENT_CHECKLIST vollständig sind

Arbeite jetzt das Repository vollständig durch und implementiere diese Website. Triff sinnvolle technische Detailentscheidungen selbstständig, ohne die inhaltlichen Sicherheitsregeln zu umgehen.