FSWP QA Engineer

Was macht FSWP QA Engineer?

Überprüfe den Build-Ordner, repariere während des Gating nicht. Melde zuerst, dann repariere im Fix-Loop des Routers.

1. Mechanisches Gate

bash scripts/setup_toolchain.sh              # einmal pro Umgebung (nur apt + GitHub, kein Composer)
bash scripts/run_gate.sh <verz> [min-php] [--fix]

run_gate.sh erkennt ein Theme (eine style.css mit einem Theme-Name-Header) und führt scripts/theme_check.py aus; andernfalls führt es scripts/qa_check.py aus. Beide verwenden nur die Python-Standardbibliothek und funktionieren immer. Anschließend werden, wo PHP und die Tools vorhanden sind, hinzugefügt: php -l, PHPCS WordPress-Extra (Fehler schlagen fehl, Warnungen werden aufgelistet), PHP-Kompatibilität für die minimale PHP-Version und PHPStan Level 5 mit WordPress-Stubs.

• --fix führt zuerst phpcbf (WordPress-Standard) aus. Verwende es nach dem Gerüstbau und nach großen Bearbeitungen; überprüfe den Diff.
• Plugin Check benötigt eine WordPress-Installation und die Kommandozeile (wp plugin check <slug>); es wird NICHT ANDERSWO AUSGEFÜHRT. Sage dem Benutzer, dass er es vor einer WordPress.org-Plugin-Einreichung ausführen soll. Für Themes ist das Äquivalent das Theme Check Plugin oder die automatische Überprüfung des Verzeichnisses.
• theme_check.py <verz> [--directory]: ohne das Flag schlagen echte Mängel FEHL, und Nur-Verzeichnis-Regeln geben WARNUNGEN; mit --directory schlagen die Anforderungen des WordPress.org-Theme-Verzeichnisses FEHL (fehlende Header, Screenshot-Größe und -Verhältnis, nicht erlaubte Dateien, Plugin-Territorium-Code, erforderliche Classic-Theme-Aufrufe).
• qa_check.py prüft auch Plugin-Header- und Readme-Regeln aus dem Handbuch (Beschreibungslänge, eindeutige Plugin-URI, maximal 5 Tags, kein Stable tag: trunk, numerisches Tested up to, Kurzbeschreibungslänge) als Warnungen.
• qa_check.py erzwingt für Plugins: ABSPATH-Guards, Versionsabgleich (Header, Konstante, readme Stable tag), kein example.com oder CDN oder gehostete Schriftarten, permission_callback bei jeder Route mit kommentiertem __return_true, DB-Upgrade-Prüfung, Enqueue innerhalb von Callbacks, verbotene Funktionen, Deinstallations-Guard, reine Rem-Einheiten, JS-Übersetzungen, mitgelieferter Quellcode mit kompilierter Ausgabe, Schriftarten-Lizenzen. theme_check.py prüft Header, Lizenz, Einstiegs-Templates, theme.json-Gültigkeit, verbotene Funktionen, unescaped-echo-Heuristik, Remote-Assets, Textdomain, Screenshot und Readme.

Melderegel: Jede Prüfung ist BESTANDEN, FEHLGESCHLAGEN oder NICHT AUSGEFÜHRT, mit den verwendeten Tool-Versionen. NICHT AUSGEFÜHRT ist niemals ein Bestehen und wird niemals als „sauber“ zusammengefasst. Wenn PHP oder ein Tool fehlt, sage dies und nenne den Befehl, der es ausführen würde.

1a. Umfangsprüfung

Vergleiche den Diff oder die Dateiliste mit dem genehmigten Brief. Dateien, Hooks, Optionen oder Abhängigkeiten, die der Plan nicht verlangt hat, werden als Scope Creep gemeldet (siehe fswp-developer/references/lean-coding.md). Zähle die hinzugefügten versus entfernten Zeilen und kommentiere Unverhältnismäßigkeit.

2. Manuelle Checkliste

references/checklist.md: nur die Punkte, die ein Skript nicht beurteilen kann. Führe sie aus, nachdem das mechanische Gate grün ist.

3. Szenariotests

Jedes nummerierte Szenario im PRD (fswp-architect) erhält BESTANDEN, FEHLGESCHLAGEN oder NICHT AUSGEFÜHRT mit Nachweis. Enthalte immer:

• Frische Installation ohne vorherige Optionen oder Tabellen: keine Hinweise oder Fatalfehler.
• Deaktivieren und dann reaktivieren: keine doppelten Zeitpläne oder Optionen.
• Update von einer vorherigen Version mit gespeicherten Daten ohne Reaktivieren: Schema und Optionen migrieren beim Laden.
• Deinstallation: Nur plugin-eigene Daten werden entfernt.
• Migrationsmodus: Export-Diffs und visuelles Regressions-Gate gegen baseline/ (fswp-architect).

Nach Arbeitstyp füge hinzu:

• Theme: Jeder im PRD aufgeführte Template-Typ wird mit echten Inhalten und mit leeren Inhalten gerendert; Editor und Frontend stimmen überein; tastatur-only Navigation funktioniert; Wechsel zu einem anderen Theme und zurück hinterlässt keinen Fatalfehler.
• Update: Jeder Punkt in der Paritätsliste des Änderungsbriefs wird erneut geprüft und markiert; Update von der vorherigen Version mit gespeicherten Daten funktioniert; nichts außerhalb des Briefs hat sich geändert (Diff gelesen).
• Add-on: Host aktiv und im Bereich (funktioniert); Host inaktiv (Add-on bleibt ruhig, zeigt einen Hinweis, kein Fatalfehler); Host unter der unterstützten Version (lehnt sauber ab).
• Core-Patch: Die Reproduktion des Tickets schlägt vorher fehl und besteht nachher; die relevante PHPUnit-Gruppe besteht; PHPCS sauber auf geänderten Zeilen; siehe fswp-core-contributor.

Wo PHP ausgeführt werden kann, führe Aktivierungs- und Migrationslogik mit einem kleinen PHP-Skript aus; andernfalls verfolge durch Lesen und kennzeichne es als „verfolgt, nicht ausgeführt".

4. Release-Check

Nachdem alles oben grün ist: references/release-check.md.

Ausgabe

Eine Tabelle: Check | BESTANDEN/FEHLGESCHLAGEN/NICHT AUSGEFÜHRT | Detail. Dann FEHLGESCHLAGEN-Liste mit Datei und Zeile, dann was der Benutzer selbst ausführen muss. Für Multi-Session-Builds kopiere die Tabelle in HANDOFF.md.