=== WP-LIT-MCP ===
Contributors: loosenit
Tags: mcp, ai, divi, pods, oauth
Requires at least: 6.9
Tested up to: 7.1
Requires PHP: 8.1
Stable tag: 0.7.0
License: GPL-2.0-or-later
License URI: https://www.gnu.org/licenses/gpl-2.0.html

MCP-Server für WordPress, Divi 5 und Pods – mit OAuth für KI-Assistenten.

== Description ==

WP-LIT-MCP stellt einen MCP-Server bereit, über den ein KI-Assistent (ein MCP-fähiger Client mit OAuth) diese
Website pflegt: Inhalte aller Inhaltstypen inkl. Pods-Feldern, Status, Kopien, Revisionen, Menüs, freigegebene
WordPress-Einstellungen, die Mediathek sowie Divi-Seiten, die Divi-Bibliothek (auch globale Module) und den
Divi Theme Builder. Jede Änderung läuft mit den Rechten des verbundenen WordPress-Benutzers und wird
protokolliert.

Einstellungen: Einstellungen → LIT MCP (Verbindung, Zugriff, Tools, Protokoll, Limits).

== Auswirkungen auf die gesamte Website ==

* Der Standard-MCP-Server von wordpress/mcp-adapter (REST-Route /wp-json/mcp/mcp-adapter-default-server)
  wird abgeschaltet (Filter mcp_adapter_create_default_server). Andere Plugins, die diesen ungeschützten
  Server erwarten, finden ihn nicht mehr.
* Es gibt genau einen MCP-Endpunkt: /wp-json/mcp/mcp-oauth-server (OAuth 2.1 über die eingebundene
  Bibliothek wp-media/mcp-oauth). Anfragen ohne gültiges Token erhalten 401 mit WWW-Authenticate.
* mcp-oauth registriert Rewrite-Regeln für /oauth/… und /.well-known/oauth-… sowie einen
  Website-Zustand-Test. Der Webserver muss /.well-known/ an WordPress durchreichen (bei nginx-Regeln,
  die Punkt-Pfade sperren, eine Ausnahme für /.well-known/ anlegen).
* Jede Verbindung ist ein Anwendungspasswort des Benutzers (Name = Client, z. B. der Name des Assistenten). Es ist im
  Benutzerprofil sichtbar und unter Einstellungen → LIT MCP → Zugriff widerrufbar.
* Die Capability lit_mcp_use wird zur Laufzeit an die freigegebenen Rollen vergeben; Rollen in der
  Datenbank werden nicht verändert. Nicht freigegebene Benutzer können keine Verbindung herstellen: die
  Anmeldung beim Verbinden endet mit „Dein Benutzer hat keinen Zugriff auf LIT MCP.“, es entsteht kein
  Anwendungspasswort. Verlieren bereits verbundene Benutzer die Freigabe, sehen sie weder die Werkzeugliste
  noch Angaben zur Website – nur den Hinweis, dass ihr Konto nicht freigegeben ist.
* Welche Werkzeuge direkt sichtbar, nur über die Meta-Werkzeuge erreichbar oder abgeschaltet sind, lässt
  sich unter Einstellungen → LIT MCP → Tools ändern.
* Eigene Daten: Optionen lit_mcp_allowed_roles, lit_mcp_exposure, lit_mcp_limits, lit_mcp_db_version,
  Tabelle {prefix}lit_mcp_log (nur Verweise, keine Inhalte), täglicher Cron-Job lit_mcp_log_cleanup,
  Transient lit_mcp_endpoint_check, Benutzer-Meta lit_mcp_log_per_page (Ansichtsoption „Einträge pro Seite“
  im Protokoll).
