Artista-Filmcamp/Ziel

Du bist ein erfahrener Creative Director, UX-Designer und Senior Fullstack-Entwickler. Entwickle eine hochwertige, produktionsfähige Buchungswebsite für das **ARTISTA MODELCAMP 2027**.

Erstelle eine tatsächlich funktionierende Anwendung mit vollständigem Quellcode, Stripe-Anbindung, Bestellverwaltung und Deployment für mein selbst gehostetes RKE2-Kubernetes-Cluster. Eine rein visuelle Demo reicht nicht.

## 1. Ziel und Arbeitsweise

Die Website soll eine deutschsprachige Onepage sein, die das Modelcamp emotional und hochwertig präsentiert und Besucherinnen verständlich bis zur verbindlichen Buchung führt.

Die öffentliche Verkaufsseite bleibt eine Onepage mit Ankernavigation. Separate technische Seiten für Zahlungsabschluss, Buchungsstatus, rechtliche Inhalte und einen geschützten Verwaltungsbereich sind erlaubt.

Arbeite selbstständig und setze sinnvolle technische Entscheidungen direkt um. Fehlende Inhalte sollen die Entwicklung nicht aufhalten. Verwende dafür zentral gepflegte, klar erkennbare Platzhalter.

Erfinde keine Veranstaltungsdaten, Leistungen, Qualifikationen, Kundenbewertungen oder rechtlichen Zusicherungen. Fehlende Angaben, die für einen echten Verkauf erforderlich sind, müssen den Live-Verkauf blockieren, aber nicht die Entwicklung oder Stripe-Testbuchungen.

Prüfe vor der Implementierung die aktuellen offiziellen Dokumentationen der eingesetzten Frameworks und Stripe. Dokumentiere relevante Architekturentscheidungen knapp.

## 2. Referenz und gestalterische Richtung

Orientiere dich am Aufbau und an der Besucherführung dieser Seite:

https://www.freedomfilmmaker.de/filmcamp

Analysiere, soweit erreichbar:

- Reihenfolge und Dramaturgie der Inhalte.
- Hero, Bildwirkung und typografische Hierarchie.
- Darstellung von Unterkunft und Dozenten.
- Video-Feedback und Vertrauenselemente.
- Preispräsentation und Buchungseinstieg.
- Mobile Nutzerführung.

Übertrage geeignete Prinzipien in eine eigenständige Gestaltung für ARTISTA. Kopiere keine fremden Texte, Markenbestandteile oder nicht freigegebenen Medien.

Wenn die Referenz nicht erreichbar ist, benenne diese Einschränkung und entwickle anhand dieses Briefings weiter. Behaupte nicht, die Seite analysiert zu haben.

Gestalterische Richtung:

- Hochwertiges, modernes Editorial-Design mit Mode- und Fotografiecharakter.
- Großzügige Bilder, ausdrucksstarke Typografie und bewusst gesetzter Weißraum.
- Warme, mediterrane Atmosphäre passend zu einer Villa in Italien.
- Als vorläufige Farbwelt: warmes Off-White, dunkles Anthrazit und ein zurückhaltender warmer Akzent.
- Markante, individuelle Kompositionen statt einer austauschbaren Ansammlung identischer Karten.
- Gute Lesbarkeit und klare Buchungsführung haben Vorrang vor Effekten.
- Dezente Animationen für Hero, Bildwechsel, Scroll-Reveal, Navigation und Buchungsdialog.
- Keine Scroll-Übernahme und keine Animationen, die Inhalte verzögern oder Bedienung erschweren.
- `prefers-reduced-motion` respektieren.

Die Seite muss auf Smartphones ebenso sorgfältig gestaltet sein wie auf großen Bildschirmen.

## 3. Technischer Rahmen

Bevorzugter Stack:

- TypeScript mit strikter Typprüfung.
- Next.js 16 mit App Router.
- React 19.
- Tailwind CSS v4.
- Motion for React.
- PostgreSQL für persistente Geschäftsdaten.
- Ein geeignetes ORM mit versionierten Migrationen.
- Stripe für Zahlungen.
- Serverseitige Eingabevalidierung, beispielsweise mit Zod.

