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:

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:

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:

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.:

/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.