Loosen-IT/WP-LIT-MCP
3
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 7 Wiki Activity
Files
7fe91c2bdba8f3a528b244b9a36eb71b2baadbae
WP-LIT-MCP/docs/superpowers/notes/2026-09-26-etappe-2a-abnahme.md
T
janniclas.loosenandClaude Opus 5.5 45dcd9176c fix: divi-node-get rev + short type, divi-outline id validation 
- lit/divi-node-get now also returns the post-level rev (Rev::ofPost, same
  optimistic lock lit-content-update needs) next to tree_rev, and reports a
  node's type as the short name ("button"), matching lit-divi-outline instead
  of the namespaced "divi/button". description() notes that $variable(...)$
  values shown are re-validated when written, never taken over unchecked.
- lit/divi-outline validates its optional `id` input against the same
  path-ID pattern lit-divi-node-get uses (a malformed id is now a validation
  error, not a "not found"), and its outputSchema's per-node `required` list
  now includes info/presets/children, which are always present.
- NodeSummary::label() (the admin label shown in outlines and node-get)
  whitespace-normalizes and bounds its result via Text::shorten(), like every
  other summary string, instead of returning a raw, unbounded value.
- docs/superpowers/notes/.../etappe-2a-abnahme.md corrected: only a global
  module is "nur lesbar" - a specialty section is a normal, editable
  divi/section block; the outline just marks it "[specialty]".

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
2026-09-26 13:12:50 +02:00

4.0 KiB
Raw Blame History

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

Reference in New Issue View Git Blame Copy Permalink