adamjali/site-forge

Site Forge

<execution_context> Phase 0 legt den Modus fest:

• auto (schnell): Mache so viel wie möglich selbst. Nach dem einen Plan-/Genehmigungs-Tor (Phase 3) bis zum Ende durchführen, ohne zu fragen. Verwende nur Medien, die du selbst kostenlos erstellen kannst (jina; MCP/Higgsfield, falls vorhanden). Wenn ein Schritt blockiert, Interaktion erfordert oder fehlschlägt – überspringe ihn, mache weiter, liste ihn unter "Übersprungen / später upgraden" am Ende auf. Tendenz zum Ausliefern.
• full (beste Qualität): Interaktiv. Frage, wann immer eine Wahl das Ergebnis sinnvoll verändert, und verwende die besten kostenlosen Medien, auch wenn sie den Benutzer benötigen (Google/Gemini für Bilder, Veo 3.1 Fast in Flow für Video – gib ihnen genaue Prompts, sie generieren, lege die Dateien ab). Ein blockierter Schritt → bitte den Benutzer um Hilfe.

Beide Modi:

• 🟢 Auto: Erkunde die Umgebung, entwerfe, schreibe Code, extrahiere Frames, führe ffmpeg aus, lokale Vorschau und stelle nach Genehmigung bereit.
• 🟡 ZWEI obligatorische Tore in beiden Modi: (1) der Phase-3-Plan vor dem Bauen und (2) die Bereitstellung selbst – frage unmittelbar vor jeder Bereitstellung, jedes Mal. Die Genehmigung für eine Bereitstellung ist niemals die Genehmigung für die nächste. Der Standard ist die lokale Vorschau.
• 🔴 Niemals: Erfinde gefälschte Anmeldeinformationen/Schlüssel; veröffentliche Behauptungen, die der Benutzer als unbestätigt markiert hat, ohne Haftungsausschluss; gib die Geheimnisse des Benutzers in Formulare ein. </execution_context>

0. Wähle das PROFIL vor allem anderen aus. Lese references/design-profiles.md und gib es in einer Zeile an: "Profil: creative-portfolio. Anzeigegrößen-Obergrenze beugen, Serifen-Verbot, Scrim-Boden, Conversion-Möbel. Craft-Floor unverändert." Der Standard ist local-service; creative-portfolio deckt Fotografen, Designer und Künstler ab; personal-agency ist Adams eigenes.Das Profil entscheidet, welche von Adams ästhetischen Regeln in Kraft sind – der Craft-Floor beugt sich nie, also gelten 16px Grundschrift, 4,5:1 Kontrast, 44px Tippziele, reduced-motion, Schema, die sechzehn sozialen Tags und die Sicherheitsheader, egal was die Aufgabenbeschreibung oder eine Referenzseite tut. Dies falsch zu machen, erzeugt eine Handwerker-Seite, die die Fotos eines Portfolios trägt.

1. Lese references/page-composition.md zuerst (es ist der Unterschied zwischen einer Seite, die sich gestaltet anfühlt, und einer, die sich leer anfühlt), dann rufe frontend-design vor jedem Markup auf (installiert → verwende es; sonst lese references/frontend-design.md – das vollständige Skill, gebündelt wörtlich, damit du seine vollständige Anleitung auch offline erhältst).

2. Rufe design-taste-frontend auf. Gib seinen einzeiligen Design-Read an ("Lese dies als: für , mit einer Sprache…") und setze die drei Drehregler. Verwende die eigenen Standardeinstellungen und Voreinstellungen des Taste-Skills. Die eine Ausnahme: seine perpetual-motion-Aktivierung bei MOTION_INTENSITY > 5 bleibt aus – kein Pulsieren, Schimmern, Schweben, Schreibmaschineneffekt oder Endlosschleifen. Überspringe seinen React/Tailwind-Stack-Abschnitt bei statischen Builds.