* Divi-Änderungen über LIT MCP speichern den Seiteninhalt für Benutzer ohne die Berechtigung
  unfiltered_html ohne die kses-Filterung von WordPress, weil diese sonst jeden unveränderten Divi-Block neu
  schreiben würde. Alle Werte, die LIT MCP dabei schreibt, werden vorher bereinigt (wp_kses_post,
  sanitize_text_field, esc_url_raw); $variable-Verweise werden geparst, geprüft und vom Plugin neu erzeugt.
  Inhalte des Code-Moduls bleiben nur mit unfiltered_html ungefiltert; eigenes HTML, CSS, HTML-Attribute,
  Interaktionen und die Lottie-Quelle von Modulen schreibt LIT MCP nur für Benutzer mit unfiltered_html.
  Beim Kopieren, Einfügen und Speichern gespeicherter Knoten (Divi-Bibliothek, lit/divi-node-copy) lehnt
  LIT MCP für Benutzer ohne unfiltered_html alles ab, was sie nicht selbst schreiben dürften – strenger als
  Divi, mit sichtbarer Fehlermeldung. Divis eigene Speicherfilter bleiben aktiv.
* Das Feld content von lit-content-create und lit-content-update nimmt kein Divi-Markup an (Divi-Blöcke
  <!-- wp:divi/… und Divi-4-Shortcodes [et_pb_…]); Divi-Inhalte entstehen nur über divi bzw. die
  lit-divi-*-Tools und damit über dieselbe Bereinigung. Anderes Block-Markup bleibt erlaubt und läuft wie
  im WordPress-Editor durch die kses-Filterung von WordPress.
* Byte-genau gilt das nur für die lit-divi-*-Werkzeuge: Werkzeuge, die eine Divi-Seite als Ganzes speichern
  (Titel, Auszug oder Felder über lit-content-update, Veröffentlichen/Planen/Zurückziehen, lit/revision-restore,
  lit/post-duplicate, lit/post-replace-with-copy), laufen für Benutzer ohne unfiltered_html wie in WordPress
  durch die kses-Filterung; die kann das Markup unveränderter Divi-Blöcke umschreiben und dabei – wie im
  WordPress-Editor – Werte entfernen, die der Benutzer nicht speichern darf.
* Unberührte Teile einer Divi-Seite bleiben beim Speichern byte-identisch. Ausnahme: Divi selbst normalisiert
  Seiten mit eigenen HTML-/Attribut-Feldern beim Speichern, sofern sie noch nicht in Divis eigener
  gespeicherter Form vorliegen (z. B. importierter Inhalt); über den Divi-Builder oder LIT MCP gespeicherte
  Seiten betrifft das praktisch nie (die Antwort warnt dann, dass der Inhalt beim
  Speichern verändert wurde).
* Nach jeder Divi-Änderung wird der statische CSS-Cache von Divi für die Seite geleert.
* Divi-Bibliothek: LIT MCP legt Bibliothekseinträge selbst an (Post-Typ et_pb_layout, Status publish, mit
  Divis Begriffen scope, layout_type, module_width und dessen Meta-Feldern) und benutzt keine Builder-Routen.
  Eine Änderung an einem globalen Bibliothekseintrag wirkt sofort auf allen Seiten, die ihn zeigen; LIT MCP
  verlangt dafür einen Probelauf mit Liste der betroffenen Seiten und confirm, legt vorher eine Revision (bei
  abgeschalteten Revisionen eine Sicherungskopie im Papierkorb) an und leert danach Divis CSS-Cache aller Seiten
  und den Theme-Builder-Cache. Die Bestätigung wird abgelehnt, wenn der Benutzer einen veröffentlichten,
  privaten oder geplanten Eintrag, der das Modul zeigt, nicht bearbeiten darf – bei Theme-Builder-Layouts
  auch ohne die Theme-Builder-Rechte; ohne Zugang zum Theme Builder nennt LIT MCP solche Layouts nur als Anzahl.
