docs: Divi guides shortform/placeholders, hints name the write tools; test: Divi write end-to-end; version 0.3.0

- Hints (PostPresenter::DIVI_NOTE, outline, catalog) and server instructions (tree_rev rule)
  name the Divi write tools; guides divi-shortform and divi-placeholders, additions to
  divi-structure, divi-attrs, overview (tool groups, 'nur lesen'), workflows, content-types.
- D7 wording and the S7 exception in readme, guides and spec 1.3/5.2; readme 0.3.0.
- ToolNamingTest: every referenced guide topic exists; overview lists exactly the topics.
- tests/Integration/divi-write-smoke.sh: all write tools via OAuth, editor without
  unfiltered_html with benign probes (S6), Divi's own save filters on the new fixture
  synthetic-divi-filters.html (S7); admin-render.php accepts the new wrap class.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01At3V6SjwbMe6eMzVGW3Hs7

docs/superpowers/notes/2026-09-26-etappe-2b-abnahme.md

@@ -0,0 +1,112 @@
+# Etappe 2b – Manuelle Abnahme (Divi schreiben)
+
+Vorbereitet von Task 10 (Hinweise, Guides, Version 0.3.0, Ende-zu-Ende-Test). Automatisch geprüft sind
+bereits:
+
+- alle Unit-Tests (`composer test`) und Lint (`composer lint`);
+- die fünf Integrationsskripte `divi-write-smoke.sh`, `divi-read-smoke.sh`, `mcp-smoke.sh`,
+  `wp-basis-smoke.sh` und `media-admin-smoke.sh` (alle in `tests/Integration/`).
+
+`divi-write-smoke.sh` prüft über den OAuth-Endpunkt:
+
+- Einfügen, Ändern, Verschieben, Löschen und Duplizieren;
+- Ersetzen mit Probelauf;
+- `lit-content-create` mit Divi-Inhalt;
+- den ersten Abschnitt auf einer leeren Seite;
+- einen Redakteur ohne `unfiltered_html`: unberührte Bytes bleiben gleich, und es wird weder Skript,
+  Event-Handler, `javascript:` noch ein eingeschleustes Attribut gespeichert oder gerendert;
+- Divis eigene Speicherfilter (Seite mit eigenen HTML-Attributen).
+
+Details stehen im Report von Task 10 (`.superpowers/sdd/2026-09-26-etappe-2b-divi-schreiben/task-10-report.md`).
+
+Die folgenden Punkte lassen sich nicht automatisch prüfen, weil sie den echten Divi Visual Builder und den
+claude.ai-Connector brauchen. Jan-Niclas prüft sie selbst (Spec §1.3 Nr. 2, §13 „Bearbeitbarkeit im
+Visual Builder“). Abweichungen als kurze Notiz zurückmelden; sie werden Folgeaufgaben (z. B. anders
+gespeicherte Spaltenbreiten, D8).
+
+## 1. Visual Builder: von Claude gebaute Seite
+
+- [ ] Dieser Auftrag in claude.ai:
+      „Lege eine Entwurfsseite ‚Abnahme Divi‘ an mit Hero (Überschrift, Text, Button mit Preset), einer
+      Zeile 1/3 + 2/3 mit Bild und Blurb, einem Akkordeon und einem Kontaktformular.“
+      Erwartet:
+      - Claude liest vorher `lit-divi-design-system` und `lit-divi-catalog`;
+      - dann `lit-content-create` mit `divi` (oder eine leere Seite plus `lit-divi-insert`);
+      - die Antwort nennt `preview_url` und `edit_url`.
+- [ ] Die Seite im Divi Visual Builder öffnen (`edit_url`) und prüfen:
+  - [ ] Alle Module erscheinen als **native Module**, nicht als Code-Modul.
+  - [ ] Die Admin-Labels folgen dem Muster „<Abschnitt> – <Modul>“, z. B. „Hero – Button“.
+  - [ ] Jedes Modul lässt sich anklicken, ändern und speichern, ohne Fehlermeldung des Builders.
+  - [ ] Die Spaltenbreiten stimmen (1/3 + 2/3), auch in der Spalteneinstellung des Builders.
+  - [ ] Farben aus `{{color:…}}` sind als **globale Farbe** verknüpft: der Farbwähler zeigt die globale
+        Farbe, nicht einen festen Hex-Wert.
+  - [ ] Das Button-Preset ist im Builder als Preset ausgewählt.
+  - [ ] Akkordeon-Einträge und Kontaktformular-Felder sind einzeln bearbeitbar.
+- [ ] Eine zweite Seite nur mit `lit-divi-insert` aufbauen lassen: leere Seite anlegen, dann
+      „Füge einen Abschnitt ‚Start‘ mit Überschrift und Text ein“. Im Builder öffnen: der Abschnitt
+      erscheint normal und ist bearbeitbar (Ruling S9: Hülle `divi/placeholder` wie beim Builder).
+
+## 2. Visual Builder: von Claude geänderte Seite
+
+- [ ] Eine bestehende, im Builder gebaute Seite kopieren (`lit/post-duplicate`) und an der Kopie per
+      claude.ai einen Button-Text ändern, ein Modul verschieben und einen Abschnitt duplizieren lassen.
+- [ ] Die Kopie im Builder öffnen und prüfen:
+  - [ ] Alle unveränderten Module sehen aus wie vorher (Einstellungen, Presets, globale Farben).
+  - [ ] Die geänderten Module sind bearbeitbar, und die Änderung ist sichtbar.
+  - [ ] Die Kopie eines Abschnitts heißt „<Label> (Kopie)“.
+
+## 3. Zurück zu Claude nach einer Builder-Änderung
+
+- [ ] Die Seite aus Schritt 1 im Builder ändern und speichern.
+- [ ] Danach per claude.ai eine weitere Änderung verlangen. Erwartet:
+  - [ ] `rev_mismatch` erscheint nur, wenn Claude eine alte `tree_rev` benutzt.
+  - [ ] Nach erneutem Lesen (`lit-divi-outline`) gelingt die Änderung.
+  - [ ] Die im Builder gemachten Einstellungen bleiben erhalten.
+
+## 4. Rückgängig
+
+- [ ] Einen Abschnitt löschen lassen. Claude fragt nach (`confirm_required`) und löscht erst nach der
+      Bestätigung.
+- [ ] Den Abschnitt über `lit/revision-restore` mit der gemeldeten `revision_id` zurückholen und im Builder
+      prüfen, dass er wieder vollständig da ist.
+
+## 5. Text auf mehreren Seiten ersetzen
+
+- [ ] „Ersetze auf allen Seiten ‚Termin‘ durch ‚Beratungstermin‘“. Erwartet:
+  - [ ] Claude zeigt erst den Probelauf (Treffer je Seite) und fragt nach.
+  - [ ] Erst danach ersetzt es.
+  - [ ] Im Protokoll-Tab (Einstellungen → LIT MCP → Protokoll) steht je geänderter Seite ein Eintrag mit
+        eigener Revision.
+  - [ ] Liegt ein Treffer in einem **globalen Modul**, ändert Claude ihn nicht, sondern nennt ihn
+        (`skipped_nodes`, „in der Divi-Bibliothek bearbeiten“).
+
+## 6. Redakteur ohne `unfiltered_html`
+
+- [ ] Mit einem Redakteurs-Konto verbinden; unter Einstellungen → LIT MCP → Zugriff muss die Rolle
+      freigegeben sein.
+- [ ] Auf einer Seite eines Administrators einen Text ändern lassen.
+- [ ] Die Seite im Builder öffnen. Erwartet:
+  - [ ] Eingebettete Inhalte des Administrators (z. B. iframe, eigenes HTML im Code-Modul) sind
+        unverändert.
+  - [ ] Die Änderung des Redakteurs ist da.
+- [ ] Den Redakteur eigenes HTML/CSS/Attribute eines Moduls setzen lassen, z. B. „füge dem Button das
+      HTML-Attribut data-x hinzu“. Erwartet: Ablehnung mit „nur im Divi-Builder änderbar“.
+
+## 7. Tool-Gruppen und „nur lesen“
+
+- [ ] Unter Einstellungen → LIT MCP → Tools die Gruppe Divi auf „nur lesen“ stellen.
+- [ ] Neu verbinden. Die Divi-Schreibwerkzeuge (`lit-divi-insert` usw.) fehlen; die Lesewerkzeuge sind
+      noch da.
+- [ ] Die Einstellung zurücksetzen.
+
+## 8. Builder-Fixtures aus 2a (falls noch offen; Ruling S20)
+
+- [ ] Seiten mit **globalem Modul**, Preset, Variablen und Dynamic Content exportieren:
+      `tests/Integration/divi-export-page.php` (Anleitung in `2026-09-26-etappe-2a-abnahme.md` §1).
+      `composer test` bleibt grün.
+- [ ] Auf einer Kopie einer solchen Seite `lit-divi-update` an einem normalen Modul ausführen. Das
+      globale Modul bleibt byte-identisch: Export vorher und nachher vergleichen.
+- [ ] Hat die Seite Module mit eigenen HTML-Attributen oder einem eigenen HTML-Element (Erweitert →
+      Attribute/HTML), meldet die Antwort evtl. „Inhalt beim Speichern verändert“. Das ist dokumentiert
+      (Ruling S7: Divi normalisiert solche Seiten selbst). Prüfen, dass die Seite im Builder danach
+      einwandfrei ist.