3. Impeccable läuft bereits: Sein Hook feuert bei jedem Schreibzugriff. Seine Befehle sind das Tor der Phase 7.

Verwende dann references/aesthetics.md als Helfer für das Theme/Type/Layout. Dies ist das Anti-Slop-Tor und der größte Qualitätshebel. Verpflichte dich zu einer klaren, aufgabenspezifischen Richtung:

• Eine klare Ästhetik, präzise ausgeführt; eine unverwechselbare Schriftkombination (niemals Inter/Roboto/Arial); eine kohärente Palette als CSS-Variablen.
• Die Struktur – welche Abschnitte, welche Hierarchie, der eine einprägsame Moment – abgeleitet von der Aufgabenbeschreibung. Verwende nicht die Form der letzten Site wieder.
• Welche Fähigkeiten passen und welche weggelassen werden sollten (siehe die Referenzkarte). Eine einfache Aufgabenbeschreibung verwendet möglicherweise keine der schweren Effekte; ein Flaggschiff kann mehrere verwenden. Schreibe eine 3–5-zeilige Design-Kurzbeschreibung, um sie in den Plan zu übernehmen.

Impeccable's Hook feuert bei jedem Schreibzugriff. Löse seine Funde auf, sobald sie auftauchen, nicht als Haufen am Ende – jeder wird entweder behoben oder explizit als Fehlalarm mit einem angegebenen Grund klassifiziert. Unterdrücke niemals inline eine Regel, um das Beheben zu überspringen; Unterdrückung benötigt Adams Bestätigung. Nach etwa 6 Bearbeitungen wird es leise, um Rauschen zu vermeiden, weshalb das Phase-7-Audit ein separates hartes Tor ist.

Einseitig vs. mehrseitig. Eine einseitige Seite wird als eine einzige index.html ausgeliefert. Eine Aufgabenbeschreibung mit unterschiedlichen Zielgruppen oder echter Tiefe (eine Geschäftsseite mit Abschnitten für Patient / Arzt / Preise / Über uns, eine Marketingseite mit einer Wissenschaftsseite) verdient stattdessen einen mehrseitigen Satz – separate *.html-Seiten, die sich eine gemeinsame Umgebung teilen. Ohne Build-Schritt werden die gemeinsamen Blöcke von Hand kopiert, also ist Drift ein echter Fehler: Halte den <head> (einschl. des Theme-Snippets zur Vermeidung von FOUC), die Navigation, den Footer und die <script>-Tags byte-identisch über jede Seite hinweg und überprüfe dies durch Hashing vor der Bereitstellung – eine Seite, die leise abweicht (andere Schriften, ein fehlender Umschalter, ein toter Link) ist der klassische Fehler. Gib jeder Seite ihre eigene selbstreferenzielle canonical/og:url + <title>/Beschreibung, erzeuge eine sitemap.xml + robots.txt und noindex alle privaten/App-Mockup-Seiten. Wenn die Seitenanzahl oder die Größe der gemeinsamen Blöcke das manuelle Kopieren anfällig macht, ist ein kleiner Include-Schritt (Node Concat, oder Eleventy/Astro) ein fairer Kompromiss – aber nur, wenn die Aufgabenbeschreibung ihn verdient; Standardmäßig ohne Build.

Dann drei mechanische Tore, die alle bereits echte Auslieferungsfehler abgefangen haben:

python3 <skill>/scripts/audit-seo.py        # SEO, lokales SEO, Sicherheit. Exit 1 bei HIGH
python3 <skill>/scripts/check-crops.py      # object-fit:cover, das das Motiv verwirft
python3 <skill>/scripts/colour-system.py    # eine Behandlung pro Foto, seitenweit

Und klicke jedes interaktive Element in einem echten Browser und behaupte eine Zustandsänderung. Ein FAQ, eine Filterleiste und eine Kartentafel wurden alle mit vollständigem Markup, vollständigem CSS und gar keinem Handler ausgeliefert: Nichts sieht im Quellcode kaputt aus. Verwende document.elementFromPoint im Zentrum des Steuerelements selbst, nicht .click(), das den Hit-Test überspringt und bei einem vollständig verborgenen Steuerelement besteht.

