---
name: xp-app-access-contract
description: Implementiere oder prüfe Rollen, Nutzerfreigaben und den Autorisierungslebenszyklus von XP- und MCP-Apps nach ci-app-access-policy/v1. Verwenden bei App-Registrierung, Policy-Export, Fensterrollen, Rollenentzug und angebundenen Kanälen; nicht für reine Inhaltsgestaltung.
---

# Gemeinsamer App-Zugriffsvertrag

## Kanonische Referenz

Vor der Umsetzung die öffentliche Referenz unter
https://mcp-lab.christian-igel.tech/xp-contract/access/ lesen. Das dortige
Manifest bestimmt die aktive Version, Schema, Referenzauswertung und gemeinsamen
Testvektoren. Version und Prüfsummen für den bearbeiteten Verbraucher festhalten.
Dieser Skill ist ein Einstieg; die vollständige Fachdefinition bleibt dort.
Bei fehlender Veröffentlichung oder Erreichbarkeit den Stand benennen und die
zugehörige geprüfte Quellrevision verwenden; keinen eigenen Ersatzvertrag erfinden.

WP-Lab bleibt Autorität für Identität, Kontostatus und Kontoberechtigungen.
Der Vertrag ergänzt Programm-, Fenster-, Foundation- und XP-Content-Verträge.
Vorhandene Veröffentlichung, Skillinstallation und Durchsetzung in einem
Verbraucher sind getrennte Nachweise; aus einem Manifest keine aktive
Rollenprüfung im Zielsystem ableiten.

## Entscheidungsregeln

- Ausgangspunkt ist die serverseitig gebundene aktuelle Ansichtsrolle. Ein neues
  XP-Fenster erbt die Desktop-Ansicht. Eine ausdrücklich gewählte Fensterrolle
  gilt nur dort und darf oberhalb der Desktop-Ansicht liegen, soweit alle Grenzen
  dies erlauben. Die Kontorolle ist eine Obergrenze, keine automatische Ansicht.
- Reihenfolge: `guest < customer < developer < admin`. Die Ausgangsrolle durch
  Konto-, App-, persönliche App- und Verbindungsobergrenzen automatisch begrenzen;
  erst danach Mindestrolle und weitere Zugriffsbedingungen prüfen.
- Fehlende Nutzerliste bedeutet keinen zusätzlichen Nutzerfilter; eine leere
  Liste verweigert jedem den Zugang. Gastzugriff braucht eine ausdrückliche
  App-Fähigkeit. Alte Rollenlisten, Nutzerverbote und Eigentümergrenzen erhalten;
  eine Freigabeliste überstimmt keine bestehende Sperre.
- Stabile bestätigte Nutzerkennungen verwenden. Namen, Telefonnummern, App-HTML,
  URL-Parameter und HostContext erteilen keine Rechte. Telegram bindet eine
  bestätigte numerische Telegram-ID an den WP-Lab-Nutzer und besitzt eine eigene
  gespeicherte Ansicht; Desktopwechsel verändern sie nicht. Kontosperren und
  dauerhafte App-Grenzen gelten auch dort.

## Export und Durchsetzung

Die Definition bei der vorhandenen Programmregistrierung oder als geschützte
MCP-JSON-Ressource mit Metadatenreferenz exportieren. Der Host prüft registrierte
App, authentifizierte Verbindung, Aussteller, Version und Revision. Vollständige
persönliche Zuordnungen bleiben Administratoren und autorisiertem Host vorbehalten;
normale Nutzer erhalten nur ihre eigene Entscheidung. Öffentliche Beispiele
enthalten ausschließlich fiktive Kennungen.

Öffnen, Ressourcenlesen, Werkzeuge und direkte Backend-Aktionen müssen dieselbe
serverseitige Entscheidung durchsetzen. Die kanonischen Testvektoren für PHP und
Python benutzen; zusätzliche bestehende Betriebsregeln dürfen nur einschränken.

## Rollenwechsel und Wiederkehr

Bei geänderter Anmeldung, Ansicht oder relevanter Autorisierung den bisherigen
App-Kontext sperren und seine Revision ungültig machen. Der Host zeigt Milchglas,
verhindert Interaktion, beendet Medien/Streams und baut den alten iframe ab.
Die App über die standardisierte Kontextänderung informieren; die Sperre wartet
nicht auf ihre Antwort. Verspätete Antworten dürfen den Inhalt nicht freigeben.

Fensterrahmen und erlaubte Rollenwahl bleiben bedienbar, fachliche App-Aktionen
bleiben gesperrt. Erst ausdrückliches Fortsetzen mit erneut geprüfter Rolle erzeugt
einen neuen Kontext. Frühere höhere Fensterrollen weder bei Wiederanmeldung noch
nach Ablauf einer Fensterbindung still wiederherstellen. Ein Fensterwechsel
ändert andere Fenster nicht; ein geänderter Desktopkontext sperrt die betroffenen
Fenster bis zu ihrer Bestätigung.

Quelltests, veröffentlichte Revision, echte angemeldete Browserprüfung und
MCP-Client-Abnahme getrennt ausweisen. Mindestens Rollen-/Listenmatrix,
Autorisierungsänderung bei laufender Aktion, direkte Aufrufe trotz UI-Sperre und
Export mit falscher Bindung oder veralteter Revision prüfen.