docs/superpowers/specs/2026-09-25-wp-lit-mcp-design.md

@@ -18,7 +18,7 @@ Ein WordPress-Plugin, das auf jeder Kundenseite einen MCP-Server bereitstellt, m
 
 1. Ein claude.ai-Connector verbindet sich per OAuth mit einer Kundenseite; nur freigegebene Rollen können Tools nutzen.
 2. Von Claude erzeugte oder geänderte Divi-Inhalte sind im Visual Builder vollständig bearbeitbar (manuell verifiziert pro Etappe).
-3. Unangetastete Inhalte bleiben byte-identisch erhalten.
+3. Unangetastete Inhalte bleiben byte-identisch erhalten. Dokumentierte Ausnahme (Ruling S7): Divi selbst normalisiert Seiten mit eigenen HTML-/Attribut-Feldern beim Speichern (`AttributeSecurity`/`HtmlSecurity` auf `wp_insert_post_data`, laufen für jeden Benutzer und werden nie entfernt); die Antwort meldet das als Warnung „Inhalt beim Speichern verändert“ (`CHANGED_ON_SAVE`), die Seite bleibt gültig (E2E `divi-write-smoke.sh` Abschnitt 8).
 4. Eine neue Website (Seitenstruktur, Menü, Einstellungen, Designsystem aus einem CD) lässt sich im Dialog aufsetzen.
 5. Jede Änderung ist nachvollziehbar (Protokoll) und umkehrbar (Revision bzw. Snapshot).
 
