Abilities-Referenz: Eingaben, Ausgaben und Grenzen

Du brauchst diese Seite erst, wenn du eine bestimmte Zusatzfunktion suchst oder genau wissen möchtest, was dein Assistent darf. Für deinen ersten Artikel oder eine Landingpage folgst du einfach dem Schnellstart. Dort erklärt WPAgently jeden nötigen Schritt ohne diese technische Referenz.

Quellvertragsstand dieser Referenz: Companion 0.4.121, Power 0.6.38 sowie CLI und Skills 0.4.91. Diese Seite beschreibt die Schemas und Grenzen dieses Quellstands. Den öffentlichen Verfügbarkeitsstand dokumentiert der öffentliche Changelog. Für tatsächlich verfügbare Schemas ist die installierte Version maßgeblich.

Eine *Ability* ist eine klar begrenzte Aktion, die dein Assistent auf deiner WordPress-Seite ausführen darf. Zum Beispiel einen neuen Entwurf anlegen, einen bestehenden Beitrag lesen oder prüfen, ob eine Seite korrekt dargestellt wird. Eine Ability darf nur das tun, was hier beschrieben ist.

Mit Free stehen dir 34 grundlegende Abilities zur Verfügung. Paid schaltet die vollständige Companion-Funktionssammlung frei. Welche davon du in deinem Assistenten siehst, hängt zusätzlich von deiner Lizenz, dem gewählten Funktionsprofil und kompatiblen Plugins auf deiner WordPress-Seite ab. Weniger sichtbare Funktionen sind deshalb nicht automatisch ein Fehler.

Diese Referenz beschreibt Companion, den normalen und empfohlenen Teil von WPAgently. Power ist ein separates Plugin für Entwicklungs- und Staging-Aufgaben. Als normaler WordPress-Nutzer lässt du Power ausgeschaltet. Falls du es bewusst für eine Testumgebung brauchst, lies zuerst den Power-Modus.

Format pro Ability

Jeder Eintrag nennt den vollständigen technischen Namen (wp-agent/...), erklärt den Zweck und zeigt die nötigen Angaben sowie das Ergebnis. Er nennt außerdem die WordPress-Berechtigung, die dafür geprüft wird. „Lesend“ bedeutet: Die Funktion schaut nur nach. „Schreibend“ bedeutet: Sie kann etwas ändern. Ein Beispiel hilft dir beim Einordnen.

„Re-Read-verifiziert“ bedeutet: Nach einer Änderung liest WPAgently das Ergebnis noch einmal aus WordPress. Erst dann meldet es, ob die Änderung wirklich angekommen ist.

Dynamische JSON-Dokumente

Wo eine öffentliche Ability anbieterdefinierte oder sonst dynamische JSON-Daten ausgibt, veröffentlicht sie kein offenes MCP-Objekt. Native Blockattribute und Supports verwenden den geschlossenen, versionierten Umschlag {format,json,sha256,bytes}. format lautet wpagently.native-block-json.v1; bytes und sha256 binden das UTF-8-JSON. Die Attributschreiber für Spectra, GenerateBlocks und Kadence erwarten denselben Umschlag und geben ihn unter written_attributes zurück.

Elementor und Beaver Builder verwenden für dynamische Elemente, Einstellungen und Patches ihren eigenen geschlossenen Builder-Dokumentumschlag {json,sha256,bytes}. Er besitzt bewusst kein Feld format. Der Server dekodiert den Wert und validiert ihn vor einer Antwort oder Mutation erneut gegen die dokumentierte Providergrenze. Überschreitet ein dynamischer Wert die jeweilige Größen-, Tiefen- oder Eintragsgrenze oder lässt er sich nicht in den öffentlichen Vertrag normalisieren, endet der betreffende Pfad fehlersicher statt Daten abzuschneiden. Statische Felder behalten ihre eigenen Schemata. Der Umschlag erweitert weder die Schreib-Allowlist noch öffnet er andere Providerdaten.

Der Quellvertragsstand 0.4.121 kapselt außerdem nur die ausdrücklich freigegebenen dynamischen Providerwerte in {format,json,sha256,bytes}. format lautet dabei entweder wpagently-json-object-v1 oder wpagently-json-array-v1. Das betrifft die SEO- und Beitragsschema-Pfade, den Post-, Produkt- und Variations-Read-back, Fluent-Forms-Felder und -Einträge, die Eingaben für Gravity Forms, Formidable Forms, Formularmigrationen sowie die dynamischen Abschnitte von get-site-context. Es gilt jeweils nur für den dort genannten dynamischen Wert, nicht für die übrigen Felder der Ability. Ein einzelnes Dokument ist höchstens 2 MiB groß. Die gesamte öffentliche Ein- oder Ausgabe bleibt auf 8 MiB, 32 Ebenen und 16.384 Werte begrenzt. Neue offene Formen werden bereits bei der Registrierung abgelehnt. Dynamische Maps bleiben nur mit einem festgelegten Wert-Schema zulässig und haben dann höchstens 256 Eigenschaften. Ihre Schlüssel sind 1-191 Byte lang und enthalten keine ASCII-Steuerzeichen.

Der bestätigte Live-Editor verwendet einen weiteren, getrennten Umschlag {format,json,sha256,bytes} mit format=wpagently.live-editor-json.v1. Bei Gutenberg sind attributes und blocks, bei Elementor element, elements, settings, settings_patch und style_patch so zu übergeben. Die Ergebnisse von Live-Editor-Befehlen erscheinen unter result in derselben Form. Ein Request und jeder darin enthaltene Umschlag sind auf 100.000 Byte begrenzt. Die Umschläge ersetzen keine Sichtprüfung, Bestätigung oder Provider-Prüfung.

1. Content-Lebenszyklus (Beiträge und Seiten)

wp-agent/create-post-from-markdown

Zweck: Einziger Remote-Schreibpfad für neue Inhalte des Plugins. Konvertiert Markdown serverseitig in valide Gutenberg-Blocks und legt einen neuen Beitrag an. Der optionale post_id-Pfad kennzeichnet nur einen Update-Versuch und endet derzeit mit HTTP 409 und manual_only, ohne Mutation. Verhindert den stillen core/freeform-Fallback (Classic-Editor-Rückfall) und meldet einen Block-Report. Siehe auch wp-agent/update-post: Auch dieser bestehende-Beiträge-Pfad ist aktuell nur manuell.

Capability: edit_posts (grobe Schranke) plus feingranulare Post-Type-Prüfung für neue Beiträge: create-Capability (wpagent_post_type_create_cap) und die passende edit-Capability des Ziel-Post-Types (z. B. edit_pages bei post_type=page). Ein post_id wird vor einem Remote-Update mit manual_only abgelehnt.

Merkmale: create ist schreibend und nicht destruktiv. update ist manual_only. Die flachen Annotationen lauten remote_create=true und manual_only_update=true; idempotent ist false.

Für die CLI-Pipelines wp-agent article und wp-agent landing gilt eine zusätzliche Vorabprüfung: Ein expliziter Slug muss bereits der nativen gespeicherten Form entsprechen. Die CLI verwirft rohe Unicode-Zeichen, Großbuchstaben, wiederholte oder abschließende Bindestriche sowie 59 Prozent-kodierte Sequenzen, die WordPress Core beim Speichern normalisiert, darunter kodierte Leerzeichen und Interpunktion. Stabil gespeicherte Prozent-kodierte UTF-8-Sequenzen wie %e4%bd%a0%e5%a5%bd und wiederholte Unterstriche bleiben zulässig. Ohne Slug erzeugt WordPress ihn aus dem Titel.

Beispiel:

{ "title": "Neuer Blogpost", "markdown": "# Überschrift\n\nText.", "status": "draft", "category": "SEO" }

Ein erfolgreicher Aufruf legt remote einen neuen Beitrag an. Wird zusätzlich post_id übergeben, antwortet die Ability stattdessen mit HTTP 409 und manual_only; es wird kein bestehender Beitrag geändert.

wp-agent/get-post

Zweck: Liest Kern-Metadaten eines Beitrags oder einer Seite (jeder registrierte, öffentliche Post-Type) inklusive Block-Report, ohne einen zweiten render-check-Aufruf zu benötigen.

Capability: edit_posts (grob) plus current_user_can('edit_post', $post_id) (löst automatisch die passende Post-Type-Capability auf, z. B. edit_pages).

Merkmale: lesend, nicht destruktiv, idempotent.

state_hash ist der exakte SHA-256-Zustand für eine spätere Update-Planung. Der aktuelle update-post-Aufruf verwendet ihn nur im dokumentierten Input-Vertrag und endet vor jeder Remote-Mutation mit HTTP 409 und manual_only.

Beispiel: { "post_id": 42 }

wp-agent/list-posts

Zweck: Listet Beiträge oder Seiten eines Post-Types mit Such-, Status- und Paginierungs-Filter als schlanke Liste. Der Post-Type ist generisch, wird aber gegen registrierte, öffentliche Types validiert.

Capability: edit_posts (grob) plus die für den konkreten post_type zuständige Edit-Capability (wpagent_post_type_edit_cap).

Merkmale: lesend, nicht destruktiv, idempotent.

Beispiel: { "post_type": "page", "status": "publish", "per_page": 10 }

wp-agent/update-post

Zweck: Preflight für ein partielles Update eines bestehenden Beitrags oder einer Seite. Der aktuelle Remote-Writer ist nicht verfügbar: Die Ability liest oder mutiert den Beitrag nicht, sondern liefert HTTP 409 mit manual_only. expected_state_hash bleibt Teil des Input-Vertrags, autorisiert aber keine Mutation. Nach der manuellen Änderung kann wp-agent/get-post den Zustand erneut lesen. Der Create-Modus von wp-agent/create-post-from-markdown bleibt davon getrennt remote verfügbar.

Capability: edit_posts (grobe Schranke). Der aktuelle Callback beendet die Ausführung vor einer beitragsbezogenen Remote-Prüfung oder Mutation mit manual_only.

Merkmale: manual-only, nicht destruktiv, nicht idempotent. Der aktuelle Vertrag schreibt keine Beitragsfelder.

Beispiel:

{ "post_id": 42, "expected_state_hash": "<64-stelliger SHA-256 aus get-post>", "title": "Neuer Titel" }

Die aktuelle Antwort ist HTTP 409 mit manual_only und recovery_required: false; WordPress erhält keine Änderung. Ändere den Beitrag beaufsichtigt in WordPress und lies ihn danach mit wp-agent/get-post erneut.

wp-agent/set-post-status

Zweck: Prüft einen gewünschten Statuswechsel eines Beitrags oder einer Seite (publish, draft, pending, private, future) gegen den vollständigen Zustand aus get-post. Der aktuelle Lifecycle-Writer führt keine Remote-Mutation aus. Nach dem frischen Re-Read und der Konflikthash-Prüfung liefert er HTTP 409 mit manual_only, bevor WordPress den Status ändert. Bei future bleibt ein in der Zukunft liegendes Datum Teil der Eingabeprüfung.

Capability: edit_posts (grob) plus current_user_can('edit_post', $post_id) plus die für den Zielstatus passende Capability (wpagent_check_post_status_cap, z. B. publish_posts bei publish).

Merkmale: manual-only, nicht destruktiv, nicht idempotent. Der aktuelle Vertrag mutiert keinen Beitragsstatus.

Beispiel: { "post_id": 42, "status": "publish" }

wp-agent/trash-post

Zweck: Prüft das Verschieben eines Beitrags oder einer Seite in den Papierkorb gegen den vollständigen Zustand aus get-post. Der aktuelle Lifecycle-Writer führt keine Remote-Mutation aus und liefert nach dem frischen Re-Read HTTP 409 mit manual_only. Der Vorgang muss in der beaufsichtigten WordPress-Verwaltung erfolgen. Eine manuelle Verschiebung bleibt über wp-agent/restore-post reversibel.

Capability: edit_posts (grob) plus current_user_can('delete_post', $post_id).

Merkmale: manual-only, nicht destruktiv, nicht idempotent. Der aktuelle Vertrag verschiebt keinen Beitrag remote.

Beispiel: { "post_id": 42 }

wp-agent/restore-post

Zweck: Prüft die Wiederherstellung eines Beitrags oder einer Seite aus dem Papierkorb gegen den vollständigen Zustand aus get-post. Der aktuelle Lifecycle-Writer führt keine Remote-Mutation aus und liefert nach dem frischen Re-Read HTTP 409 mit manual_only. Die Wiederherstellung muss in der beaufsichtigten WordPress-Verwaltung erfolgen. Ein früherer Status aus _wp_trash_meta_status darf dort übernommen werden; future bleibt wegen des Risikos eines sofortigen Cron-Publishings ausgeschlossen.

Capability: edit_posts (grob) plus current_user_can('delete_post', $post_id).

Merkmale: manual-only, nicht destruktiv, nicht idempotent. Der aktuelle Vertrag stellt keinen Beitrag remote wieder her.

Beispiel: { "post_id": 42 }

wp-agent/delete-post

Zweck: Verschiebt einen Beitrag konfliktgeschützt ausschließlich in den reversiblen Papierkorb. force=true wird vor jeder Mutation mit HTTP 409 abgewiesen. Endgültig löschst du den Beitrag nur manuell in der WordPress-Verwaltung. Als Startseite oder Beitragsseite konfigurierte Seiten bleiben geschützt (wpagent_check_protected_post).

Capability: edit_posts (grob) plus current_user_can('delete_post', $post_id).

Merkmale: schreibend, nicht destruktiv, nicht idempotent. Die Remote-Änderung braucht einen frischen expected_state_hash.

Beispiel: { "post_id": 42, "expected_state_hash": "<SHA-256 aus get-post>" }

---

wp-agent/search-replace-content

Zweck: Sucht eine literale Textfolge in Titel, Auszug oder Inhalt öffentlicher Beiträge und ersetzt sie begrenzt. Standard ist ein Dry-Run. Es werden höchstens 1.000 Kandidaten gescannt und höchstens 100 Beiträge in einer Operation geändert. HTML-Struktur, Block-Kommentare und proprietärer Builder-Fremdspeicher werden abgelehnt. Jede echte Änderung wird zurückgelesen und mit einem sieben Tage gültigen Rückgängig-Snapshot verknüpft.

Capability: edit_posts plus current_user_can('edit_post', $post_id) für jeden Treffer.

Merkmale: schreibend, nicht destruktiv, nicht idempotent.

Output: dry_run, matched_posts, updated_posts, total_replacements, items, operation_id, verified.

Beispiel: { "search": "490 Euro", "replace": "590 Euro", "post_types": ["page"], "dry_run": true }

wp-agent/undo-content-replace

Zweck: Stellt den vollständigen Vorzustand einer durch search-replace-content erzeugten Operation wieder her. Vor dem Schreiben und erneut unter einer exklusiven Sperre wird geprüft, ob alle betroffenen Felder noch exakt dem Ersetzungsergebnis entsprechen. Bei einer zwischenzeitlichen Änderung wird die gesamte Wiederherstellung abgelehnt.

Capability: edit_posts plus edit_post für jeden betroffenen Beitrag. Nur der Ersteller der Operation oder ein Nutzer mit manage_options darf sie rückgängig machen.

Merkmale: schreibend, nicht destruktiv, nicht idempotent. Der Write ist an einen frischen Zustands-Hash gebunden und darf nach einem unklaren Ergebnis nicht blind wiederholt werden.

Input: operation_id (Pflicht), dry_run (Standard true). Output: dry_run, restorable_posts, undone, verified.

Beispiel: { "operation_id": "123e4567-e89b-12d3-a456-426614174000", "dry_run": false }

---

2. Taxonomien

wp-agent/create-term

Zweck: Legt einen neuen Term in einer Taxonomie an (z. B. Kategorie oder Schlagwort). parent ist nur bei hierarchischen Taxonomien erlaubt. Re-Read-verifiziert pro Feld.

Capability: edit_posts (grob) plus die manage_terms-Capability der konkreten Taxonomie (get_taxonomy($tax)->cap->manage_terms, fail-closed auf do_not_allow).

Merkmale: schreibend, nicht destruktiv, idempotent (doppelter Name wird von wp_insert_term() abgelehnt).

Beispiel: { "taxonomy": "category", "name": "WordPress" }

wp-agent/get-term

Zweck: Liest einen einzelnen Term (Name, Slug, Beschreibung, Eltern-Term, Anzahl zugeordneter Objekte).

Capability: edit_posts (grob) plus die schwächste Standard-Taxonomie-Capability assign_terms (minimale sinnvolle Lese-Schranke).

Merkmale: lesend, nicht destruktiv, idempotent.

Beispiel: { "term_id": 5, "taxonomy": "category" }

wp-agent/list-terms

Zweck: Listet Terme einer Taxonomie mit Such-, hide_empty- und Eltern-Term-Filter. number begrenzt die Trefferzahl (Default 100, maximal 500).

Capability: edit_posts (grob) plus assign_terms der konkreten Taxonomie.

Merkmale: lesend, nicht destruktiv, idempotent.

Beispiel: { "taxonomy": "post_tag", "hide_empty": true, "number": 50 }

wp-agent/update-term

Zweck: Bereitet eine Änderung von Name, Slug, Eltern-Term oder Beschreibung eines bestehenden Terms für die manuelle WordPress-Verwaltung vor. Die Ability führt kein Term-Update aus. Sie antwortet vor jeder Mutation mit HTTP 409 und manual_only. Ein Term darf nicht sein eigener Eltern-Term sein.

Capability: edit_posts (grob) plus edit_terms der konkreten Taxonomie.

Merkmale: manual-only, keine Remote-Mutation.

Remote-Aufruf: Nicht verfügbar. Der Callback antwortet vor einer inhaltlichen Term-Prüfung oder Mutation mit HTTP 409 und manual_only. Den Term in WordPress ändern und anschließend neu lesen.

wp-agent/delete-term

Zweck: Prüft die Eingaben für das endgültige manuelle Löschen eines Terms aus einer Taxonomie. Die Ability löscht keinen Term und antwortet vor jeder Mutation mit HTTP 409 und manual_only. Es gibt keinen Papierkorb für Terme in WordPress. Den Standard-Term einer Taxonomie (z. B. die Default-Kategorie) nicht löschen.

Capability: edit_posts (grob) plus delete_terms der konkreten Taxonomie.

Merkmale: manual-only, keine Remote-Mutation.

Remote-Aufruf: Nicht verfügbar. Die aktuelle Term-, Hash- und Bestätigungsprüfung kann den Löschvorgang nur vorbereiten. Der Callback löscht nicht und antwortet mit HTTP 409 und manual_only. Den Term in WordPress löschen und anschließend neu lesen.

wp-agent/set-post-terms

Zweck: Prüft eine geplante manuelle Termzuweisung für einen Beitrag. Die Ability weist keine Terme zu, legt keine neuen Terme an und antwortet vor jeder Mutation mit HTTP 409 und manual_only. Die Änderung erfolgt anschließend in der WordPress-Verwaltung.

Capability: current_user_can('edit_post', $post_id) plus assign_terms der konkreten Taxonomie.

Merkmale: manual-only, keine Remote-Mutation.

Remote-Aufruf: Nicht verfügbar. Der Callback weist keine Terme zu und antwortet mit HTTP 409 und manual_only. Die gewünschten Zuordnungen im Beitragseditor ändern und danach den Beitrag neu lesen.

---

3. Medien

wp-agent/upload-media

Zweck: Lädt ein Bild von einer öffentlichen http(s)-URL herunter und legt es per media_handle_sideload() als neuen Medienbeitrag an. Alt-Text ist Pflicht und wird per Re-Read verifiziert. SSRF-geschützt: nur http/https, localhost/.localhost blockiert, jede aufgelöste DNS-Adresse (A und AAAA) sowie jeder Redirect-Hop (maximal 3) wird gegen private/Loopback/Link-Local-Bereiche geprüft (FILTER_FLAG_NO_PRIV_RANGE/FILTER_FLAG_NO_RES_RANGE), fail-closed bei nicht auflösbaren Hosts.

Capability: upload_files.

Merkmale: schreibend, nicht destruktiv, nicht idempotent (jeder Aufruf legt einen neuen Medienbeitrag an).

Beispiel: { "source_url": "https://example.com/bild.jpg", "alt": "Produktfoto Vorderansicht" }

wp-agent/create-direct-media-upload

Zweck: Bereitet einen direkten Upload einer lokalen Datei vor. Die Datei läuft nicht durch REST oder MCP und braucht keine öffentliche Zwischen-URL. Die Ability liefert einen POST-Endpunkt sowie die erforderlichen Header. Der Client sendet anschließend die rohen Datei-Bytes als application/octet-stream.

Capability: gültiges Companion-Gate, sicherer verbundener Redakteur ohne Administrator- oder Super-Administratorrechte und upload_files. Bei einem Eltern-Beitrag zusätzlich edit_post.

Merkmale: schreibend, nicht destruktiv, nicht idempotent. Ein neuer Aufruf ersetzt den noch offenen Slot desselben Nutzers. Der 256-Bit-Token gilt fünf Minuten und genau einmal, steht ausschließlich im Header X-WPAgent-Upload-Token und wird serverseitig nur als SHA-256-Hash gespeichert. Außerhalb lokaler Entwicklungsumgebungen ist HTTPS Pflicht. Das Limit ist das kleinere aus dem WordPress-Serverlimit und 64 MiB. Dateiname, erlaubter WordPress-Dateityp, tatsächlicher MIME-Inhalt, Bild-Alt-Text, Elternrecht, Dateigröße und unveränderte Übertragung werden fehlersicher geprüft.

Der HTTP-Endpunkt antwortet nach erfolgreichem Upload mit attachment_id, post_id, dem tatsächlich gespeicherten filename, mime_type, bytes, alt, url und verified=true. Datei, Größe, MIME-Typ, Autor, Elternbeitrag, URL und Alt-Text werden nach dem Speichern erneut gelesen. Schlägt diese Prüfung nach dem Anlegen fehl, bleibt der neue Anhang erhalten und die Antwort ist HTTP 409 mit dem Code wpagent_direct_upload_recovery_required, recovery_required=true und der nicht geheimen attachment_id zur manuellen Kontrolle. WordPress bietet hier keinen atomaren Compare-and-Delete-Mechanismus. Der Upload-Token sowie Dateiinhalt und Dateipfad erscheinen nicht in dieser Recovery-Antwort.

wp-agent/revoke-direct-media-upload

Zweck: Widerruft den noch offenen Direkt-Upload-Slot des aktuellen sicheren Redakteurs.

Capability: wie create-direct-media-upload.

Merkmale: schreibend, nicht destruktiv, idempotent. Der Output enthält revoked als Boolean.

wp-agent/set-alt-text

Zweck: Setzt den Alt-Text eines vorhandenen Medienbeitrags (_wp_attachment_image_alt). Ein leerer String ist ein gültiger Zielwert (gezieltes Leeren möglich).

Capability: edit_posts (grob) plus current_user_can('edit_post', $attachment_id).

Merkmale: schreibend, nicht destruktiv, nicht idempotent. Der Write ist an einen frischen Zustands-Hash gebunden und darf nach einem unklaren Ergebnis nicht blind wiederholt werden.

expected_state_hash ist der frische state_hash aus dem vorherigen Leseaufruf.

Beispiel: { "attachment_id": 88, "alt": "Team-Foto beim Sommerfest", "expected_state_hash": "<SHA-256 aus list-media>" }

wp-agent/set-featured-image

Zweck: Setzt einen vorhandenen Medienbeitrag als Featured Image (_thumbnail_id) eines Beitrags oder einer Seite über set_post_thumbnail().

Capability: edit_posts (grob) plus current_user_can('edit_post', $post_id) und current_user_can('edit_post', $attachment_id). Der verbundene Nutzer muss den Zielbeitrag und den Anhang bearbeiten dürfen.

Merkmale: schreibend, nicht destruktiv, nicht idempotent. Der Write ist an einen frischen Zustands-Hash gebunden und darf nach einem unklaren Ergebnis nicht blind wiederholt werden.

expected_state_hash ist der frische state_hash aus dem vorherigen Leseaufruf.

Beispiel: { "post_id": 42, "attachment_id": 88, "expected_state_hash": "<SHA-256 aus get-post>" }

wp-agent/delete-media

Zweck: Verschiebt einen Medienbeitrag konfliktgeschützt ausschließlich in den reversiblen Papierkorb. force=true wird vor jeder Mutation mit HTTP 409 abgewiesen. Ist der WordPress-Papierkorb deaktiviert, führt WPAgently keine Remote-Löschung aus. Endgültig löschst du das Medium nur manuell in der WordPress-Verwaltung.

Capability: edit_posts (grob) plus current_user_can('delete_post', $attachment_id).

Merkmale: schreibend, nicht destruktiv, nicht idempotent. Die Remote-Änderung braucht einen frischen expected_state_hash aus list-media.

Beispiel: { "attachment_id": 88, "expected_state_hash": "<SHA-256 aus list-media>" }

wp-agent/list-media

Zweck: Listet Medienbeiträge (post_type=attachment, post_status=inherit, ohne Papierkorb) mit Such-, MIME-Typ- und Paginierungs-Filter.

Capability: upload_files.

Merkmale: lesend, nicht destruktiv, idempotent.

Beispiel: { "mime_type": "image", "per_page": 20 }

---

4. Menüs

Alle fünf Menü-Abilities teilen dieselbe Capability edit_theme_options. Diese Capability ist in WordPress' Kern-Rollen ausschließlich Administratoren zugewiesen, der Editor-Rolle nicht (wp-admin/includes/schema.php, populate_roles_300()). Menüverwaltung ist in WordPress selbst Admin-Territorium, ein als Editor eingerichteter Companion-Bot bekommt hier also von jeder Ability dieser Gruppe ein 403, sofern er nicht zum Administrator hochgestuft wird.

wp-agent/create-menu

Zweck: Legt ein neues Navigationsmenü an (nav_menu-Taxonomie-Term). Ein doppelter Menüname wird als Eingabefehler (400) gemeldet, nicht als Serverfehler.

Merkmale: schreibend, nicht destruktiv, idempotent (Namenskonflikt schlägt kontrolliert fehl statt ein zweites Menü anzulegen).

Beispiel: { "name": "Hauptmenü" }

wp-agent/add-menu-item

Zweck: Fügt einem bestehenden Menü einen neuen Eintrag hinzu: entweder einen benutzerdefinierten Link (object=custom, benötigt url) oder einen Verweis auf ein bestehendes Objekt (object=page/post/category, benötigt object_id). Optional als Untereintrag über parent (muss ein Eintrag im selben Menü sein).

Merkmale: schreibend, nicht destruktiv, nicht idempotent (wp_update_nav_menu_item($menu_id, 0, ...) legt bei jedem Aufruf einen neuen Eintrag an, es gibt keinen Update-Schlüssel).

Beispiel: { "menu_id": 3, "title": "Blog", "object": "page", "object_id": 10 }

wp-agent/list-menus

Zweck: Listet alle vorhandenen Navigationsmenüs als schlanke Liste.

Merkmale: lesend, nicht destruktiv, idempotent.

Keine Input-Parameter.

Beispiel: {}

wp-agent/assign-menu-location

Zweck: Weist ein Menü einer vom aktiven Theme registrierten Position zu (z. B. primary). Positionen sind keine Datenbank-Entität, sondern kommen aus $_wp_registered_nav_menus; die Zuordnung selbst liegt im Theme-Mod nav_menu_locations und übersteht einen Theme-Wechsel deshalb nicht automatisch.

Merkmale: schreibend, nicht destruktiv, idempotent.

Beispiel: { "menu_id": 3, "location": "primary" }

wp-agent/delete-menu

Zweck: Prüft die Eingabe für das endgültige manuelle Löschen eines Navigationsmenüs. Die Ability löscht kein Menü und antwortet vor jeder Mutation mit HTTP 409 und manual_only. Menüeinträge und Zuweisungen bleiben unverändert. Es gibt keinen Papierkorb für Menüs.

Merkmale: manual-only, keine Remote-Mutation.

Output: HTTP 409 mit manual_only, ohne Änderung. Das Menü in der WordPress-Verwaltung löschen und die Menüzuteilungen danach prüfen.

Beispiel: { "menu_id": 3 }

---

5. Einstellungen

Alle drei Abilities teilen dieselbe feste Allowlist WPAGENT_SETTINGS_ALLOWLIST (includes/settings-allowlist.php): blogname, blogdescription, posts_per_page, show_on_front, page_on_front, page_for_posts, permalink_structure, timezone_string, start_of_week, date_format, time_format, default_category. Zusätzlich zur Allowlist greift immer eine harte Denylist: siteurl, home, active_plugins, wp_user_roles, users_can_register, admin_email sowie jeder Options-Name mit salt, key oder secret als Teilzeichenkette sind nie lesbar oder schreibbar, selbst falls sie versehentlich in der Allowlist stünden.

wp-agent/get-setting

Zweck: Liest eine einzelne Einstellung aus der Allowlist.

Capability: manage_options.

Merkmale: lesend, nicht destruktiv, idempotent.

Beispiel: { "name": "blogname" }

wp-agent/update-setting

Zweck: Setzt eine Einstellung aus der beschreibbaren Allowlist. Jeder Name durchläuft eine eigene Typ-/Enum-/Existenz-Prüfung vor dem Schreiben. Zwei Sonderfälle werden explizit behandelt: (1) show_on_front/page_on_front/page_for_posts werden auf fachliche Konsistenz geprüft (show_on_front=page ohne gesetzte page_on_front wird abgelehnt, page_on_front und page_for_posts dürfen nicht dieselbe Seite sein); (2) permalink_structure läuft über $wp_rewrite->set_permalink_structure() gefolgt von flush_rewrite_rules(), weil ein roher update_option()-Aufruf allein die aktiven Rewrite-Regeln nicht mit aktualisiert.

Capability: manage_options.

Merkmale: schreibend, nicht destruktiv, idempotent.

Beispiel: { "name": "posts_per_page", "value": 12 }

wp-agent/list-settings

Zweck: Listet alle Einstellungen aus der Allowlist mit ihrem aktuellen Wert, ohne dass jede Einstellung einzeln per get-setting abgefragt werden muss.

Capability: manage_options.

Merkmale: lesend, nicht destruktiv, idempotent.

Keine Input-Parameter.

Beispiel: {}

wp-agent/get-ase-free-generator-tag