Prüfe die Versionskompatibilität. Passe den Stack nur bei einem nachvollziehbaren Vorteil an. Fixiere konkrete kompatible Versionen und liefere eine Lockdatei.

Nutze Server Components, wo sinnvoll. Beschränke Client Components auf tatsächlich interaktive Bereiche.

Die Anwendung muss ohne Vercel und ohne proprietäre Hosting-Abhängigkeiten als Docker-Container laufen.

Für ein einzelnes Camp ist kein klassischer Warenkorb erforderlich. Bevorzuge eine direkte, verständliche Buchungsstrecke.

## 4. Seitenstruktur

Entwickle eine schlüssige Dramaturgie mit folgenden Inhalten:

### Hero

- ARTISTA MODELCAMP 2027 als eindeutige Identität.
- Prägnante deutsche Headline und verständliche Subline.
- Hochwertiges Leitmotiv mit austauschbarem Bild oder Video.
- Termin und Ort, sobald bestätigt.
- Klarer Buchungs-CTA.
- Preis abhängig von der tatsächlich gültigen Verkaufsphase.

### Das Camp

Erkläre Atmosphäre, Zielgruppe und bestätigte Inhalte. Formuliere überzeugend, aber ohne erfundene Versprechen.

Keine Aussagen über garantierte Agenturvermittlung, Karriereerfolg, Aufträge oder Verdienst.

### Erlebnisse und Leistungen

Zeige bestätigte Programmpunkte und enthaltene Leistungen übersichtlich. Nicht bestätigte Workshops, Shootings, Transfers, Verpflegungsleistungen oder Ergebnisse dürfen nicht als zugesichert erscheinen.

Ein beispielhafter Ablauf muss als solcher erkennbar sein. Ein verbindliches Programm darf erst mit bestätigten Angaben veröffentlicht werden.

### Unterkunft

- Bildstarke Galerie der Villa beziehungsweise Finca.
- Informationen zu Zimmern und Ausstattung nur aus bestätigten Angaben.
- Der Booking-Link und die Bilder werden nachgereicht.
- Bilder erst nach bestätigter Nutzungsberechtigung übernehmen.
- Kein dauerhaftes Hotlinking fremder Booking-Bilder.
- Bis dahin hochwertige, klar erkennbare Entwicklungsplatzhalter.

### Dozentinnen

Zwei vorbereitete Profile mit austauschbaren Porträts, Namen und Kurzbeschreibungen.

Die tatsächlichen Namen und Bilder werden nachgereicht. Keine erfundenen Lebensläufe oder Referenzen.

### Über ARTISTA

Bereite einen eigenständigen Bereich vor. Inhaltliche Grundlage soll die bestehende Stammmodel-Seite von ARTISTA sein; der Link wird nachgereicht.

Bis dahin keine Unternehmensgeschichte oder Erfolgszahlen erfinden.

### Video-Feedback

Exakt drei Slots für echte Feedback-Videos:

- Austauschbares Vorschaubild.
- Zugänglicher Play-Button.
- Video bei Bedarf laden.
- Keine automatische Tonwiedergabe.
- Platz für echten Namen und freigegebenen Begleittext.

Fehlende Videos nicht durch erfundene Testimonials ersetzen. Leere Slots im Entwicklungsmodus darstellen und im öffentlichen Produktionsbetrieb ausblenden.

### Preis und Buchung

- Verständlicher Gesamtpreis pro Person.
- Gültiger Frühbuchervorteil.
- Einmalzahlung und gegebenenfalls freigegebene Ratenzahlung.
- Neutrales Gutscheinfeld.
- Klare Zusammenfassung von Unterkunft und Leistungen vor Zahlung.

### FAQ und Abschluss

FAQ zu Buchung, Unterkunft, Anreise, Zahlungsweise und bestätigten Bedingungen. Abschließender CTA und Footer mit Kontakt und rechtlichen Verweisen.

Eine mobile Buchungsleiste ist erwünscht, sofern sie keine Inhalte oder Bedienelemente verdeckt.

## 5. Verbindliche Preislogik

Alle Beträge in EUR. Intern ausschließlich mit ganzzahligen Cent-Beträgen rechnen.

