WP-LIT-MCP/docs/superpowers/notes/2026-09-26-etappe-2a-abnahme.md

Etappe 2a – Manuelle Abnahme (Divi lesen)

Vorbereitet von Task 8 (Hinweise/Guides/Serveranweisungen/Ende-zu-Ende-Test). Automatisiert geprüft ist bereits: alle Unit-Tests (composer test, 692 Tests), Lint (composer lint) und alle vier Integrationsskripte (tests/Integration/divi-read-smoke.sh, tests/Integration/mcp-smoke.sh, tests/Integration/wp-basis-smoke.sh, tests/Integration/media-admin-smoke.sh) – Details im Report von Task 8 (.superpowers/sdd/2026-09-26-etappe-2a-divi-lesen/task-8-report.md).

Die folgenden Punkte lassen sich nicht automatisiert prüfen (echter Divi Visual Builder, claude.ai-Connector); das führt Jan-Niclas selbst durch.

1. Builder-Fixtures exportieren (Roundtrip mit echten Seiten)

Alle bisherigen Divi-Fixtures sind entweder handgeschrieben (synthetic-*.html), von Divis eigener Shortcode→Block-Konvertierung erzeugt (converted-*.html) oder reine Modul-Metadaten (metadata-sample.json). Es fehlt noch mindestens eine echte, im Visual Builder gebaute Seite als Gegenprobe für Parser/Serializer.

• 2–3 Seiten im Divi Visual Builder bauen. Zusammen sollten sie enthalten:
  • ein globales Modul (aus der Divi-Bibliothek eingefügt),
  • ein Modul-Preset,
  • eine globale Farbe und eine globale Variable,
  • Dynamic Content (z. B. Beitragstitel, ein Meta-Feld),
  • einen Spezialabschnitt (Specialty Section) und eine verschachtelte Zeile.
  • Keine personenbezogenen Daten verwenden – die Fixtures werden eingecheckt.
• Je Seite exportieren und den Roundtrip prüfen:

  cd /home/janniclas/Projekte/WordPress
  timeout 300 ddev exec wp eval-file wp-content/plugins/WP-LIT-MCP/tests/Integration/divi-export-page.php <post_id> <name>
  cd wp-content/plugins/WP-LIT-MCP && composer test
  

  Erwartet: Success: builder-<name>.html: <N> bytes, <N> blocks, globalModule: ja/nein, tree_rev <hash>., danach composer test weiterhin grün (der Test läuft automatisch über alle builder-*.html-Dateien mit).
• Schlägt der Roundtrip fehl (Parser/Serializer erzeugen nicht mehr das byte-identische Markup): das ist ein Fehler im Plugin (Parser/Serializer), nie ein Grund, die Fixture anzupassen. Als Folgeaufgabe melden statt selbst zu reparieren.
• Fixtures ohne personenbezogene Daten einchecken:

  git add tests/Fixtures/divi/builder-*.html
  git -c user.name="Jan-Niclas Loosen" -c user.email="janniclas@loosen-it.de" commit -m "test: Divi builder fixtures"
  

2. claude.ai: Divi-Lese-Werkzeuge im Gespräch

Mit dem claude.ai-Connector gegen eine Website mit aktivem Divi-5-Theme (z. B. dieses DDEV-Setup oder Staging) verbinden und prüfen, dass die Antworten mit dem tatsächlichen Aufbau im Divi-Builder übereinstimmen:

• „Zeig mir den Aufbau der Startseite“ → sollte lit-divi-outline aufrufen und einen Seitenbaum mit Pfad-IDs, Modultypen und Textauszügen liefern, der zum Divi-Builder passt.
• „Welche Farben und Presets hat die Website?“ → sollte lit-divi-design-system aufrufen und die globalen Farben/Presets nennen, die auch im Divi-Builder (Designsystem-Bereich) zu sehen sind.
• „Was sieht ein Besucher auf der Seite?“ → sollte lit-page-render-summary aufrufen und Überschriften/Texte/Links/Bilder liefern, die dem Frontend entsprechen.
• Bei einer der zuvor im Visual Builder gebauten Seiten (Schritt 1): stichprobenartig prüfen, dass globales Modul, Preset, Dynamic Content und Spezialabschnitt im Outline/Node-Get sinnvoll wiedergegeben werden (globales Modul und Spezialabschnitt ggf. als „nur lesbar“ markiert – das ist in dieser Etappe so vorgesehen, siehe divi-structure-Guide).

Ergebnis

Kurze Rückmeldung an den Ausführenden (Task 8 / Controller): welche Punkte grün sind, welche Builder-Fixtures committet wurden, und was ggf. als Folgeaufgabe (Bugfix im Parser/Serializer oder Doku-Korrektur) aufgenommen werden muss.