Zweck: Liest ausschließlich den geprüften ASE-Free-Schalter zum Entfernen der WordPress-Generator-Meta-Markierung. Der Pfad gilt nur für Admin and Site Enhancements Free 9.0.0 und meldet auch, ob dessen übergeordnete Gruppe „Disable Smaller Components“ aktiv ist.

Capability: manage_options.

Merkmale: lesend, nicht destruktiv, idempotent. Keine Parameter.

Beispiel: {}

wp-agent/update-ase-free-generator-tag

Zweck: Ändert ausschließlich diesen einen ASE-Free-Schalter. Der Pfad verlangt den aktuellen Konflikthash, bindet die Mutation an den WordPress-Blog, verwendet einen atomaren Vergleich mit erneuerbarer Sperre und liest den gespeicherten Providerzustand anschließend exakt zurück. Ist der Zustand nach dem Schreiben unsicher, endet er mit recovery_required ohne automatische Folgemutation.

Capability: manage_options.

Merkmale: schreibend, nicht destruktiv, idempotent. ASE Free 9.0.0 und die manuell aktivierte Gruppe „Disable Smaller Components“ sind Voraussetzung.

Beispiel: { "disabled": true, "expected_hash": "<64-stelliger SHA-256 aus get-ase-free-generator-tag>" }

---

6. Kommentare

Alle vier Abilities teilen die grobe Schranke moderate_comments; feingranular wird zusätzlich immer edit_comment/edit_post auf das konkrete Ziel geprüft (siehe jeweils unten), analog zum Content-Lebenszyklus-Muster.

wp-agent/list-comments

Zweck: Listet Kommentare mit optionalem Beitrags-, Status- und Paginierungs-Filter plus Gesamtzahl.

Capability: moderate_comments.

Merkmale: lesend, nicht destruktiv, idempotent.

Beispiel: { "post_id": 42, "status": "hold" }

wp-agent/moderate-comment

Zweck: Setzt den Status eines bestehenden Kommentars direkt (approve, hold, spam, trash). Behandelt explizit den Vokabular-Unterschied zwischen Eingabe (hold) und Rückgabewert von wp_get_comment_status() (unapproved), damit die Re-Read-Verifikation nicht fälschlich fehlschlägt.

Capability: moderate_comments (grob) plus current_user_can('edit_comment', $comment_id).

Merkmale: schreibend, nicht destruktiv, idempotent.

Beispiel: { "comment_id": 15, "status": "approve" }

wp-agent/reply-to-comment

Zweck: Legt einen neuen, sofort genehmigten Kommentar an: als Antwort auf einen bestehenden Kommentar (comment_id, wird dessen Kind) oder als Kommentar auf oberster Ebene für einen Beitrag (post_id). Genau eines von beiden ist Pflicht. Der Autor ist immer der aktuell angemeldete Nutzer (der Bot), nie anonym. Nutzt bewusst wp_insert_comment() statt des öffentlich-facing wp_new_comment(), um Flood-/Duplicate-Checks für anonyme Besucher und die comment_status=open-Prüfung zu umgehen (der Aufrufer ist bereits privilegiert).

Capability: moderate_comments (grob) plus, je nach Ziel, edit_comment (bei comment_id) oder edit_post (bei post_id).

Merkmale: schreibend, nicht destruktiv, nicht idempotent (jeder Aufruf legt einen neuen Kommentar an).

Beispiel: { "comment_id": 15, "content": "Danke für den Hinweis, wir prüfen das." }

wp-agent/delete-comment

Zweck: Verschiebt nur einen regulären Kommentar konfliktgeschützt in den reversiblen Papierkorb. Pingbacks, Trackbacks und Notizen bleiben unverändert. force=true wird mit HTTP 409 abgewiesen. Ist der Kommentar-Papierkorb deaktiviert, führt WPAgently keine Remote-Löschung aus. Endgültig löschst du den Kommentar nur manuell in der WordPress-Verwaltung.

Capability: moderate_comments (grob) plus current_user_can('edit_comment', $comment_id) (delete_comment ist in WordPress kein registrierter Meta-Capability-Fall und würde sonst immer false liefern).

Merkmale: schreibend, nicht destruktiv, nicht idempotent. Die Remote-Änderung braucht einen frischen expected_state_hash.

Beispiel: { "comment_id": 15, "expected_state_hash": "<SHA-256 aus list-comments>" }

---

7. Nutzer

Die gesamte Nutzerverwaltungs-Gruppe ist stark gegatet: Alle fünf Capabilities (list_users, edit_users, promote_users, create_users, delete_users) sind in einer Standardinstallation ausschließlich Administratoren vorbehalten. Der als Editor eingerichtete Companion-Bot bekommt hier immer ein 403.

wp-agent/list-users

Zweck: Listet WordPress-Nutzer mit Rollen-, Such- und Paginierungs-Filter.

Capability: list_users.

Merkmale: lesend, nicht destruktiv, idempotent.

Beispiel: { "role": "editor" }

wp-agent/get-user

Zweck: Liest die Profildaten eines einzelnen Nutzers. Gibt niemals das Passwort-Hash-Feld (user_pass), den Passwort-Reset-Schlüssel oder Session-Tokens aus; das Ergebnis wird bewusst Feld für Feld aus WP_User zusammengesetzt.

Capability: edit_users (die Capability, die WordPress selbst für den Zugriff auf ein einzelnes Nutzerprofil verlangt, nicht das schlankere list_users).

Merkmale: lesend, nicht destruktiv, idempotent.

Beispiel: { "user_id": 3 }

wp-agent/set-user-role

Zweck: Setzt die Rolle eines bestehenden Nutzers direkt (ersetzt alle bisherigen Rollen durch genau eine). Zwei harte, nicht umgehbare Schutzmechanismen: User-ID 1 wird nie geändert, der aufrufende Account (also der Bot selbst) darf seine eigene Rolle nie ändern. Zusätzliches weiches Gate: Rollen mit der Capability manage_options (administrator-äquivalent) erfordern das explizite Flag i_grant_admin=true.

Capability: promote_users (die Capability, an die WordPress selbst Rollenänderungen bindet, nicht das breitere edit_users).

Merkmale: schreibend, nicht destruktiv, idempotent.

Beispiel: { "user_id": 7, "role": "author" }

wp-agent/create-user

Zweck: Legt einen neuen Nutzer über wp_insert_user() an. Ohne Passwort wird serverseitig ein starkes Passwort erzeugt und einmalig im Ergebnis zurückgegeben (generated_password, taucht bei späteren Leseoperationen nie wieder auf). Dasselbe Administrator-Gate wie bei set-user-role.

Capability: create_users.

Merkmale: schreibend, nicht destruktiv, nicht idempotent (doppelter username schlägt am WordPress-Kern fehl statt denselben Zustand zu melden).

Beispiel: { "username": "neuer.autor", "email": "autor@example.com", "role": "author" }

wp-agent/delete-user

Zweck: Prüft die Eingabe für das endgültige manuelle Löschen eines Nutzers. Die Ability löscht keinen Nutzer, verschiebt oder löscht keine Inhalte und antwortet vor jeder Mutation mit HTTP 409 und manual_only. Die Entscheidung über Inhaltsübernahme oder Inhaltslöschung sowie die eigentliche Löschung erfolgen in der WordPress-Verwaltung. User-ID 1 und der aufrufende Account selbst dürfen nie gelöscht werden.

Capability: delete_users.

Merkmale: manual-only, keine Remote-Mutation.

Output: HTTP 409 mit manual_only, ohne Änderung.

Beispiel: { "user_id": 9, "reassign_to": 2 }

---

8. Plugins und Themes

wp-agent/list-plugins

Zweck: Listet installierte Plugins mit Dateipfad, Name, Version und Aktiv-Status. Dient als unabhängige Re-Read-Quelle für activate-plugin/deactivate-plugin.

Capability: activate_plugins.

Merkmale: lesend, nicht destruktiv, idempotent.

Keine Input-Parameter.

Beispiel: {}

wp-agent/activate-plugin

Zweck: Aktiviert ein installiertes Plugin und verifiziert per Re-Read (is_plugin_active). Fängt Throwables aus einem fehlerhaften Plugin-Hook ab, statt den ganzen REST-Request mitzureißen (echte, nicht abfangbare PHP-Fatals wie Speicherlimit/Timeout bleiben ein WordPress-Kern-Grenzfall). wp-agent-companion und wp-agent-power sind hart ausgenommen (Selbstschutz).

Capability: activate_plugins.

Merkmale: schreibend, nicht destruktiv, idempotent.

Beispiel: { "plugin_file": "akismet/akismet.php" }

wp-agent/deactivate-plugin

Zweck: Deaktiviert ein installiertes Plugin und verifiziert per Re-Read. wp-agent-companion und wp-agent-power können über diese Ability nie deaktiviert werden (für den Power-Modus gezielt wp-agent/disable-power verwenden).

Capability: activate_plugins.

Merkmale: schreibend, nicht destruktiv, idempotent.

Beispiel: { "plugin_file": "hello-dolly/hello.php" }

wp-agent/list-themes

Zweck: Listet installierte Themes mit Stylesheet-Ordnername, Name, Version und Aktiv-Status.

Capability: switch_themes (dieselbe Capability wie switch-theme, teilt sich den Bereich analog zu list-plugins/activate-plugin; von WordPress ebenfalls nicht standardmäßig an Editor vergeben).

Merkmale: lesend, nicht destruktiv, idempotent.

Keine Input-Parameter.

Beispiel: {}

wp-agent/switch-theme

Zweck: Wechselt das aktive Theme. Lehnt unbekannte, fehlerhafte (WP_Theme::errors(), geht über die reine exists()-Prüfung hinaus) oder mit der aktuellen WP-/PHP-Version inkompatible Themes vorab ab, statt sie zu aktivieren oder switch_theme() intern wp_die() auslösen zu lassen.

Capability: switch_themes.

Merkmale: schreibend, nicht destruktiv, idempotent.

Beispiel: { "stylesheet": "twentytwentyfive" }

---

9. Wiederverwendbare Blöcke

Post-Type wp_block (Gutenberg-Synced-Patterns). Für diesen Post-Type kommt bewusst nicht wpagent_validate_post_type() zum Einsatz, weil wp_block im WordPress-Kern mit 'public' => false registriert ist und dieser generische Whitelist-Check den Zugriff sonst fälschlich verweigern würde.

wp-agent/create-reusable-block

Zweck: Legt einen wiederverwendbaren Block aus Markdown an. Der Server erzeugt daraus erlaubte Core-Blöcke. Bereits serialisiertes Block-Markup und freies HTML werden nicht angenommen. Der Block wird immer als publish angelegt, weil core/block einen referenzierten Block nur bei diesem Status rendert (ein als draft angelegter Block bliebe auf jeder einbindenden Seite still leer).

Capability: edit_posts (grob) plus die tatsächliche Erstell-Capability für wp_block: publish_posts (WordPress-Kern-Kommentar: „You need to be able to publish posts, in order to create blocks“), nicht das übliche create_posts/edit_posts.

Merkmale: schreibend, nicht destruktiv, nicht idempotent (jeder Aufruf legt einen neuen wp_block-Post an).

Beispiel: { "title": "CTA-Box Newsletter", "content_markdown": "**Jetzt anmelden!**" }

wp-agent/update-reusable-block

Zweck: Prüft eine geplante manuelle Änderung von Titel oder Inhalt eines bestehenden wiederverwendbaren Blocks. Die Ability ändert keinen Block und antwortet vor jeder Mutation mit HTTP 409 und manual_only. Den Block danach in WordPress bearbeiten und den aktuellen Zustand neu lesen.

Capability: edit_posts (grob) plus current_user_can('edit_post', $block_id).

Merkmale: manual-only, keine Remote-Mutation.

Remote-Aufruf: Nicht verfügbar. Der Callback gibt HTTP 409 mit manual_only zurück, ohne title oder content_markdown zu lesen, umzuwandeln oder zu speichern. Den wiederverwendbaren Block in WordPress öffnen, dort ändern und anschließend den aktuellen Zustand erneut prüfen.

wp-agent/list-reusable-blocks

Zweck: Listet wiederverwendbare Blöcke mit Such-, Status- und Paginierungs-Filter. Kein post_type-Parameter, fest auf wp_block verdrahtet.

Capability: edit_posts (grob) plus explizit die für wp_block zuständige Lese-Capability (im Kern literal auf edit_posts gemappt).

Merkmale: lesend, nicht destruktiv, idempotent.

Beispiel: { "per_page": 10 }

wp-agent/delete-reusable-block

Zweck: Verschiebt einen wiederverwendbaren Block konfliktgeschützt in den Papierkorb. force=true wird aus Kompatibilitätsgründen akzeptiert, verlangt zusätzlich confirm_permanent_delete=true und antwortet dann ohne Mutation mit HTTP 409. Endgültig löschst du den Block nur manuell in der WordPress-Verwaltung.

Capability: edit_posts (grob) plus current_user_can('delete_post', $block_id).

Merkmale: schreibend, reversibler Papierkorb, nicht idempotent. Die Remote-Änderung braucht einen frischen expected_state_hash.

Beispiel: { "block_id": 55, "expected_state_hash": "<SHA-256 aus list-reusable-blocks>" }

---

10. SEO

wp-agent/get-seo-meta

Zweck: Liest die gespeicherten Post-SEO-Angaben aus Rank Math, Yoast, AIOSEO oder SEOPress über deren jeweiligen wirksamen Speicher- beziehungsweise Ability-Pfad und normalisiert sie. Ohne unterstütztes aktives SEO-Plugin bricht die Ability mit HTTP 409 ab. robots_noindex und robots_nofollow geben die postbezogenen Provider-Flags wieder. Globale SEO-Defaults werden nicht fälschlich als gespeicherter Post-Override ausgegeben. Die AIOSEO-Post-SEO-Laufzeit ist derzeit nur auf MariaDB praktisch nachgewiesen; MySQL und SQLite liegen außerhalb dieses Nachweises. Die erfolgreiche Ausgabe ist geschlossen und enthält jedes unten aufgeführte Feld einschließlich state_hash.

Capability: edit_posts (grob) plus current_user_can('edit_post', $post_id).

Merkmale: lesend, nicht destruktiv, idempotent.

Beispiel: { "post_id": 42 }

wp-agent/set-seo-meta

Zweck: Erkennt Rank Math, Yoast, AIOSEO oder SEOPress über deren Laufzeit-API und prüft die angeforderten Beitragsfelder vor einem möglichen manuellen Eingriff. Der aktuelle öffentliche Writer führt providerübergreifend keine Remote-Mutation aus. Nach Eingabevalidierung, frischem Provider-Re-Read und Konflikthash-Prüfung liefert er HTTP 409 mit manual_only, bevor der erste Provider-Write beginnt, weil kein vollständiger bedingter Provider-Schreibpfad nachgewiesen ist. Das gilt für Titel, Description, Fokus-Keyword, Canonical-URL, Robots-Flags sowie Open-Graph- und X/Twitter-Texte und für Rank Math, Yoast, AIOSEO und SEOPress. get-seo-meta bleibt als provider-neutraler Lesepfad aktiv. Änderungen erfolgen derzeit in der jeweiligen Plugin-Verwaltung und werden danach erneut gelesen. Der AIOSEO-Post-SEO-Lesepfad ist praktisch nur auf MariaDB mit transaktionalen InnoDB-Tabellen nachgewiesen; MySQL und SQLite liegen außerhalb dieses Laufzeitnachweises. Ohne unterstütztes aktives SEO-Plugin bricht die Ability ebenfalls mit HTTP 409 ab, statt wirkungslose Ersatzfelder zu speichern.

Capability: edit_posts (grob) plus current_user_can('edit_post', $post_id).

Merkmale: manual-only, nicht destruktiv, nicht idempotent. Der aktuelle Vertrag mutiert keinen Providerzustand.

Im aktuellen Runtime-Vertrag liefert set-seo-meta vor jeder Provider-Mutation HTTP 409 mit manual_only. Die folgenden Erfolgsfelder bleiben aus Schema-Kompatibilitätsgründen dokumentiert und werden bei diesem manuellen Ergebnis nicht als erfolgreicher Write zurückgegeben.

Beispiel: { "post_id": 42, "seo_title": "Bester WordPress-Hoster 2026", "focus_keyword": "wordpress hosting" }

wp-agent/get-seo-settings

Zweck: Liest die globalen Titelvorlagen, Archivregeln und Identitätsangaben des aktiven Rank Math, Yoast SEO, AIOSEO oder SEOPress in einem einheitlichen Vertrag. supported_fields beschreibt die Felder des normalisierten Provider-Lesepfads. Es autorisiert derzeit keinen Remote-Write, weil set-seo-settings providerübergreifend nach frischem Re-Read und Konflikthash-Prüfung mit HTTP 409 und manual_only vor jeder Mutation abbricht. Enthält eine vorhandene Vorlage einen unbekannten nativen Provider-Platzhalter, steht das Feld in unmapped_template_fields und bleibt lesbar, aber schreibgeschützt. homepage_source unterscheidet die globale Startseite von einer statischen Seite. Vorlagen verwenden ausschließlich die in template_tokens ausgegebenen WPAgently-Platzhalter. Der vollständige rohe Zustand der betroffenen Provideroptionen fließt in state_hash ein, wird aber nicht ausgegeben.

Capability: manage_options.

Merkmale: lesend, nicht destruktiv, idempotent.

Die Ability hat keine Eingabeparameter. Der Output enthält plugin, supported_fields, unmapped_template_fields, template_syntax, template_tokens, homepage_source, settings und den 64-stelligen state_hash.

wp-agent/set-seo-settings

Zweck: Prüft eine begrenzte Teilmenge globaler SEO-Einstellungen gegen den unmittelbar zuvor gelesenen Providerzustand. Unterstützt werden abhängig vom Plugin Titeltrennzeichen, globale Startseitenvorlagen, Autor-, Datums- und Sucharchive, Identität, Logo sowie Website-Namen. Provider-spezifische Platzhalter, HTML, Steuerzeichen, Zeilenumbrüche und äußere Leerzeichen werden weiterhin abgelehnt. Nach Eingabevalidierung, frischem Re-Read und expected_hash-Prüfung liefert der aktuelle Writer providerübergreifend HTTP 409 mit manual_only, bevor irgendeine Provider-Mutation beginnt. Änderungen erfolgen derzeit in der jeweiligen Plugin-Verwaltung und werden anschließend über get-seo-settings erneut gelesen.

Capability: manage_options.

Merkmale: manual-only, nicht destruktiv, nicht idempotent. Der aktuelle Vertrag mutiert keinen Providerzustand.

Pflicht sind expected_hash und ein nicht leeres partielles settings-Objekt. Zulässige Felder stehen verbindlich in supported_fields des unmittelbar vorherigen Leseaufrufs. Der Output enthält plugin, den feldweisen Bericht written, verified, rolled_back, rollback_verified, previous_hash und den neuen state_hash.

Im aktuellen Runtime-Vertrag liefert set-seo-settings vor jeder Provider-Mutation HTTP 409 mit manual_only. Die genannten Erfolgsfelder bleiben aus Schema-Kompatibilitätsgründen dokumentiert und werden bei diesem manuellen Ergebnis nicht als erfolgreicher Write zurückgegeben.

Beispiel: { "expected_hash": "<64 hex>", "settings": { "homepage_title_template": "{{site_name}} {{separator}} {{tagline}}", "search_noindex": true } }

wp-agent/get-post-schema

Zweck: Liest benutzerdefinierte Rank-Math-Schemas mit ihren stabilen schema_id-Werten oder Yoasts gespeicherte Seiten- und Artikeltypen. Der jeweilige verfügbare Typkatalog und ein SHA-256-state_hash des vollständigen verwalteten Zustands werden mitgeliefert. AIOSEO und SEOPress werden ohne bestätigten Post-Schema-Pfad mit HTTP 409 abgelehnt.

Capability: edit_posts plus edit_post. Bei Rank Math zusätzlich rank_math_onpage_snippet.

Merkmale: lesend, nicht destruktiv, idempotent.

wp-agent/set-post-schema

Zweck: Erstellt ein neues Rank-Math-Schema oder aktualisiert genau ein bestehendes Schema anhand seiner schema_id. Neue Typen müssen im aktiven Rank-Math-Katalog freigegeben sein und benötigen einen wiederverwendbaren idempotency_key. Größe, Tiefe, Knotenzahl, Schlüssel, interne Shortcode-ID, Primärschema und Providerberechtigung werden vor dem nativen Schreibpfad geprüft. Yoast akzeptiert stattdessen ausschließlich bestätigte page_type- und article_type-Werte. Ein leerer Typ löscht den jeweiligen Yoast-Override. expected_hash, Read-back, Post-Lock und Rollback verhindern veraltete, stille oder parallele Fehländerungen.

Capability: edit_posts plus edit_post. Bei Rank Math zusätzlich rank_math_onpage_snippet.

Merkmale: schreibend, nicht destruktiv, durch schema_id beziehungsweise idempotency_key idempotent.

Beispiel: { "post_id": 42, "expected_hash": "<64 hex>", "page_type": "AboutPage" }

wp-agent/delete-post-schema

Zweck: Prüft die Eingabe für das manuelle Löschen eines benutzerdefinierten Rank-Math-Schemas. Die Ability löscht kein Schema, deaktiviert keinen Rich-Snippet-Status und antwortet vor jeder Mutation mit HTTP 409 und manual_only. Die stabile schema_id muss als confirm_schema_id exakt wiederholt werden. Das Löschen erfolgt anschließend in Rank Math.

Capability: edit_posts plus edit_post. Bei Rank Math zusätzlich rank_math_onpage_snippet.

Merkmale: manual-only, keine Remote-Mutation.

Output: HTTP 409 mit manual_only, ohne Änderung. Den Providerzustand nach der manuellen Änderung mit get-post-schema neu lesen.

Beispiel: { "post_id": 42, "schema_id": "schema-731", "confirm_schema_id": "schema-731", "expected_hash": "<64 hex>" }

wp-agent/get-term-seo-meta

Zweck: Liest die gespeicherten SEO-Angaben eines Terms aus einer öffentlich sichtbaren Taxonomie über Rank Math, Yoast oder SEOPress und normalisiert Titel, Description, Fokus-Keyword, Canonical, Robots sowie Open-Graph- und X/Twitter-Texte. Der vollständige rohe Providerzustand fließt in state_hash ein. AIOSEO Free besitzt keine native Term-SEO-Schnittstelle und wird deshalb mit HTTP 409 fehlersicher abgelehnt.

Capability: edit_posts (grob) plus die konkrete edit_terms-Capability der Taxonomie.

Merkmale: lesend, nicht destruktiv, idempotent.

Der Output entspricht dem normalisierten Post-SEO-Vertrag, ersetzt post_id durch term_id und taxonomy und ergänzt den SHA-256-Wert state_hash.

Beispiel: { "term_id": 17, "taxonomy": "category" }

wp-agent/set-term-seo-meta

Zweck: Prüft den aktuellen Term-SEO-Zustand und den übergebenen expected_hash. Die Ability ändert keine Providerdaten. Rank Math, Yoast und SEOPress bieten hier keinen nachweisbar atomaren Vergleich-und-Schreib-Vorgang. Deshalb antwortet WPAgently nach erfolgreicher Prüfung mit HTTP 409 und manual_only. Ändere die Werte in der Oberfläche des aktiven SEO-Plugins und lies sie danach erneut mit get-term-seo-meta.

Capability: edit_posts (grob) plus die konkrete edit_terms-Capability der Taxonomie.

Merkmale: Kompatibilitätsendpunkt ohne Remote-Mutation, manuell, nicht destruktiv und konfliktgeschützt.

Es gibt keinen Erfolgsoutput, weil keine Remote-Mutation stattfindet. Nach gültiger Prüfung folgt HTTP 409 mit manual_only.

Beispiel: { "term_id": 17, "taxonomy": "category", "expected_hash": "<64-stelliger SHA-256>", "seo_title": "WordPress-Tipps" }

wp-agent/list-seo-redirections

Zweck: Listet bis zu 5.000 nicht gelöschte Rank-Math-Weiterleitungen. Mehrere Quellen sowie contains, start, end und regex bleiben lesbar, werden aber als writable:false gekennzeichnet. collection_hash umfasst die vollständige Sammlung und schützt eine anschließende Anlage vor parallelen Änderungen.

Capability: rank_math_redirections.

Merkmale: lesend, nicht destruktiv, idempotent.

Parameter: Optional status (any, active, inactive), search (höchstens 200 Byte), page und per_page (1-100). Der Output enthält redirections, total, page, per_page, total_pages und collection_hash.

wp-agent/get-seo-redirection

Zweck: Liest eine einzelne nicht gelöschte Rank-Math-Weiterleitung. Jede Quelle enthält pattern, comparison und ignore_case. Der Output ergänzt Ziel, HTTP-Status, Aktivstatus, Trefferzahl, Veränderbarkeit und state_hash. Die Trefferzahl ist absichtlich nicht Teil des Konflikthashs, damit echter Traffic keine reine Konfigurationsänderung blockiert.

Capability: rank_math_redirections.

Merkmale: lesend, nicht destruktiv, idempotent.

Parameter: redirection_id ist Pflicht.

wp-agent/create-seo-redirection

Zweck: Erstellt genau eine exakte lokale Quelle. Erlaubt sind HTTP 301, 302, 307, 410 und 451. Quellen werden kanonisch dekodiert, dürfen weder Startseite, Query, Fragment, Punktsegmente, Steuerzeichen noch mehrdeutige Prozentkodierung enthalten. Ziele müssen absolute oder lokale HTTP- beziehungsweise HTTPS-URLs ohne Zugangsdaten sein. HTTP 410 und 451 verlangen ein leeres Ziel. Ein frischer expected_collection_hash, eine atomare Sperre, Quellkollisionen und Schleifenprüfung schützen die Anlage. Eine semantisch identische Wiederholung liefert das bestehende Objekt mit created:false.

Capability: rank_math_redirections.

Merkmale: schreibend, destruktiv markiert, idempotent und konfliktgeschützt.

Pflichtparameter: source, destination, http_code und expected_collection_hash. Optional sind status und ignore_case. Der Output enthält redirection, created und verified.

wp-agent/update-seo-redirection

Zweck: Aktualisiert nur eine einzelne exakte Providerregel. Komplexe Regeln bleiben unverändert. expected_state_hash, Sperre, Kollisions- und Schleifenprüfung, vollständiger Read-back und verifizierter Rollback schützen den Schreibvorgang.

Capability: rank_math_redirections.

Merkmale: schreibend, destruktiv markiert, idempotent und konfliktgeschützt.

Pflichtparameter: redirection_id und expected_state_hash, dazu mindestens eines aus source, destination, http_code, status oder ignore_case. Der Output enthält redirection und verified.

wp-agent/delete-seo-redirection

Zweck: Verschiebt eine Rank-Math-Weiterleitung in den Provider-Papierkorb. Der Datensatz wird nicht hart gelöscht. Der Vorgang verlangt einen aktuellen Zustands-Hash und die ausdrückliche Bestätigung. Eine fehlgeschlagene Rückleseprüfung stellt den vorherigen Datensatz verifiziert wieder her.

Capability: rank_math_redirections.

Merkmale: schreibend, destruktiv, nicht idempotent und konfliktgeschützt.

Pflichtparameter: redirection_id, expected_state_hash und confirm:true. Der Output enthält redirection_id, deleted und verified.

wp-agent/get-seopress-post-redirection

Zweck: Liest die einfache Beitragsweiterleitung eines veröffentlichten, öffentlich erreichbaren Beitrags über die native SEOPress-Free-Route. Die Quelle wird aus der aktuellen kanonischen Beitrags-URL abgeleitet. Ausgegeben werden nur der bestätigte Aktivstatus, HTTP 301, 302 oder 307, ein lokales Ziel derselben WordPress-Site und ein vollständiger Zustands-Hash. Mehrdeutige, doppelte oder nicht lokale Providerwerte enden geschlossen.

Capability: objektbezogen edit_post. Merkmale: lesend, nicht destruktiv, idempotent. Pflicht: post_id.

wp-agent/set-seopress-post-redirection

Zweck: Setzt oder deaktiviert eine einfache lokale Beitragsweiterleitung über die native SEOPress-Free-Route. Das Ziel muss derselben WordPress-Site angehören und darf keine Zugangsdaten, Query, Fragment, Punktsegmente oder mehrdeutige Kodierung enthalten. Der vollständige Graph aller veröffentlichten öffentlich erreichbaren Beiträge wird begrenzt und ohne Postmeta-N+1 gelesen. Eigene und mehrstufige Zyklen werden vor dem Write abgelehnt. Ein aktueller expected_hash, beitrags- und graphbezogene Locks, exakte Rohzustandsattribution, Provider-Read-back und ein echter HTTP-Read-back schützen den Vorgang. Nach Beginn des Provider-Writes führt ein unklarer Zustand zu recovery_required. Es erfolgt keine automatische Folgemutation, die fremde Provideränderungen überschreiben könnte.

Capability: objektbezogen edit_post. Merkmale: schreibend, destruktiv markiert, idempotent und konfliktgeschützt. Pflicht: post_id, expected_hash, enabled; bei enabled:true zusätzlich destination und optional http_code mit 301, 302 oder 307.

---

11. Landing-Pages, Global Styles, Theme-Dateien und Site Editor

wp-agent/upsert-pattern

Zweck: Baut eine Landing-Page (post_type=page) aus einer deklarativen Sektionsliste (hero, features, media-text, logos, cta, pricing, testimonials, faq, stats, gallery, steps, comparison) als valide Gutenberg-Core-Blöcke und legt sie über slug oder post_id an beziehungsweise aktualisiert sie. Der Vertrag ist nicht als idempotent annotiert, auch wenn die Slug-Zuordnung unbeabsichtigte Duplikate verhindert. Unterstützt optionale Hintergrundbilder (core/cover beim hero), Bild-Text-Splits (core/media-text), Galerien (core/gallery), Akkordeons (core/details), Vergleichstabellen (core/table) und ein natives Icon-Set (mitgelieferte Phosphor-SVGs als core/image). Farb-, Abstands- und Schriftgrößen-Slugs werden gegen die wirksamen Global Styles aufgelöst. Vor dem Speichern prüft parse_blocks, dass garantiert 0 freeform-Blöcke entstehen; jeder Sektionstyp ist zusätzlich im echten Gutenberg-Editor als recovery-frei belegt.

Capability: edit_pages (nicht edit_posts, weil immer post_type=page erzeugt wird).