| Preisphase | Ohne Stammmodel-Code | Mit gültigem Stammmodel-Code |
|---|---:|---:|
| Early Bird | 2.200,00 € | 1.980,00 € |
| Regulär | 2.750,00 € | 2.475,00 € |

Regeln:

- Grundpreis: 2.750,00 € pro Person.
- Early Bird: 20 % Rabatt auf den Grundpreis.
- Early-Bird-Zeitraum: 01.11.2026 bis einschließlich 31.12.2026, Zeitzone Europe/Berlin.
- Regulärer Preis ab 01.01.2027, 00:00 Uhr Europe/Berlin.
- Vor dem 01.11.2026 standardmäßig Vorschau ohne Kaufmöglichkeit.
- Innerhalb der Early-Bird-Phase 2.750 € als eindeutig bezeichneten regulären Preis durchstreichen und 2.200 € hervorheben.
- Nach Ablauf keine Early-Bird-Darstellung und keine künstliche Verlängerung.

Ein gültiger Stammmodel-Code reduziert den jeweils gültigen Preis anschließend um weitere 10 %:

- 2.750 € × 0,80 × 0,90 = 1.980 €.
- Der kombinierte Nachlass beträgt 28 %, nicht 30 %.
- Regulär: 2.750 € × 0,90 = 2.475 €.

Preise und Berechtigung immer serverseitig berechnen. Niemals vom Browser übermittelte Endpreise übernehmen.

Definiere eine eindeutige Regel für Preisbindung bei begonnenem Checkout und beim Jahreswechsel. Kommuniziere sie verständlich und erzwinge sie auch in Stripe.

Die steuerliche Behandlung ist noch offen. Keine Umsatzsteuerbeträge oder Aussagen wie „inklusive 19 % MwSt.“ erfinden. Vor Live-Verkauf muss die korrekte Darstellung konfiguriert sein.

## 6. Individuelle Stammmodel-Codes

Beispiel:

`STAMMMODELLAURA1X0`

Dieser Beispielcode darf nicht automatisch als aktiver Produktionscode angelegt werden.

Der Nachlass wird persönlich vergeben und nicht öffentlich beworben. Auf der Seite erscheint nur ein neutrales Feld „Gutscheincode“.

Im geschützten Verwaltungsbereich müssen individuelle Codes anlegbar und bearbeitbar sein:

- Code.
- Aktiv/inaktiv.
- Gültigkeitszeitraum.
- Maximale Einlösungen.
- Optional Bindung an eine E-Mail-Adresse.
- Interne Zuordnung.
- Reservierte und abgeschlossene Einlösungen.

Codes sollen mit Early Bird kombinierbar sein, aber nicht mit weiteren Gutscheinen.

Verhindere Missbrauch durch serverseitige Prüfung, Rate Limiting und transaktionale Einlöselimits. Reservierungen bei abgebrochenem oder abgelaufenem Checkout korrekt freigeben.

Die Vorlage empfiehlt höchstens vier vergünstigte Stammmodel-Buchungen. Implementiere ein konfigurierbares Gesamtkontingent und hinterlege vier als vorläufigen, vor Live-Verkauf zu bestätigenden Wert.

Keine öffentlich sichtbare Liste gültiger Codes.

## 7. Zahlungsvarianten

Bereite folgende exakten Zahlungspläne vor:

| Variante | Einmalzahlung | Zwei Raten | Drei Raten |
|---|---:|---|---|
| Early Bird | 2.200,00 € | 1.100,00 € + 1.100,00 € | 800,00 € + 700,00 € + 700,00 € |
| Early Bird Stammmodel | 1.980,00 € | 990,00 € + 990,00 € | 660,00 € + 660,00 € + 660,00 € |
| Regulär | 2.750,00 € | 1.375,00 € + 1.375,00 € | 950,00 € + 900,00 € + 900,00 € |
| Regulär Stammmodel | 2.475,00 € | 1.237,50 € + 1.237,50 € | 825,00 € + 825,00 € + 825,00 € |

- Maximal drei Raten.
- Erste Rate bei Buchung.
- Letzte Rate spätestens 30 Tage vor Anreise.
- Konkrete weitere Fälligkeiten benötigen einen bestätigten Camp-Termin und eine freigegebene Terminregel.
- Keine Termine erfinden.
- Wenn die verbleibende Zeit eine Zahlungsvariante nicht mehr zulässt, diese serverseitig deaktivieren.

