umairmsm/wp-kickoff

Phase 1: Kickoff

Ziel: eine Seite der Wahrheit über das Geschäft und ein leeres Projekt mit jeder Datei, die die Methode erwartet. Es wird noch nichts entworfen oder gebaut.

Schritte

1. Gibt es bereits eine Live-Website? Wenn ja, behandeln Sie sie als laufendes Geschäft, nicht als geparkte Domain. Erstellen Sie zuerst ein Inventar (references/discovery-brief.md, „Bestehende Website“):
   • jede URL (aus ihren Sitemaps), jedes Formular, jeder Zahlungsschritt, jeder Blogbeitrag und jede Kontaktdetail;
   • ihre Search-Console-Daten, falls der Eigentümer sie teilen kann;
   • was heute Geld verdient. Der Wiederaufbau muss alles funktionsfähig halten. Crawlen Sie höflich: Lesen Sie zuerst die Nutzungsbedingungen (robots.txt ist keine Erlaubnis) und lassen Sie mindestens 2 Sekunden zwischen den Anfragen.
2. Discovery-Brief. Stellen Sie die Fragen in references/discovery-brief.md und schreiben Sie die Antworten in docs/BRIEF.md. Kennzeichnen Sie jede Tatsache mit ihrer Quelle (Eigentümer, Dokument, Crawl). Wenn Sie eine Tatsache nicht wissen, schreiben Sie PENDING-<wer>. Raten Sie nie.
3. Stack. Beginnen Sie mit dem Standard in references/stack.md. Ändern Sie eine Schicht nur aus einem Grund, den Sie benennen können, und dokumentieren Sie ihn in DECISIONS.md.
4. Erstellen Sie das Projekt mit dem Scaffolder des Kits (zwei Ordner über diesem Skill):

   bash <kit>/bin/wp-site-new --name "Acme Touren" --slug acme-touren --prefix acme \
        --domain example.com --dir ~/sites/acme-touren --git
   

   • slug: Kleinbuchstaben und Bindestriche. Er benennt das DDEV-Projekt, die Ordner und die Textdomänen.
   • prefix: 2 bis 12 Kleinbuchstaben oder Ziffern. Jede Funktion, Option, jeder Beitragstyp, Meta-Key, Hook und Nonce beginnt mit <prefix>_.
5. Füllen Sie AGENTS.md:
   • was die Website ist;
   • wer Design und Kundentexte genehmigt;
   • die festgelegten Entscheidungen;
   • harte Regeln, die für dieses Geschäft spezifisch sind, wie regulierte Behauptungen, anzuzeigende Lizenzen oder Wörter, die der Eigentümer niemals haben möchte.
6. Privates Remote-Repository, eingerichtet am ersten Tag. Der Eigentümer erstellt ein privates Repository und pusht. Sobald die lokale Website existiert (Phase 3), führen Sie scripts/backup.sh aus und bewahren Sie eine Kopie auf einem anderen Rechner auf.
7. Inventar der Zugangsdaten (docs/reference/CREDENTIALS_INVENTORY.md):
   • listen Sie jedes Konto auf (Registrar, DNS, Host, SMTP, Analysedienste, Search Console, Zahlungen, CDN);
   • schreiben Sie, wo jedes Geheimnis lebt;
   • nur Namen, niemals Werte.
8. Haken Sie das Kickoff-Gate in SITE_STATUS.md mit Nachweisen ab: Genehmigungsdatum des Briefs, erster Commit-SHA, Name des Remote-Repositorys.

Gate

• docs/BRIEF.md vom Eigentümer genehmigt (Datum)
• Festgelegte Entscheidungen und harte Geschäftsregeln in AGENTS.md
• Projekt erstellt und committet; privates Remote-Repository existiert
• Inventar der Zugangsdaten begonnen (nur Namen)
• Ersetzen einer Live-Website: URL- und Feature-Inventar gespeichert in docs/data/legacy/ (oder „n/a“)

Fallstricke, auf die wir gestoßen sind

• Den „Cutover“ als DNS-Änderung zu behandeln, während die alte Website an diesem Tag kostenpflichtige Buchungen erhielt.
• Die Bewertungszahlen einer alten Website („1.118 Bewertungen“) stellten sich als erfunden heraus. Übernehmen Sie sie nicht.
• Das Proxying der Domain über Cloudflare, während der alte Host nach IP ratenlimitierte. Der Host sah nur die IPs von Cloudflare, sodass echte Besucher 429-Fehler erhielten. Überprüfen Sie die Limits des Ursprungs, bevor Sie den Proxy einschalten.
• Den Notizen eines anderen Agenten zu vertrauen, die „gelöst“ besagten. Der Fix war ungepusht, ungetestet und nie bereitgestellt. Überprüfen Sie das echte System.
• Jemand hat einen API-Key in einen Agenten-Chat eingefügt. Rotieren Sie jeden Schlüssel, den ein Agent gesehen hat.