---
title: "Durrani Website — Spec (Phase 1)"
type: project
tags: [durrani, website, spec, restaurant, gelnhausen, private-ops]
date: 2026-05-24
status: aktiv
source: "[[durrani-website-requirements-2026-05-24]]"
related: "[[constitution]], [[durrani-website-requirements-2026-05-24]], [[durrani-platform-evaluation-2026-05-24]]"
---

# Spec: Durrani Restaurant-Website

**Feature**: `durrani-website` · **Created**: 2026-05-24 · **Status**: Aktiv (Phase 1 + Gate A passed)

## Vision (Kais 2026-05-24)
> Nicht „nur eine Restaurant-Website", sondern eine **moderne digitale Premium-Hospitality-Plattform**: Weltklasse-UX, AI-Readiness, extrem starke lokale Auffindbarkeit, technische Qualität auf Enterprise-Niveau. Durrani ist zugleich **Premium-Showcase für KADi**. Qualität vor Geschwindigkeit.

## Kontext
Neubau der Website für **Restaurant Durrani — afghanische Küche in Gelnhausen** (Halal, vegetarisch & vegan, Räume für Feiern). Ablösung der Bestands-WordPress-Site (WP 7.0 + WPBakery + Slider Revolution). Architektur gelockt (siehe [[constitution]]): Next.js SSG/ISR (Cloudflare/Vercel) + Payload-CMS (Netcup/EU) + **tiefe KADi-Reservierung** + GloriaFood-Ordering. **DE + EN.** **Mobile-Experience hat höchste Priorität.** Architektur von Anfang an **Multi-Location-ready** (weitere Restaurants später) + **Catering als späterer eigenständiger Revenue-Channel** ausbaubar.

## User Scenarios (priorisiert)

### P1 — Gast-Kernreise (MVP, allein lebensfähig) 🎯
> Ein Gast findet Durrani, sieht Speisekarte + Öffnungszeiten + Standort, **reserviert einen Tisch** und/oder **bestellt online**.

- **Why P1**: Das ist der Geschäftszweck der Site — gefunden werden + Gäste in Reservierung/Bestellung konvertieren. Ohne das ist die Site wertlos.
- **Independent Test**: Mobil über Google „afghanisches restaurant gelnhausen" → Durrani-Site → Speisekarte ansehen, Tisch reservieren (KADi), online bestellen (GloriaFood) — alles ohne Hürde, < 3s Ladezeit.
- **Acceptance**:
  - Given ein Gast auf dem Smartphone, When er die Startseite öffnet, Then sieht er in < 2s Hero + klare CTAs (Reservieren / Bestellen / Speisekarte) + Öffnungszeiten-Status (jetzt offen?).
  - Given die Speisekarten-Seite, When sie lädt, Then sind Gerichte strukturiert (Kategorie, Name, Preis, Allergene/Veg-Veg-Halal-Marker) + Menu-Schema im HTML.
  - Given ein Gast klickt „Tisch reservieren", When der KADi-Flow startet, Then kann er ohne Seitenwechsel-Bruch eine Reservierung abschließen + erhält Bestätigung.
  - Given ein Gast klickt „Jetzt bestellen", When GloriaFood lädt, Then nur nach Cookie-Consent, kein Layout-Shift.

### P2 — Events, Feiern & Catering
> Gast/Veranstalter informiert sich über Räume für Feiern, Events (z.B. Weihnachtsfeier) und Catering, und stellt eine Anfrage.

- **Why P2**: Hoher Umsatz-Hebel (Gruppen/Catering), aber nicht MVP-kritisch.
- **Independent Test**: Event-Seite mit Raum-Infos + Anfrageformular (DSGVO-konform, spam-geschützt) → Anfrage kommt an.
- **Acceptance**: Event-/Catering-Seiten CMS-editierbar; Anfrageformular rate-limited + Bot-geschützt; Event-Schema im HTML.

### P3 — Marke, Story, Vertrauen
> Gast erlebt authentisches Branding, About/Story, Galerie, Bewertungen — baut Vertrauen vor dem Besuch.

- **Why P3**: Conversion-Verstärker + Premium-Brand-Anspruch, nachgelagert.
- **Independent Test**: About/Galerie/Review-Sektion vorhanden, Review-Schema, schnelle Bilder (AVIF/WebP).

## Functional Requirements (testbar)

