Baue auf meinem Opus Growth Hosting-Server
[server name] den
[year]-Wirkungsbericht von
[organisation name] als Website, die ihre Geschichte beim Scrollen erzählt. Organisation:
[what it does, where, founding year]. Kernaussage des Berichts:
[one sentence]. Die vier Hauptkennzahlen:
[figure, unit, one-sentence explanation]. Diagrammdaten:
[for each chart, title, periods and values]. Budget:
[income sources and expense lines, amounts and shares]. Kapitel:
[chapter names and the text or notes for each]. Plan für nächstes Jahr:
[items]. Woher die Zahlen stammen und wo ihre Grenzen liegen:
[which records, how missing data was handled]. Erstellt von und Veröffentlichungsdatum:
[editor's name, date]. Kontakt:
[email],
[phone],
[address]. Domain:
[domain]. Fotos:
[links; no faces of children or beneficiaries].
Seiten: Bericht (/: Titelschlagzeile, Zusammenfassungsabsatz mit der Antwort zuerst, Autor und Datum, Titelbild, mitlaufende Kapitelnavigation und der Reihe nach Jahresübersicht, Kapitel, Budget, Plan für nächstes Jahr und Fragen zum Bericht), Methodik (/yontem/: Quelle und Grenzen jeder Zahl), Organisation und Kontakt (/dernek/ oder ein Name, der zu Ihrer Organisation passt), Datenschutz und KVKK (/gizlilik/) und 404.html. Schreibe die Diagramme als statisches SVG, das aus den von mir genannten Werten erzeugt wird, nicht mit Chart.js oder D3; runde die Werte nicht und prüfe, ob die Summen stimmen. Zeige das Budget als `<table>` ohne jede Mindestbreite, nicht als Diagramm.
Stil: ein Longread wie eine Daten-Reportage in der Zeitung. Papierfarbener Hintergrund, eine Fontshare-Serifenschrift für Überschriften (zum Beispiel Bespoke Serif) und eine gut lesbare Textschrift mit tabular-nums-Unterstützung (zum Beispiel Epilogue), höchstens zwei Diagrammfarben. Auf dem Desktop eine 220 px breite, mitlaufende Kapitelliste links; auf dem Smartphone eine horizontal scrollbare Kapitelleiste, die oben haften bleibt, mit einer dünnen Lesefortschrittslinie darunter.
Bewegungsregeln (der schwierigste Teil, bitte buchstabengetreu befolgen):
1. Bibliotheken: nur der GSAP-3.13-Core und ScrollTrigger, nur auf der Berichtsseite. Lenis wird NICHT geladen, weil natives Scrollen für einen Longread angenehmer ist; auch SplitText und Diagrammbibliotheken werden nicht geladen. Auf den Seiten Methodik, Organisation und Datenschutz gibt es überhaupt keine Skripte.
2. Liniendiagramme: Jede Linie ist ein `<path pathLength="1">` und im HTML vollständig gezeichnet. JS setzt strokeDasharray 1 und strokeDashoffset 1 nur bei Diagrammen, die beim Laden unterhalb des Bildschirms liegen, und führt den Offset per ScrollTrigger-scrub (start "top 75%", end "bottom 65%") auf 0; Datenpunkte wachsen ein, sobald die Linie sie erreicht. SVG-Text muss in einer viewBox von 600 Einheiten mindestens 22 Einheiten groß sein, damit er auf Smartphones über 12 px bleibt, und rechts müssen mindestens 40 Einheiten frei bleiben, damit das letzte Achsenlabel nicht abgeschnitten wird.
3. Jedes Diagramm ist ein `<svg role="img" aria-labelledby>` mit title und desc, die alle Werte in einem Satz nennen; die figcaption zeigt die Quelle und verlinkt auf die Methodikseite, und DIREKT NACH der Figure folgt ein `<details>` mit der Beschriftung "Daten als Tabelle anzeigen", das eine echte `<table>` enthält. Diese Tabelle ist die Textversion der Daten für Barrierefreiheit und KI-Suche.
4. Zähler: Der Endwert steht im HTML im türkischen Format (zum Beispiel 31.540). Die sichtbare Zahl steht in einem aria-hidden-span, derselbe Wert in einem sr-only-span für Screenreader. JS setzt nur Zähler auf 0 zurück, die beim Laden unterhalb des Bildschirms liegen, und zählt sie mit Intl.NumberFormat("tr-TR") hoch, sobald sie in den Bildschirm kommen; eine bereits sichtbare Zahl wird nie zurückgespult. Gib der Zahl tabular-nums und eine Mindestbreite, die der Zeichenzahl des Endwerts entspricht (mit einer Tailwind-Klasse, nicht mit einem style-Attribut), damit die Zeile beim Zählen nicht springt.
5. Kapitelnavigation: Die Links sind Anker, die ohne JS funktionieren. JS ermittelt per ScrollTrigger je Kapitel das aktive, setzt aria-current="true" auf dessen Link und scrollt die Leiste auf dem Smartphone seitlich, sodass der aktive Link sichtbar ist (die Leiste, nicht die Seite). Das Haften gehört an die Sidebar (aside), die direktes Kind des Grids über den gesamten Bericht ist, nicht an die innere nav; in der Demo blieb sticky auf der inneren nav auf Smartphones nie haften.
6. Keine weitere Bewegung außer der Lesefortschrittslinie und den Bildern, die mit data-reveal erscheinen.
Einrichtung und bekannte Fallstricke (jeder einzelne hat in der Demo-Messung Punkte gekostet oder etwas kaputt gemacht, keinen überspringen):
1. Wenn auf dem Server bereits eine Live-Seite liegt, sag es mir zuerst, denn die Einrichtung überschreibt index.html und den Ordner assets. Zeige scaffold_site mit confirm=false als Vorschau und rufe nach meiner Freigabe confirm=true auf. Lies danach site_design_guide und site_seo_guide. Bevor du Code schreibst, lege die Designrichtung (Typografie, Farbe, Raster, Signaturelement, Bewegungssprache und die Bibliotheken, die NICHT geladen werden) in einer kurzen ART.md außerhalb von assets ab und zeige sie mir.
2. Tailwind kompilieren, nicht vom CDN laden. Installiere `npm i -D tailwindcss@3` mit site_run_command und background=true und beobachte es mit site_command_status. Die content-Pfade in `tailwind.config.js` müssen jede HTML-Datei, jedes Template und jede JS-Datei abdecken, die Klassen schreibt. `_src/tw.css` enthält eine 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 aus den Seiten und verlinke nur `/assets/site.css`. Kompiliere nach jeder HTML-Änderung neu.
3. Schriften selbst hosten. Prüfe zuerst, dass die gewählte Fontshare-Familie die türkischen Buchstaben hat (ş, ğ, ı, İ, ç, ö, ü): In der Demo hatte Tanker kein punktloses ı und Outfit kein ş, ğ oder İ, sodass diese Buchstaben in Überschriften auf eine andere Schrift zurückfielen. Lade die woff2-Datei jedes Schnitts einzeln mit site_fetch nach `assets/fonts/`, schreibe die @font-face-Regeln mit `font-display: swap` in `assets/app.css` (design-check sucht dort nach der Custom-Font) und prüfe den font-family-Namen im heruntergeladenen CSS. Lade die im sichtbaren Bereich genutzten Überschrift- und Textschriften auf jeder Seite mit `<link rel="preload" as="font" type="font/woff2" crossorigin>` vor, noch vor dem Stylesheet; preloade nicht mehr als zwei Dateien, denn ein dritter vorgeladener Schnitt verlängerte in der Demo den mobilen LCP um 0,2 Sekunden. Den meisten Fontshare-Schriften fehlt das ₺-Zeichen, also schreibe für Preise "TL".
4. Menü und Footer als statisches HTML. Lade chrome.js oder site.config.js nicht auf den Seiten. Schreibe ein kleines `chrome-stamp.mjs`, das die Navigationsliste aus site.config.js liest und `_src/header.tpl` und `_src/footer.tpl` auf jeder Seite zwischen die Marker `<!-- nav:start --><!-- nav:end -->` und `<!-- footer:start --><!-- footer:end -->` stempelt und dem aktiven Link aria-current="page" gibt. Templates dürfen nicht auf .html enden und müssen Platzhalter wie `
[[NAV]]` statt `{{...}}` verwenden. Baue das mobile Menü ohne JS mit `<details>`. Halte Name, Adresse und Telefon der Organisation als reinen Text im Footer und gib jedem Touch-Ziel mindestens 44x44 px, auch den Links in Footer und Breadcrumb.
5. Bilder schon beim Herunterladen mit site_fetch konvertieren: Schreibe dasselbe Foto mit resize="480x", "800x" und "1200x", image_format="webp", quality=65 in getrennte Dateien. site_fetch schneidet nie zu; wenn ein Unsplash-Foto ein anderes Seitenverhältnis braucht, lade die zugeschnittene Version, indem du der URL Parameter wie `?w=1600&h=1200&fit=crop` anhängst. Gib jedem `<img>` srcset, sizes sowie width und height passend zum echten Seitenverhältnis. Das große Bild im sichtbaren Bereich bekommt fetchpriority="high" und wird nicht lazy geladen; die übrigen bekommen loading="lazy" decoding="async". Wenn das Hauptbild auf dem Smartphone den Bildschirm füllt, liefere mit `<picture>` einen kleineren Zuschnitt.
6. Schreibe die SVG-Version des Logos mit site_write_file als favicon.svg und füge jeder Seite `<link rel="icon" href="/favicon.svg" type="image/svg+xml">` hinzu. Ohne Favicon protokolliert der Browser einen 404, und Best Practices fällt auf 96.
7. Regeln des HTML-Validators: Beginne mit einem großgeschriebenen `<!DOCTYPE html>`, verwende ` ` für die Leerzeichen im sichtbaren Text von tel:-Links, nutze nie ein style=""-Attribut, gib jedem Button type="button" und setze kein `<details>` nach der figcaption in eine `<figure>`.
8. Lade die Bewegungsbibliotheken (GSAP, ScrollTrigger) von jsdelivr mit site_fetch nach `assets/vendor/`, pinne die Version und lade sie nur auf der Berichtsseite. Verwende kein `<script defer>`; setze am Seitenende einen kleinen Loader, der auf das load-Ereignis, zwei requestAnimationFrame-Aufrufe und dann requestIdleCallback wartet und die Skripte der Reihe nach mit async=false anhängt. Ein einzeiliges Skript im `<head>` fügt `<html>` die Klasse `js` hinzu und die Klasse `anim`, außer prefers-reduced-motion ist "reduce"; ohne `anim` lädt der Loader nichts. Definiere versteckte Startzustände nur unter `.anim` und füge als Sicherheitsnetz eine CSS-Animation hinzu, die alle versteckten Elemente nach 2,5 Sekunden einblendet, falls die Bibliothek nie ankommt. In früheren Demos schoben verzögerte Bibliotheken den mobilen LCP auf 3,2 Sekunden; mit diesem Loader maßen die Seiten 99 bis 100. Nenne das Attribut für beim Scrollen eingeblendete Elemente data-reveal; design-check erkennt Bewegung nur unter diesem Namen.
SEO, AEO und GEO:
1. Verwende verzeichnisartige URLs mit abschließendem Schrägstrich (/yontem/, /dernek/, /gizlilik/). Fülle den seo-Block in site.config.js aus und führe `node seo-stamp.mjs` aus. Schreibe das seitenspezifische Schema (Berichtsseite: WebPage mit einem Report als mainEntity, inklusive headline, datePublished, dateModified, image, author (Person, die Redakteurin bzw. der Redakteur) und publisher, dazu FAQPage; Methodik: Article; Organisationsseite: AboutPage mit einem passenden Untertyp der Organisation (zum Beispiel NGO); BreadcrumbList auf Unterseiten. Wenn es kein Büro mit Besuchsverkehr gibt, setze localBusiness:false in site.config.js) in getrennte `<script type="application/ld+json">`-Blöcke und verknüpfe sie per @id mit dem Basisgraphen. Verschachtele BreadcrumbList nicht in @graph, sondern halte sie in einem eigenen Block, denn nur so sieht seo-check sie.
2. Halte Titel bei höchstens 60 Zeichen (seo-check meldet alles über 65 als Fehler), Beschreibungen zwischen 120 und 158 Zeichen, ein h1 pro Seite und keine übersprungenen Überschriftenebenen (ein h3 direkt nach dem h1 senkte Accessibility auf 98). Jede Seite braucht mindestens 150 Wörter Hauptinhalt; Kontakt- und Datenschutzseiten bleiben oft darunter.
3. Der erste Absatz jeder Seite beantwortet die Frage der Seite direkt. Schreibe seitenspezifische FAQs mit `<details>` und zeichne sie als FAQPage aus. Zeige die veröffentlichende Organisation und ein Datum "Zuletzt aktualisiert" in `<time>`.
4. Schreibe in robots.txt deine Entscheidung für GPTBot, OAI-SearchBot, ChatGPT-User, ClaudeBot, Claude-User, Claude-SearchBot, PerplexityBot, Perplexity-User, Google-Extended, Applebot-Extended, Bingbot und CCBot nieder und begründe sie, und verweise auf die Sitemap. Gib sitemap.xml echte lastmod-Daten. llms.txt enthält eine korrekte Zusammenfassung der Seite in zwei Sätzen, die wichtigsten Fakten und eine Liste der wichtigen Seiten.
5. Nichts erfinden: Schreibe keine Bewertungen, Ratings, Auszeichnungen, Kundenzahlen, Zertifikate, Öffnungszeiten, Koordinaten oder Preise, ohne mich zu fragen. Lass jedes Feld, das du nicht kennst, ganz aus dem Schema weg.
Prüfschritte (der Reihe nach; sag erst "fertig", 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 mit view="mobile" und view="desktop" an. site_preview erfasst die Seite mit ausgeschalteter Bewegung (reduced-motion); fehlt in dieser Aufnahme Inhalt, ist der bewegungslose Zustand kaputt. Weiter unten liegende Lazy-Bilder können in der Ganzseitenaufnahme leer sein; zähle das nicht als Fehler, prüfe aber ihre Pfade.
3. Führe core_web_vitals für jede Seite mit strategy="mobile" und strategy="desktop" aus. Abnahme: auf Mobile Performance mindestens 95 und Accessibility, Best Practices und SEO 100; auf Desktop alle vier mindestens 95. Finde bei einer Seite, die das verfehlt, mit resources=true die langsame Datei, behebe sie und miss erneut. Führe danach seo_audit auf der Startseite mit strategy="mobile" und runs=2 aus. In der Liste der Netzwerkanfragen darf keine Adresse außerhalb deiner eigenen Domain übrig bleiben.
4. Kein horizontales Scrollen bei 360, 390, 768 und 1440 px, Touch-Ziele von mindestens 44 px und keine Konsolenfehler. Die Seite muss außerdem in einem 390x790- und einem 1440x898-Rahmen makellos aussehen, wie auf den Prompt-Seiten.
Bewegungsprüfung: site_preview kann keine Bewegung zeigen, also sag mir, worauf ich in meinem eigenen Browser achten soll. Auf dem Desktop sollten die Zähler von null bis zum Endwert hochzählen, sobald sie in den Bildschirm kommen, Diagrammlinien sich beim Scrollen von links nach rechts zeichnen, wobei die Punkte nacheinander erscheinen, und die Kapitelliste links das Kapitel markieren, das ich gerade lese. Auf dem Smartphone sollte die Kapitelleiste oben haften bleiben und das aktive Kapitel ins Bild schieben. Bei aktivierter reduzierter Bewegung und bei ausgeschaltetem JavaScript zeigt jede Kennzahl ihren Endwert, jedes Diagramm ist vollständig gezeichnet, und die Datentabellen lassen sich öffnen.
Nach der Veröffentlichung: Zeige die Regel `/assets/* Cache-Control: public, max-age=31536000, immutable` mit site_headers als Vorschau und wende sie nach meiner Freigabe an; ändere danach bei jeder CSS- oder JS-Änderung den Dateinamen mit einer Versionsnummer (site-v2.css und so weiter). Reiche sitemap.xml mit gsc_submit_sitemap ein und prüfe die Startseite mit gsc_url_inspect. Gib mir zum Schluss: eine Punktetabelle pro Seite (Seite, vier Mobile-Werte, vier Desktop-Werte, LCP, CLS), die Ergebnisse der Prüfschritte, das Ergebnis der im Browser ausprobierten Interaktionen und die Liste der angewendeten Korrekturen.
