Baue auf meinem Opus Growth Hosting-Server
[server name] eine mehrseitige, statische Website im Schweizer Minimalstil für unsere Praxis. Praxis:
[practice name],
[profession, e.g. law firm or accounting practice],
[city]. Tätigkeitsfelder:
[areas]. Berufsträger: [for each, name, title, bar or chamber they are registered with, registration number, areas]. Telefon:
[phone], E-Mail:
[email], Adresse:
[address], Domain:
[domain]. Thema des Hinweisbeitrags: [a frequently asked topic, e.g. the legal cap on rent increases].
In diesem Bereich treffen Menschen Entscheidungen über ihr Geld und ihre Rechte. Vertrauen muss daher aus Klarheit, Qualifikationen und Quellen entstehen, nicht aus Dekoration. Beachte das Berufsrecht: für Rechtsanwälte in der Türkei die Werbeverbotsverordnung der Union der türkischen Anwaltskammern, für Steuerberater die Berufsregeln der TÜRMOB, oder das entsprechende Regelwerk dort, wo wir tätig sind. Schreibe keine Erfolgsquoten, keine Zahl gewonnener Fälle, keine Mandantennamen, keine Superioritätsbehauptungen wie "beste" oder "führender Experte", keine Honorarvergleiche, keine Garantien und keine übertriebenen Versprechen. Stelle Informationen mit dem Hinweis dar, dass sie allgemeiner Natur sind und keine Rechts- oder Finanzberatung ersetzen.
Die Designrichtung ist Schweizer Minimal:
1. Schrift: eine Grotesk-Familie von Fontshare (z. B. Switzer 400, 500, 600). Die Hierarchie entsteht nur durch Größe und Schriftschnitt: eine große, enge, linksbündige Überschrift, ruhiger Fließtext, kleine Abschnittslabels.
2. Farbe: weißer Hintergrund, fast schwarzer Text, ein dunkles Grau und genau eine Akzentfarbe (z. B. Schweizer Rot). Der Akzent erscheint nur am Abschnittszeichen, an Labels und am Fokusring. Fotos sind schwarzweiß (Tailwind grayscale).
3. Raster: strikt 12 Spalten. In jedem Abschnitt steht das Label in den Spalten 1 bis 3 und der Inhalt in 4 bis 12; Abschnitte werden durch eine 1 Pixel breite schwarze Linie getrennt. Keine abgerundeten Ecken, keine Schatten.
4. Signaturelement: Abschnittslabels, nummeriert mit einem § in der Akzentfarbe, und schwache 12-Spalten-Hilfslinien, die nur per CSS hinter dem ersten Bildschirm gezeichnet werden.
5. Bewegung: keine.
Seiten und ihr Schema:
1. index.html: ein erster Bildschirm, dessen Eröffnungsabsatz "worum es geht, für wen, wo" beantwortet, die Tätigkeitsfelder, die Arbeitsweise und die Honorarbemessung (keine Zahlen, nur die amtliche Gebührenordnung und ein schriftlicher Mandatsvertrag), der neueste Hinweisbeitrag, eine Teamübersicht. WebPage.
2. calisma-alanlari.html: ein Abschnitt pro Tätigkeitsfeld; der erste Absatz beantwortet die häufigste Frage in diesem Feld, danach folgen die Hauptthemen und die Rechtsgrundlage. Ein Service pro Feld.
3. ekip.html: ein Profil für jeden Berufsträger (Name, Titel, Kammer, Tätigkeitsfelder, Kurzbiografie). AboutPage und eine Person pro Berufsträger (jobTitle, knowsAbout, worksFor #business, memberOf die Kammer).
4. bilgi-notlari/
[topic].html: ein auf das Gesetz gestützter Beitrag, der mit einer kurzen Antwort beginnt. Oben: Autor, Prüfer, Veröffentlichungsdatum und Datum der letzten Prüfung; am Ende ein Quellenverzeichnis. Article (Autor und Herausgeber über @id, image, datePublished, dateModified, citation) sowie reviewedBy und lastReviewed an der WebPage. Schreibe niemals einen rechtlichen oder finanziellen Punkt, den du nicht kennst; frage mich bei jedem Satz, bei dem du unsicher bist.
5. sss.html: sechs echte Fragen, FAQPage. 6. iletisim.html: ContactPage. 7. kvkk.html (mit Erwähnung der Berufsverschwiegenheit) und 404.html.
Technische Regeln. Befolge sie exakt, denn die folgenden Prüfungen messen genau das:
1. Einrichtung. Führe scaffold_site zunächst als Vorschau aus, zeige mir die Dateiliste und installiere mit confirm=true, nachdem ich zugestimmt habe. Lies danach site_design_guide und site_seo_guide vollständig. Bevor du Code schreibst, halte die Richtung in _kaynak/ART.md fest (Wirkung, Schriftpaarung, Farben mit Kontrastverhältnissen, Raster, Signaturelement, Entscheidung zur Bewegung, Seitenliste) und zeige sie mir.
2. JavaScript entfernen. Keine Seite dieser Website lädt JavaScript. Entferne auf jeder Seite das Skript cdn.tailwindcss.com, die Zeile tailwind.config, die Tags für GSAP, ScrollTrigger, SplitText, Lenis und Swiper sowie die Skript-Tags motion.js, chrome.js und site.config.js; lösche assets/chrome.js und assets/motion.js. Behalte assets/site.config.js, aber nur als Quelle für Marke, Kontakt und SEO für seo-stamp.mjs; sie wird nie im Browser geladen.
3. Menü und Footer sind statisches HTML. Die Komponenten <site-nav> und <site-footer> werden per JavaScript gezeichnet, sodass Such- und KI-Crawler weder das Menü noch die internen Links noch die Kontaktdaten sehen. Schreibe den Header nach _kaynak/ust.inc und den Footer (Name, Adresse, Telefon, E-Mail, alle Seitenlinks, Datenschutzhinweis, "Web: Opus Growth") nach _kaynak/alt.inc. Nutze die Endung .inc, damit seo-stamp und html-validate die Fragmente nicht als Seiten behandeln. Jede Seite enthält die Marker <!-- ust:bas --><!-- ust:son --> und <!-- alt:bas --><!-- alt:son -->. Schreibe dann mit site_write_file ein abhängigkeitsfreies Node-Skript unter _kaynak/parca-bas.mjs: Es stempelt beide Fragmente zwischen die Marker in jeder HTML-Datei, setzt aria-current="page" auf den Menülink der aktuellen Seite und schreibt sitemap.xml neu, wobei das dateModified aus dem JSON-LD jeder Seite als lastmod dient (404- und noindex-Seiten werden übersprungen). Baue das mobile Menü ohne JavaScript mit <details><summary>Menü</summary>; Desktop- und Mobilmenü sind zwei getrennte <nav>-Elemente mit unterschiedlichen aria-labels.
4. Schriften selbst hosten. Diese Website verwendet eine Schriftfamilie und höchstens drei Dateien. Lade das Fontshare-CSS (https://api.fontshare.com/v2/css?f[]=family@400,600&display=swap, Gewichtscode 401 für Kursiv) mit site_fetch nach _kaynak/fontshare.css, lies es mit site_read_file und übernimm nur die woff2-URLs der angeforderten Familie; der Dienst hängt manchmal eine Familie an, die du nicht angefordert hast. Lade jede woff2-Datei mit site_fetch nach assets/fonts/. Lege die @font-face-Regeln (font-display: swap) in assets/app.css ab, da design-check.mjs nur in dieser Datei nach einer eigenen Schrift sucht. Verwende nicht die Standardschriften Inter, Roboto, Poppins oder Montserrat.
5. Tailwind kompilieren. assets/app.css wird zur Tailwind-Quelle: oben @tailwind base; @tailwind components; @tailwind utilities;, dann @font-face, der Fokusring, der Skip-Link, eine prefers-reduced-motion-Regel und eigene Komponentenklassen innerhalb von @layer components. Gib einer Komponentenklasse niemals den Namen einer Tailwind-Utility (list-item, table, grid, container, hidden usw.), denn der Konflikt zerstört nach dem Kompilieren stillschweigend das Layout. Schreibe tailwind.config.js im Stammverzeichnis (content: ["./*.html", "./**/*.html", "./_kaynak/*.inc"], Farben und fontFamily). Führe "npx --yes tailwindcss@3 -i assets/app.css -o assets/site.css --minify" mit site_run_command und background=true aus und warte mit site_command_status darauf. Das <head> jeder Seite enthält in dieser Reihenfolge: genau ein <link rel="stylesheet" href="/assets/site.css">, dann eine Preload-Zeile für jede Schriftdatei, die im ersten Bildschirm verwendet wird (Überschrift, Akzent und Fließtext; as="font" type="font/woff2" crossorigin). Preload-Zeilen vor dem Stylesheet verzögern das CSS und verlängern LCP; eine Schrift im ersten Bildschirm ohne Preload wird spät getauscht, verschiebt die Seite und erhöht CLS. Außerdem <link rel="icon" href="/assets/img/favicon.svg" type="image/svg+xml">. Die Favicon-Zeile ist Pflicht: Ohne sie fragt der Browser /favicon.ico an, erhält einen 404, und der Konsolenfehler senkt Best Practices.
6. Bilder. Lade Fotos mit site_fetch mit resize und image_format="webp" in mehreren Breiten herunter (480, 800, 1200 und 1600 für das Bild im ersten Bildschirm, 480, 800 und 1200 für die übrigen; Qualität zwischen 60 und 75, niedriger bei detailreichen Fotos). Jedes <img> hat srcset, sizes passend zum tatsächlichen Layout, width und height (null CLS) und einen aussagekräftigen, ehrlichen Alternativtext. fetchpriority="high" gehört nur auf das Bild, das Lighthouse als LCP-Element meldet, und dieses Bild wird nicht lazy geladen; jedes andere Bild verwendet loading="lazy". Ist das LCP-Element Text, bekommt kein Bild fetchpriority. Bereite außerdem assets/img/logo.png, ein assets/img/og.jpg mit 1200x630 und assets/img/favicon.svg vor.
7. HTML-Regeln (html-validate-Standards). <!DOCTYPE html> in Großbuchstaben; kein Inline-style-Attribut (auch nicht das style="background:var(--brand)" des Kits, nutze stattdessen eine Klasse); statt normaler Leerzeichen im Text von tel:-Links; ein type an jedem <button>; keine nachgestellten Leerzeichen; Tabellen mit <thead>, <tbody> und th scope. Links in Absätzen sind unterstrichen; Links in Menü, Footer, Breadcrumb und Buttons haben eine Tippfläche von mindestens 44x44 Pixeln (min-h-
[44px] min-w-
[44px]).
8. Strukturierte Daten. Fülle den seo-Block in site.config.js (siteUrl, description, logo, og image, Geschäftstyp, Adressfelder) und führe "node seo-stamp.mjs" mit site_run_command aus; es stempelt Organization, WebSite und, wo passend, einen LocalBusiness-Untertyp sowie Canonical- und OG-Tags. Ergänze seitenspezifisches Schema von Hand: auf jeder Seite einen WebPage-Knoten mit @id (oder AboutPage, ContactPage, CollectionPage, ProfilePage), datePublished und dateModified, isPartOf #site, about #business oder #org und breadcrumb, der auf eine BreadcrumbList verweist; dazu einen Service pro Tätigkeitsfeld, eine Person pro Berufsträger auf der Teamseite, Article und reviewedBy auf dem Hinweisbeitrag und FAQPage auf der FAQ-Seite. Schreibe jeden Knoten in einen EIGENEN <script type="application/ld+json">-Block und verwende keinen @graph-Wrapper, denn seo-check.mjs liest nur den @type der obersten Ebene und übersieht eine BreadcrumbList innerhalb von @graph. Verknüpfe die Knoten über @id. Erfinde niemals Öffnungszeiten, Koordinaten, Bewertungen, Rezensionen, Auszeichnungen, Kundenzahlen oder Zertifikate; lasse unbekannte Felder weg.
9. KI-Zugriff. Schreibe robots.txt: die gesamte Website offen, nur /_kaynak/ gesperrt; Allow: / für GPTBot, OAI-SearchBot, ChatGPT-User, ClaudeBot, Claude-User, Claude-SearchBot, PerplexityBot, Perplexity-User, Google-Extended, Applebot-Extended und Bingbot; deine Entscheidung zu CCBot mit der Begründung als Kommentar; die Sitemap-Zeile zuletzt. Lege im Stammverzeichnis eine llms.txt an: eine korrekte Zusammenfassung des Unternehmens in zwei Sätzen, die wichtigen Seiten mit je einer Zeile und die Kontaktdaten. Schreibe 404.html (noindex, mit den Markern für Header und Footer).
10. Texte. Jede Seite hat innerhalb von <main> mindestens 150 Wörter eigenen Text, und der erste Absatz beantwortet direkt die Hauptfrage der Seite. Titel haben 48 bis 60 Zeichen, Beschreibungen 145 bis 158, auf jeder Seite einzigartig. Keine Gedankenstriche oder Halbgeviertstriche, keine Standardslogans, keine leeren Versprechen. Wenn etwas auf der Website nicht echt ist, sage klar, dass es fiktiv ist.
Prüfungen. Führe sie nach jeder Änderung mit site_run_command in dieser Reihenfolge aus und gehe erst weiter, wenn jede sauber ist:
1. node _kaynak/parca-bas.mjs, node seo-stamp.mjs, der Tailwind-Build (erneut, wenn du Klassen hinzugefügt hast).
2. node seo-check.mjs: 0 Fehler und 0 Warnungen. Wenn es "gövde kısa" (Textkörper zu kurz) warnt, ergänze echten Text, keinen Füllstoff.
3. node design-check.mjs: 0 Fehler. Die einzige Warnung darf "Hiç hareket yok" (keine Bewegung) sein; der Stil verlangt das, nenne also im Bericht den Grund.
4. npx --yes html-validate "**/*.html": 0 Fehler.
5. Sieh dir jede Seite mit site_preview bei view="mobile" und view="desktop" an und prüfe die Startseite zusätzlich bei 360 und 768 Pixeln. Behebe horizontalen Überlauf, gequetsch
