Baue auf meinem Opus Growth Hosting-Server
[server name] eine dunkle, mehrseitige Produktwebsite für
[product name], die ihre Geschichte beim Scrollen erzählt. Produkt:
[what it does, who it is for]. Die drei Schritte, die Nutzer im Produkt durchlaufen:
[three steps]. Wichtigste Funktionen:
[4 to 6 features]. Kontakt:
[email],
[phone],
[WhatsApp number],
[address if any]. Domain:
[domain]. Farbwunsch:
[colour or "you choose"]. Echte Produkt-Screenshots oder Fotos:
[links or "none"].
Seiten: Startseite (/), Produkt (/urun/), Über uns (/hakkimizda/), Kontakt (/iletisim/), Datenschutz (/gizlilik/) und 404.html. Abschnitte der Startseite in dieser Reihenfolge: Hero (h1, Beschreibung in zwei Sätzen, zwei Buttons, Produktbild), die Produktstory als Signature-Element, Funktionen, Zielgruppe, FAQ und ein abschließender Call-to-Action. Kein Formular auf der Kontaktseite; nutze E-Mail, Telefon und einen WhatsApp-Link mit vorausgefüllter Nachricht, weil der Server nur statische Dateien ausliefert.
Stil: Dark Motion. Dunkler Hintergrund, eine zurückhaltende Akzentfarbe (kein Neon), eine enge Grotesk als Display-Schrift von Fontshare (z. B. Cabinet Grotesk) und eine ruhige Fließtextschrift (z. B. Switzer). Keine Verläufe und kein WebGL; hebe dir das Auffällige für die Produktstory auf.
Animationsregeln (der schwierigste Teil, befolge sie buchstabengetreu):
1. Bibliotheken: GSAP 3.13 Core, ScrollTrigger, SplitText und Lenis. Lade sie mit site_fetch von jsdelivr in `assets/vendor/` herunter und fixiere die Version. Lade sie nur auf der Start- und der Produktseite; die Seiten Über uns, Kontakt und Datenschutz enthalten gar kein Skript. Lade Swiper nicht.
2. Binde diese nicht mit `<script defer>` ein. Setze am Ende der Seite einen kleinen Loader ein: Nach dem load-Event wartet er zwei requestAnimationFrame-Aufrufe und dann requestIdleCallback, hängt die Skripte der Reihe nach mit async=false an und lädt nichts herunter, wenn `<html>` die Klasse `anim` nicht hat. In der Demo haben per defer geladene Bibliotheken die mobile LCP auf 3,2 s getrieben und die Performance bei 92 belassen; mit diesem Loader waren es 99.
3. Ein einzeiliges Skript im `<head>` setzt die Klasse `js` auf `<html>` und die Klasse `anim`, es sei denn, prefers-reduced-motion ist "reduce". Definiere versteckte Ausgangszustände nur unter `.anim`, damit Inhalte ohne JS oder für Besucher, die weniger Bewegung bevorzugen, von Anfang an sichtbar sind und die Bibliotheken für sie nie heruntergeladen werden. Als Sicherheitsnetz für den Fall, dass eine Bibliothek nicht lädt, füge eine CSS-Animation hinzu, die jedes versteckte Element nach 2,5 s sichtbar macht. Wenn JS später als das eintrifft, verstecke bereits sichtbare Inhalte nicht erneut; baue nur die fixierte Story auf.
4. SplitText-Einstieg für Überschriften: Die h1 im ersten Bildschirm ist das LCP-Element, starte sie nie versteckt. Die h1 beginnt sichtbar in einer abgedunkelten Farbe, die den AA-Kontrast noch besteht, und SplitText bringt ihre Zeilen nacheinander in volle Farbe (mask- und aria-Optionen aktiviert). Behalte den maskierten Einstieg mit aufsteigenden Zeilen für die weiter unten liegenden h2-Überschriften bei und spiele ihn beim Scrollen mit ScrollTrigger ab.
5. Signature-Element: Nutze in der Produktstory ScrollTrigger pin und scrub über gsap.matchMedia nur ab 768 px Breite (scrub etwa 0.6, end "+=180%"). Links werden die drei Schritte nacheinander aktiv; rechts füllt sich der Produktbildschirm Schritt für Schritt. Dimme inaktive Schritte nicht über opacity; ändere nur die Überschriftenfarbe und die Rahmenlinie. In der Demo haben über opacity gedimmte Schritte auf dem Desktop den Kontrasttest nicht bestanden und die Barrierefreiheit auf 95 gedrückt. Auf Mobilgeräten gibt es kein Pinning; die Schritte erscheinen im normalen Fluss. Ohne JS zeigt der Produktbildschirm seinen fertigen Zustand.
6. Aktiviere Lenis nur für `(pointer: fine)`-Geräte, damit Touch-Geräte natives Scrollen behalten. Steuere Lenis über gsap.ticker und setze den Fokus nach dem Scrollen zu einem Anker-Link auf das Ziel.
7. Der Produktbildschirm ist eine dekorative Figure mit aria-hidden und einer figcaption, die beschreibt, was gezeigt wird. Jede Interaktion funktioniert per Tastatur und der Fokusring bleibt sichtbar.
Setup und bekannte Fallstricke (jeder davon hat in den Demo-Messungen einen Wert gesenkt, überspringe keinen):
1. Wenn auf dem Server bereits eine Website live ist, sag mir das zuerst, denn das Setup überschreibt index.html und den Ordner assets. Zeige scaffold_site mit confirm=false als Vorschau und rufe es nach meiner Freigabe mit confirm=true auf. Lies danach site_design_guide und site_seo_guide. Lege vor dem Schreiben von Code die Designrichtung (Typografie, Farbe, Raster, Signature-Element, Bewegungssprache und die Bibliotheken, die NICHT geladen werden) in einer kurzen ART.md außerhalb von assets ab und zeig sie mir.
2. Kompiliere Tailwind, statt es vom CDN zu laden. Installiere es mit site_run_command und background=true: `npm i -D tailwindcss@3`, danach site_command_status. Die content-Pfade in `tailwind.config.js` müssen jede HTML-Datei, die Templates und jede JS-Datei abdecken, die Klassennamen schreibt. `_src/tw.css` enthält die Zeile `@import "../assets/app.css";` und die drei `@tailwind`-Zeilen; kompiliere sie mit `npx tailwindcss -c tailwind.config.js -i _src/tw.css -o assets/site.css --minify` zu einer einzigen Datei. Entferne das Skript cdn.tailwindcss.com und die Inline-tailwind.config von jeder Seite und verlinke nur `/assets/site.css`. Kompiliere nach jeder HTML-Änderung neu.
3. Hoste die Schriften selbst. Lies das CSS der gewählten Fontshare-Familien, lade die woff2-Datei jeder Schriftstärke mit site_fetch nach `assets/fonts/` herunter und schreibe die @font-face-Regeln mit `font-display: swap` in `assets/app.css`; design-check sucht dort nach einer eigenen Schrift. Prüfe den font-family-Namen im heruntergeladenen CSS, denn Fontshare kann eine andere Familie liefern, wenn eine Schriftstärke nicht existiert. Lade die Schrift der Überschrift im ersten Bildschirm und die Fließtextschrift auf jeder Seite per `<link rel="preload" as="font" type="font/woff2" crossorigin>` vor; in der Demo hat das die durch den Schrifttausch verursachte Layoutverschiebung beseitigt (CLS 0,024 auf 0). Die meisten Fontshare-Schriften haben kein ₺-Glyph, schreibe für Preise also "TL".
4. Mache Menü und Footer zu statischem HTML. Lade chrome.js und site.config.js nicht auf den Seiten. Schreibe ein kleines `chrome-stamp.mjs`, das die Navigationsliste in site.config.js liest und `_src/header.tpl` sowie `_src/footer.tpl` zwischen den Markern `<!-- nav:start --><!-- nav:end -->` und `<!-- footer:start --><!-- footer:end -->` jeder Seite einstempelt und dabei dem aktuellen Link aria-current="page" hinzufügt. Gib den Templates keine .html-Endung und verwende Platzhalter wie `
[[NAV]]` statt `{{...}}`, sonst lesen design-check und seo-check sie als unfertige Seiten. Baue das mobile Menü ohne JS mit `<details>`. Lass Firmenname, Adresse und Telefon im Footer als reinen Text stehen.
5. Konvertiere Bilder direkt beim Herunterladen mit site_fetch: Schreibe dasselbe Foto in separate Dateien mit resize="480x", "800x" und "1200x", image_format="webp", quality=65. Gib jedem `<img>` srcset, sizes, width und height. Das Hauptbild im ersten Bildschirm bekommt fetchpriority="high" und wird nie lazy geladen; die übrigen bekommen loading="lazy" decoding="async". Wenn das Hauptbild den Handybildschirm ausfüllt, liefere mit `<picture>` auf Mobilgeräten einen breiteren, kleineren Ausschnitt aus (in der Demo sank das mobile Hero-Bild von 89 KB auf 43 KB).
6. Erstelle mit site_fetch aus dem Logo ein 48-px-PNG-Favicon und füge `<link rel="icon">` zu jeder Seite hinzu. Ohne es protokolliert der Browser einen 404 und Best Practices fällt auf 96.
7. Regeln des HTML-Validators: Beginne jedes Dokument mit einem großgeschriebenen `<!DOCTYPE html>` (die Starterdateien des Kits verwenden Kleinbuchstaben), nutze ` ` für die Leerzeichen im sichtbaren Text von tel:-Links, verwende nie ein style=""-Attribut und gib jedem Button type="button".
SEO, AEO und GEO:
1. Verwende Verzeichnis-URLs mit abschließendem Schrägstrich (/urun/, /hakkimizda/, /iletisim/, /gizlilik/). Fülle den seo-Block in site.config.js aus und führe `node seo-stamp.mjs` aus. Schreibe das seitenspezifische Schema (Startseite WebPage und FAQPage; Produkt SoftwareApplication und FAQPage; Über uns AboutPage; Kontakt ContactPage; BreadcrumbList auf Unterseiten. Für ein Softwareunternehmen ohne physisches Geschäft setze localBusiness:false in site.config.js) in getrennte `<script type="application/ld+json">`-Blöcke und verknüpfe es per @id mit dem Basisgraphen. Vergrabe BreadcrumbList nicht in einem @graph; gib ihm einen eigenen Block, denn nur so erkennt seo-check es.
2. Title 48 bis 60 Zeichen (seo-check meldet alles über 65 als Fehler), Descriptions 145 bis 158 Zeichen, eine h1 pro Seite. Jede Seite braucht mindestens 150 Wörter Hauptinhalt; Kontakt- und Datenschutzseite bleiben oft darunter.
3. Der erste Absatz jeder Seite beantwortet die Frage der Seite direkt. Schreibe ein seitenspezifisches FAQ mit `<details>` und zeichne es als FAQPage aus. Zeige die veröffentlichende Organisation und ein Datum "Zuletzt aktualisiert" mit `<time>`.
4. Schreibe in robots.txt deine Entscheidung samt Begründung für GPTBot, OAI-SearchBot, ChatGPT-User, ClaudeBot, Claude-User, Claude-SearchBot, PerplexityBot, Perplexity-User, Google-Extended, Applebot-Extended, Bingbot und CCBot und verweise auf die Sitemap. sitemap.xml enthält echte lastmod-Daten. llms.txt enthält eine korrekte Zusammenfassung der Website in zwei Sätzen und die Liste der wichtigsten Seiten.
5. Erfinde nichts: keine Bewertungen, Ratings, Auszeichnungen, Kundenzahlen, Zertifikate, Öffnungszeiten, Koordinaten oder Preise, außer ich nenne sie dir. Lass unbekannte Felder im Schema weg.
Gates (der Reihe nach; melde den Abschluss erst, wenn alle bestanden sind):
1. Führe mit site_run_command `node chrome-stamp.mjs`, den Tailwind-Build, `node seo-stamp.mjs`, `node seo-check.mjs` (0 Fehler, 0 Warnungen), `node design-check.mjs` (0 Fehler; begründe jede verbleibende Warnung) und `npx html-validate "**/*.html"` (0 Fehler) aus.
2. Sieh dir jede Seite mit site_preview an, view="mobile" und view="desktop". site_preview erfasst die Seite mit ausgeschalteter Bewegung (reduced-motion); fehlen auf diesem Bild also Inhalte, ist der Zustand ohne Bewegung defekt. In Full-Page-Aufnahmen können weiter unten liegende Lazy-Bilder leer erscheinen; das ist kein Fehler, prüfe aber ihre Pfade.
3. Führe core_web_vitals für jede Seite mit strategy="mobile" und strategy="desktop" aus. Bestanden: mobil Performance mindestens 95 sowie Barrierefreiheit, Best Practices und SEO 100; Desktop alle vier mindestens 95. Finde auf einer durchgefallenen Seite mit resources=true die bremsende Datei, behebe das Problem und miss erneut. Führe danach seo_audit auf der Startseite mit strategy="mobile" und runs=2 aus. Die Liste der Netzwerkanfragen darf keinen anderen Host als deine eigene Domain enthalten.
4. Kein horizontales Scrollen bei 360, 390, 768 und 1440 px Breite, Touch-Ziele mindestens 44 px, keine Konsolenfehler.
Bewegungsprüfung: site_preview kann keine Bewegung zeigen. Beschreibe daher den fixierten Abschnitt der Startseite und sag mir, was ich in meinem eigenen Browser prüfen soll: Auf dem Desktop sollte die Produktstory oben haften bleiben, während die Schritte beim Scrollen voranschreiten; auf dem Handy sollte sie ohne Haften durchfließen; und bei eingeschaltetem reduzierten Bewegungsmodus im Betriebssystem sollte sich nichts bewegen und alles sichtbar sein.
Nach der Veröffentlichung: Zeige mit site_headers die Regel `/assets/* Cache-Control: public, max-age=31536000, immutable` als Vorschau und wende sie nach meiner Freigabe an; benenne CSS- oder JS-Dateien danach bei jeder Änderung um (site-v2.css usw.). Reiche sitemap.xml mit