* Divis Rollen-Editor gilt zusätzlich zu den WordPress-Rechten: ohne „Divi-Bibliothek“, „In der Bibliothek
  speichern“, „Aus der Bibliothek hinzufügen“ bzw. „Globale Bibliothekselemente bearbeiten“ lehnt LIT MCP ab.
* Divi Theme Builder: neue Vorlagen legt LIT MCP deaktiviert an (über Divis eigene Funktionen, mit Layouts für
  Kopfzeile, Inhalt und Fußzeile); sichtbar werden sie nur über lit/tb-activate nach Probelauf und confirm.
  Änderungen an Bedingungen aktiver Vorlagen und an Layouts, die Besucher sehen, verlangen ebenfalls Probelauf
  und confirm (Layouts vorher mit Revision bzw. Sicherungskopie). Deaktivieren geht immer. Der Theme Builder
  verlangt „Beiträge anderer bearbeiten“, „Design bearbeiten“ (edit_theme_options) und das Divi-Recht
  „Theme Builder“; Vorlagen, die der Benutzer nicht bearbeiten darf, nennt LIT MCP nicht (aktive nur als
  Anzahl). Solange der Theme Builder ungespeicherte Änderungen hat, ändert LIT MCP keine Vorlagen (außer
  Deaktivieren). Speichert ein Theme-Builder-Fenster, das vor dem Anlegen geöffnet wurde, entfernt Divi die neue
  Vorlage wieder; lit/tb-list zeigt sie dann unter detached.
* lit/library-make-global legt globale Einträge an und ersetzt inhaltsgleiche Vorkommen auf Seiten und
  Beiträgen erst nach Probelauf und confirm, jede Seite mit eigener Revision; Theme-Builder-Layouts und
  Bibliothekseinträge ändert es nicht.
* Ohne Zugang zur Divi-Bibliothek (Recht „Divi-Bibliothek“ oder Tools-Gruppe deaktiviert) nennt LIT MCP keine
  Bibliotheks-IDs, auch nicht bei globalen Modulen auf Seiten.
* Interne Links über {{link:<ID>}} nutzen Divis eigenen dynamischen Inhalt „<Typ> Link“: die Adresse wird beim
  Anzeigen ermittelt. Für Entwürfe und private Ziele zeigt Divi Besuchern nur ?page_id=<ID> (ohne Titel).
  Dieselben Zielregeln gelten für die Vollform post_link_url_<Typ>; Bibliothekseinträge sind kein Linkziel.
* lit-site-status prüft, ob die von LIT MCP genutzten Divi-Funktionen vorhanden sind, und nennt nach einem
  Divi-Update fehlende unter problems.
* Pods-Felder: Die Feldrechte von Pods gelten auch über LIT MCP. „Verborgen“ und für den Benutzer gesperrte
  Felder (nur Admins, Rollen- oder Capability-Beschränkung) werden weder angezeigt noch geschrieben;
  „schreibgeschützt“ (bzw. gesperrt mit „schreibgeschützt statt verborgen“) sind nur lesbar.
* Uploads über LIT MCP: nur Bilder (jpg, png, gif, webp, avif), PDF, MP4, MP3; Größenlimit einstellbar
  (Standard 5 MB, höchstens 32 MB; Base64-Upload und Download höchstens 10 MB); Import per URL nur von öffentlich erreichbaren Adressen (interne/lokale Adressen werden
  abgelehnt).

* Debug-Log: Sind WP_DEBUG und WP_DEBUG_LOG gleichzeitig an, schreibt die mitgelieferte Bibliothek
  mcp-oauth jede MCP-Anfrage (bis 8 KB, Tokens und Passwörter geschwärzt) samt Tool-Argumenten – also
  z. B. Seiteninhalte, Entwürfe und Base64-Uploads – nach wp-content/debug.log. Auf Live- und
  Staging-Seiten WP_DEBUG_LOG deshalb aus lassen oder das Log vor Webzugriff schützen.

== Filter für Entwickler ==

