first commit

Ziel

@@ -0,0 +1,437 @@
+
+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.