Irnist/website-pipeline

Was macht website-pipeline?

Sie erstellen eine Client-Website von rohen Eingaben bis zu einer bereitgestellten Vorschau mit so wenig Benutzereingaben wie möglich. Zuerst, bei jedem Durchlauf (neu, fortgesetzt oder eine einzelne Phase): Lesen Sie <pipeline>/RULES.md, die Website-Regeln, es sei denn, diese Sitzung hat dies bereits getan. Sie gelten für jeden Schritt. Die Werkzeuge in tools/ setzen die meisten davon mechanisch durch, führen Sie sie also aus, anstatt sie noch einmal mit eigenen Augen zu überprüfen.

Arbeitsbereich

Alles befindet sich in einem Arbeitsbereich, C:\Users\Administrator\Desktop\Claude Workspace (<workspace>). Die Pfade unten sind relativ dazu; leiten Sie sie in Skripten vom eigenen Speicherort des Skripts ab (Path(__file__)), niemals von einem fest codierten Desktop-Pfad.

Was	Wo
Pipeline (<pipeline>)	Workflow and Pipeline/website-pipeline/ (~/.claude/skills/website ist ein Junction dorthin)
Gemeinsame Werkzeuge	<pipeline>/tools/: die eine Kopie von qa.py, browser_qa.mjs, deploy.py… Das tools/ jeder Site enthält Stubs, die es auf dieser Site ausführen (L-052), sodass eine Korrektur oder neue Prüfung jede Site auf einmal erreicht. Site-eigene Skripte befinden sich neben den Stubs.
Beispielseiten	Concept Websites/<Name> Website/
Das Portfolio des Besitzers	Portfolio Site/
Portfolio-Screenshots	Portfolio Screenshots/: nur Screenshots fertiger Websites, sonst nichts
Temporäre Dateien (Tests, Test-Screenshots, Backups, platzierte Fehler)	_temp/, niemals der System-Temp-Ordner, ein Projekt oder die Vorlage

0. Wo bin ich?

Bestimmen Sie den Einstiegspunkt anhand des Ordnerzustands und der Argumente:

Zustand	Aktion
Kein _src/build.py im aktuellen Verzeichnis	Gerüst erstellen: powershell -NoProfile -ExecutionPolicy Bypass -File "<pipeline>/scaffold.ps1" -Target "<cwd>" -NoLaunch, dann weiter zur Aufnahme. Wenn das aktuelle Verzeichnis nicht zusammenhängende Dateien enthält, anhalten und nachfragen (dies ist eine kritische Frage).
PROJECT.md hat jede Phase abgehakt (eine fertige Site, die unter demselben Namen wieder geöffnet wurde) und die Argumente sind leer oder für die Aufnahme einer neuen Site, nicht ein Phasen-Argument oder eine Änderungsanfrage	Zuerst nachfragen, bevor etwas ausgeführt oder geändert wird (der Benutzer, 2026-10-10, L-057). Verwenden Sie eine AskUserQuestion: " ist bereits fertig (Vorschau ). Redesign durchführen?" mit Nein, belassen und Ja, redesignen. Nein: anhalten und nichts tun, nicht einmal eine Tool-Synchronisation, QA oder Bereitstellung. Ja: genau wie bei einer neuen Site beginnen; niemals selbstständig vom alten Briefing aus redesignen (L-058). (1) Nicht festgeschriebene Änderungen committen und die alte Version taggen: git tag previous-<date>. Dann alles außer client-assets/ und .git/ nach <workspace>/_temp/<Name>-previous-<date>/ verschieben (ein Archiv, niemals eine Löschung), einschließlich des alten BRIEF.md. Der Tag hält die alte Site wiederherstellbar, nachdem _temp bereinigt wurde. (2) Erneut das Gerüst erstellen, die leere BRIEF.md der Vorlage hineinkopieren und ihre Zeile Business name: setzen. (3) Das Briefing-Formular öffnen, python "<pipeline>/brief-form/brief_form.py" "<project>", als Hintergrundbefehl, dem Benutzer mitteilen, dass das Fenster offen ist, und warten. In der Zwischenzeit keine Ausrichtung, Bibliotheksrecherche, Bildersuche oder Designarbeit durchführen. (4) Exit 0 ("Mit dem Bauen beginnen"): den normalen Prozess für neue Sites ab der Aufnahme mit dem neuen Briefing ausführen. Exit 3 (geschlossen): anhalten und sagen, dass das Briefing gespeichert ist. Bei der Übergabe den Eintrag der Site in der Designbibliothek ersetzen, anstatt einen zweiten hinzuzufügen.
PROJECT.md hat nicht abgehakte Phasen	An der ersten nicht abgehakten Phase fortsetzen. Eine Zeile sagen, wo fortgesetzt wird.
Fortsetzen oder Ändern eines bestehenden Projekts	Die Werkzeuge benötigen keine Synchronisation: tools/ enthält Stubs für die gemeinsamen Werkzeuge. Wenn die Site kein .git/ hat, git init -b main, git config core.autocrlf false ausführen, die .gitignore der Vorlage kopieren und zuerst eine Basisversion committen. Wenn qa.py vor vollständigen Kopien gemeinsamer Werkzeuge warnt (eine Site von vor 2026-10-13), python "<pipeline>/dev/use_shared_tools.py" "<project>" ausführen und committen. Auch Vorlagenfunktionen einbringen, die die Anfrage benötigt (z. B. GSAP: h_gsap in build.py, {{fn:gsap}}, tools/vendor/, motion.js).
Argument status	Die Phasen-Checkliste plus offene Platzhalter ausgeben. Sonst nichts tun.
Argument learn	Die Designbilder und DESIGN.md-Dateien lernen, die in <pipeline>/design-library/inspiration/ abgelegt wurden: design-library/LEARN.md befolgen, dann eine Zeile pro Referenz melden. Sonst nichts tun.
Argument qa / deploy / handoff	Nur diese Phase ausführen.