* lit_mcp_allowed_roles – Liste der freigegebenen Rollen (nach der Einstellung unter Zugriff).
* lit_mcp_upload_mimes – erlaubte Dateitypen für Uploads (Endungen => MIME-Typ); wirksam ist nur, was
  WordPress dem Benutzer ohnehin erlaubt.
* lit_mcp_guides – eigene Anleitungen für lit-guide (Thema => Markdown).
* lit_mcp_excluded_post_types – Inhaltstypen, die LIT MCP nicht anzeigt und nicht bearbeitet.

== Rückgängig machen ==

Es gibt keine allgemeine "Rückgängig"-Funktion; was sich wie zurücksetzen lässt, hängt vom Werkzeug ab:

* Inhalte (Titel, Text, Auszug): über WordPress-Revisionen (Werkzeuge lit/revisions-list,
  lit/revision-restore). Felder und Begriffe sind in Revisionen nicht enthalten.
* Divi-Seiten: jede Divi-Änderung legt vorher eine Revision an (revision_id in der Antwort); zurück über
  lit/revision-restore. Beim seitenübergreifenden Ersetzen erhält jede geänderte Seite eine eigene Revision.
* Bibliothekseinträge: jede Änderung legt vorher eine Revision an (revision_id), bei abgeschalteten Revisionen
  eine Sicherungskopie im Papierkorb (backup_id); zurück über den Revisionsvergleich in WordPress (restore_url
  in der Antwort; lit/revision-restore gilt nur für Inhaltstypen, nicht für Bibliothekseinträge). Neu
  angelegte Einträge (lit/library-save, lit/library-make-global) in der Divi-Bibliothek löschen; durch
  Instanzen ersetzte Knoten über die Revision der jeweiligen Seite zurückholen.
* Theme Builder: Vorlagen haben keine Revisionen. lit/tb-assign nennt die bisherigen Bedingungen (previous) und
  schreibt sie ins Protokoll; lit/tb-activate schaltet zurück. Layouts erhalten wie Divi-Seiten eine Revision,
  wiederherstellbar im Revisionsvergleich von WordPress (restore_url in der Antwort; nicht über
  lit/revision-restore). Neu angelegte Vorlagen und Layouts im Divi Theme Builder löschen.
* Original durch eine Kopie ersetzen (lit/post-replace-with-copy): vorher legt das Werkzeug eine Revision
  und eine vollständige Sicherung des bisherigen Originals im Papierkorb an (backup_id in der Antwort) –
  von dort in WordPress wiederherstellbar.
* Medien löschen (lit/media-delete): ohne aktivierten Medien-Papierkorb (WordPress-Standard, Konstante
  MEDIA_TRASH in wp-config.php) endgültig und nicht rückgängig zu machen; mit aktiviertem Medien-Papierkorb landet das
  Medium dort.
* Menüs (lit/menu-set-items): die Antwort enthält previous_items (Stand vorher), mit dem sich der
  vorherige Baum nachbauen lässt – neu angelegte Einträge bekommen dabei eine neue ID, CSS-Klassen,
  Linkziel und Beschreibung gehen verloren.
* WordPress-Einstellungen (lit/wp-settings-update): die Antwort enthält previous mit den alten Werten.
* Alle genannten Änderungen stehen zusätzlich im Änderungsprotokoll (Einstellungen → LIT MCP →
  Protokoll), das bei Inhalten, Medien und Menüs auf den passenden Bearbeiten-/Revisions-/Mediathek-Link
  verweist.
* Alles andere (z. B. neu angelegte Entwürfe, hochgeladene Medien, neue Menüs) lässt sich nur über die
  üblichen WordPress-Wege rückgängig machen (Papierkorb, manuelles Löschen) – nicht über ein eigenes
  Undo-Werkzeug von LIT MCP.

== Deaktivieren und Löschen ==