Merkmale: schreibend, nicht destruktiv, nicht idempotent. Die Slug- oder ID-Zuordnung verhindert unbeabsichtigte Duplikate, ist aber keine Idempotenzannotation.

Für wp-agent landing gilt zusätzlich die CLI-Vorabprüfung aus dem Artikelpfad: Ein expliziter Slug muss bereits der nativen gespeicherten Form entsprechen. Die CLI verwirft rohe Unicode-Zeichen, Großbuchstaben, wiederholte oder abschließende Bindestriche sowie 59 Prozent-kodierte Sequenzen, die WordPress Core beim Speichern normalisiert. Stabil gespeicherte Prozent-kodierte UTF-8-Sequenzen wie %e4%bd%a0%e5%a5%bd und wiederholte Unterstriche bleiben zulässig. Ohne Slug wird der Titel verwendet.

Beispiel:

{
  "title": "Landingpage Webinar",
  "slug": "webinar-anmeldung",
  "status": "draft",
  "sections": [
    { "type": "hero", "heading": "Kostenloses Webinar", "image_url": "https://deine-domain.tld/wp-content/uploads/hero.webp", "cta_label": "Jetzt anmelden", "cta_url": "#formular" },
    { "type": "features", "heading": "Das lernst du", "items": [ { "title": "Erster Punkt", "text": "Kurz erklärt.", "icon": "rocket" } ] },
    { "type": "faq", "heading": "Häufige Fragen", "items": [ { "title": "Was kostet das Webinar?", "text": "Nichts, die Teilnahme ist kostenlos." } ] },
    { "type": "cta", "heading": "Nur noch wenige Plätze frei", "button_label": "Platz sichern", "button_url": "#formular" }
  ]
}

wp-agent/get-global-styles

Zweck: Liest den vollständigen User-Global-Styles-Datensatz als typgetreuen, exportierbaren JSON-Snapshot. Der Snapshot ist auf 512 KiB begrenzt und enthält einen SHA-256-Konflikthash, der das aktive Theme, die Datensatz-ID und den exakten gespeicherten Inhalt bindet. Der Hash ist für jeden folgenden Design-Write erforderlich.

Capability: edit_theme_options.

Merkmale: lesend, nicht destruktiv, idempotent.

Fehlt für das aktive Theme noch ein User-Global-Styles-Datensatz, antwortet die Ability mit HTTP 409 und dem Code wpagent_gs_no_post. Dieser Leseweg bleibt strikt nicht schreibend und legt den Datensatz nicht automatisch an. Öffne und speichere Global Styles einmal im WordPress-Editor und wiederhole danach den Leseaufruf. Erst dann steht ein gültiger state_hash für einen Design-Write zur Verfügung.

wp-agent/set-global-styles

Zweck: Setzt Farben, Schriftgrößen, Abstände, Schriftfamilien und einen eng erlaubten Ausschnitt der Standard-Styles im WordPress-eigenen wp_global_styles-Datensatz. Theme-Dateien und Theme-Presets bleiben unverändert. Custom-Presets werden nach Slug ersetzt oder ergänzt. Ein exakter Konflikthash und eine gemeinsame Kurzzeitsperre verhindern paralleles Überschreiben. Der Zustand wird direkt aus der Datenbank zurückgelesen und bei jeder Abweichung bytegenau zurückgerollt.

Capability: edit_theme_options.

Merkmale: schreibend, nicht destruktiv, idempotent.

Mindestens eine Token-Kategorie oder styles muss gesetzt sein. Preset-Referenzen in styles werden gegen die nach dem Merge tatsächlich verfügbaren Slugs geprüft.

Ein Write setzt ebenfalls einen bestehenden Datensatz und einen frischen expected_hash voraus. Fehlt der Datensatz, liefert die Ability HTTP 409 mit wpagent_gs_no_post und mutiert nichts. Initialisiere Global Styles einmal manuell im WordPress-Editor, lies danach get-global-styles erneut und verwende den neuen state_hash.

Beispiel: { "expected_hash": "<SHA-256 aus get-global-styles>", "colors": [{ "slug": "brand-primary", "color": "#6d45f9", "name": "Primär" }], "replace": false }

Native Global-Style-Varianten

Die drei folgenden Abilities bilden die Stilvarianten des WordPress-Site-Editors ab. Dazu gehört eine native Standardauswahl zum Zurücksetzen sowie jede vollständige, Farb- und Typografievariante des aktiven Themes. Varianten-IDs sind an Theme, Umfang, Position und exakten Inhalt gebunden. Ein Theme-Wechsel oder eine veränderte Variantendatei macht eine ältere ID bewusst ungültig.

Alle drei benötigen edit_theme_options. Der Schreibpfad ist destruktiv und idempotent. Vollständige Varianten ersetzen vorhandene Nutzer-Einstellungen und normale Styles. Freies Root- und Block-CSS bleibt nach den Regeln des Site-Editors erhalten. Farbvarianten ersetzen nur Farbgruppen. Typografievarianten ersetzen Typografie- und Abstandsgruppen. Der resultierende Datensatz ist auf 512 KiB begrenzt. Eine Abweichung des eigenen Writes wird bytegenau zurückgerollt. Ändert ein externer Writer den bereits verifizierten Zustand danach erneut, bleibt seine Fassung erhalten und die Ability meldet HTTP 409.

Die Lese- und Exportpfade für Stilvarianten legen keinen fehlenden Datensatz an. Das gilt auch für wp-agent/export-spectra-one-design-snapshot, wp-agent/export-spectra-one-portable-snapshot und wp-agent/preflight-spectra-one-portable-snapshot, wenn der Global-Styles-Teil ausgewertet wird. In diesen Fällen antwortet der Pfad mit HTTP 409 und wpagent_gs_no_post. Initialisiere den Datensatz zuerst im WordPress-Editor und starte danach den Leseaufruf oder Preflight erneut.

Spectra One 1.2.3 ist über diese nativen WordPress-Pfade praktisch geprüft. Der Test bestätigt den Katalog mit neun Stilentscheidungen, einen verifizierten Global-Styles-Farb-Write und die exakte Wiederherstellung des Ausgangszustands.

wp-agent/write-theme-file

Zweck: Schreibt eine Datei ausschließlich in das aktive (Child-)Theme-Verzeichnis. Erlaubt sind nur die Endungen .html, .json und .css. Pfad-Traversal wird sowohl lexikalisch (kein ..-Segment, kein absoluter Pfad) als auch per realpath-Prüfung gegen das Theme-Verzeichnis verhindert; Symlinks als Ziel werden abgelehnt.

Capability: edit_themes (Dateisystem-nahe, privilegierte Aktion, die ein Editor standardmäßig nicht besitzt).

Merkmale: schreibend, nicht destruktiv, idempotent (Überschreiben derselben Datei ist wiederholbar).

Beispiel: { "rel_path": "patterns/hero.html", "contents": "<!-- wp:heading --><h2>Hallo</h2><!-- /wp:heading -->" }

Site-Editor-Templates, Template-Teile und Blocknavigationen

Diese 15 Abilities verwalten die drei nativen Datenflächen des WordPress Site Editors. Alle verlangen edit_theme_options und sind deshalb standardmäßig Administratorfunktionen. Template-Schreibpfade verweigern klassische Themes. Rohes Block-Markup ist kein Eingabefeld. Stattdessen serialisiert der Server höchstens 50 strukturierte Core-Komponenten. Erlaubt sind Markdown, Template-Teil, Blockmuster, Website-Logo und -Titel, Blocknavigation, Beitragstitel, Beitragsbild, Inhalt, Auszug, Datum, Autor, Begriffe, Abfrageüberschrift, Abfrage-Loop, Trennlinie und Abstandshalter.

Spectra One 1.2.3 ist als reales Block-Theme mit einem vollständigen Anlage-, Lese- und Löschzyklus für ein Template-Teil praktisch geprüft. Die Kompatibilitätsmatrix meldet deshalb den nativen Speicherpfad wp_global_styles+site-editor nur für das aktive Theme als installiert.

Der Schreibpfad lehnt freie HTML-, Shortcode-, Freeform-, nicht registrierte und fremde Blöcke rekursiv ab. Registrierte und damit ausführbare Shortcodes werden auch innerhalb erlaubter Core-Blöcke gesperrt. Referenzierte Template-Teile, Blocknavigationen, Blockmuster und synchronisierte Core-Blöcke werden ebenfalls rekursiv geprüft. Dabei zählt nicht nur der gespeicherte Rohinhalt. Die Prüfung erfasst auch Blöcke, die WordPress über Block Hooks zur Laufzeit ergänzt. Zyklische Referenzen zwischen diesen Datenflächen werden blockiert. Inhalt ist auf 1 MiB begrenzt. Änderungen verwenden einen SHA-256-Zustands-Hash, eine atomare Ressourcensperre, vollständigen Read-back und einen exakten Rollback einschließlich Zeitstempeln. Erstellung, Aktualisierung und Löschung derselben Ressource teilen sich denselben Sperrschlüssel. Theme- und Plugin-Vorlagen werden nur mit confirm_theme_override=true überschrieben. Löschen erfolgt zunächst reversibel, wird nachgeprüft und entfernt danach nur die Datenbankversion. Eine darunterliegende Theme- oder Plugin-Vorlage bleibt erhalten. Noch verwendete Template-Teile und Navigationen benötigen zusätzlich confirm_references=true.

Template-Ressourcen enthalten id, wp_id, theme, slug, type, source, origin, title, description, status, content, area, has_theme_file, is_custom, modified, den tiefen Blockbericht und hash. Navigationsressourcen enthalten id, slug, title, status, content, modified, item_count, den tiefen Blockbericht und hash. Bei einer query-loop-Komponente gelten per_page, post_type, order und order_by standardmäßig als explizite Abfrage. Nur inherit_query=true übernimmt bewusst die Abfrage des aktuellen Archivkontexts.

---

12. Verifikation und Infrastruktur

wp-agent/render-check

Zweck: Parst den Beitragsinhalt, zählt Blöcke, flaggt core/freeform (den stillen Classic-Editor-Fallback) und rendert das Server-HTML (do_blocks()) zur Kontrolle.

Capability: edit_posts (grob) plus current_user_can('edit_post', $post_id).

Merkmale: lesend, nicht destruktiv, idempotent.

Beispiel: { "post_id": 42 }

wp-agent/refresh-hooks

Zweck: Holt Admin-/Save-only-Nacharbeiten nach, die beim Schreiben über REST/Abilities statt über den Editor sonst ausbleiben: (1) flush_rewrite_rules(false), (2) clean_post_cache() für die zuletzt geänderten Beiträge (oder eine explizite post_ids-Liste), (3) bei aktivem Rank Math zusätzlich Invalidierung des Sitemap-Caches (Cache::invalidate_storage(), Fallback Cache_Watcher::clear(), sonst dokumentierter WP-CLI-Fallback wp rankmath sitemap generate).

Capability: edit_posts.

Merkmale: schreibend, nicht destruktiv, idempotent.

Beispiel: { "limit": 5 }

wp-agent/disable-power

Zweck: Panik-Schalter, der bewusst im verifizierten Kern-Plugin lebt (nicht in wp-agent-power selbst), damit der Kern den Roh-Zugriffs-/Entwicklermodus (wp-agent-power, inklusive exec-php und aller anderen Power-Abilities) auch dann abschalten kann, wenn dieses Plugin sich fehlverhält. Deaktiviert wp-agent-power sofort per deactivate_plugins(), sofern installiert.

Capability: activate_plugins.

Merkmale: schreibend, nicht destruktiv (jederzeit über wp-agent/activate-plugin umkehrbar), idempotent.

Keine Input-Parameter.

Beispiel: {}

---

wp-agent/create-browser-link

Zweck: Erzeugt für den aktuell authentifizierten, sicheren Nicht-Administrator mit Inhaltsrechten einen einmal verwendbaren Link zu Dashboard, Beiträgen, Seiten oder Mediathek. Der zufällige Token ist 256 Bit stark, wird nur als SHA-256-Hash gespeichert, läuft nach 120 Sekunden ab und erfordert außerhalb lokaler Entwicklungsumgebungen HTTPS. Der Token steht nicht in der URL. Das Browserwerkzeug muss ihn beim Aufruf als Header X-WPAgent-Browser-Token senden, damit er nicht in Zugriffslogs, Referrern oder der Browserchronik landet.

Capability: edit_posts, aber weder manage_options noch Super-Administratorstatus. Damit gelten dieselben Grenzen wie bei den geführten Verbindungsnutzern. Der Link erweitert keine WordPress-Rechte.

Merkmale: schreibend, nicht destruktiv, nicht idempotent.

Input: optional destination (dashboard, posts, pages, media). Output: url, headers, expires_at, user_id, destination, one_time. headers muss unverändert und ausschließlich für diesen einmaligen Aufruf verwendet werden.

wp-agent/revoke-browser-link

Zweck: Widerruft den noch offenen Backend-Einmal-Link des aktuell authentifizierten sicheren Nicht-Administrators.

Capability: wie create-browser-link.

Merkmale: schreibend, nicht destruktiv, idempotent. Output: revoked.

---

13. Page-Builder, ACF, WooCommerce und Formulare

Native WPForms-Abilities

WPForms stellt seine eigenen Abilities bereit. WPAgently implementiert ihre Formlogik nicht doppelt, sondern übernimmt nur aktuell registrierte und von WPForms mit meta.mcp.public: true veröffentlichte Werkzeuge in den eigenen MCP-Server. Das Kontrollzentrum trennt Formular-Lesen (list-forms, get-form, get-form-stats), sensible Einträge (get-entry-summaries, get-entry, search-entries) und den zusammen mit describe-editing-schema veröffentlichten Schreibpfad (create-form, add-field, update-field, update-form-settings). Unbekannte spätere WPForms-Abilities bleiben einzeln steuerbar, sofern WPForms sie ebenfalls ausdrücklich für MCP veröffentlicht.

WPForms Lite erlaubt diese Pfade standardmäßig nur Administratoren. Die Verbindungsseite kann stattdessen die drei WPAgently-eigenen Capabilities wpagently_wpforms_forms_access, wpagently_wpforms_entries_access und wpagently_wpforms_write_access gezielt an einen sicheren Redakteur vergeben. Der offizielle Filter wpforms_current_user_can akzeptiert damit ausschließlich am exakten WPAgently-MCP-Endpunkt die dokumentierten Lese-, Eintrags- und Schreibprüfungen. Normale WPForms-Admin-, AJAX- und fremde REST-Pfade sowie unbekannte Rechte wie Löschen bleiben abgelehnt. Der native WPForms-Schreibschalter bleibt zusätzlich zwingend. IP-Adressen in nativen Eintragsantworten werden für diesen Agent-Nutzer über den offiziellen Maskierungsfilter verborgen. Beim Widerruf und bei der Deinstallation entfernt WPAgently nur selbst protokollierte Ergänzungen. Auch nach einer WPForms-Deaktivierung bleiben protokollierte Rechte auf der Verbindungsseite widerrufbar.

wp-agent/get-wpforms-delivery

Zweck: Liest die vorhandenen WPForms-Bestätigungen und kompakte E-Mail-Benachrichtigungen über den nativen Formular-Handler. Standardmäßig erscheinen bei Benachrichtigungen nur ID, Name, Betreff und ein vollständiger Einzelhash. include_notification_details: true ergänzt Empfänger, Absender, Antwortadresse, Kopien und Nachricht. Unbekannte Add-on-Daten fließen in die Konfliktprüfung ein, werden aber nie ausgegeben. state_hash bindet einen späteren Write an den vollständigen rohen Formularinhalt.

Capability: wpagently_wpforms_write_access am WPAgently-MCP-Endpunkt sowie die native objektbezogene WPForms-Prüfung edit_form_single. Merkmale: lesend, nicht destruktiv, idempotent. Pflicht: form_id. Optional: include_notification_details, standardmäßig false.

wp-agent/update-wpforms-confirmation

Zweck: Prüft eine geplante manuelle Änderung einer vorhandenen WPForms-Bestätigung gegen die begrenzten sicheren Werte. Die Ability ändert keine Bestätigung und antwortet vor jeder Mutation mit HTTP 409 und manual_only. Die Änderung erfolgt im WPForms-Backend.

Capability: wie get-wpforms-delivery. Merkmale: manual-only, keine Remote-Mutation. Pflicht: form_id, confirmation_id, expected_hash, confirmation.

wp-agent/create-wpforms-confirmation

Zweck: Erstellt die erste wirksame Bestätigung oder unter WPForms Pro eine zusätzliche Bestätigung mit der nächsten sicheren numerischen ID. Name und Typ sind Pflicht. Nachrichten, Seitenziele und Weiterleitungen verwenden dieselben Grenzen wie der Update-Pfad. WPForms Lite lehnt eine zweite Regel ab, weil ohne Pro-Bedingungslogik keine sichere Mehrfachauswahl besteht. Mehrere Regeln unter WPForms Pro sind ohne legalen Praxis-Fixture noch nicht empirisch bestätigt.

Capability: wie get-wpforms-delivery. Merkmale: schreibend, nicht destruktiv, nicht idempotent. Pflicht: form_id, expected_hash, confirmation.

wp-agent/delete-wpforms-confirmation

Zweck: Prüft die Eingabe für das manuelle Löschen einer zusätzlichen WPForms-Bestätigung. Die Ability löscht keine Bestätigung und antwortet vor jeder Mutation mit HTTP 409 und manual_only. Die letzte Bestätigung bleibt unverändert.

Capability: wie get-wpforms-delivery. Merkmale: manual-only, keine Remote-Mutation. Pflicht: form_id, confirmation_id, confirm_confirmation_id, expected_hash.

wp-agent/update-wpforms-notification

Zweck: Prüft eine geplante manuelle Änderung einer WPForms-E-Mail-Benachrichtigung gegen die begrenzten sicheren Werte. Die Ability ändert weder Benachrichtigung noch globalen Versand-Schalter und antwortet vor jeder Mutation mit HTTP 409 und manual_only. Die Änderung erfolgt im WPForms-Backend.

Capability: wie get-wpforms-delivery. Merkmale: manual-only, keine Remote-Mutation. Pflicht: form_id, notification_id, expected_hash. Mindestens notification oder notifications_enabled muss übergeben werden.

wp-agent/create-wpforms-notification

Zweck: Erstellt die erste wirksame E-Mail-Benachrichtigung oder unter WPForms Pro eine weitere mit der nächsten sicheren numerischen ID. Name, Empfänger, Betreff, Absendername, Absenderadresse und Nachricht sind Pflicht. notifications_enabled kann den globalen Versand ausdrücklich setzen. WPForms Lite lehnt eine zweite Regel ab, weil seine Laufzeit nur die erste Benachrichtigung sendet. Mehrere Regeln unter WPForms Pro sind ohne legalen Praxis-Fixture noch nicht empirisch bestätigt.

Capability: wie get-wpforms-delivery. Merkmale: schreibend, nicht destruktiv, nicht idempotent. Pflicht: form_id, expected_hash, notification. Optional: notifications_enabled.

wp-agent/delete-wpforms-notification

Zweck: Prüft die Eingabe für das manuelle Löschen einer WPForms-E-Mail-Benachrichtigung. Die Ability löscht keine Benachrichtigung, ändert keinen globalen Versand-Schalter und antwortet vor jeder Mutation mit HTTP 409 und manual_only.

Capability: wie get-wpforms-delivery. Merkmale: manual-only, keine Remote-Mutation. Pflicht: form_id, notification_id, confirm_notification_id, expected_hash.

Native Ninja-Forms-Abilities

Ninja Forms 3.14.10 registriert 32 Abilities und veröffentlicht davon 29 für MCP. WPAgently übernimmt nicht ungeprüft das breite Provider-Recht nf_edit_forms. Stattdessen werden 24 bekannte, öffentliche Werkzeuge in vier getrennte Gruppen eingeordnet:

Das breite Recht wird ausschließlich während eines passenden Aufrufs am exakten WPAgently-MCP-Endpunkt vermittelt. Es wird nie im Nutzerkonto gespeichert. Ein JSON-RPC-Batch erhält das Recht nur, wenn sämtliche enthaltenen Ninja-Forms-Werkzeuge bekannt und über ihre jeweilige Gruppe erlaubt sind. Gemischte Tool-Batches und Batches mit mehr als 100 Nachrichten werden abgewiesen. Ein Nutzer mit einem bereits dauerhaft vorhandenen nf_edit_forms gilt nicht als sicherer Agent-Nutzer. Beim Widerruf und bei der Deinstallation entfernt WPAgently nur die vier selbst protokollierten Gruppenrechte.

Die acht Abilities ninjaforms/delete-action, ninjaforms/delete-calculation, ninjaforms/delete-form, ninjaforms/delete-submission, ninjaforms/get-plugin-settings, ninjaforms/remove-field, ninjaforms/update-plugin-settings und ninjaforms/update-submission bleiben in Quarantäne. Die Gründe sind fehlende technische Bestätigung, dauerhafte Löschungen, globale Nebenwirkungen und mögliche Geheimnisse in Plugin-Einstellungen. ninjaforms/process-submission kann echte E-Mails versenden. Es ist deshalb eine eigene, doppelt freizuschaltende Gruppe und darf nur nach einem ausdrücklichen Auftrag verwendet werden. Einreichungen können personenbezogene Daten enthalten und werden nie zusammen mit dem reinen Formularrecht freigeschaltet.

wp-agent/detect-builder

Zweck: Erkennt pro Beitrag, mit welchem Page-Builder/Format sein Inhalt tatsächlich gespeichert ist (nicht nur, welche Builder-Plugins aktiv sind). Prüft drei Speicher-Familien introspektiv (nie nur angenommen): JSON in Postmeta (Elementor, Bricks, Beaver Builder, Breakdance, Oxygen), Gutenberg-Block-Kommentare in post_content (Core, Kadence, Spectra, GenerateBlocks) und Shortcodes (WPBakery, [vc_*]). Kaskade bei mehreren Postmeta-Signalen: Bricks vor Beaver Builder vor Oxygen vor Breakdance vor Elementor. ACF ist immer additiv, außer der Beitrag ist selbst eine ACF-Feldgruppe.

Capability: edit_posts (grob) plus current_user_can('edit_post', $post_id).

Merkmale: lesend, nicht destruktiv, idempotent.

Beispiel: { "post_id": 42 }

wp-agent/list-block-types

Zweck: Listet die auf der Website tatsächlich registrierten Blocktypen der Namespaces Core, Kadence, GenerateBlocks und Spectra. Suche, Namespace-Filter und Pagination sind begrenzt. Die Ausgabe enthält Name, Namespace, Titel, Kategorie, API-Version, Dynamik und Attributzahl, aber keine Callbacks oder lokalen Quellpfade.

Capability: edit_posts.

Merkmale: lesend, nicht destruktiv, idempotent. Optional sind search, namespace mit all, core, kadence, generateblocks oder uagb, page und per_page bis 500.

wp-agent/get-block-type

Zweck: Liest einen einzelnen registrierten Blocktyp einschließlich bereinigter Attribute, Supports, Eltern- und Vorfahrenregeln. Schlüssel, die auf Passwörter, Tokens, API-Schlüssel, Cookies oder andere Geheimnisse hinweisen, sowie nicht JSON-kompatible Laufzeitwerte werden entfernt. Die dynamischen Felder attributes und supports sind jeweils der geschlossene, versionierte Umschlag {format,json,sha256,bytes} aus dem vorstehenden Abschnitt, keine offenen Objekte.

Capability: edit_posts.

Merkmale: lesend, nicht destruktiv, idempotent. Pflicht ist name im Format namespace/block aus einem der vier freigegebenen Namespaces.

wp-agent/get-native-block-document

Zweck: Liest den vollständigen gespeicherten post_content eines berechtigten Beitrags zusammen mit Status, Änderung, rekursiver Blockzahl, Freeform-Zahl, Blocktypen, erkanntem Builder und einem stabilen Inhalts-Hash. Dadurch kann ein Agent reale Dokumentstrukturen analysieren, ohne aus Plugin-Dokumentation zu raten.

Capability: edit_posts (grob) plus current_user_can('edit_post', $post_id).

Merkmale: lesend, nicht destruktiv, idempotent. Pflicht ist post_id. Es gibt absichtlich keine Ability, die serialisiertes Block-Markup zurückschreibt. Core-Inhalte werden nur über die vorhandenen Markdown- oder deklarativen Serverpfade erzeugt. Kadence- und GenerateBlocks-Blöcke bleiben außerhalb ihrer jeweils engen Attributpfade fail-closed. Statische Spectra-Blöcke bleiben ebenfalls geschlossen, mit genau zwei versionsgebundenen Abilities für die drei responsiven Ausrichtungsattribute sowie die klassischen headingColor- und subHeadingColor-Werte eines uagb/advanced-heading unter Spectra 2.20.1. Für die serverseitig registrierte dynamische Spectra-Teilmenge gibt es den folgenden begrenzten Attributpfad.

wp-agent/get-spectra-blocks-separator

Zweck: Liest genau einen separat registrierten spectra/separator an einem expliziten rekursiven Blockpfad. Der Vertrag gilt ausschließlich für Spectra Blocks 1.0.4 mit serverseitigem Render-Callback und vollständig passendem Attributschema. Er gibt nur Stil, Ausrichtung, Breite, Höhe und Farbe zurück. Rohes Markup, freie CSS-Werte, innere Blöcke, weitere responsive Werte und abweichende Providerattribute bleiben geschlossen.

Capability: edit_posts (grob) plus current_user_can('edit_post', $post_id).

Merkmale: lesend, nicht destruktiv, idempotent. Pflicht sind post_id und path mit 1 bis 32 nicht negativen Indizes. Das Dokument muss kleiner als 1 MiB sein und sich stabil mit WordPress parse- und serialisieren lassen.

Beispiel: { "post_id": 42, "path": [0, 1] }

wp-agent/update-spectra-blocks-separator

Zweck: Ändert an diesem exakt geprüften Spectra-Blocks-Separator ausschließlich Stil, Ausrichtung, Breite, Höhe und Farbe. Stil ist auf acht Providerwerte begrenzt, Ausrichtung auf left, center oder right, Breite auf 1-100 % oder 1-2.000 px, Höhe auf 1-400 px und Farbe auf sechsstellige Hex-Werte. Die Aktion aktualisiert keine Texte, kein Roh-Markup und keine anderen Providerattribute.

Capability: edit_posts (grob) plus current_user_can('edit_post', $post_id).

Merkmale: schreibend, nicht destruktiv, nicht idempotent. Pflicht sind post_id, path, mindestens ein erlaubter settings-Wert und der aktuelle expected_hash. Der Pfad prüft Spectra Blocks 1.0.4, kanonische Dokumentstruktur und Provider-Markup, sperrt den Beitrag exklusiv, legt eine Revision an, schreibt mit bytegenauem CAS, rendert und liest das Ergebnis erneut. Bei unsicherem Read-back versucht er den vorherigen Zustand wiederherzustellen und meldet sonst recovery_required; eine fremde Änderung wird nicht überschrieben.

Beispiel: { "post_id": 42, "path": [0, 1], "settings": { "separator_color": "#1a73e8" }, "expected_hash": "<64-stelliger SHA-256 aus get-spectra-blocks-separator>" }

wp-agent/update-spectra-block-attributes

Zweck: Ändert an einem expliziten rekursiven Blockpfad ausschließlich schema-bekannte Attribute eines sichtbaren dynamischen Spectra-Blocks. Der Zielblock muss sowohl in Spectras sichtbarer Registry als auch mit einem aufrufbaren Render-Callback und Attributschema in WordPress registriert sein. Erlaubt sind begrenzte boolesche, numerische und reine Textwerte sowie ausschließlich skalar typisierte begrenzte Arrays. Objekte, interne IDs, Metadaten, Locks, Klassennamen, Core-Styles, Roh-HTML, Blockkommentare, aktive Skript- und HTML-Daten-URIs, freie CSS-Deklarationen, unbekannte Attribute und nur in JavaScript registrierte statische Spectra-Blöcke werden abgelehnt.

Capability: edit_posts (grob) plus current_user_can('edit_post', $post_id).

Merkmale: schreibend, nicht destruktiv, nicht idempotent. Pflicht sind post_id, path mit 1-32 Indizes und expected_hash. Optional setzt attributes als geschlossener nativer Block-Umschlag {format,json,sha256,bytes} höchstens 50 Werte und remove_attributes setzt höchstens 50 registrierte Werte auf den Providerstandard zurück. Ein erfolgreicher Write verbraucht den erwarteten Dokumenthash, deshalb wäre eine automatische Wiederholung derselben Anfrage nicht sicher. Der Pfad sperrt den Beitrag, prüft den vollständigen Dokumenthash, begrenzt Patch und Dokumentgröße, legt eine verifizierte Revision an, serialisiert mit WordPress, prüft unveränderte Blockstruktur, rendert serverseitig, liest Inhalt und Attribute exakt zurück und invalidiert Spectras Beitrags- und Asset-Cache. Nach Mutationsbeginn stellt er den vorherigen Inhalt nur wieder her, wenn der exakt erwartete eigene Kandidat noch gespeichert ist und die Rückstellung verifiziert werden kann. Bei Fremdänderung, Berechtigungs- oder Lockverlust bewahrt er den aktuellen Zustand und meldet recovery_required; die angelegte Revision ist dann der manuelle Prüfweg. Die Ausgabe enthält Zielblock, Pfad, tatsächlich angeforderte Änderungen, Revisions-ID, Renderlänge sowie vorherigen und neuen Hash.

wp-agent/update-spectra-static-heading-alignment

Zweck: Ändert ausschließlich headingAlign, headingAlignTablet oder headingAlignMobile eines statischen uagb/advanced-heading an einem expliziten Blockpfad. Dieser Vertrag gilt ausschließlich für Spectra 2.20.1. Er akzeptiert nur left, center oder right; Markup, Text, block_id und jedes weitere Attribut bleiben unverändert. Jede andere Spectra-Version, ein dynamisch registrierter Zielblock oder ein abweichender Providervertrag endet vor der Mutation geschlossen.

Capability: edit_posts (grob) plus current_user_can('edit_post', $post_id).

