--- name: xp-python-app-contract description: Baue oder prüfe Python-Apps für Fenster XP und MCP Apps mit Pflichtbasis, optionalen Fähigkeiten, Fensterereignissen und servergeprüften Rollen. Nicht für allgemeine Python-Skripte oder eine ungefragte PHP-Migration. --- # Python-Apps für Fenster XP Vor Umsetzung die öffentliche Referenz und ihr Manifest unter https://mcp-lab.christian-igel.tech/xp-contract/app/ lesen. Der Vertrag `ci-python-app/v1`, das gebündelte SDK und seine Quellrevision sind die kanonische Definition. Fehlende Veröffentlichung klar benennen und die geprüfte Quellrevision verwenden. Eine öffentliche Referenz beweist keinen Rollout. ## App bauen und erkennen - Die Pflichtbasis `ci_app_contract.AppBase` und `AppInfo` verwenden. Stabile App-ID, Name und Version deklarieren. Fehlerhafte Pflichtdaten verhindern Start; sie sind keine leere Fähigkeit. - Nur tatsächlich benötigte optionale Klassen implementieren: `ToolProvider`, `ResourceProvider`, `WindowUI`, `SettingsProvider`, `StreamProvider`, `EventProvider`, `AgentProvider`. Fehlt eine Klasse, gilt ihr dokumentierter Default: leere Angebote beziehungsweise kein Support. Keine leeren Gerüste oder erfundenen Tools, Menüs, Streams und Agentenzugänge ergänzen. - `await app.describe(principal)` aus einem servergeprüften Kontext aufrufen. Implementierte Klassen und ihre tatsächlichen Angebote bestimmen den Deskriptor. `supported_events` und `supported_actions` müssen zur App passen. Registrierung/Scan ausschließlich über zugelassene Quellen; keine vom Browser bestimmten Python-Imports, Dateiwurzeln oder Ziel-URLs. - Dieselbe begrenzte Discovery bei XP-Start, bestätigter Anmeldung beziehungsweise Identitätsänderung und Aktualisieren verwenden. Rollenabhängige Angebote an Identität/Sitzung, Fensterrolle, Autorisierungsrevision, App und Verbindung binden. Betroffene Caches bei Kontext-/App-/Verbindungsänderung und Refresh verwerfen; niemals einen Admin-Deskriptor global für Customer wiederverwenden. Fehler zeigen und keine früheren höheren Fähigkeiten reaktivieren. Cache und Ablaufdatum ersetzen keine aktuelle Backend-Autorisierung. - Technische `supported_roles` ausdrücklich deklarieren, sobald die App mehr als den konservativen Customer-Default braucht. WP-Lab bleibt Identitäts- und Rechteautorität. Desktoprolle ist Startansicht, nicht Obergrenze einer bewusst gewählten Fensterrolle. `xp-app-access-contract` zusätzlich lesen. ## Fensterereignisse und Darstellung `AppBase` stellt die Standardereignisse und deren validierten No-op bereit. Für unbenötigte Ereignisse keine eigene Klasse anlegen. Zusätzliche Ereignisse über `EventProvider` registrieren. Der Host prüft Absender, Besitz, Fenster-/Instanzbindung und aktuelle `contextRevision` vor `dispatch_event(envelope, authorize=...)`. Ein Browserereignis verleiht keine Rolle. Rollenwechsel erst nach Serverbestätigung und neuer Autorisierungsrevision melden. Unbekannte Namen: `handled: false`, diagnostischer Code, kein Payloadlog und keine Fachaktion. Den vorhandenen Explorer-Menüvertrag für `menu`/`menu-activate` mit stabiler Aktions-ID, aktuell bestätigter Menürevision und Kontextbindung verwenden. Unbekannte, deaktivierte, entfernte und veraltete Aktionen abweisen. Ein zusätzliches `window-action` darf einen bereits ausführenden Menüweg nicht ein zweites Mal auslösen. Keine zweite Actionroute einführen; `file.open` nur bei tatsächlich implementierter Fachfunktion anbieten. Runtime-Angebote aus der tatsächlichen Menüanmeldung abfragen: oberste Felder `revision`/`action_source`, Aktionsobjekte mit `id`/`label` und optional `disabled`/`busy`. Quellen `xp-content-menu`/`foundation-window`; vor Anmeldung keine Revision/Quelle erfinden. Menü-, App- und Autorisierungsrevision trennen. Legacy `{revision,id}` und Foundation `{revision,actionId,arguments}` erhalten; eine angenommene Notification ist kein Nachweis abgeschlossener Fachaktion. Bei Foundation verhindern Antwort-`error`, Ergebnis-`isError: true` oder ein fehlendes Manifest das zusätzliche Informationsereignis. Bei UI-Arbeit zusätzlich `xp-mcp-content-contract` lesen. Die Formate `phone-format`, `tablet-hochformat`, `tablet-querformat`, `desktop-format` verhandeln, auf `view.changed` reagieren und responsive Styles/Inhalte prüfen. Dabei den tatsächlichen Inhaltsbereich in CSS-Pixeln messen, ohne Rahmen und Taskleiste; äußere Fenster-/Bildschirmgröße genügt nicht. Apps ohne UI brauchen keine künstlichen Styles. Größe allein oder deklarierte Formate belegen keine nutzbare Darstellung. ## Vorhandenes PHP-Backend adaptieren Für eine beauftragte XP-App mit PHP-Fachlogik einen Python-Adapter mit `AppBase`/`AppInfo` einsetzen; keine zusätzliche Pflichtklasse oder leere Providergerüste. PHP behält seine Fachlogik und WP-Lab Identität, SSO und Rechte. Nur fest registrierte PHP-Operationen mit geprüften Eingabeschemas anbinden; keinen allgemeinen Code-/URL-Proxy und keine synthetischen Fachtools bauen. Reine Discovery kann als autorisiertes PHP→fest registrierter Python-CLI-Probe ohne persönliche Daten oder Fachtools erfolgen. PHP prüft Konto, Sitzung, aktuelle Rolle und App-Freigabe vor und nach dem begrenzten Aufruf. Ein Startscan ohne Fenster besitzt keine Fenster-/Instanzbindung; keine solche Bindung erfinden. Die Beschreibung belegt weder Fachtransport, Fensterrollenwechsel noch Backend-Ereigniszustellung. Für tatsächlich adaptierte Fachaktionen Python→PHP serverseitig authentifizieren und an App, Nutzer/Sitzung, wirksame Fensterrolle, Autorisierungsrevision, Ziel und begrenzte Gültigkeit binden. Ein Dienstschlüssel authentifiziert den Adapter, erteilt keine Nutzerrechte. PHP prüft aktuelle WP-Lab-Freigaben und fachliche Rechte bei jedem Aufruf selbst. Kein globales Admin-Servicekonto darf die Fensterrolle umgehen. Direkte PHP-Aktionen müssen dieselbe Entscheidung durchsetzen. Ablehnung, Ablauf, Widerruf, falsche Bindung oder Backend-Ausfall nicht als Erfolg behandeln; verspätete Ergebnisse nach Kontextwechsel verwerfen. Tatsächliche UI-/Menüwege erhalten und vorhandene Aktionen einmal ausführen. Standardereignisse bleiben ohne Fachhandler informativ oder No-op; keinen Backend-Ereignistransport aus einem UI-Listener ableiten. Responsive Formate am Inhaltsbereich prüfen. Ein Python-Adapter macht eine normale App nicht automatisch zur MCP App; diese Anbindung braucht eine echte UI-Ressource und eigene Transport-/Clientnachweise. Zulässige und abgewiesene Rollen auf Python- und PHP-Seite, direkte Umgehungsversuche, fremde/alte Kontexte, Entzug während Aufruf und PHP-Ausfall prüfen. Entscheidung, implementierter Adapter, aktivierter Scan und reale UI-/MCP-Abnahme getrennt dokumentieren. Nur ausdrücklich beauftragte Apps adaptieren; keine automatische Änderung von Ananda, Yoga oder anderen Diensten. ## MCP- und Agentengrenzen Bei MCP zusätzlich `mcp-creation` lesen. Beschreibung als geschützte JSON-Ressource exportieren; nur eigene Nutzerentscheidung zeigen. MCP UI über echte `ui://`-Resource, `text/html;profile=mcp-app` und `_meta.ui.resourceUri` anbieten. Vorhandene OAuth-Audience, CSP und Sandbox erhalten. Ein UI-Starttool ist Adapterinfrastruktur und verlangt keine fingierten App-Fachtools. Automatisches Verpacken normaler Apps als MCP App bleibt eine gesonderte, erst zu klärende Aufgabe. `AgentProvider` nur bei echten App-Zusätzen zum Agenten implementieren; ein Host-Basisagent benötigt diese Klasse nicht. Host-vermittelte, an Fenster/App/Nutzer/Revision gebundene Sitzung verwenden. Standardmäßig alle in der aktuellen Fensterrolle erlaubten App-Tools/MCP-Funktionen bereitstellen; App-Einschränkungen und jederzeitige Nutzersperren je Tool/MCP zusätzlich anwenden. Mindestrollen schließen höhere Rollen ein, ausdrückliche Verbote bleiben wirksam. Änderungen sofort serverseitig durchsetzen, abbrechbare laufende Aufrufe/Voice beenden und `agent-capabilities-changed` best effort senden; weder Zustellung noch App-ACK abwarten. Neue Aufrufe am aktuellen effektiven Angebot prüfen; Caches/verspätete Antworten dürfen gesperrte Fähigkeiten nicht zurückbringen. Vertragsforderung und tatsächlich vorhandene Serversperre getrennt prüfen. Einwilligung, Mikrofonberechtigung, Verbindung und Aufnahme getrennt anzeigen. Entzug/Close stoppt Aktionen und Voice; Deadline und bestätigtes Budget serverseitig erzwingen. Vor echten API-Aufrufen `paid-api-budget` anwenden; kein Live-API-QA ohne Budget. ## Prüfung und Veröffentlichung Minimal-App ohne optionale Klassen, tatsächlich benötigte Fähigkeiten, Default-Events, unbekannte Events/Aktionen und abgewiesene falsche oder alte Kontexte prüfen. Host sperrt sofort unabhängig von App-Hooks; eigene Streams und Ressourcen korrekt schließen. Admin-Konto in Customer-Desktop mit Entwicklerfenster sowie echte Customer-Ablehnung und zwei unabhängige Fenster prüfen. SDK, Backend, veröffentlichte Revision, angemeldete Browserabnahme, MCP-Client und Voice-Abnahme separat melden. Bestehende PHP-Fachlogik bleibt hinter dem ausdrücklich beauftragten Python-Adapter; keine PHP-Migration ableiten.