* Deaktivieren entfernt den Cron-Job und lässt WordPress die Rewrite-Regeln neu erzeugen; der
  MCP-Endpunkt und die OAuth-Adressen sind danach nicht mehr erreichbar. Einstellungen und Protokoll
  bleiben erhalten. Verbindungen werden dabei nicht widerrufen: Wird das Plugin wieder aktiviert, gelten
  sie weiter (Zugriffstoken eine Stunde, Refresh-Token 30 Tage, solange das Anwendungspasswort besteht).
  Wer den Assistenten sicher trennen will, widerruft die Verbindungen vorher unter Zugriff.
* Löschen entfernt zusätzlich alle eigenen Optionen und die Protokolltabelle (auf Multisite je Website)
  sowie die Ansichtsoption „Einträge pro Seite“ des Protokolls bei allen Benutzern.
* Nicht entfernt werden die Daten von mcp-oauth (Option mcp_jwt_secret, Option
  wpmedia_mcp_oauth_rewrite_version, Benutzer-Meta mcp_refresh_jti_*, Anwendungspasswörter der
  Verbindungen), weil diese Bibliothek auch von anderen Plugins genutzt werden kann. Verbindungen
  deshalb vor dem Löschen unter Einstellungen → LIT MCP → Zugriff widerrufen; nicht mehr benötigte
  Anwendungspasswörter lassen sich im Benutzerprofil entfernen.

== Multisite ==

Das Plugin wird je Website aktiviert und konfiguriert; Rollenfreigaben, Tool-Einstellungen und
Protokoll gelten pro Website. Super-Admins haben (wie jede Capability in WordPress) immer lit_mcp_use,
unabhängig von den freigegebenen Rollen. Der Standard-MCP-Server von mcp-adapter wird ebenfalls website-weit
abgeschaltet.

== Frequently Asked Questions ==

= Kann ich Tools abschalten oder nur lesend freigeben? =

Ja, unter Einstellungen → LIT MCP → Tools einzeln oder je Gruppe; „nur lesen“ schaltet alle schreibenden
Tools einer Gruppe auf einmal ab.

= Bleiben vom Assistenten bearbeitete Divi-Seiten im Visual Builder bearbeitbar? =

Ja. LIT MCP erzeugt native Divi-5-Module mit Admin-Labels und verknüpft Farben, Variablen und Presets mit dem
Designsystem. Nach einer Änderung im Builder liest der Assistent die Seite neu, bevor er weiter ändert.

= Was passiert, wenn der Assistent ein globales Modul ändert? =

Die Änderung wirkt auf allen Seiten mit diesem Modul. LIT MCP speichert erst nach einem Probelauf, der die
betroffenen Seiten nennt, und einer ausdrücklichen Bestätigung (confirm); vorher entsteht eine Revision des
Bibliothekseintrags.

== Divi-Freigabe ==

LIT MCP schreibt nur mit Divi-Versionen, die für diese Plugin-Version geprüft sind. Nach einem Divi-Update lesen die Divi-Werkzeuge weiter; schreibende Divi-Werkzeuge antworten mit „divi_untested“, bis ein Administrator unter Einstellungen → LIT MCP → Divi die Prüfung startet und die Version freigibt. Die Prüfung legt eine Entwurfsseite an, schreibt und rendert sie und löscht sie danach endgültig. Hat Divi Stellen geändert, die LIT MCP nachbildet, ist die Version „inkompatibel“ (divi_incompatible) – dann hilft nur ein Update von LIT MCP. Für Entwickler: `wp --user=<admin> lit-mcp divi-check [--diff] [--update-reference]`.

== Changelog ==