Die Raten aus der Vorlage sind fachliche Vorgaben, keine rechtliche Freigabe. Zahlungspläne technisch vorbereiten und im Testmodus prüfen; im Live-Modus erst nach Prüfung und ausdrücklicher Freigabe aktivieren.

Wähle eine anhand aktueller Stripe-Dokumentation geeignete Umsetzung für endliche Zahlungspläne mit teilweise unterschiedlichen Ratenbeträgen. Begründe die Entscheidung.

Kein unbegrenzt laufendes Abonnement und keine Gleichsetzung mit Klarna oder anderen externen Finanzierungsangeboten.

Falls spätere Raten automatisch eingezogen werden:

- Erforderliche Zustimmung und geeignete Zahlungsmethoden berücksichtigen.
- Zusätzliche Authentifizierung ermöglichen.
- Fehlgeschlagene Zahlungen und Wiederholungsversuche sauber abbilden.
- Nach der letzten Rate weitere Abbuchungen zuverlässig ausschließen.

Zeige Gesamtpreis, heute fälligen Betrag, restliche Raten und Fälligkeiten vor dem Zahlungsabschluss transparent an.

## 8. Unterkunft und Kapazität

Die vorliegenden Angaben zur Zimmerart sind widersprüchlich:

- Es wird von einem einzelnen Platz in einem geteilten Zimmer gesprochen.
- Die interne Kalkulation nennt fünf Doppelzimmer mit französischem Doppelbett für zehn Teilnehmerinnen.

Erfinde daraus keine Einzelzimmer oder getrennten Einzelbetten.

Bis zur Klärung gilt:

- Nur ein Buchungsprodukt: Teilnahme pro Person mit geteilter Unterbringung.
- Keine buchbare Einzelbelegung.
- Keine Zimmer-Upgrades.
- Keine Auswahl zwischen mehreren Unterkunftskategorien.
- Ein möglicherweise geteiltes französisches Doppelbett muss vor einem echten Kauf ausdrücklich und korrekt beschrieben werden.
- Live-Verkauf bleibt bis zur Bestätigung der Unterbringung gesperrt.

Intern vorläufig mit zehn verkaufbaren Teilnehmerinnenplätzen rechnen. Den Wert konfigurierbar halten und vor Veröffentlichung bestätigen lassen.

Keine öffentliche Platzzahl, keinen Restplatz-Zähler und keine künstliche Verknappung anzeigen.

Verhindere Überbuchungen durch Datenbanktransaktionen und zeitlich begrenzte Reservierungen. Berücksichtige parallele Checkouts, verzögerte Zahlungen und verspätete Webhooks.

## 9. Stripe und Bestellprozess

Bevorzuge Stripe Checkout, sofern es den bestätigten Ablauf vollständig abbildet. Verwende eine eingebettete Zahlungsoberfläche nur bei begründetem Mehrwert.

Ablauf:

1. Person startet Buchung auf der Onepage.
2. Buchungsdaten und Zahlungsvariante werden erfasst.
3. Optionaler Gutschein wird serverseitig geprüft.
4. Gesamtpreis, Unterkunft, Leistungen und Zahlungsplan werden zusammengefasst.
5. Erforderliche Erklärungen werden eingeholt.
6. Bestellung und Platzreservierung werden serverseitig angelegt.
7. Stripe-Zahlung wird gestartet.
8. Verifizierte Webhooks aktualisieren den Zahlungsstatus.
9. Bestätigungsseite und E-Mail zeigen den tatsächlich bestätigten Status.

Ein Aufruf der Erfolgsseite darf niemals allein eine Bestellung als bezahlt markieren.

Erforderlich sind:

- Prüfung der Stripe-Webhook-Signatur anhand des unveränderten Request-Bodys.
- Idempotente Checkout-Erstellung und Webhook-Verarbeitung.
- Umgang mit mehrfachen, verzögerten und ungeordneten Events.
- Getrennte Buchungs- und Zahlungszustände.
- Behandlung von Abbruch, Ablauf, Zahlungsfehlern und Rückerstattungen.
- Nachvollziehbare Zuordnung von Stripe-Objekten zu internen Bestellungen.
- Speicherung des bei Buchung vereinbarten Preises und Zahlungsplans als unveränderlicher Snapshot.
- Keine Zahlungsdaten wie Kartennummern in der eigenen Datenbank.

