---
name: xp-mcp-content-contract
description: Entwickle oder prüfe eigene HTML- und MCP-Apps für XP-Fenster nach dem versionierten XP-Content-Vertrag. Nicht für Explorerrechte, Fensterrahmen oder das Umformatieren fremder Apps.
---

# XP-Content-Vertrag

Öffentliche Definition und Beispiel:
https://mcp-lab.christian-igel.tech/documentation/contracts/xp-content/v1.1/

Verwende Version 1.1.0 und die dort veröffentlichte Datei `xp-content-1.1.0.css`.
Pinne Version und SHA-256 im eigenen Release. Lade die konkrete Referenz vor
neuer Implementierung; keine Klassen oder Fähigkeiten erfinden.

Root: `.xp-content[data-xp-content-version="1"]`. Allgemeine Bausteine:
`xp-card`, `xp-note`, `xp-prose`, `xp-stack`, `xp-grid`, `xp-form`, `xp-field`,
`xp-actions`, `xp-list`, `xp-statusbar`, `xp-error`. Semantisches HTML, explizite
Labels und Status verwenden. Kein zweiter XP-Fensterrahmen, keine Explorerpfade,
Roots, Rollen oder Dateiverwaltung als allgemeinen Inhaltsvertrag behandeln.

Eigene MCP-Apps bündeln CSS beim Build im `text/html;profile=mcp-app`-Dokument.
Opt-in am Ressourceninhalt:
`_meta["tech.christian-igel/xp-content"]={"version":"1.1.0"}`.
Der gleichnamige HostContext-Zusatz enthält nur Darstellungsfähigkeiten.
Versionskennzeichnung ist keine Authentifizierung oder Sicherheitsabnahme.

Fremde Apps bleiben unverändert, sofern sie nicht ausdrücklich teilnehmen.
Kein CSS aus dem WordPress-Theme in Sandboxiframes injizieren, kein App-HTML
umschreiben, keine CSP/Permissions erweitern, um Styles zu erzwingen.
WP-Lab bestimmt Kontostatus, wirksame Rolle und Programmfreigabe. Keine
Rollenparameter oder fremden Grants übernehmen. Theme nur über HostContext und
lokales `data-xp-theme`; keine Parent-Cookies oder Parent-DOM lesen.

Vor Veröffentlichung: CSS bündeln, MIME/Metadaten/Version prüfen, Unit- und
Vertragstests ausführen, 320/390/1280 Pixel, 200-Prozent-Zoom, Tastaturfokus,
hell/dunkel, App/Funktionen, zwei Fenster, Resize, Schließen und Fehler prüfen.
Benötigte OAuth-/Rollen-/Parallelclient-Abnahme separat nachweisen. Nur neue
immutable Releases bauen, bisherige Auswahl und Rückschaltweg erhalten.
Geplant, implementiert, getestet, veröffentlicht und authentifiziert abgenommen
getrennt berichten. Keine Secrets oder hostgebundenen Credentials in diesem Skill.

Für 1.1.0 gilt zusätzlich das explizite Darstellungsprofil `data-xp-presentation="xp|neutral"`; der vertrauenswürdige Host setzt es, nicht das Parent-DOM. 1.0.0 bleibt unterstützt.

Gemeinsame 1.1.0-Bausteine: `xp-layout`, `xp-sidebar`, `xp-sidebar-group`, `xp-sidebar-item`, `xp-icon`, `xp-view`, `xp-eyebrow`, `xp-lead`, `xp-section-heading`, `xp-program-actions`, `xp-action-grid`, `xp-toolbar`, `xp-tabs`. Die App verwendet eigene fachliche Navigation; globale Kontodaten und Rechte bleiben beim Host.

Additional shared layout classes: `xp-media-header`, `xp-media-image`, `xp-media-body`, `xp-definition-list`, `xp-sidebar-footer`, `xp-action-copy`, `xp-check`. These describe layout only; account fields and authorization stay application responsibilities.

## Explorer-Menü (1.1.0)

Eigene Apps deklarieren Buttons mit `xp-menu-item` und Selects mit `xp-menu-select`.
`data-xp-menu="file|view|projects"` bestimmt Datei, Ansicht oder Projekte;
`data-xp-menu-label` überschreibt optional die Beschriftung. `xp-menu-only` am
Element oder dessen Label blendet es erst nach bestätigter Hostübernahme aus.
Häufige Aktionen wie Speichern, Vorschauwechsel und Aktualisieren bleiben als
Schnellzugriff im Inhalt. Seltene Aktionen wie Neues Projekt, Projektwechsel
und Entwurf verwerfen gehören ins Menü. Formulare bleiben im Inhalt; das Menü
öffnet sie. Vorschau-Dokumente erhalten diese Klassen niemals automatisch.

`xp-content-menu-1.1.0.js` wird lokal gebündelt. `installExplorerMenu(app,root)`
vor `app.connect()` aufrufen; `context(hostContext)` nach Verbindung und bei
Änderungen, `dispose()` bei Abbau. Host optiert mit `menuProtocol:1` im
XP-Content-HostContext und `chrome:"host"` ein. Ohne Opt-in bleibt alles sichtbar.
Diese eigene Erweiterung ist kein standardisiertes MCP-Apps-Menüprotokoll.

Request `tech.christian-igel/xp-content/menu`: `{revision,items}`; maximal 60
Einträge, pro Select maximal 20. Eintrag: `{id,menu,label,disabled,checked}`.
IDs sind opak (`m0` usw.), Label maximal 100 Zeichen ohne Steuerzeichen.
Antwort `{accepted:revision}` bestätigt Platzierung. Der Host aktiviert über
`tech.christian-igel/xp-content/menu-activate` mit `{revision,id}` ausschließlich
einen aktuellen, aktivierten Eintrag desselben Fensters. Keine URLs, HTML,
Tokens, Formularwerte, Tools oder ausführbaren Programme im Menüprotokoll.
Die App prüft erneut Existenz und disabled und benutzt ihren bisherigen Handler.
Revisionen verhindern veraltete Aktivierungen. Bei Trennung/Ansichtswechsel
entfernt der Host die Einträge. Keine Parent-DOM-Zugriffe oder neuen Netzrechte.

Der Editor zeigt einen eigenen Punkt Projekte. Zuletzt in dieser App-Sitzung
geöffnete Projekte stehen zuerst; diese Reihenfolge wird nicht persistent
gespeichert. Der aktuelle Projektname bleibt im Inhalt. Nicht verfügbare
Projekte kommen ausschließlich aus der autorisierten Serverliste und werden
nicht aus einem lokalen Verlauf wiederhergestellt.

Abnahme offen: authentifizierter Editor in echtem XP-Fenster, zwei Fenster,
Tastatur/Fokus, Projektwechsel mit ungespeicherten Änderungen, getrennte Sitzung,
App/Funktionen-Wechsel sowie neutrale Fallback-Ansicht. Ein erfolgreicher SDK-
Transporttest ist kein Browsernachweis.

Bei mehr als 20 Projekten öffnet „Alle Projekte auswählen“ die vollständige autorisierte Auswahl im Inhalt.