= 0.7.0 =
* Designsystem schreiben (Etappe 4): Presets lesen, anlegen, ändern, löschen, einzelnen Modulen und ganzen Seiten zuweisen und Verweise überall entfernen (Probelauf, Bestätigung, Snapshot, Wiederherstellen).
* Globale Farben und Variablen anlegen und ändern; Variablen werden archiviert, nicht gelöscht; Verweise auf Variablen durch ihren Wert ersetzen.
* Divi-Theme-Optionen (Schriften, Größen, Layout) lesen und ändern; eigene Schriften von einer URL hochladen; Schriftnamen mit Vorschlägen prüfen.
* Schleifen-Inhalte (`loop_*`, `{{loop:…}}`) in Modulen innerhalb einer Divi-Schleife; `lit/divi-dynamic-sources` zeigt sie je Knoten.
* Divi-Freigabe je Fähigkeit statt pauschaler Sperre; neue Guides.
* Sicherheit (Audit der Etappe): Schleifen-Optionen werden gegen die Art jeder Schleife der Vorfahrenkette geprüft; Schleifen über Benutzer oder private Beiträge brauchen list_users bzw. read_private_posts; Wiederherstellen prüft betroffene Seiten; gemeinsame, atomare Sperre für Farben und Theme-Optionen; Schriften-Abruf nur mit cURL und auf die geprüfte Adresse gepinnt (DNS-Rebinding); Bild-Variablen können die :root-Regel nicht mehr verlassen.

= 0.6.1 =
* Divi 5.14.0 geprüft und freigegeben (Referenz von SyncToServerController::update() nachgezogen; die Builder-Kennzeichen werden unverändert gesetzt).
* Admin: Gruppenschalter im Reiter „Tools“ wirken sofort sichtbar; Protokollfilter auch auf Telefonen; „Protokoll leeren“ nur bei Einträgen und mit Anzahl; Hinweis zur Divi-Prüfung; Rückfrage vor dem Aussperren im Reiter „Zugriff“.

= 0.6.0 =
* Divi-Absicherung: Divi-Zugriffe gebündelt in Adaptern mit Manifest; Fingerabdrücke der nachgebildeten Divi-Funktionen.
* Ungetestete oder veränderte Divi-Versionen sperren alle schreibenden Divi-Wege (divi_untested / divi_incompatible); lesende Divi-Werkzeuge melden es in warnings.
* Neuer Reiter „Divi“: Prüfung mit Wegwerfseite, Freigabe nach grüner Prüfung, Freigabe zurückziehen.
* lit-site-status zeigt den Freigabe-Zustand (release).
* WP-CLI: wp lit-mcp divi-check mit --diff und --update-reference.

= 0.5.0 =
* Divi Theme Builder: Vorlagen, Bedingungen und Layouts auflisten (lit/tb-list), Vorlagen mit Kopfzeile,
  Inhalt und Fußzeile anlegen – immer deaktiviert (lit/tb-create-template) –, Bedingungen setzen
  (lit/tb-assign, auch vom Theme Builder entfernte Vorlagen wieder zuordnen), ausdrücklich aktivieren oder
  deaktivieren (lit/tb-activate).
* Die Divi-Werkzeuge bearbeiten Theme-Builder-Layouts; sichtbare Layouts erst nach Probelauf und confirm.
  Felder im Inhalt-Layout ({{field:…}} und im Divi-Builder gewählte Felder) werden gegen den Inhaltstyp der
  Vorlage geprüft (nur Warnungen).
* Ähnliche Abschnitte finden (lit/library-find-similar); Knoten in globale Module umwandeln und
  inhaltsgleiche Vorkommen ersetzen (lit/library-make-global); Divi-Änderungen weisen auf gleich aufgebaute
  Abschnitte der Bibliothek hin.
* Tools-Gruppe „Divi Theme Builder“; lit-site-status prüft die genutzten Theme-Builder-Funktionen.
* Sicherheit: Bibliotheks-IDs bleiben ohne Bibliothekszugang verborgen; interne Links in der Vollform
  (post_link_url_*) folgen denselben Zielregeln wie {{link:ID}}; globale Einträge enthalten keine Verweise auf
  andere Einträge, in keiner Schreibweise.

