Generative KI kann Divi-Layouts erzeugen – das ist nicht mehr die Frage. Die Frage ist, ob die erzeugten Werte auch das sind, was Divi 5 wirklich speichert. Wer schon mal ein von einer KI erfundenes Attribut im Visual Builder gesucht hat, kennt das Problem: Das JSON sieht plausibel aus, landet in der Datenbank – und der Visual Builder ignoriert es still oder rendert etwas anderes als beabsichtigt.
Der Diviskit Agent geht dieses Problem an der Wurzel an: Der Preset-Emitter des MCP-Servers schreibt nur Divi-Shapes, deren Evidenz belegt ist. Alles andere wird abgelehnt – nicht mit einer Warnung, sondern mit einem harten Gate.
Das Problem: Plausibles JSON ist kein verifiziertes JSON
Sprachmodelle erzeugen Divi-Attribute nach Mustern aus Doku, Schema und Training. Das funktioniert für häufige Fälle erstaunlich gut – und bricht genau dort, wo Divi 5 Eigenheiten hat: Wrapper-Strukturen (title vs. module vs. content), Preset-Buckets mit Panel-IDs statt Attribut-Pfaden, Font-Patterns mit und ohne separates Weight-Feld, Hover-States ohne value-Wrapper. Eine Shape, die zu 95 % stimmt, ist eine, die im Produktivbetrieb 5 % falsch rendert.
Die ehrliche Antwort darauf ist nicht „besseres Prompting", sondern eine Evidenz-Registry: Für jede Attribut-Familie und jede Modul-Zelle ist dokumentiert, auf welcher Basis ihre Shape bekannt ist.
Die Registry: Evidenz-Level statt Bauchgefühl
verified-attrs.json ist der Evidenz-Speicher des Diviskit-MCP-Servers. Jede Pattern-Family (z. B. divi/font, module.decoration.spacing) und jede Modul-Zelle darunter trägt ein Evidenz-Level:
- UNVERIFIED – geraten oder unbekannt
- SCHEMA_OBSERVED – aus Schema/Doku abgeleitet, nie gegen eine echte Site geprüft
- RUNTIME_VERIFIED – zur Laufzeit akzeptiert
- VB_ROUNDTRIP_VERIFIED – hat einen Visual-Builder-Roundtrip überlebt
- VB_PRESET_STORAGE_VERIFIED – byte-genau so im kanonischen Divi-Preset-Storage belegt
- CROSS_VERSION_STABLE – identisch auf mindestens zwei Divi-Versionen verifiziert
Der Emitter darf ausschließlich Zellen ab VB_PRESET_STORAGE_VERIFIED schreiben. Fehlt eine Zelle oder liegt sie darunter, verweigert das Gate den Write mit einer klaren Fehlermeldung – EvidenceGateError – statt eine ungeprüfte Shape in die Datenbank zu kippen. Zwei Regeln machen das belastbar: Effektive Evidenz ist immer min(Pattern-Level, Zellen-Level), und fehlende Modul-Zellen erben niemals implizit vom Pattern-Level.
Neu: Die Evidence-Pipeline automatisiert die Verifikation
Bisher entstand diese Evidenz aus mühsamen manuellen Dumps: Im Visual Builder ein Preset bauen, den gespeicherten Datensatz exportieren, die Shape dokumentieren. Das war korrekt, aber nicht wiederholbar – und es hing an einem Alt-Projekt. Jetzt ist die Verifikation selbst automatisiert, und zwar über zwei komplementäre Wege:
capture: Der Storage-Roundtrip
diviskit-preset capture nimmt eine Emitter-Shape, schreibt sie über die REST-Route /preset/create auf eine Scratch-Site, liest sie über /preset/inspect zurück und vergleicht emittiertes und gespeichertes Attribut-Set Byte für Byte. Ein Match beweist: Unsere kanonische Shape übersteht den echten Divi-Storage-Pfad verlustfrei. Ein Mismatch wird als Drift-Signal protokolliert – ins Backlog, niemals als stille Absenkung.
adopt: Ground Truth aus dem Visual Builder
Für Zellen, die der Emitter noch nicht abdeckt, kehrt diviskit-preset adopt die Richtung um: Einmal im Visual Builder das Preset bauen, dann per ID adoptieren – die gespeicherte Shape ist per Definition kanonisch und wird als Evidenz übernommen. Damit ist der manuelle Dump-Workflow ersetzt: Kein Export-File, kein Copy-Paste, kein Rätselraten, ob das dump auch wirklich die gespeicherten Bytes sind.
build-registry: Deterministisch statt Handarbeit
Die Registry selbst ist ein generiertes Artefakt. Ein Generator merged den handgepflegten Seed (Bestands-Evidenz) mit den Capture-Dateien – append-only, reviewbar, im Git-Diff sichtbar. Matches auf zwei verschiedenen Divi-Versionen heben eine Zelle automatisch auf CROSS_VERSION_STABLE. Ein --check-Modus regeneriert in-memory und schlägt in CI fehl, wenn jemand an der generierten Datei handeditiert hat.
Was das konkret bedeutet
- Verlässliche Presets. Wenn der Agent ein Button-, Font- oder Spacing-Preset schreibt, ist seine Shape auf einer echten Divi-Site durch Storage-Roundtrip belegt – nicht nur aus dem Schema extrapoliert.
- Drift-Erkennung bei Divi-Updates. Einmal die Capture-Suite gegen die Dev-Site laufen lassen: Jede Shape, die Elegant Themes in einem Update geändert hat, fällt als Diff auf – bevor sie in Kunden-Layouts landet.
- Ehrliche Fehler statt stiller Defekte. Nicht verifizierte Kombinationen werden abgelehnt statt „auf gut Glück" geschrieben. Der Agent sagt, was er nicht weiß.
- Versionierte Sicherheit. Aktuell sind zentrale Zellen (Spacing auf Sections, Heading- und Body-Fonts in beiden Font-Patterns, Button-Hintergrund, -Rahmen und -Font) auf Divi 5.6.x und 5.13.x identisch verifiziert –
CROSS_VERSION_STABLE.
Sicherheit mit eingebaut
Captures laufen nur gegen Sites, die ausdrücklich freigegeben sind: --site muss in der Allowlist-Umgebungsvariablen DIVISKIT_VERIFY_SITES stehen und mit dem WP_URL-Host der Credentials übereinstimmen. Drei Checks, bevor auch nur ein Request rausgeht – ein Versehen gegen Produktion ist damit strukturell ausgeschlossen. Capture-Presets werden nach dem Readback sofort wieder gelöscht.
Der Unterschied zur Konkurrenz
Divi AI und generische KI-Seitenbauer erzeugen plausible Abschnittsstapel – und überlassen die Prüfung dem Nutzer. Der Diviskit-Ansatz dreht das um: Die Prüfung ist Teil der Maschinerie. Jede schreibbare Shape trägt nachvollziehbare Evidenz, jede Divi-Version wird zum Regressionstest, und die Lücke zwischen „sieht richtig aus" und „ist nachweisbar richtig" ist geschlossen.
Die Evidence-Pipeline ist Teil von @diviskit/mcp-server (Open Source, GPL). Wer tiefer einsteigen will: data/registry-seed.json und data/evidence/ im Repository zeigen den kompletten Mechanismus – inklusive der Backlog-Datei, die listet, welche Zellen als Nächstes verifiziert werden.