# 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:
  ```bash
  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:
  ```bash
  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. Nur das globale Modul ist dabei „nur lesbar“ (siehe `divi-structure`-Guide);
      ein Spezialabschnitt (specialty section) ist ein normaler, bearbeitbarer `divi/section`-Block –
      Outline zeigt ihn lediglich mit dem Zusatz `[specialty]`, nicht als „nur lesbar“.

## 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.