@@ -171,7 +171,7 @@ Seiten, Theme-Builder-Layouts (`et_header_layout`, `et_body_layout`, `et_footer_
 
 - Parst `post_content` in einen Baum (auf Basis von `parse_blocks`, mit Sonderbehandlung für `divi/global-layout` und `globalModule`, die `parse_blocks` laut Divi-Code nicht korrekt verarbeitet).
 - Serialisiert den Baum zurück; unveränderte Knoten werden aus ihrem Original-Markup übernommen.
-- **Invariante:** Parse → Serialize ohne Änderung ergibt byte-identischen Inhalt. Fremde/unbekannte Blöcke bleiben unberührt.
+- **Invariante:** Parse → Serialize ohne Änderung ergibt byte-identischen Inhalt. Fremde/unbekannte Blöcke bleiben unberührt. Ausnahme beim Speichern (nicht im BlockTree): Divi selbst normalisiert Seiten mit eigenen HTML-/Attribut-Feldern beim Speichern (`module.decoration.attributes`, `module.advanced.html` mit `htmlBefore`/`htmlAfter`/`elementType`) – Divi parst und serialisiert dann die ganze Seite neu; gemeldet als `CHANGED_ON_SAVE` (Ruling S7).
 - Reines PHP ohne WordPress-Abhängigkeit (vollständig unit-testbar).
 - Attributwerte mit `$variable(...)$` werden beim Serialisieren wie von Divi erwartet escaped (`"` → `"`).
 - Umsetzung (D3): eigener Tokenizer mit dem Delimiter-Muster von `WP_Block_Parser` statt `parse_blocks()` – ohne WordPress testbar, jedes Byte zwischen den Delimitern bleibt erhalten. Knoten mit `globalModule`, `divi/global-layout` oder nicht dekodierbaren Attributen sind undurchsichtig: sie werden nicht betreten, nur als Ganzes verschoben, dupliziert oder gelöscht (Bearbeitung ab Etappe 3). Unbalanciertes Markup wird abgelehnt, nie repariert.