---
title: "Durrani Website — Project Constitution"
type: reference
tags: [durrani, website, constitution, principles, private-ops, architecture]
date: 2026-05-24
status: aktiv
source: "[[durrani-website-requirements-2026-05-24]]"
related: "[[durrani-website-requirements-2026-05-24]], [[durrani-platform-evaluation-2026-05-24]]"
---

# Durrani Website — Constitution

> **Version** 1.0 · **Ratified** 2026-05-24 · **Scope**: alle Features, Inhalte, Architektur-Entscheidungen der Durrani-Restaurant-Website. Jeder Plan (Phase 2) wird gegen diese NON-NEGOTIABLEs geprüft. Quelle: [[durrani-website-requirements-2026-05-24]], Architektur: [[durrani-platform-evaluation-2026-05-24]].

## Gelockte Architektur (Kais 2026-05-24)
Next.js (SSG/ISR) Frontend auf **Cloudflare/Vercel** · **Payload-CMS self-hosted auf Netcup/EU** · **tiefere KADi-Reservierungs-Integration** (nicht nur Widget) · GloriaFood-Ordering-Embed.

## Principles (NON-NEGOTIABLE)

### I. Security-First / Minimale Angriffsfläche
Statisches Frontend ohne öffentliche PHP/DB-Surface. CMS-Admin hinter Auth + 2FA, nicht öffentlich erreichbar. Secrets nur in ENV (nie im Repo). Formulare rate-limited + Bot-Schutz (Turnstile/Honeypot). **Security darf die UX echter Gäste NIE verschlechtern** — keine Captcha-Walls für normale Besucher. Regelmäßige Security-Checks + Logging/Monitoring kritischer Fehler.

### II. Performance-Budget (Core Web Vitals als Feature)
Harte Schwellen, CI-geprüft: **LCP < 2.0s, INP < 200ms, CLS < 0.1** (Mobile, 4G), **Lighthouse Performance ≥ 95**. Bilder modern (AVIF/WebP, responsive, lazy). Kein Render-Blocking. Geschwindigkeit ist Conversion — Regressionen blocken den Merge.

### III. SEO + AI-Discoverability
Vollständiges, valides Schema.org (Restaurant, LocalBusiness, Menu, FAQ, Event, Review, Breadcrumb). Semantische HTML-Struktur + saubere Überschriften-Hierarchie. Starke Local-SEO (Google Business Profile, NAP-Konsistenz). AI-Crawler-freundlich (klares SSG-HTML, keine JS-Wall). Auffindbar für Google + ChatGPT/Claude/Gemini/Perplexity.

### IV. Daten-Souveränität / EU / DSGVO
CMS + alle Inhaltsdaten auf **Netcup/EU**. Reservierungs-/Kontakt-Daten DSGVO-konform (Einwilligung, Zweckbindung, AVV mit Sub-Prozessoren). Keine US-Datentransfers ohne Rechtsgrundlage. Cookie-Consent vor nicht-essenziellen Skripten (GloriaFood/Analytics).

### V. Editor-Autonomie (kein Content-in-Code)
Alle editierbaren Inhalte (Speisekarte, Öffnungszeiten, Events, Texte, Bilder) pflegt das Restaurant-Team selbst über die Payload-CMS-UI — **ohne Entwickler, ohne Deploy-Wissen**. Inhalte die sich ändern können dürfen NICHT hartkodiert werden.

### VI. Kein Auto-Publish (Human-Review-Gate)
Automatisierte SEO-/Content-/Schema-Vorschläge werden **gedraftet, nie automatisch live publiziert**. Ein Mensch gibt frei. Schützt Rankings vor Auto-Spam-Strafen. (Deckt sich mit private-ops „kein Auto-Publish".)

### VII. KADi-First Reservierung (Dogfooding)
Reservierung läuft über **KADi** (KADiCons eigenes Produkt) als tiefe, eigene Integration — nicht als austauschbarer Fremdbaustein. Durrani ist zugleich Showcase/Dogfood für KADi-Reservation. Schwächen die dabei auffallen → zurück ins KADi-Produkt.

### VIII. Premium-Brand-Qualität + Accessibility
Authentisches, hochwertiges Branding, Premium-UX. **WCAG 2.2 AA** als Minimum (Kontrast, Keyboard, Screenreader, prefers-reduced-motion). „Internationales Premium-Hospitality-Brand", nicht Template-Look.

### IX. Beste praktische Lösung — keine Über-Komplexität
Architektur-Entscheidungen wählen die einfachste Lösung die die Ziele erfüllt. Keine Technologie „weil cool". Jede Abweichung/Zusatz-Dependency in einem ADR begründet. Langfristig wartbar + erweiterbar vor kurzfristig clever.

### X. Extensibility-ready (Multi-Location + Roadmap)
Datenmodell + Routing + API-Layer sind von Anfang an **Multi-Location-ready** (location-scoped Content, weitere Restaurants ohne Re-Architektur) — auch wenn v1 nur Gelnhausen ausliefert. Catering ist als ausbaubarer eigenständiger Revenue-Channel modelliert. Roadmap-Features (Kundenkonto, Loyalty, Waitlist, Eventbuchungen, WhatsApp, AI-Concierge, Empfehlungen, Seasonal-Menus) dürfen durch v1-Entscheidungen nicht verbaut werden. Deckt sich mit der Aria-Distributions-Denke (Memory `project_aria_distribution_strategy`): heute bauen, dass morgen skaliert.

### XI. Mobile-First
Mobile-Experience ist die Leit-Plattform, nicht die Anpassung. Jeder Flow wird zuerst mobil entworfen + getestet, dann nach oben skaliert.

## Amendments
Änderungen an Principles brauchen explizites Kais-OK + Versions-Bump + Datum hier.