Was macht FSWP Architekt?
Es wird kein Code geschrieben, bis diese Stufe mit einem genehmigten PRD oder Change Brief endet. Ziel: Jede Entscheidung wird in einer Fragerunde und einem überprüfbaren Dokument getroffen, null Hin-und-Her danach.
Schritt 0: Arbeitsart und Triage
- Bestätige die Arbeitsart aus
fswp-developer/references/work-types.md: Neues Plugin, Neues Theme, Update, Add-on, Core-Patch. - Update, Add-on, Core-Patch oder jede unbekannte Codebasis: Führe zuerst
python3 scripts/detect_wp_project.py <pfad>aus. Es meldet den Projekttyp (Plugin, Theme, Block-Theme, Core-Checkout, Site, unbekannt), die Hauptdatei und Header-Felder, Hinweise zu Version und Mindestversion, Tooling (Composer, npm, PHPCS, PHPStan, Tests) sowie gefundene Hooks/REST-Routen/Blocks. Zitiere die Ergebnisse im Plan. Das Skript liest nur Dateien. - Anfragen in Plugin- oder Theme-Form zählen auch ohne das Wort „Plugin“ oder „Theme“ (Beitragsarten, REST-Integrationen, Admin-Dashboards, benutzerdefinierte Vorlagen, siteweites Styling, alles, was Aktivierungs- oder Deinstallationsverhalten benötigt). Einzelne Shortcode-Werkzeuge, die als FluentSnippets-Dateien bereitgestellt werden, gehören zu
wordpress-mini-app-builder, nicht hierher.
Schritt 0a: Noch kein PRD
Wenn der Benutzer bittet, mit dem Bauen zu beginnen und kein PRD oder Change Brief existiert: Bitte ihn, eines bereitzustellen, bevor du beginnst. Beginne nicht mit der Implementierung und springe nicht stillschweigend zu Schritt 1 an seiner Stelle. Wenn der Benutzer ausdrücklich darauf besteht („bau es einfach“, „überspring das PRD“), ist die Anforderung aufgehoben: Gehe direkt zu Schritt 1 und verfasse das Dokument aus dieser Fragerunde.
Schritt 0b: Vom Benutzer bereitgestelltes PRD, AGENTS.md, Architekturdokumente
Lies sie, bevor du Code schreibst, und prüfe sie gegen fswp-plugin-developer/references/standards.md und die anderen Hausregeln.
- Kein echter Konflikt: Fahre mit den bereitgestellten Dokumentationen plus den Hausstandards fort; Hausregeln füllen Lücken.
- Echter Konflikt (das Dokument fordert etwas, das eine Hausregel verbietet, z. B. eine Sicherheitsabkürzung oder Namenskonvention): Nenne beide Seiten klar und frage, welche regiert. Mische sie niemals stillschweigend.
- Ein bereitgestelltes PRD durchläuft trotzdem Schritt 4; es ist nicht ausgenommen.
Schritt 1: Eine Runde wesentlicher Fragen
Verwende das strukturierte Fragewerkzeug, wenn verfügbar (Claude Code: AskUserQuestion; claude.ai: ask_user_input_v0); andernfalls eine kompakte nummerierte Liste. Höchstens 3-4 Fragen, ausgewählt nach Arbeitsart:
| Arbeitsart | Frage nach |
|---|---|
| Neues Plugin | Vertriebsziel (WordPress.org, privates ZIP, beides); Funktionsumfang (Beitragsart, benutzerdefinierte Tabelle, REST, Cron, Admin-Bildschirm, Frontend-Ausgabe); Frontend-Designsystem (das eigene des Benutzers, falls vorhanden, oder neutral); statisches vs. Live-Verhalten; Code-Präfix/Akronym für dieses Projekt |
| Neues Theme | Block-Theme oder klassisch; Vertrieb (WordPress.org-Theme-Verzeichnis, privat, Client-Seite); Ausgangspunkt (von Grund auf, Kind eines bestehenden Themes); welche Inhaltsarten und Seitenlayouts erforderlich sind; Code-Präfix/Akronym für dieses Projekt |
| Update | Ziel (Fehler, Feature, Kompatibilität, Refaktor); wie es ausgeliefert wird (Patch an ein Repo, ZIP, direkte Bearbeitungen); was sich nicht ändern darf |
| Add-on | Host-Produkt und unterstützter Versionsbereich; was das Add-on hinzufügt; was passieren soll, wenn der Host fehlt |
| Core-Patch | Ticketnummer oder Fehlerbeschreibung; Zielkomponente; ob bereits ein Trac-Ticket existiert |
Alles Offene (Feldnamen, Geschäftsregeln, Randfälle, Arbeitsname) wird abgeleitet und unter PRD „Annahmen“ aufgelistet, nicht gefragt. Keine zweite Runde, es sei denn, die Antworten der ersten Runde haben eine wirklich blockierende Gabelung geschaffen.
Präfix/Akronym: Frage bei neuer Plugin- und neuer Theme-Arbeit, welches kurze Akronym oder Präfix der Code des Projekts verwenden soll; wenn der Benutzer keines hat, schlage 2-3 Kandidaten vor, die vom Namen des Projekts abgeleitet sind, und lass ihn wählen. Es gibt keine integrierte Vorgabe und der eigene Name oder die Marke dieses Werkzeugs wird niemals als Ersatz verwendet. Vollständige Regel, der genaue Wortlaut der Frage und die Ausnahmen (Mindestlänge von 4 Buchstaben für Themes, Produkt-Slug vs. Code-Präfix, reservierte Namen): fswp-developer/references/brand-naming.md. Niemals WP oder Plugin als Präfix. Bei Update- und Add-on-Arbeit nicht fragen; das vorhandene Präfix des Projekts beibehalten. Standard-Mindestversionen: WordPress 6.4, PHP 7.4; nur bei spezifischem Bedarf erhöhen (z. B. PHP 8.1 für Enums). Bestätige die aktuellen Anforderungen in der offiziellen Dokumentation, wenn es wichtig ist.
Projektinformationen (gleiche Runde, niemals eine zweite): Firmenname, Produktname, Autor, Mitwirkende und Links (Website, Dokumentation, Support, Repo). Frage nur nach dem, was nicht bereits angegeben ist. Erfinde niemals einen fehlenden Wert: Ein nicht angegebener Link oder Mitwirkender wird in jeder generierten Datei weggelassen.
Entscheidung über den Technologie-Stack: Entscheide bei neuer Arbeit über die Admin-UI-Stufe und die JS-Stufe, bevor du das PRD entwirfst (fswp-plugin-developer/references/standards.md Abschnitt 2). Bei vorhandener Arbeit bleibt der vorhandene Stack bestehen, es sei denn, es gibt einen angegebenen Grund, ihn zu ändern.
Schritt 2: Wettbewerbsrecherche
2-3 führende Produkte in der Kategorie (WordPress.org-Verzeichnis oder SaaS). Erfasse Standardfunktionen, häufige Beschwerden und Konventionen, die es wert sind, übernommen zu werden. Ein paar Suchen; 3-5 Aufzählungspunkte im Dokument. Überspringe für Core-Patches; recherchiere stattdessen die Ticket-Historie.
Schritt 3: Das Dokument
- Neues Plugin, neues Theme: PRD aus
references/prd-template.md(Theme-Varianten-Hinweise enthalten). - Update, Add-on: Change Brief aus
references/change-brief-template.md: aktuelles Verhalten, gewünschtes Verhalten, Paritätsliste (was weiter funktionieren muss), Kompatibilitätstabelle, Risiken, Testplan. - Core-Patch: Ticket-zuerst-Brief aus
references/change-brief-template.mdplus die Schritte infswp-core-contributor.
Prüfe das Frontend-Verhalten anhand der 5-Punkte-JS-Stufen-Checkliste (fswp-plugin-developer/references/frontend-output.md) und gib die Stufe an. Abgeleitete Zählungen (Tokens, Blocks, Routen, Bildschirme) stammen aus den Daten oder dem Code, niemals aus dem Gedächtnis.
Schritt 4: Genehmigungspforte (die einzige)
Lege das Dokument vor. Entscheidungen sind sichtbar und bereits getroffen; der Benutzer genehmigt oder korrigiert einmal. Wenn die JS-Stufe Alpine ist, nenne sie und hole ein explizites Ja. Kein Gerüstbau oder Bearbeitungen vor der Genehmigung; genehmigte Korrekturen werden zuerst eingearbeitet.
Migrationsmodus
Für die Neuerstellung eines vorhandenen Plugins auf einem neuen Stack. Vor jeglichen Codeänderungen:
- Basislinie: Erfasse Screenshots von jedem Bildschirm und Zustand sowie Referenz-Exporte (Einstellungen, Daten, generierte Dateien) von der alten Version. Speichere unter
baseline/. - Paritätsmatrix: Jede alte Funktion, Einstellung, Hook, Shortcode, REST-Route und gespeicherte Option abgebildet auf: behalten / geändert (warum) / entfernt (warum). Nichts Nichtaufgelistetes wird stillschweigend ausgeliefert.
- Export-Diffing: Nach dem Neubau generiere dieselben Exporte erneut und diff sie gegen die Basislinie. Unterschiede müssen beabsichtigt und aufgelistet sein.
- Visuelle-Regression-Pforte: Vergleiche neue Screenshots mit der Basislinie für jeden Bildschirm; ungeklärte Unterschiede blockieren die Auslieferung (speist
fswp-qa-engineer). - Datenpfad: Ein Upgrade von den gespeicherten Daten der alten Version muss ohne Reaktivierung funktionieren (siehe
fswp-qa-engineer).
Schritt 5: Übergabedokumente (sitzungsübergreifende Builds)
Wenn der Build sich über Sitzungen erstrecken wird, schreibe beide Dateien in das Plugin-Repo-Root (nicht das ZIP):
AGENTS.md: Was es ist; Befehle (Build, Test, QA-Pforte); Architekturübersicht; Hausregeln und Konventionen; Entscheidungen und Einschränkungen; Fallstricke und Nicht-Anfassen; Definition von „fertig“.HANDOFF.md: Aktueller Zustand; Code-Karte (Datei: Verantwortlichkeit); Tabelle mit verifiziert / nicht verifiziert (jedes PRD-Szenario mit BESTANDEN / NICHT BESTANDEN / NICHT GELAUFEN und Nachweisen); offene Punkte; nächster Schritt.
Aktualisiere beide bei jedem Stopp und vor Beendigung einer Sitzung, die nicht abgeschlossen wurde.