Bei Ratenzahlung bedeutet eine erfolgreiche erste Rate nicht „vollständig bezahlt“. Zeige Teilzahlung und offenen Betrag korrekt an.

Die Buchungsbestätigung erfolgt per konfigurierbarem E-Mail-Anbieter oder SMTP. Im Entwicklungsmodus einen sicheren Testausgang verwenden.

## 10. Verwaltung und Datenmodell

Erstelle einen schlanken, wirklich geschützten Adminbereich für:

- Buchungsübersicht und Buchungsdetails.
- Zahlungsstatus, offene Beträge und Fälligkeiten.
- Filter und CSV-Export.
- Gutscheinverwaltung.
- Interne Kapazität und Reservierungen.
- Pflege der notwendigen Camp-Konfiguration.
- Dokumentierten Umgang mit Stornierungen und Rückerstattungen.

Kein offener Adminbereich und keine fest eingebauten Standardpasswörter. Nutze eine etablierte Authentifizierungslösung und prüfe Berechtigungen auch serverseitig bei jeder Aktion.

Modelliere mindestens:

- Camp und Verkaufsfreigaben.
- Buchung und Teilnehmerdaten.
- Preis-Snapshot.
- Zahlungsplan und Raten.
- Gutschein und Einlösung.
- Platzreservierung.
- Verarbeitete Stripe-Events.

Bestandsänderungen und Zahlungsaktionen müssen nachvollziehbar sein.

## 11. Inhalte und Freigaben

Die beigefügte Kalkulation enthält interne Informationen. Folgendes darf nicht auf die öffentliche Seite oder in öffentlich ausgelieferte Daten gelangen:

- Kosten der Villa und Verpflegung.
- Margen, Gewinn und Break-even.
- Werbebudget.
- Teambelegung.
- Interne Argumentation zu Stammmodel-Rabatten.
- Interne Empfehlungen zu Kontingenten.

Laut Vorlage nicht enthalten:

- Anreise nach Italien und zurück.
- Persönliche Ausgaben vor Ort.
- Reiserücktrittsversicherung.

Diese Ausschlüsse müssen verständlich dargestellt werden. Leite aus internen Kostenpositionen keine öffentlich zugesicherten Leistungen ab.

Vor Live-Verkauf sind insbesondere erforderlich:

- Bestätigter Termin und Ort.
- Veranstalter- und Kontaktdaten.
- Bestätigte Unterkunft und enthaltene Leistungen.
- Steuerlich korrekte Preisangaben.
- Freigegebene Buchungs-, Storno- und Zahlungsbedingungen.
- Prüfung der reiserechtlichen Einordnung sowie gegebenenfalls erforderlicher Absicherung und Unterlagen.

Übernimm rechtliche Aussagen aus der Kalkulation nicht ungeprüft als geltendes Recht. Erfinde keine rechtssicheren AGB.

Implementiere eine serverseitige Verkaufsfreigabe, die auch direkt aufgerufene Checkout-Endpunkte schützt. Testmodus und Vorschau müssen ohne Live-Freigabe nutzbar bleiben.

## 12. Qualität und Datenschutz

- Tastaturbedienbarkeit, sichtbare Fokuszustände und ausreichende Kontraste.
- Beschriftete Formulare und verständliche Fehlermeldungen.
- Korrektes Fokusmanagement in Dialogen.
- Responsive Bilder und performantes Laden.
- Keine unnötig großen Client-Bundles.
- Keine personenbezogenen Daten oder Secrets in Logs.
- Serverseitige Validierung aller Eingaben.
- Schutz schreibender Endpunkte und administrative Zugriffskontrollen.
- Keine nicht erforderlichen Tracking-Dienste ohne passende Einwilligung.
- Externe Videoanbieter erst gemäß konfiguriertem Datenschutzkonzept laden.