Wenn sich etwas ruckelig anfühlt, TRACE es, taste es nicht nur an. performance_start_trace dann scrollen, dann performance_analyze_insight("ForcedReflow") nennt die fehlerhafte Funktion bei Datei und Zeile. Die Bildratenabtastung hat eine Varianz von plus/minus zehn Punkten und wird dich auf die falsche Fährte schicken. Siehe scroll-performance.md.

Design-Stack-Tor – hart, vor der Bereitstellung, keine Ausnahmen:

1. /impeccable critique (UX-Review) dann /impeccable audit (a11y, Leistung, reaktionsschnell).
2. Jeder Fund wird behoben oder als Fehlalarm mit einem angegebenen Grund klassifiziert. Niemals inline unterdrücken. Unterdrückung benötigt Adams Bestätigung.
3. Führe die eigene Preflight-Checkliste des Taste-Skills aus (sein Abschnitt 14).
4. Durchsuche das CSS nach infinite-Animationen und getönten box-shadow und neutralisiere beide. Dies fängt die eine Einstellung des Taste-Skills, die wir bewusst überschreiben.

Standard ist LOKAL. Vorschau mit python3 -m http.server 8080 im Build-Verzeichnis und iteriere dort. Stelle nicht bereit, es sei denn, der Benutzer fragt in diesem Moment danach – eine Live-URL ist nur für einen zahlenden Kunden oder eine geplante Demo gerechtfertigt, und jede Bereitstellung kostet Netlify-Credits (38 Bereitstellungen für eine Seite haben ein monatliches Kontingent erschöpft und ein kostenpflichtiges Upgrade erzwungen). Bündle alle ausstehenden Korrekturen in EINE Bereitstellung pro Überprüfungsrunde.

Die mobile Qualitätssicherung wird auf die erste echte Bereitstellung verschoben – sie kann nicht lokal durchgeführt werden und der Automatisierungsbrowser kann keinen echten mobilen Viewport emulieren. Plane einen dedizierten mobilen Test zum Zeitpunkt der Demo, anstatt so zu tun, als wäre er früher verifiziert worden.

Stelle NIEMALS das Projektstammverzeichnis bereit. .netlifyignore wird von netlify deploy --dir NICHT beachtet, und die Bereitstellung eines Stammverzeichnisses hat einmal die PRIVATE ADRESSE eines Kunden und ein TRACKER-PASSWORT über die gesamte Flotte veröffentlicht. Erstelle ein explizites Veröffentlichungsverzeichnis und überprüfe jede Live-Oberfläche:

python3 scripts/make-dist.py .        # veröffentlicht nur Web-Dateien, behält .py/.md/package.json zurück
netlify deploy --prod --dir dist
scripts/verify-published.sh <host> [owner-street-name]   # muss "clean" ausgeben; Exit-Code != 0 = Leck

Wenn der Benutzer zustimmt, stelle mit scripts/deploy-netlify.sh bereit (references/deploy.md) – Netlify ist das Einzige, was am Ende installiert wird; aktiviere Forms (ignore_html_forms) + den Benachrichtigungs-Hook, wenn es ein Formular gibt. Richte dann standardmäßig Cloudflare Web Analytics ein (der Benutzer möchte es normalerweise): frage nach einem Beacon-Token für den bereitgestellten Hostnamen, füge das Snippet vor </body> ein OHNE SRI (Cloudflare rotiert es – die dokumentierte Ausnahme) und stelle es neu bereit. Präsentiere es in auto als "benötigt den Benutzer"-Punkt mit dem genauen Hostnamen. Details in references/deploy.md. Melde die Live-URL, was verwendet wurde und (in auto) die Liste der Übersprungenen/Später-Upgraden.

Referenzkarte

…

[gekürzt zur Übersetzung]