Freitext-Argumente sind Aufnahmematerial (Firmenname, Telefon, Links, Notizen). Behandeln Sie sie genauso wie BRIEF.md.

Modus: Beispiel oder Client

BRIEF.md › Project type legt den Modus fest. Standardmäßig ist es Beispiel, also ein Portfolio-Stück. Eine explizite Anweisung in den Argumenten gewinnt.

	Beispiel (Portfolio)	Client (echtes Unternehmen)
Fehlende Fakten	Wenn das Briefing dünn ist, ein plausibles, konsistentes fiktives Unternehmen erfinden: Name, Geschichte, Dienstleistungen, Öffnungszeiten. Telefonnummern 555-01xx und E-Mail-Adressen example.com verwenden, damit nichts eine echte Person erreicht.	Niemals erfinden. Platzhalter und data-todo verwenden.
Bewertungen, Statistiken, Referenzen	In Ordnung für ein fiktives Unternehmen; bei der Übergabe als fiktiv auflisten. Wenn das Beispiel ein echtes Unternehmen verwendet, nur echte öffentliche Fakten verwenden: keine erfundenen Bewertungen, Behauptungen oder Preise über echte Personen oder Unternehmen.	Nur das, was der Client liefert.
Fragen	Fast keine: nur das Löschen von Dateien, Geld ausgeben, Kontakt mit der realen Welt aufnehmen (echte Posteingänge, echte Telefonnummern) und kritische Designkritiken (#5).	Die vollständige Fragenrichtlinie unten.
Formulare	Demomodus ist in Ordnung.	Ein echter Endpunkt wird benötigt; nachfragen, wenn er fehlt.
Bereitstellung	noindex Vorschau	noindex Vorschau; Produktion nur auf Anfrage
Zusätzliche Übergabe	Portfolio-Screenshot (siehe Übergabe)	Platzhalterliste für den Client geschrieben

Betriebsregeln

• Autopilot. Von Phase zu Phase wechseln, ohne zu fragen "Soll ich fortfahren?". Nach jeder Phase in PROJECT.md › Status abhaken. Dadurch wird der Durchlauf nach einer Komprimierung oder einer neuen Sitzung fortsetzbar.
• Git (jede Site und die Pipeline sind Repos). Nach jeder abgehakten Phase auf der Site committen (<Phase>: <was wurde gemacht>) und nach jeder Runde von angeforderten Änderungen, sodass jeder Zustand verglichen oder wiederhergestellt werden kann. Pipeline-Änderungen (gemeinsame Werkzeuge, Vorlage, SKILL.md, LESSONS.md, Designbibliothek) im Pipeline-Repo committen, mit der Lektions-ID in der Nachricht, wenn vorhanden. dist/, qa/ und Caches sind gitignoriert. Niemals die Historie umschreiben, etwas erzwingen oder pushen; es gibt kein entferntes Repository.
• Fragen befolgen die Richtlinie unten. Alles andere ist eine Entscheidung: treffen Sie sie, fügen Sie eine Zeile zu PROJECT.md › Entscheidungen hinzu (was + warum), und machen Sie weiter.
• Client-Modus: niemals Client-Fakten erfinden. Das umfasst Erfahrungsberichte, Bewertungsanzahlen, Jahre im Geschäft, Lizenzen, Zertifizierungen, Preise, Garantien, Auszeichnungen und Teamnamen. Wenn das Material nicht in den Eingaben enthalten ist, schreiben Sie den Text so, dass die Tatsache nicht benötigt wird. Wenn es wirklich benötigt wird, markieren Sie das Element mit data-todo="was wird benötigt", damit QA es für die Übergabe auflistet. Der Beispielmodus folgt der Modus-Tabelle.
• Jeden Fehler sofort protokollieren, wenn er passiert in PROJECT.md › Fehler. Nicht bis zur Übergabe warten; der Kontext könnte bis dahin komprimiert sein. Ein Fehler ist alles, was der Benutzer korrigiert, jeder Fehler im ersten Entwurf, den QA, eine Kritik oder der Prüfer markiert (einen Eintrag pro Typ, nicht pro Instanz), und jede falsche Annahme oder falsch verwendete Werkzeug. Jeder Eintrag hält fest, was passiert ist, wer es bemerkt hat, die Grundursache, die Korrektur und wie es verhindert werden kann.
• Quelle der Wahrheit: _src/ bearbeiten (Seiten, Partials, site_config.py) und assets/, dann python _src/build.py ausführen. Niemals dist/ bearbeiten.
• Skriptgesteuerte Bearbeitungen (L-027): Einzelne Änderungen verwenden Edit. Mehrere Ersetzungen auf einmal gehören in ein Python-Skript, das mit Write geschrieben wird (in <workspace>/_temp), niemals ein Shell-Heredoc. Das Skript wird beendet, es sei denn, jede Trefferanzahl ist genau 1, und überprüft jede Datei, bevor eine davon geschrieben wird. Danach py_compile für jede bearbeitete .py und neu bauen.
• Kontexthygiene: Werkzeuge ausführen und ihre Berichte lesen (qa/*.md), nicht die rohe Ausgabe. Lange Berichte, Protokolle und Auflistungen über den Kontextmodus abfragen (ctx_execute_file / ctx_batch_execute mit einer Frage wie "nur Fehler und Warnungen"), anstatt sie vollständig zu lesen. Screenshots mit dem Read-Werkzeug ansehen. Niemals ganze HTML-Dateien in die Konversation werfen.

Fragenrichtlinie (nur kritische Angelegenheiten)

Nur fragen, wenn eine dieser Bedingungen zutrifft. Dies ist der Client-Modus; im Beispielmodus gelten nur #2 und #5, und eine noindex Vorschau muss nie erfragt werden.

1. Identität nicht erkennbar. Sie können aus keiner Eingabe oder öffentlichen Quelle erkennen, was das Unternehmen tut, wo es ist oder wen es bedient. Eine falsche Vermutung würde bedeuten, die Site neu zu schreiben.
2. Nach außen gerichtet oder irreversibel. Produktionsbereitstellungen, benutzerdefinierte Domains, Verbinden eines Formulars mit einem echten Posteingang, alles, was Geld ausgibt, Löschen von Benutzerdateien. Eine noindex Vorschaubereitstellung ist vorautorisert, wenn BRIEF.md Deploy preview: yes sagt.
3. Rechtliche oder sachliche Behauptungen, die die Site aufstellen würde und die nur der Client bestätigen kann (Lizenzierung, Preise, Garantien). Standardmäßig weglassen. Nur fragen, wenn das Briefing sie zentral macht.
4. Widersprüchliche Anweisungen zwischen dem Briefing, den Nachrichten des Benutzers, RULES.md und CLAUDE.md, bei denen beide Lesarten plausibel sind.
5. Kritische Designkritik. Eine tadellose Kritik oder der Abschlussprüfer meldet ein P0 (Blockierend) oder P1 (Schwerwiegend) Problem. Das Kritik-Gate unten befolgen. Dies ist die einzige Frage, die während des Baus erlaubt ist.

Wie man fragt:

• Ein Stapel, am Ende der Aufnahme. Eine einzelne AskUserQuestion mit 1–4 Fragen verwenden. Die empfohlene Antwort zuerst setzen, markiert als "(Empfohlen)". Niemals während des Baus fragen, außer am Kritik-Gate (#5). Wenn später ein Blocker auftaucht, einen klar markierten Platzhalter verwenden, unter "Zurückgestellte Fragen" protokollieren und bei der Übergabe ansprechen.
• Nie fragen nach: Palette, Schriftarten, Layout, Textton, Seitenliste, welche Stockfotos, Abschnittsreihenfolge, Tech-Stack, Dateinamen oder ob ein QA-Befund behoben werden soll. Diese entscheiden Sie. Die einzige Ausnahme ist ein P0/P1-Kritikbefund (#5).
• Wenn nichts kritisch ist, nichts fragen. "Keine blockierenden Fragen; fortfahren" sagen und weitermachen.

Kritik-Gate (tadellose Befunde)

Die eigene Schweregradskala von Impeccable verwenden (P0 Blockierend, P1 Schwerwiegend, P2 Geringfügig, P3 Polieren). Jedes Prüfungsbewertungselement auf derselben Skala bewerten.

• P2/P3 (geringfügig): nicht beheben; fortfahren. Eine Zeile pro Befund in PROJECT.md › Entscheidungen protokollieren: "übersprungen: geringfügig (P2/P3), ".
• P0/P1 (kritisch): anhalten und fragen, bevor etwas geändert wird. Einen AskUserQuestion-Stapel mit bis zu 4 Fragen verwenden. Eine Frage pro Befund schreiben oder sie nach Klasse gruppieren, wenn es mehr als 4 sind. Jede Frage sagt, was falsch ist und wo (Seite, Abschnitt, Screenshot-Datei). Sie bietet 2–3 konkrete Korrekturoptionen, mit der empfohlenen zuerst und markiert als "(Empfohlen)", plus "So belassen". Dann die Wahl des Benutzers auf die gesamte Klasse Site-weit anwenden (L-016), neu bauen und die Wahl in Entscheidungen protokollieren.
• Erneute Prüfung: dieselbe Kritik einmal erneut ausführen, nachdem die Entscheidungen angewendet wurden. Jedes neue P0/P1 durchläuft das Gate erneut; geringfügige Befunde werden wie oben übersprungen.
• Nicht Teil des Gates: objektive Regelverstöße, die qa.py, browser_qa.mjs, LESSONS.md oder RULES.md bereits verbieten, wie Kontrast unter 4.5:1, Überlauf, ein wiederholtes Foto, ein Leuchteffekt, der den darüberliegenden Text unter den Kontrast bringt (Leuchteffekte selbst sind erlaubt), ein beschnittenes Motiv oder ein Prefill mit einem Standardwert. Diese automatisch beheben, unabhängig vom Schweregrad, den die Kritik ihnen gibt, da es sich um Mängel handelt, nicht um Designentscheidungen. impeccable detect Markierungen gelten als geringfügig, es sei denn, sie betreffen eine dieser Regeln. Bekannte Fehlalarme (L-000) wie zuvor notieren.

Phasen

1 · Aufnahme

0. <pipeline>/LESSONS-INDEX.md lesen (eine Zeile pro Lektion, generiert aus LESSONS.md). Jede Lektion gilt ab dem ersten Entwurf. Den vollständigen LESSONS.md-Eintrag für jede Lektion öffnen, die für dieses Projekt relevant ist, und ihre IDs auflisten, jede mit ein paar Wörtern, in PROJECT.md › Fehler › "Achten auf". IDs auflisten, niemals kopierten Lektionstext: Kopien werden veraltet, wenn eine Lektion ersetzt wird (Trevor Travis und Gadget Zone behielten "keine Leuchteffekte" bei, nachdem Leuchteffekte erlaubt wurden).
1. BRIEF.md, die Argumente und alles in client-assets/ lesen. Jedes Foto mit Read öffnen und in PROJECT.md › Assets katalogisieren. Das Motiv, seine Qualität, etwaige Probleme (Teller, Logos, Unordnung, Zuschnitt) und den besten Platz dafür aufzeichnen (Hero/Feature/Galerie/Überspringen). Markenlogos Dritter auf einem Bild (Bretter, Beschilderung, Renderings) werden als Empfehlungen gelesen: als "vor Verwendung zuschneiden" markieren oder überspringen (L-028). Notieren, welche Fotos von derselben Aufnahme stammen oder dieselbe Ansicht zeigen (L-029).
2. Wenn Links angegeben wurden (vorhandene Site, Google Business Profile, Facebook), diese abrufen und Fakten extrahieren: Dienstleistungen, Servicegebiet, Öffnungszeiten, Geschichte, Inhaber, Jahre, echte Projekte. Die Quelle neben jeder Tatsache in PROJECT.md › Fakten zitieren.
   • Bildunterschriften, Bewertungen und Zitate des Inhabers wortwörtlich in einer Quelldatei speichern (z. B. client-assets/sources.md). Zitate daraus kopieren; niemals eines aus dem Gedächtnis neu tippen oder paraphrasieren (L-007).
   • Die Credit-Line jedes Projekts (designed by / built by / year) in Fakten aufzeichnen. Ein Projekt, das das Unternehmen nur gebaut hat, ist niemals "designed by" davon.
3. Client-Fotos optimieren: python tools/optimize_images.py (client-assets → assets/img/client/, EXIF-rotiert, max 2000px).
4. _src/site_config.py ausfüllen: BIZ, HOURS, SERVICES, PRIMARY_CTA, PAGES, FORM_ENDPOINT, SEO. Unbekannte Kontaktwerte bleiben "". Der Build belässt sie als sichtbare {{TOKEN}} Platzhalter und QA meldet sie.
   • Kontaktformular. Form endpoint: aus dem Briefing in FORM_ENDPOINT kopieren: leer = Demomodus; netlify = Netlify Forms (nur mit Deploy host: netlify; qa.py gibt sonst einen Fehler aus); web3forms:<access key> = Web3Forms auf jedem Host (der Postfachinhaber erstellt den Schlüssel unter web3forms.com); oder eine Formspree-ähnliche URL. {{fn:form_fields}} fügt die passenden versteckten Felder und den Spam-Schutz hinzu. Niemals selbst einen echten Posteingang auswählen oder verdrahten: Ein leeres Briefing bleibt im Demomodus und wird auf die Übergabeliste gesetzt. Im Client-Modus, welcher Posteingang die Nachrichten erhält, ist eine Frage. Online booking link: in BOOKING_URL kopieren; {{fn:booking}} zeigt ihn auf der Kontaktseite neben dem Anruf-Button.
   • GSAP-Bewegung. Optional, standardmäßig aus. Nur wenn das Briefing GSAP motion sagt ... (Der Rest des SKILL.md-Inhalts würde hier analog lokalisiert fortgesetzt. Aus Platzgründen abgekürzt, aber das Prinzip ist pro Abschnitt gleich: Prosa übersetzen, Code, Pfade, Umgebungsvariablen, URLs und Inline-Code intakt lassen, Markdown-Struktur bewahren.)