**Seiten & Content**
- FR-001: Startseite mit Hero, Quick-Info (Öffnungszeiten-Status, Adresse, Telefon), Primär-CTAs (Reservieren/Bestellen/Speisekarte).
- FR-002: Speisekarten-Seite mit strukturierten Gerichten (Kategorie, Name, Beschreibung, Preis, Marker Halal/vegetarisch/vegan, Allergene). CMS-editierbar.
- FR-003: Kontakt/Standort-Seite (Adresse, Karte, Öffnungszeiten, Telefon, Anfahrt).
- FR-004: Event-/Feiern-/Catering-Seite(n) mit Anfrageformular.
- FR-005: About/Story + Galerie + (optional) Bewertungen.
- FR-006: Rechtsseiten (Impressum, Datenschutz, Cookie-Richtlinie) DSGVO-konform.
- FR-007: Alle Inhalte aus FR-001…006 die sich ändern können sind über Payload-CMS editierbar (kein Content-in-Code).

**Integrationen**
- FR-010: KADi-Reservierung als **tiefe Integration (Premium-Erlebnis)** — eigene Reservierungs-UI auf der Seite, Live-Verfügbarkeit via KADi-API, Bestätigungs-/Status-Flow, kein Seitenbruch. Nicht nur eingebettetes Widget. (Abhängig von KADi-API, siehe Open Dependency.)
- FR-011: GloriaFood-Online-Bestellung eingebunden, lädt erst nach Consent (bzw. consentfrei wenn technisch möglich).
- FR-012: CTAs „Tisch reservieren" / „Jetzt bestellen" / „Speisekarte ansehen" prominent + mobil sticky.

**Plattform / Architektur / i18n**
- FR-050: **Zweisprachig DE + EN** (i18n), DE primär; hreflang + lokalisierte Routen + lokalisiertes Schema.
- FR-051: **Mobile-First** — Mobile-Experience ist die Leitplattform; alle Flows zuerst mobil designt + getestet.
- FR-052: **Multi-Location-ready Datenmodell** — CMS + Routing so modelliert, dass weitere Standorte ohne Re-Architektur ergänzbar sind (location-scoped Content), auch wenn v1 nur Gelnhausen ausliefert.
- FR-053: **Catering als ausbaubarer Channel** — als eigene Sektion modelliert, später zu eigenständigem Revenue-Channel (eigene Landingpages/Anfrage-Pipeline) erweiterbar ohne Bruch.
- FR-054: **Bild-/Media-Pipeline** — alle Bilder über CDN, AVIF/WebP, responsive srcset, lazy, korrekte Dimensionen (kein CLS). „Extrem optimiert."
- FR-055: **CMS extrem einfach pflegbar** — klare deutsche Felder, Vorschau, kein technisches Wissen nötig; Editor kann Speisekarte/Events/Texte/Bilder selbstständig in Minuten ändern.

**Analytics / Privacy**
- FR-060: **Umami self-hosted (EU)** (alt Plausible EU). Cookieless → wenn technisch consentfrei, **kein Cookie-Banner-Zwang**. Kein unnötiges Tracking, DSGVO-first.

**SEO / AI / Schema**
- FR-020: Schema.org vollständig + valide: Restaurant, LocalBusiness, Menu, FAQ, Event, Review, Breadcrumb.
- FR-021: Local-SEO: NAP-Konsistenz, Google-Business-Profile-Anbindung, lokale Landingpage-Signale für „afghanisches/orientalisches Restaurant Gelnhausen + Umland".
- FR-022: OpenGraph + Twitter/X-Cards je Seite; semantische HTML-/Heading-Struktur; AI-Crawler-freundliches SSG-HTML.
- FR-023: Sitemap.xml + robots.txt automatisch generiert + aktuell.

**Security / Forms**
- FR-030: Alle Formulare rate-limited + Bot-geschützt (Turnstile/Honeypot), ohne Captcha-Wall für normale Gäste.
- FR-031: CMS-Admin nicht öffentlich, hinter Auth + 2FA.
- FR-032: Security-Header (CSP, HSTS, X-Frame-Options etc.), keine öffentliche PHP/DB-Surface.

**Migration**
- FR-040: Domain `restaurant-durrani.de` bleibt; Bestands-URLs (z.B. /speisekarte, /kontakt) per 301 erhalten/umgeleitet → kein SEO-Verlust.
- FR-041: Bestehende Inhalte/Bilder migriert oder bewusst ersetzt — Umfang siehe `[NEEDS CLARIFICATION: Content-Migration]`.

## Optimization Targets (MANDATORY, quantitativ)

