WordPress-Seite: Vom leeren Ordner zur Produktion

Was macht WordPress-Seite: Vom leeren Ordner zur Produktion?

Dieses Kit ist eine Methode plus ein Starter-Projekt. Es wurde auf einer echten mehrsprachigen Buchungs-Website gelernt, über die echte Kunden bezahlen. Die Phasen werden der Reihe nach durchlaufen. Jede Phase endet mit einem Gate: Verlasse eine Phase nur, wenn ihr Gate wahr ist und die Belege dokumentiert sind.

1. Finde heraus, wo das Projekt steht

1. Suche nach SITE_STATUS.md im Projektverzeichnis.
   • Fehlt: Das Projekt wurde noch nicht gestartet. Verwende wp-kickoff.
   • Vorhanden: Lies sie ein. Die aktuelle Phase ist die erste Phase mit einem nicht abgehakten Gate.
2. Lies AGENTS.md (die Projektregeln), dann die neuesten Zeilen von SESSION_LOG.md und DECISIONS.md.
3. Teile dem Besitzer in zwei Zeilen mit: die aktuelle Phase und den nächsten konkreten Schritt.

2. Die Phasen

#	Phase	Skill	Gate zum Verlassen (Belege kommen in SITE_STATUS.md)
1	Kickoff	wp-kickoff	Brief vom Besitzer genehmigt; getroffene Entscheidungen festgehalten; privates Repo; Zugangsdaten nach Namen aufgelistet
2	Design	wp-design	Statischer Prototyp abgezeichnet (Screenshots + Datum); Tokens gesetzt; Schriften selbst gehostet
3	Build	wp-build	Lokale Site läuft; Core-Plugin + Child-Theme aktiv; echte Inhalte werden durch Core-Funktionen gerendert; Anfragen werden gespeichert, bevor sie weitergeleitet werden; Strukturtests grün
4	Content	wp-content	Jede öffentliche Seite hat vom Besitzer genehmigten Text und echte Fotos; rechtliche Seiten vorhanden; kein nicht genehmigter KI-Text
5	SEO & Sprachen	wp-seo	Tests für Titel, Beschreibung, Canonical, Schema und hreflang grün; Weiterleitungen für alte URLs; jede zusätzliche Sprache hat ihren Piloten bestanden
6	Qualität	wp-quality	Vollständige Suite grün; 0 Barrierefreiheitsverstöße; Leistungsbudgets auf dem Staging erfüllt
7	Auslieferung	wp-ship	Staging spiegelt Live; Härtung angewendet; Launch-Auditor BESTANDEN; Cutover durchgeführt; 7 Tage beobachtet
8	Betrieb	wp-operate	Automatische Backups mit einer externen Kopie; eine Wiederherstellungsübung durchgeführt; Update- und Alert-Routinen geschrieben

• Übergabe der Arbeit einer Phase an einen Builder-Agenten (Antigravity, Codex, ein anderer Claude): wp-task-file.
• Review vor einem Merge: Agent wp-rules-reviewer. Vor dem Go-Live: Agent launch-auditor.

3. Harte Regeln (jede Phase, jeder Agent)