Merkmale: schreibend, nicht destruktiv, nicht idempotent. Pflicht sind post_id, path, alignment und expected_hash. Das optionale viewport ist auf desktop, tablet oder mobile begrenzt und verwendet ohne Angabe weiterhin desktop. Der Pfad prüft eine kanonisch parse- und serialisierbare Dokumentstruktur, sperrt den Beitrag, verlängert und bestätigt die Sperre vor und nach den Mutationen, legt eine Revision an, prüft Struktur und statisches Ziel-Markup, aktualisiert Spectras Cache und liest gespeicherten Zustand sowie Ziel-Markup erneut. Scheitert eine Prüfung nach dem Start oder geht die Sperre verloren, endet die Aktion mit recovery_required. Bei Lockverlust erfolgt keine automatische Gegenmutation; der aktuelle Zustand und die Revision müssen manuell geprüft werden.

wp-agent/update-spectra-static-heading-colors

Zweck: Ändert ausschließlich headingColor, subHeadingColor und optional separatorColor eines statischen uagb/advanced-heading an einem expliziten Blockpfad. Der Vertrag gilt ausschließlich für Spectra 2.20.1 und den klassischen Farbmodus. Jeder übergebene Wert muss eine sechsstellige Hex-Farbe oder inherit sein. inherit schreibt den nativen leeren Providerwert. separatorColor wird nur angenommen, wenn genau eine vorhandene Trennlinie mit einem freigegebenen Providerstil und dem exakten statischen Wrapper nachgewiesen ist. Gradients, CSS-Variablen, freie CSS-Syntax, Markup, Texte, block_id und alle anderen Attribute bleiben gesperrt.

Capability: edit_posts (grob) plus current_user_can('edit_post', $post_id).

Merkmale: schreibend, nicht destruktiv, nicht idempotent. Pflicht sind post_id, path, heading_color, description_color und expected_hash; separator_color ist optional. Ausrichtungs- und Farbpfad teilen denselben exklusiven Dokument-Lock. Der Pfad verlangt ein kanonisches Blockdokument und den exakt geprüften statischen Provider-Wrapper, legt vor dem bytegenauen CAS eine Revision an, bestätigt den Lock vor und nach jeder wirksamen Phase, aktualisiert Spectras Cache und liest Inhalt, Attribute und Ziel-Markup erneut. Der reale E2E bindet alle drei Farben an die exakten, von Spectra 2.20.1 erzeugten Zielselektoren und lehnt eine Separatorfarbe ohne Provider-Wrapper ab. Lockverlust oder ein unsicherer Read-back nach Mutationsbeginn liefert recovery_required ohne automatische Gegenmutation.

wp-agent/update-generateblocks-block-attributes

Zweck: Ändert ausschließlich fünf versionsgebundene GenerateBlocks-Attribute. generateblocks/query-page-numbers.midSize akzeptiert eine ganze Zahl von 0 bis 10. generateblocks/query.paginationType akzeptiert nur standard oder instant. Zusätzlich darf tagName beim Query-Wrapper nur div, section, article, aside, header, footer, nav oder main, bei Page Numbers nur div, section oder nav und bei einem kanonischen Nur-Text-Block nur p, span, div oder h1 bis h6 sein. Interaktive Tags und vorhandenes Inline-Markup bleiben gesperrt. Der Server ersetzt dabei ausschließlich das zuvor exakt bestätigte kanonische Provider-Markup und hält Kommentarattribute, innerHTML und innerContent gemeinsam konsistent. Block, Attribut und Typ müssen zusätzlich im live registrierten WordPress-Schema vorhanden sein. Freies Markup, andere Attribute, Blocktypen und CSS-Funktionen bleiben gesperrt.

Capability: edit_posts (grob) plus current_user_can('edit_post', $post_id).

Merkmale: schreibend, nicht destruktiv, nicht idempotent. Pflicht sind post_id, path und expected_hash; mindestens ein freigegebenes Attribut wird im geschlossenen nativen Block-Umschlag {format,json,sha256,bytes} geschrieben oder entfernt. Der Pfad verwendet Kurzzeit-Lock, verifizierte Revision, bytegenauen Datenbank-CAS, eine exakte Provider-Strukturprüfung, GenerateBlocks-Cache-Invalidierung, einen auf verifizierte Query-Vorfahren und das Ziel reduzierten Frontend-Render sowie exakten Read-back. Nur bei einem freigegebenen tagName wird der kanonische Wrapper gemeinsam mit dem Attribut umgestellt. Eine fremde Paralleländerung bleibt erhalten und führt zu recovery_required.

wp-agent/update-kadence-block-attributes

Zweck: Ändert ausschließlich 41 eng freigegebene Attribute vorhandener kadence/advancedheading-, kadence/spacer- oder kadence/progress-bar-Blöcke. Bei Advanced Heading bleiben level, drei responsive Ausrichtungen, Texttransformation, Schriftstil, Schriftgewicht, drei responsive Pixel-Schriftgrößen von 8 bis 200, drei responsive Pixel-Zeilenhöhen von 8 bis 300, drei responsive Pixel-Buchstabenabstände von -10 bis 50, vier Pixel-Außenabstände von -500 bis 500 sowie klassische sechsstellige Text- und Hintergrundfarben erlaubt. Bei einem vorhandenen, sicher geformten Provider-Icon kommen Icon- und Hover-Iconfarbe, Iconseite und vertikale Iconausrichtung hinzu. Die Außenabstände verwenden ausschließlich die Einheit px. Beim kanonischen Spacer sind nur eine positive Desktop-, Tablet- und Mobilhöhe von 1 bis 2.000 sowie die Einheit px, rem oder vh erlaubt. Die Desktop-Höhe bleibt verpflichtend, responsive Overrides dürfen entfernt werden. Die einfache Progress Bar muss den nativen Typ line verwenden, darf keine Labels, Masken, Links, freien Texte oder inneren Blöcke enthalten und akzeptiert nur Fortschrittswert, Maximalwert, drei Strichbreiten von 1 bis 20 sowie zwei sechsstellige Farben. Der Fortschrittswert darf den Maximalwert nicht überschreiten. Block, Attribut und Typ müssen zusätzlich im live registrierten WordPress-Schema vorhanden sein. Abweichendes Markup, andere Attribute und freie CSS-Funktionen bleiben gesperrt.

Capability: edit_posts (grob) plus current_user_can('edit_post', $post_id).

Merkmale: schreibend, nicht destruktiv, nicht idempotent. Pflicht sind post_id, path und expected_hash; mindestens ein freigegebenes Attribut wird im geschlossenen nativen Block-Umschlag {format,json,sha256,bytes} geschrieben oder entfernt. Der Pfad erneuert seinen Kurzzeit-Lock vor und nach kritischen Schritten, verwendet eine verifizierte Revision, bytegenauen Datenbank-CAS, Strukturprüfung, Frontend-Render einschließlich CSS-Nachweis und exakten Read-back. Kadence Blocks 3.7.8 aktualisiert die Ausgabe beim Rendern selbst. Konflikte und fremde Paralleländerungen werden nicht überschrieben. Geht der Lock nach begonnenem Write verloren, bleibt die Mutation zur manuellen Prüfung erhalten und der Pfad meldet recovery_required ohne automatischen Rollback.

wp-agent/get-acf-fields

Zweck: Liest die einem Beitrag, Benutzer, Begriff, Kommentar oder ACF-Optionsspeicher zugeordneten Felder über die offiziellen ACF-APIs (acf_get_field_groups(), acf_get_fields() und get_field()), nie über rohe Metadaten. Liefert den portablen unformatierten Wert, den echten field_-Key, den kanonischen ACF-Objektbezeichner und einen SHA-256-Hash über Ziel, Wert, Nebenwirkungen und wirksame Felddefinition. Nicht lesbare Beitrags-, Medien- und Benutzerreferenzen werden nicht ausgegeben.

Capability: Dynamisch passend zum Ziel. Verlangt edit_post, edit_user, edit_term, edit_comment oder für den generischen Optionsspeicher manage_options. Eine registrierte ACF-Optionsseite verwendet ihre konfigurierte Capability. Benutzerfelder brauchen zusätzlich list_users. Das Ausgabeattribut writable bleibt für alle Felder false, weil kein ACF-Feldwert remote geändert wird. Die Berechtigung, Begriffe der konfigurierten Taxonomie zuzuweisen, ist nur Feld- und Berechtigungsmetadaten für eine manuelle Änderung im WordPress-Backend und hebt die manual_only-Grenze von update-acf-field nicht auf. Erfordert Advanced Custom Fields, sonst folgt HTTP 409.

Merkmale: lesend, nicht destruktiv, idempotent.

Beispiele: { "post_id": 42 } oder { "object_type": "term", "object_id": 9 }. post_id und der explizite Objektvertrag dürfen nur zusammen vorkommen, wenn beide exakt denselben Beitrag bezeichnen.

wp-agent/update-acf-field

Zweck: Leitet eine gewünschte Änderung eines zugeordneten ACF-Felds eines Beitrags, Benutzers, Begriffs, Kommentars oder Optionsspeichers auf den manuellen Weg in Advanced Custom Fields oder der passenden WordPress-Verwaltung weiter. Die Ability ruft update_field() nicht auf und antwortet vor jeder Mutation mit HTTP 409 und manual_only. Den Wert anschließend manuell ändern und erneut lesen.

Das REST- und MCP-Schema prüft nur die strukturelle Eingabehülle. Dazu gehören erlaubte Schlüssel, grundlegende Typen, Muster- und Größenbegrenzungen sowie der begrenzte JSON-Wertumschlag. Es liest keine ACF-Felddefinition und führt keine fachliche ACF- oder Provider-Wertprüfung durch. Der manual-only-Callback liest keinen ACF-Wert und keine Taxonomie-Zuweisung, nimmt keine Sperre und führt weder Read-back noch Rollback aus. Alle ACF-Feldtypen, Werte und verschachtelten Strukturen bleiben remote schreibgeschützt.

Capability: Dynamisch wie bei get-acf-fields. Referenzen verlangen die jeweils oben beschriebenen zusätzlichen Leserechte oder Zuweisungsrechte. Ein uploadedTo-Medienfeld bleibt außerhalb eines Beitrags schreibgeschützt. Taxonomiefelder mit load_terms oder save_terms bleiben im Optionsspeicher schreibgeschützt. Erfordert Advanced Custom Fields.

Merkmale: manual-only, keine Remote-Mutation.

Remote-Aufruf: Nicht verfügbar. Der Callback antwortet nach der REST- und MCP-Schema-Prüfung mit HTTP 409 und manual_only, ohne ACF-Zustand oder Felddefinition zu lesen. Den Feldwert in Advanced Custom Fields oder der passenden WordPress-Verwaltung ändern und anschließend erneut lesen.

Gemeinsamer Vertrag für persistente ACF-Feldgruppen

Die folgenden sechs Abilities verwalten ausschließlich in der Datenbank gespeicherte ACF-Feldgruppen. In PHP oder Local JSON registrierte Gruppen werden weder als veränderbar aufgelistet noch über einen bekannten Key geöffnet. Alle sechs Pfade verlangen manage_options und damit regulär einen Administrator. Sie verwenden die nativen ACF-APIs, nie direkte Änderungen an wp_posts oder wp_postmeta.

Der portable Schreibpfad unterstützt höchstens 100 Felder pro Gruppe und 200 Auswahlwerte pro Feld. Er akzeptiert die Typen text, textarea, number, range, email, url, true_false, select, checkbox, radio und button_group. Location-Regeln müssen aus einfachen exakten post_type == ...-Regeln bestehen. Komplexe Regeln, bedingte Logik, andere Feldtypen und abgeschnittene Definitionen werden lesend als portable: false markiert und bei Update oder Duplizierung vollständig abgelehnt.

Jede Ausgabe enthält einen SHA-256-Hash über die vollständige rohe Gruppen- und Felddefinition ohne flüchtige Datenbank-IDs. wp-agent/update-acf-field-group und wp-agent/delete-acf-field-group sind manual-only: Sie ändern oder löschen keine Gruppe und antworten vor jeder Mutation mit HTTP 409 und manual_only. Die Änderung erfolgt in Advanced Custom Fields, danach wird die Gruppe erneut gelesen. Die übrigen hier beschriebenen Lese-, Erstell- und Duplizierungspfade behalten ihren jeweiligen eigenen Vertrag.

wp-agent/list-acf-field-groups

Zweck: Listet persistente Feldgruppen alphabetisch mit Suche und Pagination. Jede Gruppe enthält Titel, Aktivstatus, einfache Inhaltstypen, begrenzte Felddefinitionen, Feldzahl, Portabilität, Zahl der Location-Regeln und Konflikt-Hash.

Merkmale: lesend, nicht destruktiv, idempotent.

wp-agent/get-acf-field-group

Zweck: Liest eine persistente Feldgruppe anhand ihres group_-Keys im selben vollständigen Ausgabeformat wie die Liste.

Merkmale: lesend, nicht destruktiv, idempotent.

wp-agent/create-acf-field-group

Zweck: Erstellt eine portable Feldgruppe mit neuen kryptografisch zufälligen group_- und field_-Keys. Nicht verifizierbare Teilanlagen werden entfernt.

Merkmale: schreibend, nicht destruktiv, nicht idempotent.

wp-agent/update-acf-field-group

Zweck: Prüft eine geplante manuelle Änderung von Titel, Aktivstatus, Inhaltstypen oder Feldliste einer portablen Gruppe. Die Ability ändert keine Gruppe, entfernt keine Felder und antwortet vor jeder Mutation mit HTTP 409 und manual_only. Die Änderung erfolgt in Advanced Custom Fields.

Merkmale: manual-only, keine Remote-Mutation.

Remote-Aufruf: Nicht verfügbar. Die Feldgruppe in Advanced Custom Fields ändern und danach erneut lesen.

wp-agent/duplicate-acf-field-group

Zweck: Kopiert eine portable persistente Gruppe mit neuen Gruppen- und Feld-Keys. Die Quellgruppe wird unter einer Änderungssperre erneut gelesen und muss dem expected_hash entsprechen.

Merkmale: schreibend, nicht destruktiv, nicht idempotent.

wp-agent/delete-acf-field-group

Zweck: Prüft die Eingabe für das manuelle dauerhafte Löschen einer persistenten Feldgruppe. Die Ability löscht weder Gruppe noch Felddefinitionen und antwortet vor jeder Mutation mit HTTP 409 und manual_only. Die Löschung erfolgt in Advanced Custom Fields.

Merkmale: manual-only, keine Remote-Mutation.

Remote-Aufruf: Nicht verfügbar. Die Feldgruppe in Advanced Custom Fields löschen und danach erneut lesen.

Gemeinsamer Vertrag für persistente ACF-Inhaltstypen und Taxonomien

Die folgenden zehn Abilities verwalten ausschließlich persistente ACF-Definitionen aus der Datenbank. Definitionen aus PHP oder Local JSON bleiben ausgeschlossen. Alle Pfade verlangen manage_options und Advanced Custom Fields 6.1 oder neuer. Schreiben erfolgt über die nativen ACF-APIs. Jeder neue oder geänderte Datensatz wird als vollständige Definition zurückgelesen und zusätzlich gegen die wirksame WordPress-Laufzeitregistrierung geprüft.

Der verlustfreie Pfad unterstützt gemeinsame Beschriftungen, Beschreibung, Aktivstatus, Sichtbarkeit, Hierarchie, REST- und KI-Freigabe sowie einen optionalen Rewrite-Slug. Inhaltstypen ergänzen eine begrenzte WordPress-Supportliste, registrierte Taxonomien und die Archivfreigabe. Taxonomien ergänzen 1-20 registrierte Objektarten und die Admin-Spalte. Der eigentliche Inhaltstyp- oder Taxonomie-Slug bleibt nach der Anlage unveränderlich. Weitere ACF-Einstellungen führen zu portable: false und sperren Updates.

Jede Ausgabe enthält content_count, portable, registration_conflict und einen SHA-256-Hash über die vollständige Definition. registration_conflict: true bedeutet, dass eine andere WordPress-Komponente denselben Laufzeit-Slug registriert hat. Eine solche Definition wird weder aktualisiert noch automatisch gelöscht. Erstellungen und Änderungen nutzen atomare, ablaufende Sperren. Updates verlangen den zuletzt gelesenen expected_hash; Abweichungen eines ACF-Hooks lösen einen Rollback aus.

Listen akzeptieren optional search, page und per_page (höchstens 50). Inhaltstyp-Schreibpfade akzeptieren zusätzlich description, active, public, hierarchical, show_ui, show_in_rest, allow_ai_access, ai_description, rewrite_slug, supports, taxonomies und has_archive. Taxonomie-Schreibpfade akzeptieren dieselben gemeinsamen Felder sowie object_types und show_admin_column.

Native Custom-Post-Type-UI-Definitionen

Zehn administratorgeschützte Abilities verwalten persistente Inhaltstyp- und Taxonomiedefinitionen aus Custom Post Type UI 1.19.3 oder neuer. Per PHP registrierte Definitionen bleiben ausgeschlossen. Der Slug ist nach der Anlage unveränderlich. CPT UI übernimmt die wirksame Laufzeitregistrierung ab dem nächsten WordPress-Request, deshalb melden erfolgreiche Mutationen reload_required: true.

Jede Leseantwort enthält einen SHA-256-Hash über den vollständigen Optionszustand der jeweiligen Definitionsart. Änderungen und Löschungen verlangen diesen Hash und verwenden je Optionsart eine atomare Kurzzeitsperre. Teilupdates ändern nur freigegebene Felder und erhalten unbekannte Providerdaten. Der Schreibpfad begrenzt Anzahl und Gesamtgröße, liest den exakten Optionszustand zurück und stellt bei Abweichungen den vorherigen Wert einschließlich Autoload-Metadaten wieder her. Das Löschen entfernt nur die Definition. Beiträge und Begriffe bleiben erhalten und benötigen bei vorhandenem Inhalt confirm_content=true.

Native ACPT-Lite-Definitionen

Zehn administratorgeschützte Abilities verwalten persistente Inhaltstyp- und Taxonomiedefinitionen aus ACPT Lite 2.0 oder neuer. Der Pfad arbeitet mit den nativen Modell- und Repository-Klassen. Native synchronisierte WordPress- oder Fremddefinitionen, reservierte Bezeichner, Slug-Änderungen und Rewrite-Kollisionen mit vorhandenen Seiten, Inhaltstypen oder Taxonomien bleiben gesperrt. Das eigene registrierte Modell wird bei sicheren Teilupdates ausgenommen. ACPT Lite registriert einen neuen oder geänderten Zustand ab dem nächsten WordPress-Request, deshalb melden erfolgreiche Mutationen reload_required: true.

Jede Leseantwort enthält einen SHA-256-Hash über das vollständige Providermodell einschließlich ID, Beschriftungen, Einstellungen und Zuordnungen. Änderungen und Löschungen verlangen diesen Hash und verwenden eine gemeinsame atomare Kurzzeitsperre für beide Definitionsarten. Damit können parallele Inhaltstyp- und Taxonomieoperationen nicht dieselbe ACPT-Zuordnungstabelle verändern. Vor jedem Konfliktvergleich und Read-back wird ACPTs persistenter Providercache geleert. Teilupdates erhalten benutzerdefinierte Beschriftungen und unbekannte Einstellungen. Abweichungen oder teilweise fehlgeschlagene Zuordnungen lösen einen verifizierten Rollback aus. Das Löschen entfernt nur die Definition. Beiträge und Begriffe bleiben erhalten und benötigen bei vorhandenem Inhalt confirm_content=true. Verknüpfte ACPT-Metafelder sperren die Löschung.

Native Pods-Datenmodelle und Felder

Sieben administratorgeschützte Abilities decken begrenzte Pods-Modelle und Felder über die native PHP-API ab. Dieser Modell- und Feldpfad umfasst ausschließlich eigenständige Inhaltstypen und Taxonomien mit storage=meta. Erweiterte WordPress-Kernobjekte, Definitionen tabellenbasierter Advanced Content Types, Umbenennungen und unbekannte Providerzustände bleiben in diesem Pfad schreibgeschützt. Für begrenzte Datensätze bereits vorhandener, standardmäßig konfigurierter ACTs existieren die fünf getrennten Abilities im folgenden Abschnitt. Neue Modelle und fehlende Felder können nicht atomar mit einem positiven Provider-Read-back nachgewiesen werden. Deshalb antworten create-pods-model und upsert-pods-field bei einem fehlenden Feld vor jeder Mutation mit HTTP 409. delete-pods-model und delete-pods-field sind manual-only und antworten mit HTTP 409 und manual_only vor jeder Mutation. Modelle und Felder werden für diese Vorgänge im Pods-Backend manuell angelegt oder gelöscht, anschließend erneut gelesen.

Modell-Hashes umfassen die vollständigen rohen Modell- und Felddefinitionen. Feld-Hashes umfassen die vollständige rohe Felddefinition. Updates verlangen den zuletzt gelesenen Hash, alle Schreibvorgänge verwenden eine atomare Kurzzeitsperre und einen vollständigen Provider-Read-back. Bei Abweichungen wird der vorherige Zustand zurückgespielt und erneut geprüft. Nicht von WPAgently verwaltete Pods-Optionen werden benannt und bei Teilupdates erhalten.

Der Feldpfad unterstützt text, website, phone, email, paragraph, wysiwyg, datetime, date, time, number, currency, file, avatar, oembed, pick, boolean und color. Beziehungsfelder dürfen auf registrierte Inhaltstypen, Taxonomien, Benutzer oder Medien zeigen. Ein Typwechsel mit vorhandenen Werten verlangt confirm_data_migration=true. Die manual-only-Löschpfade entfernen weder Definitionen noch Beziehungsdaten. Die Löschung erfolgt im Pods-Backend; danach wird das Modell erneut gelesen.

Pods Advanced-Content-Type-Datensätze

Fünf weitere administratorgeschützte Abilities verwalten ausschließlich Datensätze eigenständiger, tabellenbasierter Pods Advanced Content Types mit type=pod, storage=table, Standardtabellenkonfiguration und höchstens 20 nicht wiederholbaren Textfeldern. Pods muss mindestens Version 3.3.9 innerhalb der Hauptversion 3 bereitstellen. Veränderte Systemfelder, Autor-Systemfelder, Sonderkonfigurationen, wiederholbare oder nicht textuelle Felder, fremde Subsites und unbekannte Providerzustände bleiben geschlossen. SQLite ist lesend freigegeben, Schreibzugriffe bleiben dort gesperrt, weil Pods 3.3.9 eine Anlage nicht eindeutig mit einer positiven Datensatz-ID bestätigt.

Listen und Einzelabruf verwenden die native pods()-API und liefern nur die freigegebenen Textwerte, den Schema-Hash und pro Datensatz einen vollständigen SHA-256-Konflikthash. Anlegen und Aktualisieren verlangen manage_options, binden Subsite, Modell und Schema unter einer atomaren Kurzzeitsperre, verwenden ausschließlich Pods::add() beziehungsweise Pods::save() und lesen das Ergebnis nativ zurück. delete-pods-act-record ist dagegen manual-only und antwortet vor jeder Mutation mit HTTP 409 und manual_only. Den Datensatz im Pods-Backend löschen und die Abwesenheit anschließend erneut lesen.

Native Meta-Box-Datenmodelle, Feldwerte, Beziehungen und Einstellungsseiten

39 Abilities bilden begrenzte native Pfade für Meta Box 5.14, MB Builder 5.4, MB Custom Post Type 2.12, MB Relationships 1.13 und MB Settings Page ab. wp-agent/get-meta-box-status zeigt die erkannten Kern- und Builder-Versionen, die Zahl der nativen Provider-Abilities sowie die Verfügbarkeit des Settings-Page-Vertrags. Fehlende Erweiterungen führen bei der jeweiligen Operation zu HTTP 409, nicht zu einem stillen Fallback auf rohes Postmeta.

Die Proxies von Meta Box übernehmen kein offenes natives Schema. Sie veröffentlichen nur einen geschlossenen, begrenzten abgeleiteten Vertrag und validieren Eingaben sowie Provider-Ausgaben dagegen. Fehlt der native Vertrag der Ability, die REST-Schemavalidierung oder eine erforderliche Meta-Box-Erweiterung, liefert der betroffene Proxy HTTP 409. Es gibt keinen Fallback auf rohe Metadaten oder rohe Provider-Ausgaben. Eine Provider-Ausgabe außerhalb des abgeleiteten Vertrags wird nicht weitergegeben.

Feldgruppen, einzelne Felddefinitionen, Inhaltstypen und Taxonomien verlangen manage_options. ACF-Feldwerte verlangen die zum konkreten Ziel passende WordPress-Berechtigung: edit_post, edit_user, edit_term, edit_comment oder bei Optionsspeichern manage_options beziehungsweise die für eine registrierte ACF-Optionsseite konfigurierte Capability. Meta-Box-Feldwerte bleiben auf Beiträge beschränkt und verlangen zunächst edit_posts sowie die native objektbezogene Provider-Berechtigung. Meta Box muss das Feld kennen. Beliebige Metaschlüssel, nicht lesbare Referenzen, nicht bearbeitbare Objekte und Einstellungen ohne Administratorrecht bleiben gesperrt.

Der Feld-Lesepfad korrigiert einen Fehler in MB Builder 5.4.2, durch den das erste Feld mit Index 0 nicht gelesen werden kann. WPAgently verwendet dafür einen strikten eigenen Index und die öffentliche Builder-Normalisierung. Die Format-Ability entfernt ausschließlich die zusätzliche field_id-Eigenschaft, die Meta Box 5.14 zurückgibt, obwohl sein eigenes Ausgabeschema sie verbietet.

Die elf Pfade zum Ändern oder Löschen bestehender Feldgruppen, Felder, Inhaltstypen, Taxonomien und Feldwerte sind registrierte manual-only-Abilities: update-meta-box-field-group, delete-meta-box-field-group, update-meta-box-field, delete-meta-box-field, move-meta-box-field, update-meta-box-post-type, delete-meta-box-post-type, update-meta-box-taxonomy, delete-meta-box-taxonomy, update-meta-box-field-value und delete-meta-box-field-value. Meta Box bietet dafür keine belastbare versionierte Compare-and-Swap-Prüfung. Der Callback antwortet deshalb vor jeder Provider-Mutation mit HTTP 409 und manual_action_required=true. Änderungen oder Löschungen erfolgen im WordPress-Backend und werden danach neu gelesen. Die jeweiligen Create- und Read-Abilities bleiben davon getrennt.

Die acht Relationship-Abilities verlangen immer manage_options. Listen und Einzelabruf bleiben lesend. create-meta-box-relationship und add-meta-box-connection sind die beiden Remote-Schreibpfade: Definitionen dürfen nur freigegebene Einstellungen und höchstens 44 Zeichen lange IDs enthalten, bereits per PHP registrierte IDs werden nicht überschrieben, und Verbindungen verwenden die öffentliche MB-Relationships-API. Beide Pfade validieren Providerzustand und Eingaben, verwenden ihre atomare Sperre und lesen das Ergebnis zurück. update-meta-box-relationship, delete-meta-box-relationship und delete-meta-box-connection sind dagegen registrierte manual-only-Abilities. Meta Box bietet für diese vorhandenen Objekte keine speicheratomare Compare-and-Set- oder Compare-and-Delete-Operation. Sie antworten deshalb vor jeder Mutation mit HTTP 409 und manual_only; Änderungen, Löschungen und dauerhafte Löschungen erfolgen in WordPress und werden anschließend neu gelesen.

Die fünf Settings-Page-Abilities verlangen ebenfalls manage_options und die vollständig aktive Kombination aus MB Settings Page und MB Builder. Listen und Einzelabruf bleiben lesend. create-meta-box-settings-page ist der einzige Remote-Schreibpfad: Er verwaltet ausschließlich persistente Builder-Definitionen, überschreibt nie PHP-definierte Seiten, sperrt PHP-Callbacks, aktive SVG-Daten-URLs und bekannte allgemeine Standardberechtigungen, und liest persistente sowie aktive Definition zurück. update-meta-box-settings-page und delete-meta-box-settings-page sind manual-only. Da Meta Box für bestehende Settings-Page-Definitionen keine speicheratomare Compare-and-Set- oder Compare-and-Delete-Operation bietet, antworten sie vor jeder Mutation mit HTTP 409 und manual_only. Sie verschieben weder Definitionen in den Papierkorb noch löschen sie dauerhaft. Änderungen oder Löschungen erfolgen im WordPress-Backend und werden danach neu gelesen. Wertezugriffe über die proprietäre Laufzeiterweiterung sind ohne legal lizenzierte praktische Installation weiterhin nicht zertifiziert.

wp-agent/get-product

Zweck: Liest ein WooCommerce-Produkt vollständig über WC_Product: Kerndaten, Preise, Lager, Sichtbarkeit, Versandmaße, Medien, Kategorien, Schlagwörter, Versandklasse und Attribute. Rohes Postmeta wird nie verwendet.