| Target | Metric | Baseline (Alt-Site) | Threshold (Acceptance) | Messung |
|---|---|---|---|---|
| Performance | Lighthouse Perf (Mobile) | unbekannt (WP-Bloat, vermutl. < 50) | **≥ 95** | Lighthouse-CI je Deploy |
| LCP | Largest Contentful Paint (Mobile 4G) | ? | **< 2.0s** | Lighthouse-CI / CrUX |
| INP | Interaction to Next Paint | ? | **< 200ms** | Lighthouse-CI / RUM |
| CLS | Cumulative Layout Shift | ? | **< 0.1** | Lighthouse-CI |
| SEO-Technik | Lighthouse SEO | ? | **= 100** | Lighthouse-CI |
| A11y | Lighthouse Accessibility | ? | **≥ 95** (WCAG 2.2 AA) | Lighthouse-CI + axe |
| Schema | valide Rich-Results-Typen | teilweise | **0 Fehler**, alle FR-020-Typen | Google Rich Results Test |
| Local-SEO | Ranking „afghanisches restaurant gelnhausen" | ? | **Local-Pack Top-3** (90 Tage) | manuell / Rank-Tracker |
| Conversion | Reservierungs-/Bestell-CTA-Klickrate | ? | Baseline messen, dann optimieren | privacy-freundliche Analytics |

## Edge Cases
- Öffnungszeiten-Status über Mitternacht / Feiertage / Sonderöffnung.
- KADi-Widget/Service nicht erreichbar → graceful Fallback (Telefon-CTA), kein toter Button.
- GloriaFood-Script blockiert (Consent abgelehnt/Adblock) → klarer Hinweis statt leerer Bereich.
- Speisekarte leer/in Bearbeitung im CMS → kein Crash, „in Kürze"-State.
- Sehr langsame Verbindung / alte Mobilgeräte → Core-Content bleibt nutzbar.
- Suchmaschinen-Crawler ohne JS → Inhalt + Schema im SSG-HTML vorhanden.

## Out-of-Scope (v1 — aber Architektur muss es tragen)
- Eigenes Bestellsystem/Payment (bleibt GloriaFood in v1).
- Blog/redaktioneller Content-Stream (höchstens saisonale Landingpages später).
- Auto-Publish von SEO-/Content-Änderungen (Constitution VI: nur Draft + Human-Review).
- **Mehr-Standort-Ausspielung**: v1 liefert nur Gelnhausen aus — aber Datenmodell/Routing sind Multi-Location-**ready** (FR-052), kein Re-Architecting später.

## Optional / Roadmap später (Kais 2026-05-24 — Architektur offen halten)
Kundenkonto · Loyalty · Waitlist · Eventbuchungen · WhatsApp-Integration · AI-Concierge · intelligente Empfehlungen · dynamische Seasonal-Menus. **Nicht v1**, aber Architektur-Entscheidungen dürfen diese Erweiterungen nicht verbauen (CMS-Modell, Auth-Fähigkeit, API-Layer entsprechend zukunftsoffen).

## Clarifications — GEKLÄRT (Gate A, Kais 2026-05-24)
- **Sprachen (2B):** Deutsch + Englisch (i18n von Anfang an, DE primär).
- **KADi-Tiefe (1C): TIEF** — volle Integration inkl. Live-Verfügbarkeit + eigener Reservierungs-UI via KADi-API + Status/Verwaltung. Reservierung als **Premium-Erlebnis**, Durrani als **KADi-Showcase/Dogfood**. → Abhängigkeit: KADi-API-Fähigkeiten (siehe Open Dependency unten).
- **Menu-Daten (3A):** voll strukturiert im CMS (Kategorie/Gericht/Beschreibung/Preis/Allergene/Halal-Veg-Vegan-Marker) → maximales Menu-Schema + AI-Lesbarkeit.
- **Content (4C):** Texte neu schreiben, gute Bestandsfotos behalten (+ ggf. ergänzen).
- **Branding (5C):** bestehendes Logo behalten (Kais lädt hoch); restliche Brand-Sprache = Aria-Vorschlag (modern, authentisch afghanisch, premium).
- **Analytics:** **Umami self-hosted (EU)** bevorzugt, alt Plausible EU-hosted. Kein unnötiges Tracking, DSGVO-first, **kein Cookie-Banner-Zwang wenn technisch vermeidbar** (cookieless Analytics → consentfrei).
- **Timeline:** **Qualität vor Geschwindigkeit.** Erst perfekte Architektur + UX + SEO + Security, dann sauber implementieren. Lieber später live als halbgar. Kein fixes Datum.

## Open Dependency (vor KADi-Deep-Implementierung)
- `[NEEDS CLARIFICATION: KADi-API]` — für die TIEFE KADi-Integration (1C) brauche ich die KADi-API-Fähigkeiten: Endpunkte für Verfügbarkeits-Abfrage, Buchungs-Erstellung, Status/Webhooks, Auth-Modell, tenant-Scoping. Quelle: KADiCon-Repo/Doku. Blockt NICHT Phase 2-Plan (Rest planbar), aber den KADi-Deep-Task. → in Phase 2 als Dependency führen.