1. Plugin-First. Logik, Daten, Richtlinientexte, Formulare, Schema und SEO leben im Core-Must-Use-Plugin. Das Theme ist Layout. Das Skin ist das Aussehen. Ein Redesign darf kein Feature verlieren.
2. Keine hartcodierten Karten, Preise oder Slugs in Templates. Frage den Inhaltstyp ab und rendere über die Render-Funktion des Core-Plugins, sodass eine CMS-Bearbeitung überall sichtbar ist.
3. Leads werden zuerst gespeichert. Formulare posten an admin-post.php mit einem Nonce. Die Site speichert den Lead in ihrer eigenen Datenbank und leitet ihn dann weiter. Keine API-Schlüssel oder Drittanbieter-Endpunkte auf der Seite.
4. Keine gefälschten Beweise. Zeige niemals Bewertungen, Rezensionszahlen oder Testimonials an, die niemand belegen kann. Importierte oder „Legacy“-Rezensionszahlen gelten als gefälscht, bis sie belegt sind.
5. Echte Fotos für jeden benannten Ort, Raum, jedes Produkt oder jede Person. KI-Bilder nur als allgemeine Szenen, benannt ai-*, protokolliert und niemals als „dies ist Ihr Zimmer“ präsentiert.
6. Fakten stammen vom Besitzer. Preise, Richtlinien, Inklusivleistungen und Sicherheitsfakten werden niemals erfunden. KI-Text ist ein Entwurf, bis der Besitzer ihn genehmigt. Unbekannt = PENDING-<wer>.
7. Kein KI-geschriebenes PHP in Produktion ohne Branch, lokalen Test, Diff und einen menschlichen Merge. WordPress Coding Standards. Alles mit Präfix versehen.
8. Keine Page Builder. Keine Google Fonts-Aufrufe. Schriften selbst hosten: Ein deutsches Gericht hat Schadensersatz angeordnet, weil das Nachladen von Google die IP-Adressen der Besucher preisgab.
9. Staging und lokal werden nie indexiert und senden niemals E-Mails an echte Kunden.
10. Tests werden niemals abgeschwächt, um grün zu werden: Kein Löschen, Überspringen oder Erneutes Erstellen von Snapshots. Das Umbenennen eines Tests benötigt die Zustimmung des Besitzers.
11. Deployments gehören dem Besitzer. Von einem Commit über scripts/deploy-safe.sh: zuerst Trockenlauf, zuerst Backup, das Wort live von einem Menschen eingegeben.
12. Die Datenbank ist Inhalt. Ändere sie nur über eine überprüfbare Änderungsdatei und ein geschütztes Skript mit Trockenlauf. Backup vor jeder DB-Änderung.
13. Geheimnisse gelangen nie in Git, Logs, Prompts oder auf die Seite. CREDENTIALS_INVENTORY.md listet Namen und Orte, an denen jedes Geheimnis lebt, niemals Werte.
14. Ein Schema-Besitzer (normalerweise das SEO-Plugin). Gib niemals ein Offer ohne Preis aus.

4. Frage zuerst den Besitzer

• Installation von Plugins, Themes, Tools oder kostenpflichtigen Diensten (Page Builder: niemals).
• Jegliche Änderung an Preisen, Währungen, Richtlinien, Markennamen oder Logos. Veröffentlichung einer neuen Sprache.
• Alles, was DNS, Cloudflare, Hosting, Staging oder Live betrifft. Destruktive DB- oder Dateibefehle.
• Senden von Code oder Kundeninhalten an eine Drittanbieter-KI-API.

5. Wie zu arbeiten ist

• Eine Phase nach der anderen, ein kleiner Schritt nach dem anderen. Nach jedem sinnvollen Schritt committen (Conventional Commits).
• Branch, lokaler Test, Diff, dann merged der Besitzer. Agenten pushen, mergen, deployen oder verwenden niemals ssh auf einem Server, es sei denn, der Besitzer bittet um genau diese Aktion.
• Jede Entscheidung kommt in DECISIONS.md (Datum, wer, warum). Beende jede Sitzung mit einer Zeile in SESSION_LOG.md.
• „Erledigt“ bedeutet überprüft: Öffne die Seite, führe den Test aus, lese die Antwort des Servers. Wiederhole niemals das „Gelöst“ eines anderen Agenten, ohne es selbst überprüft zu haben.

6. Hilfreiche Skills aus anderen Kits (falls installiert)

• agent-skills-kit: wordpress-modern, wp-plugin-development, wp-wpcli-and-ops, wp-performance für WordPress-API-Details.
• agent-loop-kit: supervised-build, agent-supervisor für unbeaufsichtigte Builder-Schleifen mit einem Gate und einem Reviewer.