Bereite Titel, Beschreibung, Canonical und Social-Sharing-Vorschau vor. Strukturierte Veranstaltungsdaten erst mit bestätigten Angaben ausgeben. Vorschau, Admin und Buchungsstatusseiten nicht indexieren.

## 13. Deployment auf RKE2

Liefere:

- Produktionsfähiges Multi-Stage-Dockerfile.
- Next.js-Standalone-Build.
- Ausführung als Nicht-Root.
- `.dockerignore`.
- `.env.example` ohne echte Secrets.
- Lokale Entwicklungsumgebung mit PostgreSQL.
- Kubernetes-Manifeste oder eine übersichtliche Helm-Struktur.
- Deployment, Service und Traefik-Ingress.
- Konfigurierbare Domain, IngressClass und TLS-Einstellungen.
- cert-manager-Anbindung mit konfigurierbarem ClusterIssuer; `letsencrypt-prod` als anpassbares Beispiel.
- Readiness- und Liveness-Probes.
- Ressourcenanforderungen und sinnvolle Limits.
- Separaten, kontrollierten Datenbank-Migrationsschritt.
- Dokumentation für Secrets, Stripe-Webhooks und E-Mail-Konfiguration.

Die Anwendung muss mehrere Replikate vertragen. Bestellungen, Kapazitäten, Gutscheine, Reservierungen und Zahlungsjobs dürfen nicht ausschließlich im Prozessspeicher liegen.

Keine In-Process-Timer für verbindliche Ratenfälligkeiten. Verwende Stripe-native Terminierung oder einen dauerhaften, idempotenten Worker beziehungsweise Kubernetes-CronJob.

PostgreSQL braucht geeigneten Datenbankspeicher. SMB-Freigaben nicht ungeprüft als PostgreSQL-Datenverzeichnis verwenden. Medien separat persistent speichern; kein `emptyDir` für dauerhaft benötigte Uploads.

Dokumentiere Backup und Wiederherstellung der Geschäftsdaten.

## 14. Tests und Abnahme

Teste die tatsächlichen Geschäftsrisiken:

- Alle vier Gesamtpreise.
- Exakte Ratensummen einschließlich 1.237,50 €.
- Zeitgrenzen am 01.11.2026 und 01.01.2027 in Europe/Berlin.
- Ungültige, abgelaufene und ausgeschöpfte Gutscheine.
- Gleichzeitige Einlösung begrenzter Codes.
- Gleichzeitige Buchungen bei knapper Kapazität.
- Abgelaufene Reservierungen und verspätete Zahlung.
- Doppelte und ungeordnete Stripe-Webhooks.
- Zahlungserfolg, Abbruch, Fehler und Teilzahlung.
- Sperre sämtlicher Live-Checkout-Zugänge ohne Freigabe.
- Verhinderung weiterer Abbuchungen nach der letzten Rate.
- Zugriffsschutz für Admin und Buchungsdaten.

Führe außerdem Build, Typprüfung und eine visuelle Prüfung auf Smartphone, Tablet und Desktop durch.

## 15. Erwartetes Ergebnis

Liefere eine fertig implementierte Anwendung mit:

1. Hochwertiger Onepage.
2. Funktionierender Stripe-Testbuchung.
3. Persistenter Bestell- und Gutscheinverwaltung.
4. Geschütztem Adminbereich.
5. Docker- und RKE2-Deployment.
6. Verständlicher README.
7. Kurzer Liste der noch benötigten Inhalte und Freigaben.
8. Übersicht der ausgeführten Tests und verbleibenden Einschränkungen.

Pflege offene Inhalte zentral, insbesondere:

- Camp-Termin und genauer Ort.
- Booking-Link und freigegebene Unterkunftsbilder.
- Verbindliche Zimmer- und Bettbeschreibung.
- Namen und Porträts der beiden Dozentinnen.
- Link zur ARTISTA-Stammmodel-Seite.
- Drei echte Feedback-Videos.
- Bestätigte Leistungen und Programm.
- Veranstalterdaten, steuerliche Angaben und freigegebene Bedingungen.

Beginne mit einer knappen Architektur- und Designentscheidung und setze anschließend die Anwendung um. Stoppe nicht nach einem Konzept oder einer statischen Oberfläche.