Capability: edit_posts (grob) plus current_user_can('edit_post', $product_id) (löst über WooCommerce' map_meta_cap() auf die WooCommerce-Capability edit_products auf, standardmäßig nur Shop Manager und Administrator, nicht Editor). Erfordert WooCommerce (sonst 400).

Merkmale: lesend, nicht destruktiv, idempotent.

Beispiel: { "product_id": 120 }

wp-agent/update-product

Zweck: Partielles Update eines WooCommerce-Produkts ausschließlich über das WC_Product-Objekt (offizielle Setter plus save()), nie über wp_update_post()/update_post_meta() direkt. Grund: ein roher update_post_meta()-Aufruf ändert zwar die Postmeta-Zeile, aber weder WooCommerce' Objekt-Cache noch die Lookup-Tabelle wp_wc_product_meta_lookup, die Preis-Sortierung/-Filterung im Shop-Frontend nutzt. Prüft eine doppelt vergebene SKU vorab über wc_get_product_id_by_sku() (statt die synchron geworfene WC_Data_Exception von set_sku() zu einem unabgefangenen HTTP 500 werden zu lassen).

Capability: edit_posts (grob) plus current_user_can('edit_post', $product_id) (WooCommerce edit_products). Erfordert WooCommerce.

Merkmale: schreibend, nicht destruktiv, idempotent.

Beispiel: { "product_id": 120, "regular_price": "24.99", "stock_quantity": 50 }

wp-agent/get-woocommerce-store-settings

Zweck: Liest einen begrenzten, geheimnisfreien Snapshot der effektiven WooCommerce-Shopkonfiguration. Dazu gehören Basisland und Bundesland, Währung und Format, Steueraktivierung, Preis- und Gewichtsmaße, Dimensionseinheit, Bestandsverwaltung, Gastkauf, Kontenerstellung, HTTPS-Checkout sowie veröffentlichte Shop-, Warenkorb-, Kassen- und Kontoseiten. Zugangsdaten, Zahlungsanbieter-Konfigurationen, Webhooks, E-Mail-Adressen und rohe Optionen werden nicht ausgegeben.

Capability: manage_woocommerce. Merkmale: lesend, nicht destruktiv, idempotent. Keine Parameter.

wp-agent/list-products

Zweck: Sucht und filtert Produkte über WC_Product_Query und den offiziellen Product Data Store. Unterstützt search, exakte sku, status, type, page und per_page bis 100. Liefert vollständige Produktobjekte plus total und pages.

Capability: edit_products. Merkmale: lesend, nicht destruktiv, idempotent.

wp-agent/preview-woocommerce-bulk-price-update

Zweck: Erstellt eine bestätigbare Vorschau für eine begrenzte WooCommerce-Preisaktion auf alle Produkte einer Kategorie oder eines Schlagworts. selection enthält ausschließlich taxonomy mit product_cat oder product_tag, eine positive term_id und include_variations. operation erlaubt einen ganzzahligen Rabatt von 1 bis 90 Prozent, einen positiven festen Angebotspreis oder das Entfernen des Angebotspreises. Produkte mit geplanten Angebotszeiträumen werden geschlossen abgelehnt.

Die Auswahl umfasst höchstens 50 eigenständig bepreisbare Produkte oder Varianten. Produkt- und Variationsabfragen stoppen bereits beim 51. Ziel, bevor weitere Objekte vollständig geladen werden. Die Vorschau liefert die exakten Ziel-IDs, alte und geplante Preise, zugehörige variable Elternprodukte sowie einen SHA-256-Hash. Dieser bindet Subsite, WooCommerce-Version, Währungs- und Preisformat, Auswahl, Vorgang, Zielreihenfolge, Produktzustand und Elternzustand.

Capability: edit_products. Merkmale: lesend, nicht destruktiv, idempotent.

wp-agent/execute-woocommerce-bulk-price-update

Zweck: Führt ausschließlich eine unveränderte Bulk-Preisvorschau aus. Pflicht sind blog_id, dieselbe selection und operation, die exakte sortierte item_ids-Liste, preview_collection_hash und confirm=true. Vor Beginn werden vollständige Auswahl, Zielmenge, Preise, Term-Zugehörigkeit, Elternzustand und Shopkontext erneut geprüft.

Jedes Ziel wird separat mit einer kurzlebigen Sperre geschützt, unmittelbar vor der nativen WC_Product::save()-Mutation erneut gelesen und danach samt Lookup-Zustand und gegebenenfalls variablem Elternpreis zurückgelesen. Der globale Ausführungsschlüssel wird vor und nach jedem Save erneuert. Bei verlorenem Besitz, unklarem Providerzustand oder abweichendem Read-back endet der Vorgang mit recovery_required; bereits geschriebene Preise werden nicht automatisch zurückgesetzt und fremde Änderungen werden nie überschrieben.

Capability: edit_products plus die native edit_post-Berechtigung für jedes Ziel und jeden variablen Elternartikel. Merkmale: schreibend, nicht destruktiv, nicht idempotent.

wp-agent/create-product

Zweck: Erstellt einfache oder variable Produkte über WC_Product_Simple beziehungsweise WC_Product_Variable. Pflichtfelder sind type und name. Alle Produktfelder aus update-product können direkt gesetzt werden. SKU-Kollisionen und ungültige Preise werden vor dem Speichern abgelehnt, das gespeicherte Produkt wird frisch zurückgelesen.

Capability: native Erstell- und bei Veröffentlichung publish_products-Capability. Merkmale: schreibend, nicht destruktiv, nicht idempotent.

wp-agent/delete-product

Zweck: Verschiebt ein Produkt konfliktgeschützt und reversibel in den WordPress-Papierkorb. force=true oder permanent=true wird vor jeder Mutation mit HTTP 409 abgewiesen. Ist der Papierkorb deaktiviert, führt WPAgently keine Remote-Löschung aus. Pflicht sind product_id, ein frischer expected_state_hash und confirm: true.

Capability: objektbezogen delete_post. Merkmale: schreibend, reversibler Papierkorb, nicht idempotent.

wp-agent/list-product-variations

Zweck: Listet alle Varianten eines variablen Produkts über dessen native Kind-IDs und WC_Product_Variation auf. Pflicht: product_id.

Capability: objektbezogen edit_post am Elternprodukt. Merkmale: lesend, nicht destruktiv, idempotent.

wp-agent/upsert-product-variation

Zweck: Erstellt oder aktualisiert eine Variante über WC_Product_Variation. Bei der Anlage sind product_id und mindestens ein am Elternprodukt freigegebenes Variantenattribut erforderlich. Mit variation_id wird partiell aktualisiert. Preise, SKU, Lager, Status, Medien, Maße und digitale Eigenschaften werden nativ gespeichert. Danach werden Elternprodukt, Lookup-Daten und Transients synchronisiert.

Capability: objektbezogen edit_post am Elternprodukt. Merkmale: schreibend, nicht destruktiv, idempotent beim Update.

wp-agent/delete-product-variation

Zweck: Verschiebt eine zum angegebenen Elternprodukt gehörende Variante konfliktgeschützt und reversibel in den WordPress-Papierkorb. force=true oder permanent=true wird vor jeder Mutation mit HTTP 409 abgewiesen. Ist der Papierkorb deaktiviert, führt WPAgently keine Remote-Löschung aus. Pflicht sind product_id, variation_id, ein frischer expected_state_hash und confirm: true. Danach wird das variable Produkt synchronisiert.

Capability: delete_post an der Variante plus Bearbeitungsrecht am Elternprodukt. Merkmale: schreibend, reversibler Papierkorb, nicht idempotent.

wp-agent/list-product-attributes

Zweck: Listet alle globalen WooCommerce-Produktattribute frisch über wc_get_attribute_taxonomies() auf. Jedes Ergebnis enthält ID, Name, Slug, Taxonomienamen, Typ, Sortierung, Archivstatus, Anzahl abhängiger Attributwerte und einen vollständigen SHA-256-Zustands-Hash. Die Begriffszahlen werden für die gesamte Liste in einer gemeinsamen Datenbankabfrage gelesen.

Capability: manage_product_terms. Merkmale: lesend, nicht destruktiv, idempotent. Erfordert WooCommerce und dessen öffentliche Attribut-API.

wp-agent/get-product-attribute

Zweck: Liest genau eine globale Attributdefinition über ihre attribute_id und liefert denselben vollständigen Zustand wie die Liste.

Capability: manage_product_terms. Merkmale: lesend, nicht destruktiv, idempotent. Eine unbekannte ID liefert HTTP 404.

wp-agent/upsert-product-attribute

Zweck: Erstellt oder aktualisiert eine globale Attributdefinition ausschließlich über wc_create_attribute() beziehungsweise wc_update_attribute(). Bei der Anlage ist name Pflicht. slug, type, order_by und has_archives sind optional. Ein Update benötigt attribute_id, expected_state_hash und mindestens ein geändertes Feld. Slugs dürfen optional mit pa_ eingegeben werden und nach der Bereinigung höchstens 28 Zeichen enthalten. Registrierte WooCommerce-Attributtypen werden zur Laufzeit geprüft.

Sicherheit: Die Ability hält eine atomare globale Kurzzeitsperre, vergleicht den frischen vollständigen Zustand einschließlich der Anzahl abhängiger Attributwerte, liest das Ergebnis erneut über WooCommerce und rollt eine nicht exakt bestätigte Anlage oder Änderung verifiziert zurück. Sie erkennt auch einen Teilfehler, bei dem ein WooCommerce-Hook erst nach dem Datenbank-Insert abbricht. Eine Slug-Umbenennung läuft über WooCommerce, damit Produktattribute, Varianten-Metadaten und die Term-Sortieroption nativ migriert werden.

Capability: manage_product_terms. Merkmale: schreibend, destruktiv, nicht idempotent. Der destruktive Marker gilt auch für Updates, weil eine Umbenennung die Katalogstruktur verändert.

wp-agent/delete-product-attribute

Zweck: Prüft die Eingabe für das manuelle Löschen einer globalen WooCommerce-Attributdefinition. Die Ability ruft wc_delete_attribute() nicht auf, entfernt keine Attribute oder Begriffe und antwortet vor jeder Mutation mit HTTP 409 und manual_only. Die Löschung erfolgt in WooCommerce.

Capability: manage_product_terms. Merkmale: manual-only, keine Remote-Mutation.

Produktkategorien, Produktschlagwörter und die Begriffe globaler Attribute werden über die allgemeinen Taxonomie-Abilities verwaltet. Versandklassen sind dort ausdrücklich gesperrt und verwenden die folgenden spezialisierten Abilities. Die vier Attribut-Abilities verwalten die WooCommerce-spezifischen globalen Attributdefinitionen selbst.

wp-agent/list-product-shipping-classes

Zweck: Listet WooCommerce-Versandklassen paginiert ohne N+1-Abfragen. Jedes Ergebnis enthält ID, Namen, Slug, Klartextbeschreibung, Produktnutzung und einen vollständigen Zustands-Hash.

Capability: manage_woocommerce. Merkmale: lesend, nicht destruktiv, idempotent. Optional: search, page, per_page.

wp-agent/get-product-shipping-class

Zweck: Liest genau eine Versandklasse mit demselben bestätigten Zustand und Konflikthash. Eine unbekannte ID liefert HTTP 404.

Capability: manage_woocommerce. Merkmale: lesend, nicht destruktiv, idempotent. Pflicht: shipping_class_id.

wp-agent/upsert-product-shipping-class

Zweck: Erstellt oder aktualisiert eine Versandklasse über die native WooCommerce-Taxonomie. Namen, Slug und Klartextbeschreibung sind begrenzt; doppelte Namen oder Slugs werden abgelehnt. Updates verlangen einen frischen expected_state_hash. Providerrechte, eine atomare Sperre, exakter Read-back und die eindeutige neue Term-ID schützen den Vorgang. Meldet WooCommerce Erfolg, der Zustand lässt sich danach aber nicht exakt zuordnen, antwortet die Ability mit recovery_required und führt keine automatische Löschung oder Rückschreibung aus.

Capability: manage_woocommerce. Merkmale: schreibend, destruktiv markiert, nicht idempotent. Für die Anlage ist name Pflicht. Für ein Update sind shipping_class_id, expected_state_hash und mindestens ein änderbares Feld erforderlich. Remote-Löschen bleibt gesperrt, weil fremde WooCommerce-Schreibvorgänge nicht an dieselbe Sperre gebunden sind und eine verwaiste Produktzuordnung sonst nicht race-frei ausgeschlossen werden kann.

wp-agent/list-orders

Zweck: Listet WooCommerce-Bestellungen über wc_get_orders() und den aktiven WooCommerce-Datenspeicher. Der praktisch geprüfte Pfad verwendet HPOS. Personen-, Adress-, Zahlungs- und Positionsdaten bleiben standardmäßig aus der Antwort entfernt. Sie erscheinen nur über die getrennten Schalter include_customer, include_payment und include_items. Pro Antwort sind höchstens 100 Bestellungen und pro Bestellung höchstens 200 Positionen erlaubt.

Capability: read_private_shop_orders. Merkmale: lesend, nicht destruktiv, idempotent. Optional: status, customer_id, die drei include_*-Schalter, page und per_page. Output: orders, total, total_pages, page, per_page.

wp-agent/get-order

Zweck: Liest genau eine Bestellung über wc_get_order(). Die kompakte Standardantwort enthält Status, Zeitpunkte und Summen, aber keine Kunden-, Adress-, Zahlungs- oder Positionsdaten. Diese Felder müssen wie bei list-orders einzeln angefordert werden. Rückerstattungsobjekte werden nicht als Bestellungen akzeptiert.

Capability: read_private_shop_orders. Merkmale: lesend, nicht destruktiv, idempotent. Pflicht: order_id. Optional: include_customer, include_payment, include_items.

wp-agent/list-order-notes

Zweck: Listet höchstens 100 WooCommerce-Bestellnotizen. type begrenzt die Antwort auf all, internal oder customer. Notizen können selbst personenbezogene Kommunikationsinhalte enthalten und gehören deshalb zur getrennten Bestellrechte-Gruppe.

Capability: read_private_shop_orders. Merkmale: lesend, nicht destruktiv, idempotent. Pflicht: order_id. Optional: type, limit.

wp-agent/set-order-status

Zweck: Setzt einen registrierten Bestellstatus über das native WC_Order-Objekt und liest die Bestellung anschließend neu. confirm: true ist zwingend, weil Statuswechsel E-Mails, Lagerbewegungen, Webhooks und Drittanbieter-Automationen auslösen können. expected_date_modified lehnt veraltete Schreibversuche mit HTTP 409 ab. refunded und checkout-draft sind gesperrt. Eine Erstattung benötigt einen eigenen Zahlungs- und Betragsvorgang und wird von dieser Ability nicht vorgetäuscht.

Capability: edit_shop_orders. Merkmale: schreibend, destruktiv, idempotent. Pflicht: order_id, status, confirm. Optional: expected_date_modified. Output: frisch gelesene order und verified.

wp-agent/add-order-note

Zweck: Fügt eine bereinigte Nur-Text-Notiz über WC_Order::add_order_note() hinzu und liest sie neu. Kundensichtbare Notizen benötigen confirm_customer_notification: true, weil WooCommerce eine E-Mail auslösen kann. Der Pflichtwert idempotency_key bindet genau eine Nutzlast an genau eine Bestellung. Wiederholungen liefern die vorhandene Notiz, eine abweichende Nutzlast mit demselben Schlüssel wird mit HTTP 409 abgelehnt.

Capability: edit_shop_orders. Merkmale: schreibend, destruktiv, idempotent. Pflicht: order_id, note, idempotency_key. Optional: customer_note, confirm_customer_notification. Output: note, verified, reused.

Bestellrechte werden nie zusammen mit normalen WooCommerce-Katalogrechten oder beim Anlegen eines Agent-Nutzers vergeben. Die Verbindungsseite kann read_private_shop_orders und edit_shop_orders für einen sicheren Redakteur ausdrücklich ergänzen. Beim Abschalten oder Deinstallieren entfernt WPAgently ausschließlich protokollierte Ergänzungen und erhält vorher vorhandene Rechte. Die Gruppe orders ist vollständig nur in den Profilen Vollzugriff und Benutzerdefiniert sichtbar. Im Profil Nur lesen können die drei Lese-Abilities erscheinen, die Capability bleibt trotzdem erforderlich. Das Inhaltsprofil enthält keine Bestell-Abilities. Nicht unterstützt werden Bestellanlage, Positionsänderungen, Erstattungen und Zahlungsaktionen.

wp-agent/list-contact-forms

Zweck: Listet Contact-Form-7-Formulare über WPCF7_ContactForm::find(). Unterstützt Suche und Pagination und liefert pro Treffer ID, unveränderliche Provider-Kennung, vollständigen SHA-256-Zustands-Hash, Slug, Titel, Sprache und den einbettbaren Shortcode.

Capability: wpcf7_read_contact_forms. Diese Plugin-Capability wird von Contact Form 7 standardmäßig auch Redakteuren gewährt.

Merkmale: lesend, nicht destruktiv, idempotent. Optionale Parameter: search (string), page (integer ab 1), per_page (integer 1-100). Output: forms[], total, page, per_page.

wp-agent/get-contact-form

Zweck: Liest ein Contact-Form-7-Formular über dessen Objekt-API, nicht aus rohem Postmeta. Liefert die Form-Tag-Vorlage, geparste Felder, sichere Teilansichten beider Mailkonfigurationen, Meldungen, Shortcode, den vollständigen SHA-256-Zustands-Hash und die aktuellen Ergebnisse des nativen WPCF7_ConfigValidator. Die Mailansichten enthalten Aktivierung, Betreff, Absender, Empfänger, Nur-Text-Inhalt, ein einzeln verwaltbares Reply-To, Leerfeldbehandlung und Format. Anhangspfade, beliebige Zusatzheader und rohe additional_settings werden nicht ausgegeben. Boolesche Indikatoren weisen auf erhaltene, nicht sichtbare erweiterte Konfiguration hin.

Capability: wpcf7_read_contact_forms plus objektbezogen wpcf7_edit_contact_form.

Merkmale: lesend, nicht destruktiv, idempotent. Pflichtparameter: form_id (integer).

wp-agent/create-contact-form

Zweck: Erstellt ein Formular mit wpcf7_save_contact_form(). Ohne eigene Vorlage verwendet Contact Form 7 seine sprachabhängige Standardvorlage. Eine eigene Vorlage darf ausschließlich CF7-Form-Tags und eng erlaubtes Struktur-Markup ohne Scripts, Inline-Stile oder rohe Formular-Controls enthalten. Für eine eigene Vorlage erzeugt WPAgently eine gültige Standardbenachrichtigung aus den tatsächlich vorhandenen Feld-Tags. Sichere Mailänderungen sind auf subject, sender, recipient, body, reply_to, exclude_blank, beim Autoresponder zusätzlich active und auf den Wechsel zu format: plain begrenzt. Meldungen sind reine Texte mit bekannten CF7-Schlüsseln. Der Kandidat durchläuft den nativen Konfigurationsvalidator und eine Mail-Tag-Allowlist vor dem Speichern. Ein exakter vollständiger Read-back ist Pflicht. Eine Abweichung entfernt das unvollständige Formular automatisch.

Capability: wpcf7_edit_contact_forms.

Merkmale: schreibend, nicht destruktiv, nicht idempotent. Pflichtparameter: title. Optional: locale, form, mail, mail_2, messages. Rohe additional_settings, Anhänge, beliebige Header und das Aktivieren von HTML-Mail sind nicht beschreibbar. Output: form und verified.

wp-agent/update-contact-form

Zweck: Aktualisiert ausschließlich die sicheren Eigenschaften von create-contact-form. expected_hash bindet den Schreibvorgang an den vollständig gelesenen Zustand. Ein atomar erworbener Kurzzeit-Lock verhindert parallele Agent-Schreibvorgänge. Nicht übergebene und nicht sichtbare Providerdaten bleiben vollständig erhalten. Vor dem Speichern werden Struktur-Markup, Mail-Tags, Mailboxen, Bestätigungstexte und die vollständige betroffene CF7-Konfiguration geprüft. Nach dem Speichern muss der vollständige logische Zustand exakt dem validierten Kandidaten entsprechen. Bei Speicherfehler, Drift oder nachträglichem Validierungsfehler wird der komplette vorherige Zustand über die native Objekt-API wiederhergestellt und erneut per SHA-256 geprüft.

Capability: wpcf7_edit_contact_forms plus objektbezogen wpcf7_edit_contact_form.

Merkmale: schreibend, nicht destruktiv, idempotent. Pflichtparameter: form_id, expected_hash. Die optionalen Eigenschaften entsprechen create-contact-form.

wp-agent/duplicate-contact-form

Zweck: Dupliziert ein Formular über WPCF7_ContactForm::copy() und save(). expected_hash und derselbe formularbezogene Kurzzeit-Lock verhindern eine Kopie aus einem veralteten oder gleichzeitig veränderten Zustand. Vor dem Speichern muss die vollständige Quelle valide sein. Die Kopie erhält eine neue ID und behält sämtliche Provider-Eigenschaften. Der vollständige logische Zustand wird exakt neu gelesen. Eine abweichende Kopie wird automatisch gelöscht.

Capability: wpcf7_edit_contact_forms plus objektbezogen wpcf7_edit_contact_form.

Merkmale: schreibend, nicht destruktiv, nicht idempotent. Pflichtparameter: form_id, expected_hash; optional title. Output: form und verified.

wp-agent/delete-contact-form

Zweck: Prüft die Eingabe für das manuelle dauerhafte Löschen eines Contact-Form-7-Formulars. Die Ability ruft delete() nicht auf und antwortet vor jeder Mutation mit HTTP 409 und manual_only. Das Formular bleibt unverändert und wird im Contact-Form-7-Backend gelöscht.

Capability: wpcf7_edit_contact_forms plus objektbezogen wpcf7_delete_contact_form.

Merkmale: manual-only, keine Remote-Mutation. Pflichtparameter: form_id, expected_hash, confirm. Output: HTTP 409 mit manual_only, ohne Änderung.

wp-agent/list-fluent-forms

Zweck: Listet Fluent-Forms-Formulare über den nativen FormService. Suche, Status und Pagination sind begrenzt. Der zugrunde liegende Fluent-Forms-API-Pfad berücksichtigt formularbezogene Manager-Einschränkungen. Unbekannte Modell-, Add-on- und Form-Meta-Daten werden nicht ausgegeben.

Capability: fluentform_dashboard_access. Merkmale: lesend, nicht destruktiv, idempotent. Optional: search, status (published, unpublished, all), page, per_page (1-100).

wp-agent/get-fluent-form

Zweck: Liest ein Formular über FormService::find(). Ausgegeben werden ausschließlich ID, Titel, Status, Typ, Zahlungskennzeichen, Zeitstempel, Shortcode, Feldanzahl und vollständiger Feldhash. Rohe Provider-Feldstrukturen bleiben intern. Die native Fluent-Forms-ACL wird mit der konkreten Formular-ID geprüft.

Capability: fluentform_forms_manager plus formularbezogene Fluent-Forms-ACL. Merkmale: lesend, nicht destruktiv, idempotent. Pflicht: form_id.

wp-agent/create-fluent-form

Zweck: Erstellt über FormService::store() zunächst die native leere Vorlage und setzt Titel, Status und optional die Absende-Beschriftung über den nativen Updater. Felder werden anschließend ausschließlich über die sichere Feld-Ability angelegt. Der gespeicherte Zustand wird neu gelesen und mit der beabsichtigten Nutzlast verglichen. Bei einer Abweichung wird das unvollständige Formular gelöscht und die Löschung verifiziert.

Capability: fluentform_forms_manager. Merkmale: schreibend, nicht destruktiv, nicht idempotent. Pflicht: title. Optional: status, submit_label. Output: form, verified.

wp-agent/update-fluent-form

Zweck: Prüft eine geplante manuelle Änderung von Titel, Status oder Absende-Beschriftung eines Fluent-Forms-Formulars. Die Ability ruft FormService::update() nicht auf und antwortet vor jeder Mutation mit HTTP 409 und manual_only. Die Änderung erfolgt im Fluent-Forms-Backend.

Capability: fluentform_forms_manager plus formularbezogene Fluent-Forms-ACL. Merkmale: manual-only, keine Remote-Mutation. Pflicht: form_id. Optional: title, status, submit_label, expected_hash.

wp-agent/duplicate-fluent-form

Zweck: Dupliziert ein Formular über FormService::duplicate(), damit Fluent Forms auch eigene Metadaten und Dateien kopiert. Eine optionale Umbenennung läuft über den nativen Updater. ID, Status und Felder werden mit dem Quellformular verglichen. Eine fehlerhafte oder nicht verifizierbare Kopie wird gelöscht und die Löschung geprüft.

Capability: fluentform_forms_manager plus formularbezogene Fluent-Forms-ACL. Merkmale: schreibend, nicht destruktiv, nicht idempotent. Pflicht: form_id; optional title.

wp-agent/delete-fluent-form

Zweck: Prüft die Eingabe für das manuelle dauerhafte Löschen eines Fluent-Forms-Formulars. Die Ability ruft FormService::delete() nicht auf und antwortet vor jeder Mutation mit HTTP 409 und manual_only. Das Formular bleibt unverändert.

Capability: fluentform_forms_manager plus formularbezogene Fluent-Forms-ACL. Merkmale: manual-only, keine Remote-Mutation. Pflicht: form_id, confirm.

wp-agent/get-fluent-form-fields

Zweck: Liest die kompakte, geheimnisfreie Feldstruktur eines Formulars. Die Ausgabe enthält Feldschlüssel, normalisierte Typen, sichere Einstellungen, Absende-Beschriftung, Feldanzahl, den vollständigen fields_hash und einen aus den tatsächlich geladenen Provider-Komponenten abgeleiteten Typkatalog. Text, E-Mail, Textbereich, Zahl, Auswahl, Mehrfachauswahl, Radio, Checkbox, Name, Adresse, Land, URL und Datum sind sicher abgebildet. Telefon, Datei und Bild erscheinen nur als verfügbar, wenn die konkrete Fluent-Forms-Installation ihre nativen Komponenten bereitstellt. Unbekannte Add-on-Felder werden als nicht unterstützte Platzhalter ohne rohe Einstellungen ausgegeben.

Capability: fluentform_forms_manager plus formularbezogene Fluent-Forms-ACL. Merkmale: lesend, nicht destruktiv, idempotent. Pflicht: form_id. Output: form_id, fields, field_count, fields_hash, empty, submit_label, field_types.

wp-agent/upsert-fluent-form-field

Zweck: Prüft eine geplante manuelle Anlage oder Änderung eines unterstützten Fluent-Forms-Felds gegen die sichere Feldvorlage. Die Ability legt kein Feld an, ändert keines und antwortet vor jeder Mutation mit HTTP 409 und manual_only. Die Feldänderung erfolgt im Fluent-Forms-Backend.

Capability: fluentform_forms_manager plus formularbezogene Fluent-Forms-ACL. Merkmale: manual-only, keine Remote-Mutation. Pflicht: form_id, field_key, expected_hash, field. Optional: after_field_key. Output: HTTP 409 mit manual_only, ohne Änderung.

wp-agent/delete-fluent-form-field

Zweck: Prüft die Eingabe für das manuelle Löschen eines unterstützten Fluent-Forms-Felds. Die Ability löscht kein Feld und antwortet vor jeder Mutation mit HTTP 409 und manual_only. Unbekannte Add-on-Felder bleiben auch im manuellen Prüfpfad außerhalb des Vertrags.

Capability: fluentform_forms_manager plus formularbezogene Fluent-Forms-ACL. Merkmale: manual-only, keine Remote-Mutation. Pflicht: form_id, field_key, expected_hash, confirm. Optional: allow_empty_form. Output: HTTP 409 mit manual_only, ohne Änderung.

wp-agent/get-fluent-form-delivery

Zweck: Liest die Übermittlungsbestätigung und kompakte E-Mail-Benachrichtigungen eines Formulars über den nativen Fluent-Forms-SettingsService. Standardmäßig enthält jede Benachrichtigung ausschließlich ID, Name, Aktivierungsstatus, Empfängerart, Betreff und den vollständigen Einzelhash. include_notification_details: true ergänzt Empfängeradresse oder Formularfeld, Absender, Antwortadresse, BCC, Nachricht und Template-Schlüssel. Unbekannte Add-on-Einstellungen und Geheimnisse bleiben in beiden Ansichten verborgen. confirmation_hash deckt die vollständigen rohen allgemeinen und erweiterten Formulareinstellungen ab. notifications_hash deckt die vollständigen rohen Benachrichtigungsdatensätze ab, einschließlich nicht ausgegebener Felder. Kompakte und detaillierte Ausgabe verwenden identische Konflikthashes.

Capability: fluentform_forms_manager plus formularbezogene Fluent-Forms-ACL. Merkmale: lesend, nicht destruktiv, idempotent. Pflicht: form_id. Optional: include_notification_details, standardmäßig false. Output: form_id, confirmation, confirmation_hash, notifications, notifications_hash, notification_details_included.

wp-agent/update-fluent-form-confirmation

Zweck: Prüft eine geplante manuelle Änderung der Fluent-Forms-Bestätigung gegen die begrenzten sicheren Werte. Die Ability ändert keine Nachricht, kein Verhalten und kein Weiterleitungsziel und antwortet vor jeder Mutation mit HTTP 409 und manual_only. Die Änderung erfolgt im Fluent-Forms-Backend.

Capability: fluentform_forms_manager plus formularbezogene Fluent-Forms-ACL. Merkmale: manual-only, keine Remote-Mutation. Pflicht: form_id, expected_hash, confirmation. Output: HTTP 409 mit manual_only, ohne Änderung.

wp-agent/upsert-fluent-form-notification

Zweck: Prüft eine geplante manuelle Anlage oder Änderung einer Fluent-Forms-E-Mail-Benachrichtigung gegen die begrenzten sicheren Werte. Die Ability erstellt oder aktualisiert keine Benachrichtigung und antwortet vor jeder Mutation mit HTTP 409 und manual_only. Die Änderung erfolgt im Fluent-Forms-Backend.

Capability: fluentform_forms_manager plus formularbezogene Fluent-Forms-ACL. Merkmale: manual-only, keine Remote-Mutation. Pflicht: form_id, expected_hash, notification; optional notification_id für ein Update. Output: HTTP 409 mit manual_only, ohne Änderung.

wp-agent/delete-fluent-form-notification

Zweck: Prüft die Eingabe für das manuelle Löschen einer Fluent-Forms-E-Mail-Benachrichtigung. Die Ability löscht keine Benachrichtigung und antwortet vor jeder Mutation mit HTTP 409 und manual_only. Die Benachrichtigung bleibt unverändert.

Capability: fluentform_forms_manager plus formularbezogene Fluent-Forms-ACL. Merkmale: manual-only, keine Remote-Mutation. Pflicht: form_id, notification_id, expected_hash, confirm. Output: HTTP 409 mit manual_only, ohne Änderung.

Fluent Forms vergibt die benötigten Rechte nicht automatisch an einen normalen Redakteur. Die Verbindungsseite kann fluentform_dashboard_access und fluentform_forms_manager gezielt für einen sicheren Agent-Nutzer ergänzen. Formularbezogene Manager-Einschränkungen bleiben wirksam. Beim Abschalten oder Deinstallieren entfernt WPAgently ausschließlich protokollierte Ergänzungen und erhält vorher vorhandene Nutzerrechte.

wp-agent/list-fluent-entries

Zweck: Listet höchstens 100 Einträge eines konkreten Formulars über die native Fluent-Forms-Entry-API. Suche, Status und Pagination sind begrenzt. Feldwerte bleiben standardmäßig verborgen. IP-Adresse, Browserkennung, Zahlungsdaten, Transaktionen und unbekannte Metadaten werden auch bei include_values: true nicht ausgegeben.

Capability: fluentform_entries_viewer plus formularbezogene Fluent-Forms-ACL. Merkmale: lesend, nicht destruktiv, idempotent. Pflicht: form_id. Optional: search, status, include_values, page, per_page.

wp-agent/get-fluent-entry

Zweck: Liest die Feldwerte eines Eintrags über die native Fluent-Forms-Entry-API. Die Ausgabe besteht ausschließlich aus fest erlaubten Kerndaten und den begrenzten Formularwerten. Ein SHA-256-Versionswert deckt Status, Favorit, Antwort und Änderungszeit ab.

Capability: fluentform_entries_viewer plus formularbezogene Fluent-Forms-ACL. Merkmale: lesend, nicht destruktiv, idempotent. Pflicht: entry_id.

wp-agent/set-fluent-entry-status

Zweck: Setzt einen vom konkreten Formular unterstützten Eintragsstatus über den nativen Fluent-Forms-Bulk-Service. expected_version kann konkurrierende Änderungen mit HTTP 409 abweisen. Das Ergebnis wird neu gelesen. Eine Ausnahme nach bereits erfolgter Mutation oder ein abweichender Read-back löst einen verifizierten Rollback auf den vorherigen Status aus.

Capability: fluentform_manage_entries plus formularbezogene Fluent-Forms-ACL. Merkmale: schreibend, destruktiv, idempotent. Pflicht: entry_id, status. Optional: expected_version.

wp-agent/set-fluent-entry-favorite

Zweck: Setzt oder entfernt die Favoritenmarkierung idempotent über den nativen Fluent-Forms-Bulk-Service. Das Ergebnis wird neu gelesen. Ausnahmen nach einer Mutation und abweichende Ergebnisse werden auf den vorherigen Wert zurückgerollt und der Rollback wird geprüft.

Capability: fluentform_manage_entries plus formularbezogene Fluent-Forms-ACL. Merkmale: schreibend, nicht destruktiv, idempotent. Pflicht: entry_id, favorite. Optional: expected_version.

wp-agent/delete-fluent-entry

Zweck: Prüft die Eingabe für das manuelle Löschen eines Fluent-Forms-Eintrags. Die Ability löscht weder Eintrag noch Begleitdaten und antwortet vor jeder Mutation mit HTTP 409 und manual_only.

Capability: fluentform_manage_entries plus formularbezogene Fluent-Forms-ACL. Merkmale: manual-only, keine Remote-Mutation. Pflicht: entry_id, confirm. Optional: expected_version.

Fluent-Forms-Eintragsrechte sind wegen möglicher personenbezogener Daten von den Formularrechten getrennt. Sie werden beim Anlegen eines Agent-Nutzers nie automatisch vergeben. Die Gruppe entries erscheint vollständig nur in den Profilen Vollzugriff und Benutzerdefiniert. Die Verbindungsseite kann fluentform_entries_viewer und fluentform_manage_entries gezielt ergänzen und entfernt später ausschließlich die protokollierten Ergänzungen.

wp-agent/list-kadence-forms

Zweck: Listet native kadence_form-Objekte unter Kadence Blocks Free 3.7.8 begrenzt und paginiert auf. Die Ausgabe enthält nur ID, Titel, Status und Änderungszeit, keine Empfänger, Nachrichten oder anderen Zustellungsdaten.

Capability: edit_kadence_forms und für jedes Ergebnis edit_post. Merkmale: lesend, nicht destruktiv, idempotent. Optional: search, status, page, per_page (1-100).

wp-agent/get-kadence-form-settings

Zweck: Liest genau ein natives Kadence-Formular, seine begrenzten Feldtypen und die sichere Schnittmenge aus Beschreibung, Browservalidierung, lokalem Redirect, Ausblenden nach dem Absenden und kompakten E-Mail-Einstellungen. Die Ausgabe kennzeichnet unbekannte oder fortgeschrittene Aktionen, Header und Providerzustände und bindet den vollständigen rohen Formularzustand an einen SHA-256-Hash.

Capability: edit_kadence_forms und edit_post für das Formular. Merkmale: lesend, nicht destruktiv, idempotent. Pflicht: form_id.

wp-agent/update-kadence-form-settings

Zweck: Ändert ausschließlich Beschreibung, Browservalidierung, einen root-relativen oder gleichartigen Redirect, Ausblenden nach dem Absenden sowie eine einzelne E-Mail-Aktion mit genau einem Empfänger. Unbekannte Aktionen, doppelte Aktionen, Pro, CC, BCC, Header, unsichere URLs und nicht kanonische Providerzustände bleiben gesperrt. Ein vollständiger expected_hash, ein erneuerbarer Create-only-Lock, erneute Rechte- und Providerprüfung sowie exakter Rohzustands-Read-back sichern den Vorgang. Nach einer begonnenen, aber nicht eindeutig bestätigten Mutation meldet die Ability recovery_required und führt keine automatische Folgemutation aus.

Capability: edit_kadence_forms und edit_post für das Formular. Merkmale: schreibend, nicht destruktiv, idempotent. Pflicht: form_id, expected_hash, settings.

wp-agent/list-gravity-forms

Zweck: Listet Gravity-Forms-Formulare über GFAPI::get_forms(). Unterstützt Suche, Pagination und die Statusfilter active, inactive, trash und all. Ausgegeben werden ausschließlich dokumentierte Grunddaten, niemals unbekannte Add-on-Einstellungen.

Capability: gravityforms_edit_forms. Merkmale: lesend, nicht destruktiv, idempotent. Optional: search, status, page, per_page (1-100).

wp-agent/get-gravity-form

Zweck: Liest ein Formular über GFAPI::get_form() und liefert dokumentierte Grunddaten, Felder, Button, Benachrichtigungen, Bestätigungen und eine begrenzte Liste dokumentierter Formulareinstellungen. Unbekannte Form-Level-Add-on-Daten werden wegen möglicher Zugangsdaten bewusst nicht ausgegeben.

Capability: gravityforms_edit_forms. Merkmale: lesend, nicht destruktiv, idempotent. Pflicht: form_id.

wp-agent/create-gravity-form

Zweck: Erstellt ein Formular über GFAPI::add_form() und liest es anschließend über die öffentliche GFAPI neu ein. Unterstützt Titel, Beschreibung, bis zu 500 Felder, bis zu 200 Benachrichtigungen und Bestätigungen sowie eine feste Allowlist dokumentierter Einstellungen. Unbekannte Form-Level-Einstellungen werden abgelehnt.

Capability: gravityforms_create_form. Merkmale: schreibend, nicht destruktiv, nicht idempotent. Pflicht: title. Output: form, verified.

wp-agent/update-gravity-form

Zweck: Prüft eine geplante manuelle Änderung eines Gravity-Forms-Formulars. Die Ability ruft GFAPI::update_form() nicht auf und antwortet vor jeder Mutation mit HTTP 409 und manual_only. Die Änderung erfolgt im Gravity-Forms-Backend.

Capability: gravityforms_edit_forms. Merkmale: manual-only, keine Remote-Mutation. Pflicht: form_id.

wp-agent/duplicate-gravity-form

Zweck: Dupliziert ein Formular über GFAPI::duplicate_form(). Ein optionaler Titel wird über GFAPI::update_form_property() gesetzt. Schlägt das Umbenennen fehl, wird die unvollständige Kopie wieder gelöscht. Felder und optionaler Titel werden per Read-back verifiziert.

Capability: gravityforms_create_form und gravityforms_edit_forms. Merkmale: schreibend, nicht destruktiv, nicht idempotent. Pflicht: form_id; optional title.

wp-agent/delete-gravity-form

Zweck: Prüft die Eingabe für das manuelle dauerhafte Löschen eines Gravity-Forms-Formulars. Die Ability ruft GFAPI::delete_form() nicht auf und antwortet vor jeder Mutation mit HTTP 409 und manual_only.

Capability: gravityforms_delete_forms. Merkmale: manual-only, keine Remote-Mutation. Pflicht: form_id, confirm.

Gravity Forms vergibt diese drei Formular-Capabilities nicht automatisch an einen normalen Redakteur. Die Verbindungsseite kann sie gezielt für einen sicheren Agent-Nutzer ergänzen. Beim späteren Entfernen oder bei der Plugin-Deinstallation werden nur die Capabilities entzogen, die WPAgently selbst ergänzt und protokolliert hat. Bereits vorhandene Rollen- oder Nutzerrechte bleiben erhalten.

Formidable Forms

Die sechs Abilities list-formidable-forms, get-formidable-form, create-formidable-form, update-formidable-form, duplicate-formidable-form und delete-formidable-form verwenden ausschließlich die nativen Modellmethoden von FrmForm und FrmField. Listen sind auf höchstens 100 Ergebnisse pro Seite und insgesamt 5.000 Formulare begrenzt. Leseantworten enthalten nur ausdrücklich freigegebene Formular- und Feldeigenschaften. Unbekannte Add-on-Optionen werden nicht ausgegeben. Standardwerte vorhandener Passwort- und versteckter Felder werden redigiert und können nicht geändert werden.

Neue Felder sind auf die portablen Typen text, email, url, phone, number, textarea, checkbox, radio und select begrenzt. Beschreibungen und Werte werden als Klartext behandelt. Pro Formular sind höchstens 500 Felder und pro Feld höchstens 500 Auswahlwerte zulässig. Auch Textlängen und verschachtelte Standardwerte sind begrenzt. Größere bestehende Formulare werden mit HTTP 413 abgewiesen, statt eine unbeschränkte MCP-Antwort zu erzeugen. Erstellen, Aktualisieren und Duplizieren werden frisch eingelesen und verifiziert. Teilupdates erhalten nicht übergebene Formularwerte sowie unbekannte interne Feldoptionen. Wenn Formidable für eine nicht verifizierbare Neuanlage oder Kopie bereits eine Formular-ID zurückgegeben hat, bleiben das Formular und mögliche zwischenzeitlich von anderer Seite angelegte Einreichungen erhalten. Die Ability antwortet dann mit HTTP 409 wpagent_formidable_recovery_required, recovery_required: true und der nicht sensiblen form_id; prüfe den aktuellen Zustand manuell. Wenn ein nativer FrmForm::create()- oder FrmForm::duplicate()-Aufruf nach einer gespeicherten Anlage oder Kopie abbricht, bevor er die ID zurückgibt, antwortet die Ability mit HTTP 409 wpagent_formidable_recovery_required, recovery_required: true und ohne form_id, weil keine sichere Zuordnung möglich ist. Eine fehlgeschlagene Formzuweisung enthält keine Formular-ID und antwortet mit HTTP 500 wpagent_formidable_create_failed, nicht mit einer Recovery-Antwort. Bei nicht verifizierten Teilupdates erfolgt ebenfalls keine automatische Folgemutation. Eine Duplizierung darf die von Formidable neu vergebenen Feld-IDs korrekt umschreiben. wp-agent/delete-formidable-form ist manual-only: Es löscht kein Formular, keine Felder und keine Einträge, sondern antwortet vor jeder Mutation mit HTTP 409 und manual_only. Das Löschen erfolgt im Formidable-Forms-Backend. expected_form_key kann dabei einen zwischenzeitlich ausgetauschten Datensatz mit HTTP 409 abweisen.

Lesen erfordert frm_view_forms, Schreiben frm_edit_forms und Löschen frm_delete_forms. Die Verbindungsseite kann diese drei Rechte gezielt an einen sicheren Agent-Nutzer vergeben und entfernt später ausschließlich selbst protokollierte Ergänzungen. Die Mutation-Sperre besitzt eine Ablaufzeit und wird nur durch ihren Besitzer freigegeben.

Formularmigration zwischen sechs Formularanbietern

wp-agent/preview-form-migration unterstützt WPForms, Ninja Forms, Contact Form 7, Fluent Forms, Gravity Forms und Formidable Forms. Die Ability liest ein vorhandenes Formular über den berechtigungsgeprüften nativen Pfad und überführt seine portable Feldstruktur in das versionierte Format wpagently-portable-form. Für WPForms wird die native Antwort intern um die für eine verlässliche Strukturprüfung notwendigen gespeicherten Feldeigenschaften ergänzt. Contact Form 7 wird über seine öffentliche Objekt- und Form-Tag-API gelesen. Unterstützt werden die portablen Feldtypen text, email, textarea, number, checkbox, radio und select. Titel, Feldreihenfolge, Typ, Beschriftung, Hilfetext, Platzhalter, Standardwert, Pflichtstatus und Auswahlwerte werden übernommen. Die Absende-Beschriftung wird ebenfalls übernommen, außer wenn Quelle oder Ziel Formidable Forms ist. Dessen begrenzter sicherer Adapter stellt diese Eigenschaft nicht bereit. portable_submit_label: false und omitted: ["submit_label"] weisen darauf hin.

Komplexe Namensfelder, Telefonnummern, HTML-, Layout- und proprietäre Sonderfelder sowie gekürzte oder bereinigungsbedürftige Werte erscheinen in unsupported_fields. Dasselbe gilt für nicht portable Feldsemantik wie Berechnungen, Eingabemasken, Wertebereiche, Mehrfachauswahl, separate Auswahlwerte, Auswahlbilder oder bedingte Logik. portable_fields_lossless ist dann false. Die Vorschau schreibt nichts und ist auf 200 Quellfelder sowie 200 Auswahlwerte pro Feld begrenzt.

wp-agent/migrate-form verlangt zusätzlich confirm: true und verweigert jede im Ziel nicht vollständig darstellbare portable Feldstruktur mit HTTP 409. Die Ability erzeugt ausschließlich eine neue Strukturkopie bei einem der fünf anderen Anbieter. Anschließend liest sie das Ziel vollständig neu ein und vergleicht alle portablen Eigenschaften. Bei einer Abweichung wird die Zielkopie wieder gelöscht und der Vorgang schlägt sichtbar fehl. Scheitert auch dieses Löschen, meldet sie stattdessen wpagent_form_migration_rollback_failed und fordert zur manuellen Prüfung auf. Das Quellformular wird weder geändert noch gelöscht. Contact Form 7 erhält zugängliches, neu erzeugtes Markup. Checkboxen und Radiogruppen verwenden ein valides fieldset mit legend, damit CF7 nicht mehrere Controls innerhalb eines einzelnen label erzeugt. Ein CF7-Quellfeld braucht eine eindeutig zuordenbare Beschriftung. Doppelte Feldnamen, mehr als 200 Auswahlwerte, eine fehlende, leere oder mehrfache Absende-Schaltfläche und nicht sicher als Form-Tag darstellbare Werte blockieren die Vorschau. Radiofelder sind in CF7 immer erforderlich. Auch eine gleichzeitige Kombination aus Platzhalter und Standardwert kann deshalb nicht migriert werden. Benachrichtigungen, Bestätigungen, bedingte Logik, ursprüngliches Markup und Layout, anbieterspezifische Formulareinstellungen und vorhandene Einträge werden bewusst nicht kopiert. target_behavior: provider_defaults und omitted[] weisen darauf maschinenlesbar hin. Ein neues CF7-Ziel erhält eine validierte Standardbenachrichtigung aus seinen tatsächlich erzeugten Feld-Tags. Andere Ziele verwenden die Voreinstellungen ihres Anbieters. Jedes Ziel muss vor dem produktiven Einsatz fachlich konfiguriert werden.

WPForms Lite, Ninja Forms, Contact Form 7, Fluent Forms und Formidable Forms sind praktisch gegen echte installierte Plugins verifiziert. Fluent Forms, Gravity Forms und Formidable Forms besitzen zusätzlich vollständige Lese-, Ziel-, Read-back- und Rollback-Vertragstests. Die bidirektionale Fluent-Forms-Abbildung wurde gegen eine echte Ninja-Forms-Installation geprüft. Fluent Forms 6.2.11 und Formidable Forms 6.33.1 bestehen außerdem einen echten portablen Create-, Read-back- und Löschzyklus. Die praktische Migrationsprüfung mit dem lizenzierten Original-Plugin Gravity Forms bleibt offen.

Die Vorschau verlangt das jeweilige WPAgently-Leserecht des Quellanbieters. Die Migration verlangt zusätzlich das Lese- und Schreibrecht des Zielanbieters, weil der Zielzustand nach dem Anlegen vollständig neu eingelesen werden muss. Fehlt eines dieser Rechte, endet die Anfrage vor jedem Schreibzugriff. Die WPForms-eigene MCP-Schreibfreigabe und die Ninja-Forms-Quarantäne bleiben wirksam. Merkmale: Vorschau lesend und idempotent; Migration schreibend, nicht destruktiv gegenüber der Quelle und nicht idempotent.

Weglot

wp-agent/get-weglot-settings liest die aktive Weglot-Version, den Verbindungsstatus, Original- und Zielsprachen, die automatische Sprachweiterleitung, begrenzte Darstellungseinstellungen des Sprachumschalters sowie URL- und CSS-Selektor-Ausschlüsse. API-Schlüssel, öffentliche Schlüssel, benutzerdefiniertes CSS, Übersetzungsinhalte und unbekannte Provideroptionen bleiben vollständig verborgen. Vorhandene reguläre Ausdrücke in URL-Ausschlüssen sind sichtbar und fließen in den Zustands-Hash ein, können wegen möglicher Laufzeitrisiken aber nicht über WPAgently angelegt oder geändert werden.

wp-agent/update-weglot-settings prüft expected_hash und mindestens ein Änderungsfeld gegen die begrenzte sichere Eingabe. Die Ability ändert keine Weglot-Einstellung und antwortet vor jeder Mutation mit HTTP 409 und manual_only. Der Schlüssel muss bereits in Weglot selbst eingerichtet sein. Bis zu 30 eindeutige Zielsprachen, vier dokumentierte Flaggenstile, 50 relative URL-Ausschlüsse und 50 begrenzte CSS-Selektoren sind als manuelle Konfiguration zulässig. Originalsprache, Zielsprachen und benutzerdefinierte Codes dürfen nicht kollidieren. Die Änderung erfolgt im Weglot-Backend, danach wird der sichere Projektzustand erneut gelesen.

Beide Abilities verlangen manage_options. Merkmale: Lesen ist idempotent. wp-agent/update-weglot-settings ist manual-only, keine Remote-Mutation.

Astra

wp-agent/get-astra-design erkennt ein aktives Astra-Theme oder Astra-Child-Theme und liest 21 kuratierte Bereiche über Astras native WordPress-Abilities. Dazu gehören Container, Fließtext- und Überschriftentypografie, H1 bis H6, Absatzabstand, Link-Unterstreichung, globale Palette, Hintergrundfarben, Buttons, Blogarchiv, Einzelbeiträge, Einzelseiten, Sidebar, Scroll-to-top sowie Header- und Footer-Builder-Layouts. Die Antwort enthält pro verfügbarem Bereich den aktuellen Providerzustand und das strikte Eingabeschema sowie einen SHA-256-Hash über astra-settings, astra-color-palettes und die aktive Theme-Identität. Rohoptionen werden nicht ausgegeben. Ist Astra inaktiv oder sind dessen Lese- und Bearbeitungs-Abilities nicht aktiviert, bleibt die Operationsliste leer.

wp-agent/update-astra-design verlangt expected_hash, genau eine der 21 Operationen und ein nicht leeres settings-Objekt. Fontnamen, responsive Schriftgrößen, Zeilenhöhe, Zeichenabstand, Farben, Containerwerte, Button-Presets, Seitenbreiten sowie Header- und Footer-Zonen werden enger validiert als im Providervertrag. Die Palettenoberfläche verwendet neun benannte Rollen statt fehleranfälliger numerischer JSON-Schlüssel. Header und Footer akzeptieren nur die dokumentierten Komponenten in bekannten responsiven Zonen, begrenzen Listen und weisen doppelte Einträge ab. Jede gesendete Zonenliste ist der vollständige gewünschte Endzustand dieser Zone, keine anzuhängende Teilliste. Hintergrundbilder, freie CSS-Werte, Button-Abstände, Logo-Downloads, lokale Font-Dateien und Performance-Schalter sind nicht Teil dieses globalen Pfads. Individuelle Post-Metadaten besitzen den getrennten, beitragsbezogenen Vertrag unten. Jeder globale Write sperrt den vollständigen Astra-Einstellungsstand für fünf Minuten, prüft den Hash nach der Sperre erneut, schreibt über Astras Implementierung und zwingt die passende native Lese-Ability zu einem ungecachten Read-back. Nur eine semantisch exakte Bestätigung gilt als Erfolg. Providerfehler oder Abweichungen stellen astra-settings und astra-color-palettes gemeinsam wieder her und verifizieren den vollständigen Hash. Ein nicht verifizierbarer Rollback endet mit HTTP 500 und fordert zur sofortigen manuellen Kontrolle auf.

wp-agent/get-astra-post-design liest für einen konkreten post_id 16 normalisierte Astra-Vorgaben. Dazu gehören Inhalts- und Sidebar-Layout, Inhalts- und Sidebar-Stil, globaler, oberer, primärer, unterer und mobiler Header, Footer, Titel, Banner, Breadcrumbs, Beitragsbild, verwandte Beiträge und transparenter Header. inherit bedeutet, dass kein individueller Wert gespeichert ist und die globale Astra-Vorgabe gilt. Rohes Post-Meta und fremde Metafelder werden nicht ausgegeben. Der Zustands-Hash bindet die Theme-Identität, Beitrags-ID, Inhaltstyp, Existenz und exakten Wert aller erlaubten Providerfelder sowie Astras internes Layout-Migrationsflag.

wp-agent/update-astra-post-design verlangt denselben post_id, einen frischen expected_hash und mindestens eine eng typisierte Vorgabe. Teilupdates ändern ausschließlich die genannten Felder. inherit löscht nur die gewählte individuelle Vorgabe. Moderne Layoutwerte pflegen Astras Migrationsflag abhängig vom tatsächlich verbleibenden Layoutzustand. Der Write nutzt dieselbe globale Astra-Kurzzeitsperre wie die Theme-Einstellungen, liest alle erlaubten Metafelder nach der Persistierung zurück und bestätigt jeden angeforderten Endwert. Ein Fehler oder abweichender Read-back stellt Existenz und Wert sämtlicher erlaubter Metafelder einschließlich Migrationsflag wieder her und verifiziert den vollständigen Vorzustand. Fremde Beitragsmetadaten bleiben unberührt.

Die beiden globalen Abilities verlangen manage_options. Die beiden beitragsbezogenen Abilities verlangen grob edit_posts und prüfen zusätzlich bei jedem Aufruf WordPress' konkrete Meta-Capability edit_post für den Zielbeitrag. Alle vier liegen in der Expositionsgruppe Design. Astra selbst muss nur für die beiden globalen Pfade unter Astra > Dashboard > Einstellungen sowohl Abilities als auch Bearbeitungs-Abilities aktiviert haben. Ein normaler WPAgently-Redakteur erhält dadurch keine Administratorrechte. Merkmale: Beide Lesewege sind idempotent. Beide Aktualisierungen sind schreibend, nicht destruktiv und idempotent.

GeneratePress

wp-agent/get-generatepress-design erkennt GeneratePress oder ein aktives GeneratePress-Child-Theme und liest fünf kuratierte Bereiche aus dem nativen Theme-Einstellungsstand: Layout, globale Farben, Oberflächenfarben, Buttons und Typografie. Die Antwort enthält die aktive Theme-Version, die begrenzten Bereiche und einen SHA-256-Hash über den vollständigen gespeicherten generate_settings-Stand sowie die Parent- und Child-Theme-Identität. Rohoptionen und unbekannte Providerdaten werden nicht ausgegeben. Bei inaktivem Theme bleibt der sichere Bereich leer. Bei fehlenden GeneratePress-Laufzeitfunktionen scheitert der Pfad geschlossen.

wp-agent/update-generatepress-design verlangt expected_hash, genau einen Bereich und ein nicht leeres settings-Objekt. Layoutwerte, vorhandene globale Farb-Slugs, zwölf ausgewählte Oberflächenfarben, vier Buttonfarben sowie die Typografieziele body, h1, h2, h3 und buttons sind erlaubt. Freies CSS, neue Paletteneinträge, beliebige Selektoren, Fontdateien, GeneratePress-Premium-Elements, unbekannte Theme-Optionen und unkontrollierte Werte bleiben außerhalb dieses Pfads. Jeder Write sperrt den vollständigen Einstellungsstand für fünf Minuten, prüft den Konflikt-Hash innerhalb der Sperre, bewahrt unbekannte Providerdaten und erzeugt GeneratePress' nativen dynamischen CSS-Cache neu. Gespeicherter Bereich und CSS-Cache müssen den erwarteten Zustand exakt bestätigen. Bei einem Providerfehler oder einer Abweichung werden die vollständigen vorherigen Einstellungen und beide GeneratePress-Cache-Optionen wiederhergestellt und erneut geprüft.

Beide Abilities verlangen manage_options und liegen in der Expositionsgruppe Design. GeneratePress 3.6.1 ist lokal mit echten Layout-, Farb-, Typografie-, Sperr-, Konflikt-, CSS-Cache- und Rollback-Prüfungen abgedeckt. Die vorbereitete GitHub-Actions-Fixture installiert die jeweils aktuelle WordPress.org-Fassung und läuft erstmals nach Commit und Push. Merkmale: Lesen ist idempotent. Aktualisieren ist schreibend, nicht destruktiv und idempotent.

wp-agent/get-generatepress-post-design liest für einen öffentlichen Beitrag oder eine öffentliche Seite vier native Einzelvorgaben: Sidebar-Layout, Zahl der Footer-Widget-Bereiche, Inhaltscontainer und Titelanzeige. inherit bedeutet, dass kein wirksamer individueller Wert gespeichert ist. Der Zustands-Hash bindet Beitrags-ID, Inhaltstyp, Parent- und Child-Theme sowie Existenz und exakten Rohwert aller vier Metafelder. Fehlende und offiziell leere Standardwerte werden beide als Vererbung normalisiert, bleiben für Konflikterkennung und Rollback aber unterscheidbar. Doppelte Einzelwerte und unbekannte Providerwerte scheitern geschlossen.

wp-agent/update-generatepress-post-design verlangt post_id, einen frischen expected_hash und mindestens eine Änderung. Teilupdates ändern nur die genannten Felder. inherit entfernt ausschließlich die gewählte individuelle Vorgabe. Der Write prüft das konkrete edit_post-Recht, sperrt nur den Zielbeitrag, vergleicht den vollständigen Rohzustand innerhalb der Sperre und bestätigt explizite Werte zusätzlich über GeneratePress' echte Laufzeitfunktionen. Persistenzfehler oder Abweichungen stellen die exakte vorherige Darstellung einschließlich gespeicherter leerer Standardwerte wieder her und verifizieren deren Hash. Die als Beitragsübersicht konfigurierte Seite bleibt gesperrt, weil GeneratePress dort das globale Blog-Layout erzwingt und individuelle Seitenwerte wirkungslos wären. Attachments, Revisionen, Autosaves, nicht öffentliche Inhaltstypen und Premium-Elements bleiben außerhalb dieses Vertrags. Beide Abilities gehören zur Expositionsgruppe Design. Merkmale: Lesen ist idempotent. Aktualisieren ist schreibend, nicht destruktiv und idempotent.

OceanWP

wp-agent/get-oceanwp-design erkennt OceanWP oder ein aktives OceanWP-Child-Theme ab Version 4.1 und liest fünf kuratierte Bereiche aus den nativen Theme-Mods: Layout, globale Farben, responsive Typografie, Buttons und Header-Stil. Die Typografie umfasst Fließtext und globale Überschriften mit Desktop-, Tablet- und Mobilwerten. Die Antwort enthält die aktive Theme-Version und einen SHA-256-Hash über die vollständige Theme-Mod-Option sowie Parent- und Child-Theme-Identität. Rohoptionen und unbekannte Providerdaten werden nicht ausgegeben. Ungültige bekannte Providerwerte lassen den Pfad geschlossen scheitern.

wp-agent/update-oceanwp-design verlangt expected_hash, genau einen Bereich und ein nicht leeres settings-Objekt. Zulässig sind dokumentierte Layouts, Containerbreite und Einheit, sechs globale Farbrollen, vier Buttonfarben, sieben eingebaute Header-Stile sowie begrenzte responsive Typografie. Der benutzerdefinierte Header, beliebiges CSS, Fontdateien, Ocean-Extra-Module und unbekannte Theme-Optionen bleiben außerhalb dieses sicheren Pfads. Jeder Write sperrt die vollständige Theme-Mod-Option für fünf Minuten, prüft den Hash innerhalb der Sperre, bewahrt unbekannte Providerdaten und bestätigt den gespeicherten Bereich durch einen frischen Read-back. Providerfehler oder Abweichungen stellen die vollständige vorherige Option wieder her und verifizieren deren Hash.

Beide Abilities verlangen manage_options und liegen in der Expositionsgruppe Design. Schreibzugriffe sind nur im OceanWP-Head-Modus für Customizer-CSS erlaubt. Im Dateimodus fehlt dem freien Theme ein verlässlich aufrufbarer Regenerationspfad, daher endet ein Write vor jeder Mutation mit HTTP 409 und einer Umstellungsanleitung. OceanWP 4.2.2 ist lokal mit echten Layout-, Farb-, Typografie-, Header-, Sperr-, Konflikt-, Persistenz- und Rollback-Prüfungen abgedeckt. Die öffentliche GitHub-Actions-Fixture installiert die jeweils aktuelle WordPress.org-Fassung. Merkmale: Lesen ist idempotent. Aktualisieren ist schreibend, nicht destruktiv und idempotent.

wp-agent/get-oceanwp-post-design liest für einen öffentlichen Beitrag oder eine öffentliche Seite die nativen Einzelvorgaben ocean_post_layout und ocean_both_sidebars_style. Die normalisierte Antwort verwendet inherit, wenn Ocean Extra den offiziellen leeren Standardwert gespeichert hat oder die Metazeile fehlt. Sie enthält außerdem Beitragstyp und einen SHA-256-Konflikthash über Beitrag, Parent- und Child-Theme-Identität sowie den exakten erlaubten Roh-Metazustand. Doppelte Einzelwerte und unbekannte Providerwerte lassen den Pfad geschlossen scheitern.

wp-agent/update-oceanwp-post-design verlangt post_id, expected_hash und mindestens eine Änderung. Für layout sind inherit, rechte oder linke Sidebar, volle Breite, volle Bildschirmbreite und beide Sidebars erlaubt. Für both_sidebars_style sind inherit und die drei nativen OceanWP-Reihenfolgen erlaubt. Der Write prüft edit_post, sperrt nur den Zielbeitrag, vergleicht den vollständigen Rohzustand innerhalb der Sperre, erhält unberührte Metadaten und bestätigt explizite Werte zusätzlich über OceanWPs Laufzeitfunktionen. Persistenzfehler oder Abweichungen stellen die exakte vorherige Darstellung einschließlich eines vorhandenen leeren Standardwerts wieder her und verifizieren ihren Hash. Anhänge, Revisionen, Autosaves, nicht öffentliche Inhaltstypen sowie weitere Ocean-Extra-Bereiche bleiben außerhalb dieses Vertrags. Beide Abilities liegen in der Expositionsgruppe Design. Merkmale: Lesen ist idempotent. Aktualisieren ist schreibend, nicht destruktiv und idempotent.

wp-agent/get-oceanwp-post-title und wp-agent/update-oceanwp-post-title sind zwei zusätzliche, versionsgebundene Ocean-Extra-Abilities für individuelle Seitentitel-Overrides. Sie sind nur verfügbar, wenn OceanWP 4.2.2 und Ocean Extra 2.5.8 aktiv sind. Lesen liefert die normalisierten Werte für Seitenkopf, Überschrift, Stil, benutzerdefinierten Titel und Untertitel zusammen mit einem Zustands-Hash. Schreiben verlangt post_id, expected_hash und mindestens eine eng validierte Einstellung. Zulässig sind nur die dokumentierten Auswahlwerte sowie begrenzte Textüberschreibungen. Weitere Ocean-Extra-Module, Header und Roh-Metadaten bleiben ausgeschlossen. Nach dem Start einer Mutation führt jede unsichere Persistenz-, Read-back- oder Laufzeitprüfung fail-closed zu recovery_required. Es gibt dann weder ein automatisches Rollback noch eine automatische Folgemutation. Der aktuelle Zustand muss manuell geprüft werden.

wp-agent/get-oceanwp-post-layout-overrides und wp-agent/update-oceanwp-post-layout-overrides ergänzen einen getrennten, ebenfalls exakt an OceanWP 4.2.2 und Ocean Extra 2.5.8 gebundenen Layoutpfad. Lesen liefert ausschließlich normalisierte Header-Sichtbarkeit und -Stil, Footer-Widgets und -Unterzeile, eine aktive registrierte benutzerdefinierte Sidebar sowie die Inhaltsbreite mit Zustands-Hash. Schreiben verlangt post_id, expected_hash und mindestens eine begrenzte Einstellung. Eine individuelle Inhaltsbreite ist nur bei der nativen Beitragsvorlage both-sidebars zulässig. CSS, HTML, Dateipfade, nicht registrierte Sidebars und alle weiteren Providerfelder sind ausgeschlossen.

Der Write prüft Beitrag, Subsite, Provider, Berechtigung und gewählte Providerwerte nach dem Lock erneut. Er erneuert den beitragsgebundenen Lock unmittelbar vor der Mutation und nach Provider- sowie Laufzeit-Read-back. Abweichende oder nicht sicher lesbare Zustände führen nach einer begonnenen Mutation ausschließlich zu recovery_required; es gibt keine automatische Folgemutation und keine Behauptung eines vollständigen Rollbacks.

wp-agent/get-oceanwp-extra-modules und wp-agent/update-oceanwp-extra-module lesen oder ändern genau einen von fünf unter Ocean Extra 2.5.8 verifizierten Modulschaltern. My Library, Demo-Katalog und Admin-Benachrichtigungen sind les- und schreibbar. SVG-Uploads und der Frontend-Stileditor dürfen ausschließlich deaktiviert werden. Der Zustands-Hash bindet Subsite, Theme- und Pluginversion sowie alle fünf Rohoptionen. Der Write verlangt manage_options, einen create-only Lock, einen frischen Hash und einen exakten Gesamt-Read-back. Ein unklarer Zustand nach der Mutation ergibt recovery_required ohne automatisches Rollback. Die Wirkung gilt ab einer neuen WordPress-Anfrage, weil Ocean Extra Module beim Bootstrap lädt.

wp-agent/list-oceanwp-library-templates listet höchstens 100 veröffentlichte, passwortlose My-Library-Templates pro Seite. Zugelassen sind ausschließlich statische, shortcodefreie Core-Blöcke ohne Elementor-, SiteOrigin- oder Beaver-Builder-Zustand. Die Antwort enthält den Inhaltshash und die Blocktypen. wp-agent/get-oceanwp-post-library-templates liest die nativen Header- und Footer-Zuordnungen eines bearbeitbaren Beitrags. wp-agent/update-oceanwp-post-library-templates verlangt den Beitrags-Hash und für jedes neue Template dessen frischen Inhaltshash. Der Write sperrt den Zielbeitrag, prüft Provider, Berechtigung, Rohmetadaten und Templates erneut, schreibt nur ocean_header_style, ocean_custom_header_template und ocean_custom_footer_template und bestätigt OceanWPs native Laufzeitfunktionen. Nach begonnener Mutation führt jede Abweichung zu recovery_required ohne automatische Folgemutation.

Kadence

wp-agent/get-kadence-design erkennt Kadence oder ein aktives Kadence-Child-Theme ab Version 1.5 und liest sechs kuratierte Bereiche aus den nativen Providerzuständen: Inhaltsbreiten, alle 15 Farben der aktiven globalen Palette, globale Oberflächen- und Linkfarben, responsive Typografie für Fließtext und H1-H6, globale Buttons sowie die Positionen freier Desktop- und Mobilkomponenten des Header Builders. Die Antwort enthält die aktive Theme-Version und einen SHA-256-Hash über den von Kadence tatsächlich verwendeten Einstellungsspeicher, kadence_global_palette sowie die Parent- und Child-Theme-Identität. Im üblichen Theme-Modus ist der Einstellungsspeicher theme_mods_<stylesheet>. Ein abweichender Optionsmodus wird nur akzeptiert, wenn die Kadence-Laufzeit exakt den erwarteten Optionsnamen meldet. Rohoptionen und unbekannte Providerdaten werden nicht ausgegeben. Ungültige bekannte Providerwerte lassen den Pfad geschlossen scheitern.

wp-agent/update-kadence-design verlangt expected_hash, genau einen Bereich und ein nicht leeres settings-Objekt. Zulässig sind begrenzte Inhaltsbreiten, ein Wechsel zwischen den drei vorhandenen Paletten, einzelne Farben der aktiven Palette, vier globale Farbrollen, Schriftfamilie, Google-Font-Kennzeichnung, Gewicht, responsive Größe und Zeilenhöhe sowie Buttonfarben und responsive Radien. Im Bereich header darf genau eine freigegebene Kadence-Free-Komponente in eine native Desktop- oder Mobilzone verschoben, eingefügt oder entfernt werden. Positionen, Komponenten, Zeilen, Zonen, Gesamtzahl und Eindeutigkeit werden strikt geprüft. Beliebiges CSS, neue Paletteneinträge, Fontdateien, unbekannte Theme-Optionen und Kadence-Pro-Einstellungen bleiben außerhalb dieses sicheren Pfads. Kadence Forms verwenden den getrennten, oben dokumentierten Vertrag.

Jeder Write sperrt beide Providerzustände gemeinsam für fünf Minuten, erneuert die Sperre vor und nach der Mutation, prüft Berechtigung, Laufzeit und Konflikthash innerhalb der Sperre, bewahrt unbekannte Providerdaten und bestätigt den gespeicherten Bereich durch einen exakten Read-back. Auch der eigentliche Write ist ein bytegenauer Compare-and-Swap über Rohwert und Autoload-Attribut. Eine externe Änderung im letzten Schreibfenster bleibt dadurch erhalten und führt ohne eigene Mutation zu HTTP 409. Ein Rollback ändert ausschließlich die von diesem Request geschriebene Optionszeile und nur dann, wenn sie noch bytegenau dem eigenen erwarteten Write entspricht. Fremde Änderungen, Sperrverlust oder ein unklarer Zustand bleiben unangetastet und ergeben recovery_required. Der Test bestätigt den Header zusätzlich über Kadences echte Renderfunktion.

Beide Abilities verlangen manage_options und liegen in der Expositionsgruppe Design. Kadence 1.5.2 ist lokal mit echten Layout-, Paletten-, Farb-, Typografie-, Button-, Header-Builder-, Sperr-, Konflikt-, Ablauf-, Paralleländerungs-, Persistenz-, Render- sowie atomaren CAS-Schreib- und Rollback-Prüfungen abgedeckt. Die öffentliche GitHub-Actions-Fixture installiert die jeweils aktuelle WordPress.org-Fassung. Merkmale: Lesen ist idempotent. Aktualisieren ist schreibend, nicht destruktiv und idempotent.

wp-agent/list-gravity-entries

Zweck: Listet höchstens 100 Einträge eines Formulars über GFAPI::get_entries(). Status, Volltextsuche, Kalenderzeitraum und Pagination sind begrenzt. Feldwerte, IP-Adresse, Browserkennung und Zahlungsdaten bleiben standardmäßig verborgen und werden nur mit include_values: true ausgegeben.

Capability: gravityforms_view_entries. Merkmale: lesend, nicht destruktiv, idempotent. Pflicht: form_id. Optional: status, search, start_date, end_date, include_values, page, per_page.

wp-agent/get-gravity-entry

Zweck: Liest einen Eintrag über GFAPI::get_entry(). Die Antwort enthält dokumentierte Kerneigenschaften, Werte der im aktuellen Formular tatsächlich definierten Feld- und Input-IDs sowie dokumentierte Zahlungsfelder. Sämtliche unbekannten Add-on-Metadaten werden wegen möglicher Zugangsdaten bewusst ausgelassen.

Capability: gravityforms_view_entries. Merkmale: lesend, nicht destruktiv, idempotent. Pflicht: entry_id.

wp-agent/update-gravity-entry

Zweck: Aktualisiert Lesestatus, Markierung und bis zu 100 vorhandene numerische Feld- oder Input-IDs über GFAPI::update_entry_property() und GFAPI::update_entry_field(). expected_date_updated kann konkurrierende Änderungen abweisen. Teilfehler und fehlgeschlagene Read-backs lösen einen bestmöglichen Rollback aus.

Capability: gravityforms_edit_entries. Merkmale: schreibend, nicht destruktiv, idempotent. Pflicht: entry_id. Mindestens eines aus is_read, is_starred oder field_updates muss vorhanden sein.

wp-agent/set-gravity-entry-status

Zweck: Setzt einen Eintrag auf active, spam oder trash, liest ihn neu und rollt einen nicht verifizierbaren Statuswechsel zurück. Optional kann expected_date_updated einen veralteten Schreibversuch mit HTTP 409 stoppen.

Capability: gravityforms_edit_entries. Merkmale: schreibend, destruktiv, idempotent. Pflicht: entry_id, status.

wp-agent/delete-gravity-entry

Zweck: Prüft die Eingabe für das manuelle dauerhafte Löschen eines Gravity-Forms-Eintrags. Die Ability ruft GFAPI::delete_entry() nicht auf und antwortet vor jeder Mutation mit HTTP 409 und manual_only.

Capability: gravityforms_delete_entries. Merkmale: manual-only, keine Remote-Mutation. Pflicht: entry_id, confirm. Optional: expected_date_updated.

Eintragsrechte sind wegen möglicher Personen- und Zahlungsdaten vollständig von den Formularrechten getrennt. Sie werden beim Anlegen eines Agent-Nutzers nie automatisch vergeben. Die Gruppe entries erscheint vollständig nur in den Profilen Vollzugriff und Benutzerdefiniert. Das Profil Nur lesen kann die beiden lesenden Werkzeuge exponieren, aber die Gravity-Forms-Capability bleibt in jedem Fall zusätzlich erforderlich. Die Verbindungsseite kann die drei Eintrags-Capabilities gezielt ergänzen und entfernt später ausschließlich die protokollierten Ergänzungen.

wp-agent/refresh-builder-cache

Zweck: Erkennt die Builder-Signale eines Beitrags (wiederverwendet detect-builder) und löst die builder-spezifischen Cache-/Regenerations-Invalidierungen aus, damit das Frontend nicht auf veralteter Ausgabe stehen bleibt. Empirisch gegen die tatsächlich installierten Plugin-Versionen geprüft (nicht nur aus Dokumentation übernommen): Spectra 2.20.1 (__uagb_asset_version-Option plus _uag_page_assets-Meta-Löschung, entspricht wp spectra regenerate-css), GenerateBlocks 2.3.0 (GenerateBlocks_Enqueue_CSS::post_update_option()), WooCommerce 10.9.4 (wc_delete_product_transients()). Kadence 3.7.8 und WPBakery sind selbstheilend beim Rendern, keine Aktion nötig. Elementor, Breakdance und Oxygen: best-effort über bekannte In-Request-APIs, sofern die Klassen/Funktionen geladen sind; kein WP-CLI-Shell-Out aus dem REST-Request. Bricks ist im zugrunde liegenden Bauplan nicht in der Cache-Map enthalten, dafür wird keine Aktion behauptet.

Capability: edit_posts (grob) plus current_user_can('edit_post', $post_id) (über die Wiederverwendung von detect-builder).

Merkmale: schreibend, nicht destruktiv, idempotent.

Beispiel: { "post_id": 42 }

wp-agent/get-builder-compatibility

Zweck: Liefert für Gutenberg, Spectra One, Kadence, Spectra, GenerateBlocks, Elementor, Beaver Builder, Bricks, Breakdance, Oxygen und WPBakery eine maschinenlesbare Matrix aus Aktivstatus, Version, Speicherort, nativer Schreibunterstützung, Cache-Abdeckung und praktischer, praktisch lesender oder defensiver Validierung. Proprietäre Builder ohne stabile öffentliche Schreibschnittstelle werden ausdrücklich unter fail_closed gemeldet.

Capability: edit_posts.

Merkmale: lesend, nicht destruktiv, idempotent. Die Ability verändert keine Builder-Daten.

Output: builders[] enthält die Einträge. summary.native_write[] listet die nativ unterstützten Datenflächen, summary.fail_closed[] alle absichtlich abgelehnten Schreibpfade. Spectra One verwendet die nativen WordPress-Datenflächen für Global Styles und den Site Editor. Die Plugins Kadence Blocks, Spectra und GenerateBlocks sind praktisch lesbar, bleiben für rohe Block-Markup-Schreibzugriffe aber geschlossen.

wp-agent/get-elementor-document

Zweck: Liest ein bestehendes, mit Elementor gespeichertes Dokument über Elementors öffentliche Dokument-API. Die Antwort enthält die normalisierte Elementstruktur und gespeicherten Seiteneinstellungen jeweils im geschlossenen Builder-Dokumentumschlag {json,sha256,bytes}, außerdem Element- und Widget-Zusammenfassung, Elementor-Version, Bearbeitungs-URL und einen kanonischen SHA-256-Konflikt-Hash über Struktur und Einstellungen.

Capability: edit_posts (grob) plus current_user_can('edit_post', $post_id) und Elementors eigene Prüfung is_editable_by_current_user().

Merkmale: lesend, nicht destruktiv, idempotent. Ohne aktives Elementor oder bei einem nicht mit Elementor gebauten Beitrag endet die Ability fail-closed mit HTTP 409.

Pflicht: post_id. Output: post_id, built_with_elementor, elements und settings als Builder-Dokumentumschläge, element_count, widget_types[], elementor_version, edit_url, hash.

wp-agent/get-elementor-design-system

Zweck: Liest Elementors aktives globales Kit über die native Kit-API. Die Antwort enthält die vier Systemfarben, eigene Farben, die vier System-Typografie-Token, eigene Typografie, responsive Größen und Abstände, die Fallback-Schrift, Elementor-Version, Kit-ID und einen kanonischen SHA-256-Konflikt-Hash über den vollständigen semantischen Designzustand.

Capability: manage_options plus Elementors eigene Kit-Bearbeitungsprüfung.

Merkmale: lesend, nicht destruktiv, idempotent. Ohne aktives, bearbeitbares Elementor-Kit endet die Ability fehlersicher. Eigene Token sind auf jeweils 100 Einträge begrenzt. Farbwerte, IDs, Titel und Typografiewerte werden auch beim Lesen geprüft.

wp-agent/update-elementor-design-system

Zweck: Prüft eine geplante manuelle Änderung zuvor gelesener Elementor-Designbereiche gegen die begrenzten sicheren Werte. Die Ability speichert kein Kit und antwortet vor jeder Mutation mit HTTP 409 und manual_only. Die Änderung erfolgt im Elementor-Backend.

Capability: manage_options plus Elementors eigene Kit-Bearbeitungsprüfung.

Merkmale: manual-only, keine Remote-Mutation. Mindestens ein Designbereich muss zusätzlich zu expected_hash angegeben werden. Nach der manuellen Änderung den vollständigen Zustand erneut lesen.

wp-agent/get-elementor-global-classes

Zweck: Liest den vollständigen Global-Class-Zustand von Elementors v4 Atomic Elements. Der Pfad gibt keine Roh-CSS-Regeln aus. Stattdessen liefert er die vom aktiven Kit verwalteten Klassen, ihre nativen Varianten, die verfügbaren Breakpoints und einen kanonischen SHA-256-Konflikt-Hash über den gesamten Zustand.

Capability: manage_options plus Elementors eigene Capability für Global Classes.

Merkmale: lesend, nicht destruktiv, idempotent. Input ist ausschließlich ein leeres Objekt. Ohne aktives Elementor v4 mit Atomic Elements endet die Ability fehlersicher. Höchstens 1.000 Global Classes werden verarbeitet.

Output: kit_id, elementor_version, breakpoints[], classes[], total, hash.

wp-agent/create-elementor-global-class

Zweck: Erstellt eine neue Elementor-v4-Global-Class über den nativen Atomic-Elements-Vertrag. Die Klasse erhält einen sicheren CSS-Klassennamen und eine oder mehrere validierte Varianten, aber keine freie CSS- oder Rohdatenfläche.

Capability: manage_options plus Elementors eigene Capability für Global Classes.

Merkmale: schreibend, nicht destruktiv, nicht idempotent. Pflicht sind expected_hash, ein label mit 2 bis 50 sicheren CSS-Klassenzeichen und variants mit 1 bis 64 Einträgen. Jede Variante erlaubt in meta ausschließlich Breakpoint und State und verlangt ein nicht leeres props-Objekt mit höchstens 100 Einträgen. Die aktiven Breakpoints und das native Elementor-Schema validieren jeden Wert. Lock, Compare-and-Swap, Revision, vollständiges Read-back, Frontend-Prüfung und automatischer Rollback sichern den Schreibweg ab.

Output: der vollständige Global-Class-Zustand plus class, previous_hash, changed, verified, rolled_back.

wp-agent/update-elementor-global-class

Zweck: Ändert ausschließlich Label und/oder Varianten einer bestehenden Elementor-v4-Global-Class. Unverknüpfte Klassen und freie Roh-CSS-Pfade bleiben unberührt beziehungsweise geschlossen.

Capability: manage_options plus Elementors eigene Capability für Global Classes.

Merkmale: schreibend, nicht destruktiv, idempotent bei unverändertem Zielzustand. Pflicht sind expected_hash und class_id. Optional sind label und variants, mindestens eines davon muss übergeben werden. Für Label, Varianten, meta und props gelten dieselben Grenzen wie beim Erstellen. Lock, Compare-and-Swap, Revision, Read-back, Frontend-Prüfung und Rollback gelten auch für dieses Update.

Output: der vollständige Global-Class-Zustand plus class, previous_hash, changed, verified, rolled_back.

wp-agent/delete-elementor-global-class

Zweck: Prüft die Eingabe für das manuelle Löschen einer Elementor-v4-Global-Class. Die Ability löscht keine Klasse und antwortet vor jeder Mutation mit HTTP 409 und manual_only. Die Klasse und ihre Dokumentverwendungen bleiben unverändert.

Capability: manage_options plus Elementors eigene Capability für Global Classes.

Merkmale: manual-only, keine Remote-Mutation. Pflicht sind expected_hash, class_id, confirm=true und affected_post_ids als exakte aktuelle Liste mit höchstens 100 IDs. Ohne Übereinstimmung mit der aktuellen Nutzung endet die Ability fehlersicher.

Output: HTTP 409 mit manual_only, ohne Änderung.

wp-agent/set-elementor-element-global-classes

Zweck: Setzt die Global-Class-Zuordnung eines einzelnen Elementor-Elements über dessen v4-Atomic-Elements-Schnittstelle. Der Pfad nimmt ausschließlich bekannte Global-Class-IDs entgegen und bietet keinen Roh-CSS-Ersatz.

Capability: manage_options plus Elementors eigene Capability für Global Classes.

Merkmale: schreibend, nicht destruktiv, idempotent. Pflicht sind post_id, element_id, der Dokument-expected_hash und global_class_ids als eindeutige Liste mit höchstens 100 IDs. Das Ziel muss zu einem Elementor-v4-Atomic-Elements-Dokument gehören. Native Schema- und Breakpoint-Prüfung, Lock, Compare-and-Swap, Revision, vollständiges Read-back, Frontend-Prüfung und Rollback schützen die Zuweisung.

Output: der normale Elementor-Element-Schreibzustand plus global_class_ids.

wp-agent/list-elementor-widgets

Zweck: Listet die Widget-Typen aus der Registry der aktiven Elementor-Installation mit Suche, Kategorie und Pagination. Rohe HTML- und Shortcode-Widgets sowie sämtliche Legacy-Adapter mit dem Präfix wp-widget- bleiben ausgeschlossen. Titel, Kategorien und Keywords werden begrenzt und bereinigt. Fehlerhafte Drittanbieter-Widgets werden übersprungen, statt die gesamte Registry-Anfrage scheitern zu lassen.

Capability: edit_posts.

Merkmale: lesend, nicht destruktiv, idempotent. Optional: search, category, page, per_page (höchstens 200). Output: widgets[], total, page, per_page, total_pages, elementor_version. Jeder Widget-Eintrag meldet mit controls_count die Gesamtzahl schreibbarer Controls und mit controls_truncated, ob das zugehörige Schema wegen der 500-Control-Grenze gekürzt wird.

wp-agent/get-elementor-widget-schema

Zweck: Liest die schreibbaren Wert-Controls eines sicheren Widget-Typs direkt aus der aktiven Elementor-Registry. Elementor 4 legt optimierte Style-Controls getrennt von den normalen Controls ab. Der Leseweg führt beide öffentlichen Registry-Bereiche zusammen, statt Farben und Typografie stillschweigend zu verlieren. Strukturelle UI-Controls wie Sections, Tabs, Überschriften und Buttons werden nicht als schreibbar ausgegeben. Pro Control werden Name, Typ, Bezeichnung, Tab, Section, Style-, Responsive- und Dynamic-Status, die aktiven Geräte, der registrierte Werttyp, ein begrenzter JSON-Standardwert sowie höchstens 200 Optionen geliefert. Die Ausgabe ist auf 500 Controls begrenzt. controls_count nennt die tatsächlich gelieferten Controls, controls_total die vollständige Zahl und controls_truncated eine mögliche Kürzung.

Capability: edit_posts.

Merkmale: lesend, nicht destruktiv, idempotent. Pflicht: widget_type. Unsichere und unbekannte Widget-Typen werden fail-closed abgelehnt.

wp-agent/get-elementor-element

Zweck: Liest genau ein Element anhand seiner element_id aus einem bestehenden Elementor-Dokument. Die Antwort enthält den exakten Indexpfad, das Element im geschlossenen Builder-Dokumentumschlag {json,sha256,bytes} und den Konflikt-Hash des vollständigen Dokuments. Die Suche ist auf 2.000 Elemente und 64 Ebenen begrenzt und lehnt doppelte IDs ab.

Capability: edit_posts (grob) plus current_user_can('edit_post', $post_id) und Elementors eigene Prüfung is_editable_by_current_user().

Merkmale: lesend, nicht destruktiv, idempotent. Pflicht: post_id, element_id. Output: post_id, element_id, path[], element, document_hash, elementor_version.

wp-agent/create-elementor-page

Zweck: Erstellt einen neuen Elementor-Beitrag über Document::save(). Jedes Element muss eine eindeutige ID, einen in der aktiven Installation registrierten Element- oder Widget-Typ, JSON-kompatible Einstellungen und eine Kindliste besitzen. Rohe HTML-, Shortcode- und ungefilterte Legacy-Widgets sowie ausführbares Markup bleiben gesperrt. Der Pfad ist auf 2 MiB, 2.000 Elemente und 64 Ebenen begrenzt. Nach dem Speichern werden die von Elementor normalisierte Struktur, die angeforderten Seiteneinstellungen, Beitragsstatus und Frontend-Ausgabe erneut geprüft. Bei einer Abweichung wird der neue Beitrag entfernt.

Capability: edit_posts (grob), die konkrete create_posts-Capability des Beitragstyps und bei Veröffentlichung die von WordPress verlangte Publish-Capability.

Merkmale: schreibend, nicht destruktiv, nicht idempotent. Pflicht: title, elements. Optional: post_type (Standard page), status (draft, pending, private, publish; Standard draft), settings.

wp-agent/update-elementor-document

Zweck: Ersetzt die vollständige Elementor-Struktur und/oder einen Teil der Seiteneinstellungen über Document::save(). Ein ausdrücklich leeres settings-Objekt löscht die gespeicherten Seiteneinstellungen über Elementors öffentliche Settings-API. expected_hash muss dem zuletzt gelesenen Zustand entsprechen. Ein atomarer Kurzzeit-Lock verhindert parallele WPAgently-Schreibvorgänge. Vor dem Save entsteht eine Elementor-kompatible und gegen den erwarteten Zustand geprüfte WordPress-Revision. Unbekannte, unsichere oder nicht registrierte Element- und Widget-Typen, ausführbares Markup, doppelte IDs, übergroße oder zu tiefe Strukturen werden vor dem Schreiben abgelehnt. Struktur und angeforderte Einstellungen werden danach frisch gelesen und die Frontend-Ausgabe wird erzeugt. Bei Save-, Read-back- oder Render-Problemen stellt WPAgently Struktur und Einstellungen automatisch aus der Revision wieder her.

Capability: edit_posts (grob) plus edit_post und Elementors eigene Bearbeitungsprüfung.

Merkmale: schreibend, nicht destruktiv, idempotent bei identischem Konflikt-Hash und identischer Eingabe. Pflicht: post_id, expected_hash; zusätzlich mindestens elements oder settings. Output wie beim Lesepfad plus verified, frontend_verified, previous_hash und die wiederherstellbare revision_id.

wp-agent/update-elementor-element

Zweck: Ändert oder entfernt ausschließlich registrierte Wert-Controls eines einzelnen Elements, ohne die Geschwisterstruktur zu ersetzen. style_patch ergänzt einen sicheren, gerätebezogenen Pfad für registrierte Styles. Jeder Style wird nach Control-Name und den von Elementor aktiven Geräten desktop, tablet oder mobile angegeben. null entfernt den jeweiligen Gerätewert. Unterstützt werden streng validierte Farben, Slider, Dimensionen, Zahlen, Selects, Choices und Switcher mit begrenzten CSS-Einheiten und Schlüsselwörtern. Medien, URLs, freie Schriftwerte, Schattenobjekte und andere CSS-nahe Rohstrukturen bleiben über diesen Pfad geschlossen. Responsive Suffixe und nötige Gruppenaktivierungen werden nur aus Elementors öffentlicher Control- und Breakpoint-Registry abgeleitet. expected_hash schützt das vollständige Dokument vor veralteten Änderungen. Vor dem Schreiben prüft die Ability Dokumentberechtigung, Ziel-ID, Widget-Sicherheit, Control-Registry, JSON-Werte, Markup, Größe und Struktur. Ein Kurzzeit-Lock serialisiert WPAgently-Schreibvorgänge. Danach folgen Revision, Save über Elementors Dokument-API, exakte vollständige Rückleseprüfung, Frontend-Renderprüfung und eine Kompilierung der erwarteten Stylewerte über Elementors öffentliche Post-CSS-Klasse. Abweichungen lösen einen automatischen Rollback aus. Eine semantische Nulländerung erzeugt keine Revision.

Capability: edit_posts (grob) plus edit_post und Elementors eigene Bearbeitungsprüfung.

Merkmale: schreibend, nicht destruktiv, idempotent. Pflicht sind post_id, element_id, expected_hash und mindestens eines aus settings_patch, remove_settings oder style_patch. settings_patch und style_patch verwenden jeweils den geschlossenen Builder-Dokumentumschlag {json,sha256,bytes}. CSS-nahe Controls müssen über style_patch geändert oder entfernt werden. Output wie beim Elementor-Schreibpfad plus element_id, path[], element und changed.

wp-agent/create-elementor-element

Zweck: Erstellt einen begrenzten Elementor-Teilbaum an einer frei wählbaren Position. parent_id fehlt für die Dokumentwurzel, index fehlt für das Ende der jeweiligen Kindliste. Der öffentliche Elementkörper erlaubt ausschließlich elType, widgetType, settings, elements und isInner. Übergebene IDs werden für den gesamten Teilbaum verworfen und sicher neu erzeugt. Element- und Widget-Typen sowie alle gesetzten Controls müssen in der aktiven Elementor-Installation registriert und schreibbar sein. Widgets ohne ausdrücklich von Elementor gemeldete Verschachtelungsunterstützung dürfen nicht als Elternknoten dienen. Unsichere Widgets, ausführbares Markup, unbekannte Felder und Controls sowie übergroße oder zu tiefe Teilbäume werden vor dem Schreiben abgelehnt.

Capability: edit_posts (grob) plus edit_post und Elementors eigene Bearbeitungsprüfung.

Merkmale: schreibend, nicht destruktiv, nicht idempotent. Pflicht: post_id, expected_hash, element. Optional: parent_id, index. Output wie beim Elementor-Schreibpfad plus operation, changed, element_id, path[] und das frisch gelesene element.

wp-agent/duplicate-elementor-element

Zweck: Dupliziert einen vorhandenen Elementor-Teilbaum und fügt die Kopie an der gewählten Position ein. Jede Struktur-ID der Kopie wird neu erzeugt, die Quelle und ihre Geschwister bleiben unverändert. Anbieterspezifische Verweise innerhalb von Settings werden bewusst nicht geraten oder automatisch umgeschrieben. Sie bleiben exakt wie in der Quelle und werden durch die vollständige Rücklese- und Frontend-Prüfung abgesichert.

Capability: edit_posts (grob) plus edit_post und Elementors eigene Bearbeitungsprüfung.

Merkmale: schreibend, nicht destruktiv, nicht idempotent. Pflicht: post_id, element_id, expected_hash. Optional: parent_id, index. Output enthält zusätzlich die neue element_id, path[], previous_path[] der Quelle und das duplizierte element.

wp-agent/move-elementor-element

Zweck: Verschiebt einen vorhandenen Teilbaum innerhalb desselben Dokuments. Seine IDs, Settings und Kinder bleiben erhalten. Selbst- und Nachfahrenziele werden als Zyklus abgelehnt, Widgets können keine Kinder aufnehmen. index bezeichnet die endgültige Position nach dem Entfernen der Quelle. Ohne index wird am Ende eingefügt.

Capability: edit_posts (grob) plus edit_post und Elementors eigene Bearbeitungsprüfung.

Merkmale: schreibend, nicht destruktiv, idempotent. Pflicht: post_id, element_id, expected_hash. Optional: parent_id, index. Output enthält previous_path[], den frisch gelesenen path[], element und changed. Eine bereits erreichte Zielposition erzeugt keine Revision.

wp-agent/delete-elementor-element

Zweck: Prüft Ziel, Berechtigung und aktuellen Dokument-Hash. Die Ability löscht nichts remote, weil Elementor keine atomare Vergleich-und-Lösch-Operation gegen parallele Editor-Änderungen bietet. Nach der Prüfung folgt HTTP 409. Lösche den Teilbaum anschließend manuell im Elementor-Editor.

Capability: edit_posts (grob) plus edit_post und Elementors eigene Bearbeitungsprüfung.

Merkmale: Kompatibilitätsendpunkt ohne Remote-Mutation, manuell und destruktiv gemeint. Pflicht: post_id, element_id, expected_hash, confirm=true. Es gibt keinen Erfolgsoutput.

Erstellen, Duplizieren und Verschieben verwenden Konflikt-Hash, Kurzzeit-Lock, Revision, Rückleseprüfung und Frontend-Prüfung. Löschen bleibt manual-only.

wp-agent/restore-elementor-revision

Zweck: Stellt ausschließlich Elementor-Struktur und Seiteneinstellungen aus einer zum Beitrag gehörenden Elementor-Revision wieder her. Vor dem Schreiben wird auch der Revisionsinhalt gegen dieselben Größen-, Struktur-, Widget- und Markup-Grenzen wie ein normales Update geprüft. Leere Revisions-Settings löschen neuere Seiteneinstellungen vollständig. Titel, Auszug, Status und andere WordPress-Beitragsfelder werden bewusst nicht aus der allgemeinen Revision übernommen. Der aktuelle expected_hash verhindert das Überschreiben zwischenzeitlicher Elementor-Änderungen. Vor dem Restore entsteht eine zusätzliche Sicherheitsrevision. Der Zielzustand wird erneut gelesen und im Frontend gerendert; bei einem Fehler wird die Sicherheitsrevision automatisch zurückgespielt.

Capability: edit_posts (grob) plus edit_post und Elementors eigene Bearbeitungsprüfung.

Merkmale: schreibend, destruktiv gegenüber der aktuellen Elementor-Struktur, nicht idempotent. Pflicht: post_id, revision_id, expected_hash. Output enthält zusätzlich safety_revision_id.

wp-agent/get-beaver-document

Zweck: Liest ein aktives Beaver-Builder-Layout über dessen Modell-API als begrenzte flache Knotenliste. Die Ausgabe enthält Knotentyp, Modultyp, Eltern-ID, Position, Schreibbarkeit, Beaver-Version und einen kanonischen SHA-256-Konflikt-Hash. Die Einstellungen jedes Knotens liegen im geschlossenen Builder-Dokumentumschlag {json,sha256,bytes}. Globale, verknüpfte, unbekannte und unsichere Module bleiben unveränderbar; übergroße oder nicht normalisierbare öffentliche Werte werden nicht offengelegt.

Capability: edit_posts (grob) plus current_user_can('edit_post', $post_id). Merkmale: lesend, nicht destruktiv, idempotent. Pflicht: post_id.

wp-agent/list-beaver-modules

Zweck: Listet installierte Beaver-Builder-Module aus der aktiven Registry. Ausführbare Rohmodule wie HTML, Shortcode und eingebettete WordPress-Widgets werden ausgeschlossen. Suche, Gruppe und Pagination sind begrenzt.

Capability: edit_posts. Merkmale: lesend, nicht destruktiv, idempotent. Optional: search, group, page, per_page.

wp-agent/get-beaver-module-schema

Zweck: Liest die begrenzten schreibbaren Felder eines sicheren Modultyps aus der aktiven Beaver-Registry. Strukturelle Formularfelder, unbekannte Feldtypen, ausführbare Werte und übergroße Optionslisten bleiben ausgeschlossen.

Capability: edit_posts. Merkmale: lesend, nicht destruktiv, idempotent. Pflicht: module_type.

wp-agent/create-beaver-page

Zweck: Erstellt über Beaver Builders Modell-API eine Seite aus höchstens den konfigurierten Zeilen, Spalten und sicheren Modulen. Layouts und Module müssen in der aktiven Installation registriert sein, Einstellungen werden gegen die jeweiligen Provider-Schemata validiert. Nach Finalisierung werden Seitentitel, Status, angeforderte Knoten, Einstellungen, Eltern, Positionen, sichere anbieterseitige Standardnachfahren und das Frontend geprüft. Ein fehlerhafter oder unvollständiger Entwurf wird vollständig entfernt.

Capability: edit_posts, die konkrete create_posts-Capability des Seitentyps und bei Veröffentlichung dessen Publish-Capability. Merkmale: schreibend, nicht destruktiv, nicht idempotent. Pflicht: title, rows. Optional: status.

wp-agent/update-beaver-node

Zweck: Ändert oder entfernt ausschließlich schema-validierte Einstellungen eines vorhandenen lokalen Knotens. expected_hash schützt das vollständige Layout. Pflicht: post_id, node_id, expected_hash, settings_patch als geschlossener Builder-Dokumentumschlag {json,sha256,bytes}; optional: remove_settings.

Capability: edit_posts plus edit_post. Merkmale: schreibend, nicht destruktiv, idempotent.

wp-agent/create-beaver-module

Zweck: Fügt ein registriertes sicheres Modul in eine vorhandene Beaver-Spalte ein. Die Position darf höchstens dem Ende der vorhandenen Kindliste entsprechen. Auch automatisch vom Modul erzeugte Standardnachfahren müssen den sicheren Schreibvertrag erfüllen. Pflicht: post_id, parent_id, module_type, expected_hash; optional: position, settings.

Capability: edit_posts plus edit_post. Merkmale: schreibend, nicht destruktiv, nicht idempotent.

wp-agent/create-beaver-column-group

Zweck: Erstellt eine native Spaltengruppe in einer lokalen Zeile oder genau eine verschachtelte Spaltenebene innerhalb einer lokalen Spalte. Das Layout muss in Beaver Builder registriert sein. Die Position bezieht sich auf alle direkten Kinder des Elternknotens und darf höchstens dem Ende der Kindliste entsprechen. Globale oder verknüpfte Eltern, eine zweite Verschachtelungsebene und Layouts oberhalb der Knotengrenze bleiben gesperrt. Pflicht: post_id, parent_id, layout, expected_hash; optional: position.

Capability: edit_posts plus edit_post. Merkmale: schreibend, nicht destruktiv, nicht idempotent.

wp-agent/duplicate-beaver-node

Zweck: Dupliziert eine lokale Zeile, Spalte oder ein sicheres Modul über die native Modell-API. Der gesamte Teilbaum wird vor dem Schreiben geprüft. Der Read-back verlangt dieselbe Struktur und alle ausdrücklich gespeicherten Einstellungen. Von Beaver Builder beim Kopieren materialisierte Standardfelder dürfen zusätzlich erscheinen. Globale, verknüpfte, unbekannte oder unsichere Nachfahren lehnen die Operation vollständig ab.

Capability: edit_posts plus edit_post. Merkmale: schreibend, nicht destruktiv, nicht idempotent. Pflicht: post_id, node_id, expected_hash.

wp-agent/move-beaver-node

Zweck: Verschiebt ausschließlich ein lokales sicheres Modul in eine vorhandene Beaver-Spalte. Zeilen und Spalten werden im sicheren Pfad nicht umgehängt. Pflicht: post_id, node_id, parent_id, expected_hash; optional: position.

Capability: edit_posts plus edit_post. Merkmale: schreibend, nicht destruktiv, laut Annotation nicht idempotent. Eine bereits erreichte Zielposition erzeugt keine Revision.

wp-agent/delete-beaver-node

Zweck: Prüft nach confirm=true den lokalen Knoten, seine Nachfahren und den aktuellen Layout-Hash. Die Ability löscht nichts remote, weil Beaver Builder keine atomare Vergleich-und-Lösch-Operation gegen parallele Editor-Änderungen bietet. Danach folgt HTTP 409. Lösche den Knoten anschließend manuell im Beaver-Builder-Editor.

Capability: edit_posts plus edit_post. Merkmale: Kompatibilitätsendpunkt ohne Remote-Mutation, manuell und destruktiv gemeint. Pflicht: post_id, node_id, expected_hash, confirm.

wp-agent/restore-beaver-revision

Zweck: Prüft nach confirm=true, ob die Revision zum Beitrag gehört, sicher lesbar ist und zum aktuellen Hash passt. Die Ability stellt nichts remote wieder her, weil Beaver Builder keine atomare Vergleich-und-Wiederherstellungs-Operation bietet. Danach folgt HTTP 409. Stelle die Revision anschließend manuell im Beaver-Builder-Editor wieder her.

Capability: edit_posts plus edit_post. Merkmale: Kompatibilitätsendpunkt ohne Remote-Mutation, manuell und destruktiv gemeint. Pflicht: post_id, revision_id, expected_hash, confirm.

Die fünf remote schreibenden Pfade für bestehende Beaver-Layouts verwenden denselben vollständigen Konflikt-Hash, einen atomaren Kurzzeit-Lock, eine gegen den Ausgangszustand geprüfte Revision, semantisch exakte Rückleseprüfung, Frontend-Renderprüfung und Cache-Bereinigung. Je nach Operation werden vollständige Knoteneinstellungen, Eltern und Positionen oder die Gleichheit duplizierter Teilbäume geprüft. Positionen außerhalb des vorhandenen Zielknotens werden vor dem Schreiben abgelehnt. Fehler im Provider, beim Speichern, Rücklesen oder Rendern lösen einen geprüften vollständigen Rollback aus. Kann selbst der Rollback nicht exakt verifiziert werden, bleibt die Wiederherstellungsrevision erhalten und die Operation meldet ausdrücklich einen Rollback-Fehler. delete-beaver-node und restore-beaver-revision prüfen Berechtigung, Ziel und aktuellen Hash, führen aber keine Remote-Mutation aus.

wp-agent/list-spectra-blocks

Zweck: Liest die in Spectras eigener Verwaltungsoberfläche sichtbare Blockbibliothek aus der nativen Registry. Interne Kindblöcke, Erweiterungen, veraltete Blöcke und Blöcke mit fehlender Plugin-Abhängigkeit bleiben ausgeschlossen. Jeder Eintrag enthält Slug, Blockname, Titel, Beschreibung, Kategorien, Standardstatus und wirksamen Aktivierungsstatus. Der Hash deckt die vollständige rohe _uagb_blocks-Option einschließlich unbekannter zukünftiger Schlüssel ab.

Capability: manage_options. Merkmale: lesend, nicht destruktiv, idempotent. Optional: search, status (all, enabled, disabled), page, per_page. Output: version, items[], Pagination und hash.

wp-agent/set-spectra-block-status

Zweck: Aktiviert oder deaktiviert genau einen sichtbaren Spectra-Block über UAGB_Admin_Helper::update_admin_settings_option(). Interne und unbekannte Slugs werden abgelehnt. Ein Kurzzeit-Lock und expected_hash verhindern parallele WPAgently-Schreibvorgänge und veraltete Änderungen. Der vollständige Optionswert wird rückgelesen. Bei einer Abweichung wird nur der Zielschlüssel zurückgesetzt, damit gleichzeitig hinzugekommene fremde Schlüssel erhalten bleiben.

Capability: manage_options. Merkmale: schreibend, nicht destruktiv, idempotent. Pflicht: slug, enabled, expected_hash. Output: block, verified, previous_hash, hash.

wp-agent/list-spectra-popups

Zweck: Listet Spectras Beitragstyp spectra-popup mit Suche, Status-, Typ-, Aktivierungs- und Paginierungsfilter. Ausgegeben werden ausschließlich ID, Titel, Slug, Status, Typ, Aktivierung, Wiederholung, Änderungszeit und Zustands-Hash. Beliebige fremde Post-Metadaten bleiben verborgen.

Capability: manage_options. Merkmale: lesend, nicht destruktiv, idempotent. Optional: search, status, type, enabled, page, per_page, order, order_by.

wp-agent/get-spectra-popup

Zweck: Liest ein vorhandenes Spectra-Popup einschließlich Rohinhalt und rekursivem Blockbericht. Der Bericht meldet Blockzahl, Freeform-Anteil, Blocktypen und das Vorhandensein des zwingenden uagb/popup-builder-Wrappers. Inhalte über 1 MiB werden abgelehnt. Fremde Metadaten werden nicht ausgegeben.

Capability: manage_options. Merkmale: lesend, nicht destruktiv, idempotent. Pflicht: id. Output: Popup-Zusammenfassung plus content, block_count, freeform_count, block_types, has_popup_wrapper.

wp-agent/create-spectra-popup

Zweck: Erstellt ein natives Spectra-Popup oder Banner aus 1-20 begrenzten Core-Komponenten. Erlaubt sind Markdown, Trenner und Abstände bis 400 Pixel. Der Anbieter-Wrapper entspricht der realen Serialisierung von Spectra 2.20.1. Neue Objekte bleiben unabhängig vom WordPress-Status deaktiviert und müssen nach fachlicher Prüfung separat aktiviert werden.

Capability: manage_options. Merkmale: schreibend, nicht destruktiv, idempotent. Pflicht: title, type (popup oder banner), components, idempotency_key. Optional: status (draft, pending, private, publish), repetition (1-100). Derselbe Schlüssel liefert nur bei unverändertem Zielzustand dasselbe Objekt zurück. Eine andere Anfrage oder eine nachträgliche Änderung unter demselben Schlüssel wird als Konflikt abgewiesen. Eine schlüsselbezogene Kurzzeitsperre verhindert parallele Doppelanlagen. Titel, Status, Typ, deaktivierter Zustand, Wiederholung, vollständiger Inhalt, nativer Wrapper und ausschließlich erlaubte innere Core-Blöcke werden nach dem Speichern geprüft. Die drei internen Idempotenzwerte müssen jeweils genau einmal und unverändert vorhanden sein. Eine unvollständige oder mehrdeutige Anlage wird vollständig entfernt. Output: popup, verified, created.

wp-agent/update-spectra-popup

Zweck: Ändert ausschließlich Titel, WordPress-Status, Popup-Typ, Aktivierung und Wiederholung eines vorhandenen Spectra-Objekts. Aktiviert werden dürfen nur veröffentlichte Popup- oder Banner-Objekte mit vorhandenem Popup-Builder-Wrapper. Bei einem Typwechsel werden das native Blockattribut, die Wrapper- und Containerklassen sowie die zugängliche Schließen-Beschriftung gemeinsam umgestellt. Beliebiger Popup-Inhalt und fremde Metadaten sind nicht schreibbar. Ein Hash und Kurzzeit-Lock schützen vor Konflikten. Alle Zielfelder und der erwartete Inhalt werden rückgelesen, Hook-Mutationen lösen einen vollständigen semantischen Rollback aus.

Capability: manage_options. Merkmale: schreibend, nicht destruktiv, idempotent. Pflicht: id, expected_hash und mindestens eines aus title, status, type, enabled, repetition. Output: popup, verified, previous_hash.

wp-agent/delete-spectra-popup

Zweck: Verschiebt ein vorhandenes Spectra-Popup nach confirm: true konfliktgeschützt in den Papierkorb. force: true antwortet ohne Löschung mit HTTP 409, weil WordPress keine atomare Compare-and-Delete-Operation gegen parallele Editor-Änderungen anbietet. Ist der WordPress-Papierkorb deaktiviert, verweigert der reversible Pfad die Operation. expected_hash verhindert das Löschen eines zwischenzeitlich veränderten Objekts.

Capability: manage_options. Merkmale: schreibend, reversibler Papierkorb, nicht idempotent. Pflicht: id, expected_hash, confirm. Optional: force. Output: id, trashed, deleted.

Die Spectra-Spezialisierung trennt die allgemeine Core-Block-Pipeline weiterhin vom anbieterspezifischen Wrapper. Nur create-spectra-popup darf den praktisch geprüften uagb/popup-builder-Vertrag erzeugen. Freies Spectra-Markup, anbieterspezifische innere Blöcke, beliebige Popup-Inhaltsänderungen sowie tiefe Style- und Breakpoint-Einstellungen bleiben geschlossen.

wp-agent/render-verify

Zweck: Rendert einen Beitrag serverseitig gegen die effektive Frontend-Ausgabe (apply_filters('the_content', ...), nicht die rohe DB-Zeile, nicht per HTTP-Selbstanfrage) und prüft sie gegen vier belegte „Read-back lügt“-Fallen: (a) core/freeform (stiller Classic-Editor-Fallback), (b) Builder-Render-Mismatch (ein postmeta-JSON-Builder-Datensatz ist gespeichert, aber das zugehörige Plugin ist nicht aktiv, das Frontend rendert dann nur rohes post_content), (c) Contact-Form-7-Falle (Formularkonfiguration liegt in Postmeta _form, post_content ist bei diesem Post-Type inert), (d) SEO-Read-Back. Rank Math und SEOPress werden über ihre provider-eigenen Post-Metafelder gelesen, AIOSEO über seine native SEO-Ability und Yoast über seine wirksame Meta Surface, die in Produktion das Indexable berücksichtigt. Nur das jeweils aktive unterstützte SEO-Plugin wird geprüft.

Capability: edit_posts (grob) plus current_user_can('edit_post', $post_id) (über die Wiederverwendung von detect-builder).

Merkmale: lesend, nicht destruktiv, idempotent.

Beispiel: { "post_id": 42 }

---

14. Agent-Wissen und Designprofil

Diese 17 Abilities speichern expliziten, begrenzten Website-Kontext in festen WordPress-Optionen oder lesen eine redigierte lokale Systemdiagnose. Sie zeichnen keine Gespräche automatisch auf und erzeugen keinen externen Datentransfer. Lesende Pfade verlangen edit_posts. Änderungen an Site Context, Skills, Designprofil und Designrichtungen verlangen manage_options. Ein Editor darf Memories bewusst speichern und löschen.

Die sechs lesenden Sammlungen Site Context, Designprofil, Designrichtungen, Skills, Memory und Systemdiagnose stehen zusätzlich als authentifizierte MCP-Ressourcen unter wpagently://site/context, wpagently://site/design, wpagently://site/design-directions, wpagently://site/skills, wpagently://site/memory und wpagently://site/diagnostics bereit. Site-Skills mit aktivierter Prompt-Freigabe erscheinen außerdem als native MCP-Prompts.

Der Schriftimport ignoriert CSS-Kommentare und Werte in gewöhnlichen CSS-Strings, beachtet bei mehrfachen Custom Properties die letzte wirksame Deklaration und akzeptiert die letzte Deklaration eines Blocks auch ohne Semikolon. Dynamische Ausdrücke wie var(), url(), calc() oder clamp() sowie Größenwerte anstelle einer Schrift werden abgelehnt. Die Vorschau trennt Überschriften- und Fließtextschrift. Das Backend bewahrt beim Bearbeiten einer Richtung ihr gespeichertes Profil, solange der Administrator nicht ausdrücklich einen neuen Import oder das aktuelle globale Profil auswählt.

---

15. Bestätigter Live-Editor

Diese fünf Abilities verbinden den gebundenen Redakteur mit einer kurzlebigen, von einem Administrator geöffneten Browser-Arbeitsfläche im nativen Gutenberg- oder Elementor-Editor. Sie verwenden die vorhandene MCP-Verbindung. Der Agent erhält weder den Administrator-Cookie noch einen zweiten lokalen Server. Der Server prüft bei jedem Befehl erneut Sitzung, Nutzerrolle und die Bearbeitungsberechtigung des geöffneten Beitrags. Schreibbefehle werden sichtbar einzeln bestätigt. Gutenberg-Änderungen bleiben bis zum gesondert bestätigten save-post im Browser. Ein vollständiger SHA-256-Zustandshash schützt Blockstruktur und Beitragsfelder vor parallelen Änderungen. Autosaves bleiben während der Sitzung gesperrt. Neue und geänderte Gutenberg-Blöcke sind auf core, kadence, generateblocks und uagb begrenzt. Ihre Attribute werden vor der Mutation gegen das tatsächlich im Browser registrierte Schema geprüft. Die dynamischen Ein- und Ausgaben verwenden den oben beschriebenen Live-Editor-Umschlag. Elementor-Änderungen laufen nach der Bestätigung über die geprüften serverseitigen Elementor-Abilities mit eigenem Dokumenthash, Revision, Rücklese- und Frontend-Prüfung.

wp-agent/get-live-editor-status

Zweck: Liest die aktive Sitzung, den geöffneten Beitrag, Bereitschaft, Änderungsstatus, Zustandshash, Ablauf und die Zahl offener Befehle. Capability: sicherer Nicht-Administrator mit edit_posts, gebunden an genau diese Sitzung. Merkmale: lesend, idempotent.

wp-agent/live-editor-read

Zweck: Stellt einen begrenzten Lesebefehl ein. action erlaubt inspect-page, gutenberg-structure, list-block-types, get-block-schema oder get-block-attributes. Je nach Aktion sind block_name, client_id, include_text, text_limit bis 10.000 oder search bis 100 Byte zulässig. Seiteninspektionen, Schema- und Attributantworten teilen ein gemeinsames Ausgabebudget, das die stärkere WordPress-JSON-Kodierung für Unicode und Schrägstriche berücksichtigt. Als geheim erkannte Schlüssel und nicht serialisierbare Providerwerte werden redigiert. Fehlerhafte ungepaarte UTF-16-Surrogate werden sicher ersetzt. Laufzeitfehler werden vor dem Abschluss auf 8.000 Byte begrenzt. Die Antwort enthält eine command_id. Capability: gebundener sicherer Nicht-Administrator mit Bearbeitungsrecht am geöffneten Beitrag. Merkmale: lesend, nicht idempotent, weil ein kurzlebiger Queue-Eintrag entsteht.

wp-agent/live-editor-write

Zweck: Stellt eine sichtbare, einzeln zu bestätigende Aktion ein. action erlaubt open-post, create-block, update-block, delete-block, move-block, replace-inner-blocks, undo, redo oder save-post. reason ist immer Pflicht. Außer bei open-post ist der aktuelle 64-stellige expected_state_hash Pflicht. Je nach Aktion werden post_id, client_id, parent_client_id, block_name, index, begrenzte attributes oder höchstens 200 begrenzte blocks verlangt. Agent-Änderungen werden vor der Mutation gegen Namespace, registrierte Attribute, Typen, Enums, Geheimnisschlüssel und aktive Inhalte geprüft. Das Speichergate prüft die gesamte Struktur erneut auf Größen-, Tiefen- und aktive Inhaltsgrenzen. Sichere bestehende Blöcke bleiben auch mit anbietereigenen schemawidrigen Defaults oder nach Deaktivierung ihres Plugins speicherbar. Capability: gebundener sicherer Nicht-Administrator mit Bearbeitungsrecht am Zielbeitrag. Merkmale: schreibend, destruktiv markiert, nicht idempotent, immer bestätigungspflichtig.

wp-agent/live-editor-elementor-write

Zweck: Stellt eine sichtbare, einzeln zu bestätigende Elementor-Free-Operation ein. operation erlaubt open-document, update-document, update-element, create-element, duplicate-element, move-element, delete-element oder restore-revision. reason und post_id sind immer Pflicht. Jede Mutation verlangt den aktuellen 64-stelligen expected_hash; je nach Operation werden zusätzlich begrenzte Elemente, Einstellungen, Stiländerungen, IDs, Position oder Revisions-ID geprüft. Nach der Bestätigung führt ausschließlich der Server die bestehende Elementor-Ability aus. Er prüft Eigentümer, Rechte und Sitzungszustand nach dem Lock erneut, erstellt eine Revision, verifiziert Rücklese- und Frontendzustand und meldet Fehler oder recovery_required terminal zurück. Capability: gebundener sicherer Nicht-Administrator mit Bearbeitungsrecht am Zielbeitrag plus einzelne Administratorbestätigung. Merkmale: schreibend, destruktiv markiert, nicht idempotent, immer bestätigungspflichtig.

wp-agent/get-live-editor-result

Zweck: Liest anhand der 24-stelligen command_id Status, Ergebnis oder redigierten Fehler eines eigenen Befehls. Terminale Ergebnisse werden begrenzt aufbewahrt. Abgelaufene, fremde oder nicht vorhandene Befehle schlagen geschlossen fehl. Capability: gebundener sicherer Nicht-Administrator. Merkmale: lesend, idempotent.

---

16. Schnellübersicht: Capability pro Ability

---

Nachgewiesene Verträge im aktuellen Quellstand

Die folgenden Verträge sind paid-only und gehören zum Quellvertragsstand von Companion 0.4.121, Power 0.6.38 sowie CLI und Skills 0.4.91. Den öffentlichen Verfügbarkeitsstand dokumentiert der öffentliche Changelog. Die Einträge halten die Capability-Grenzen dieses Quellstands fest.

Das Operation Ledger ist eine administrative HMAC-verkettete Historie ohne Ability und ohne MCP-Tool. Der installierte MCP-Adapter bietet keinen sicheren Pre-Execution-Hook für eine zusätzliche WPAgently-Freigabe. Die bestehende Einzelfreigabe und die jeweiligen Providerverträge bleiben deshalb maßgeblich.

Weitere aktuelle Release-Verträge

Die folgenden neun Companion-Abilities gehören ebenfalls zum aktuellen Release-Satz. Ihre Providerverträge und verbleibenden Grenzen stehen in der Kompatibilitätsmatrix und der Roadmap. Der Aktivitätsverlauf und die Verbindungs-Karte sind Verwaltungs- und Onboarding-Funktionen ohne Ability-Registrierung.

Das Operation Ledger protokolliert höchstens 100 Schreibvorgänge mit den Zuständen succeeded, failed, rejected und recovery_required in einer begrenzten HMAC-Kette und kann nur von Administratoren zurückgesetzt werden. Es ist kein Berechtigungs-, Prüf- oder Freigabemechanismus. Die Verbindungs-Karte führt über die benötigten lokalen Voraussetzungen und die Client-Konfiguration, ohne Zugangsdaten offenzulegen.

Weitere eng begrenzte Providerpfade

Die folgenden 25 Abilities ergänzen den zuvor dokumentierten 373er Katalog. Sie erweitern keine allgemeine Provider-Schreibfreigabe. Jede Oberfläche ist auf den benannten Providervertrag begrenzt.

Die Roadmap trennt den Quellvertragsstand 0.4.121/0.6.38/0.4.91 von späteren Lücken. Der öffentliche Polar- und Plugin-Status wird separat geführt. Code-Snippets-Single-Use und ein über die dokumentierten ACPT-Product-Data-Felder hinausgehender Pods- oder Provider-Lebenszyklus bleiben ausdrücklich außerhalb des heutigen Vertrags: Roadmap.

Weitere eng begrenzte Designpfade

Die vier gegenüber dem vorherigen Quellstand ergänzten Companion-Abilities bleiben bewusst eng:

• Admin and Site Enhancements Free 9.0.0 erhält get-ase-free-generator-tag und update-ase-free-generator-tag. Sie lesen oder ändern ausschließlich den dokumentierten Schalter zum Entfernen der WordPress-Generator-Meta-Markierung. Die übergeordnete ASE-Gruppe muss manuell aktiviert sein. Die Änderung verwendet Blogbindung, atomaren Vergleich, erneuerbare Sperre und vollständigen Provider-Read-back.
• Spectra Blocks 1.0.4 erhält get-spectra-blocks-separator und update-spectra-blocks-separator. Sie lesen oder ändern ausschließlich Stil, Ausrichtung, Breite, Höhe und Farbe eines exakt geformten, serverseitig registrierten spectra/separator. Der Schreibpfad verwendet Dokumenthash, Revision, bytegenauen CAS, Render- und Provider-Read-back sowie den vorhandenen Wiederherstellungspfad.

Weitere eng begrenzte Builder- und Modellpfade

Die 16 gegenüber dem vorherigen Katalog ergänzten Companion-Abilities sind bewusst schmal:

• Beaver Builder erhält die sieben Abilities list-beaver-user-templates, get-beaver-user-template, save-beaver-user-template, save-beaver-node-template, delete-beaver-user-template, get-beaver-global-settings und save-beaver-global-settings. Beaver Lite stellt die native User-Template-Registrierung nicht bereit. Diese fünf Template-Pfade enden dort fehlersicher als nicht verfügbar, sie simulieren oder speichern keine Ersatz-Templates. Die primitive Global-Settings-Map bleibt ein eigener, realer Providerpfad.
• Pods ergänzt get-pods-field-values und update-pods-field-values für vorhandene, unterstützte Felder. Nicht modellierte Feldformen, Tabellenkonfigurationen und unsichere Providerzustände bleiben geschlossen.
• ACPT ergänzt list-acpt-meta-groups, get-acpt-meta-group, create-acpt-meta-group, update-acpt-meta-group, delete-acpt-meta-group, get-acpt-field-values und update-acpt-field-values. Sie verwenden den nativen Providerpfad und akzeptieren nur die modellierte persistente Meta-Gruppe beziehungsweise unterstützte Feldwerte.

Der GenerateBlocks-Schreibpfad bleibt auf seine freigegebenen strukturellen Query- und Paginierungsattribute begrenzt. Er schreibt weder Rich Text noch beliebigen Klartext. Die kommerzielle Meta-Box-Settings-Pages-Laufzeit für Werte bleibt bis zu einer legal lizenzierten Praxis-Fixture extern unzertifiziert. Weitere lizenzierte oder proprietäre Providerflächen bleiben außerhalb dieses Vertrags.

---