= 0.4.0 =
* Divi-Bibliothek: Einträge auflisten und lesen (lit/library-list), Knoten als normalen oder globalen Eintrag
  speichern (lit/library-save), als Kopie oder globale Instanz einfügen (lit-library-insert, direkt).
* Globale Module: Bibliothekseinträge mit den Divi-Werkzeugen bearbeiten; bei globalen Einträgen Probelauf
  mit betroffenen Seiten, confirm, Revision bzw. Sicherung und seitenweite Cache-Leerung.
* Knoten zwischen Seiten und Bibliothekseinträgen kopieren (lit/divi-node-copy).
* Interne Links mit {{link:<ID>}}; lit/divi-dynamic-sources listet Divis dynamische Quellen und geeignete Felder.
* lit-guide mit dem Thema „all“; lit-divi-design-system mit Filtern (only, module); lit-divi-node-get und
  lit-divi-outline nennen die Bibliotheks-ID globaler Module; lit-page-render-summary weist auf globale Module
  hin; lit-site-status prüft die genutzten Divi-Funktionen.
* Tools-Gruppe „Divi-Bibliothek“; „nur lesen“ sperrt auch Schreibzugriffe der Divi-Werkzeuge auf die Bibliothek.
* Sicherheit: Interaktionen und die Lottie-Quelle von Modulen nur mit unfiltered_html; gespeicherte Knoten
  werden beim Kopieren, Einfügen und Speichern für Benutzer ohne unfiltered_html geprüft.

= 0.3.0 =
* Divi-Seiten: Seitenbaum mit Pfad-IDs und tree_rev, Knoten in Voll- und Kurzform, Modulkatalog,
  Designsystem (Farben, Variablen, Schriften, Presets), gerenderte Zusammenfassung; Abschnitte, Zeilen und
  Module einfügen, ändern, verschieben, duplizieren und löschen (Kurzform, Vollform, Platzhalter wie
  {{color:primary}}), Text seitenübergreifend ersetzen mit Probelauf, Qualitätswarnungen, neue Seiten
  direkt mit Divi-Inhalt.
* Tools nach Gruppen einstellbar (direkt/indirekt/deaktiviert, „nur lesen“ je Gruppe; gilt auch für
  Divi-Inhalt über lit-content-create); überarbeitete Einstellungsseite, Protokoll als WordPress-Liste mit
  Filtern, Zugriff mit „Zuletzt genutzt“ je Verbindung.
* OAuth-Discovery: /.well-known/oauth-* antwortet direkt statt per Weiterleitung (wichtig bei Permalinks mit
  Schrägstrich am Ende); nicht freigegebene Benutzer können keine Verbindung mehr herstellen.
* Sicherheit: kein Divi-Markup über content, eigene Prüfung privater Adressbereiche beim Import per URL
  (auch bei Weiterleitungen) mit neutraler Fehlermeldung, Pods-Feldrechte, kein direkter Aufruf der
  PHP-Dateien.
* Kurzform: level auch für Kontaktformular, CTA, Toggle, Akkordeon, Slide, Zähler und Teammitglied;
  lit/menu-create liefert menu_rev.

= 0.2.0 =
* WordPress-Basis: Schema-Erkennung inkl. Pods, Inhalte lesen/anlegen/ändern, Status, Kopie und
  Austausch, Revisionen, Menüs, WordPress-Einstellungen, Mediathek (Suche, Vorschau, Metadaten,
  Hochladen, Herunterladen, Löschen mit Verwendungsprüfung), Änderungsprotokoll, Einstellungsseite
  (Verbindung, Zugriff, Tools, Protokoll, Limits), konfigurierbare Tool-Exposition, Aufräumen bei
  Deaktivierung/Deinstallation.

= 0.1.0 =
* Anbindung: OAuth-geschützter MCP-Server, Rollen-Gate, lit-guide, lit-site-status.