janniclas.loosenandClaude Opus 5.5
45dcd9176c
- 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>
66 lines
4.0 KiB
Markdown
66 lines
4.0 KiB
Markdown
# 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.
|