Skip to content

SkillPilot Coach v1: Release, Rollback und Stilllegung

Stand: 19. Oktober 2026

Status: 1.0.0 wurde abgelehnt; sämtliche ChatGPT/OpenAI-Review- Entwicklungssperren sind ausdrücklich aufgehoben. Aktueller lokaler Paketstand: 1.1.3, mit dem aktuellen ZIP-Verfahren vorbereitet. Öffentlich über den Git-Marketplace ist weiterhin 1.1.2 dokumentiert. Der neue Kandidat umfasst die korrigierte Fortsetzung nach Zielabschluss, Regeln gegen lösungshaltige Antwortvorschläge und die lokal reproduzierte Korrektur für einen fehlgeschlagenen UI-Handshake vor verspäteter Bildzustellung. Der aktuelle Windows-Work/Voice- Bericht zeigt weiterhin keine vollständige Bildfolge; ein erfolgreicher Renderer-Aufruf mit dem bereits ausgerollten älteren Widget ist nachgewiesen. Installation und Lernstart in Windows ChatGPT Desktop sind vom Product Owner bestätigt. Die offizielle OpenAI-Einreichung bleibt DRAFT, nicht eingereicht und nicht im OpenAI-Verzeichnis veröffentlicht. Der GUI-/Serverrollout wird vom Product Owner durchgeführt; die lokalen Änderungen allein deployen ihn nicht. Die Review-Historie bleibt nachvollziehbar.

Arbeitsreihenfolge seit 12. September 2026: zuerst den laufenden Claude-Beta- Betrieb stabilisieren, dann den bewährten Kandidaten gezielt im echten ChatGPT- Host abnehmen und anschließend einreichen. Die begrenzten späteren Aufträge vom 24. September für Archivinstallation/native CIMD und vom 5. Oktober für die bestehende Git-/Desktop-Beta samt normalem GUI-Start ergänzen diese Reihenfolge. Am 19. Oktober beauftragte der Product Owner die Umstellung auf das aktuelle Deployment-Verfahren und die Prüfung von Mobilgeräten und Web. Ziel ist das Remote-MCP-Plugin mit gebündeltem Skill im öffentlichen Verzeichnis. Die Git-Beta bleibt der bestehende Desktopweg. Die folgenden Release- Schritte gelten innerhalb dieser verbindlichen Entwicklervorgabe; Sicherheitsprüfungen und Einreichungsnachweise bleiben unverändert.

Dieses Runbook setzt den Versionierungs- und Lebenszyklusplan operativ um. Es gilt für skillpilot-coach-v1.

1. Feste Identität und V1-Vertrag

Bestandteil Verbindlicher Wert
Plugin-Identität skillpilot-coach-v1
Anzeigename SkillPilot Coach v1
aktueller Paketstand 1.1.3 lokal vorbereitet; Git-/Desktop-Beta 1.1.2 veröffentlicht; OpenAI-Portal DRAFT
Contract Major 1
Lifecycle-Policy policyRevision=5
öffentlicher MCP-Endpunkt und OAuth Resource/Audience https://mcp-coach-v1.skillpilot.com/mcp
Protected Resource Metadata https://mcp-coach-v1.skillpilot.com/.well-known/oauth-protected-resource/mcp
Domain-Challenge https://mcp-coach-v1.skillpilot.com/.well-known/openai-apps-challenge
aktive MCP-Apps-UIs genau zwei: Lernzielbild und Karteikartenlernen
Support-URL https://skillpilot.com/imprint
Historisches Reviewvideo https://skillpilot.com/api/public/openai/review/skillpilot-coach-v1/1.0.0/sha256-20f5327535513df8b1c088b553195baf6ae339d57fc417b303488ae597644deb.mp4 (keine Abnahme des aktuellen Kandidaten)
Veröffentlichungsstatus Git-Beta 1.1.2 veröffentlicht; aktueller Draft 1.1.3-SNAPSHOT unveröffentlicht; frühere veröffentlichte Git-Pakete und Snapshots bleiben erhalten
Quellpaket ai/openai plugin/skillpilot-coach-v1/

Permanente SkillPilot-ID, CREATE/EXISTING, Providerhinweis sowie Curriculum, Stage, Subjects, Profile und Personalisierung werden ausschließlich im First-Party-WebGUI konfiguriert. Der normale Einstieg Lernen starten / Start learning und der Cockpit-Einstieg führen zur Anbieterauswahl. Für ChatGPT Desktop (Beta) erzeugt Lernen mit ChatGPT vorbereiten eine frische opake learningSessionId; die vorbereitete Nachricht wird in einen neuen Desktop-Chat kopiert. ?coach=chatgpt-desktop ist eine optionale Vorauswahl, ?chatgptTest=1 bleibt eine kompatible Vorauswahl ohne separaten Startkasten. OAuth autorisiert die feste App, wählt aber keinen Lernenden aus.

Ohne aktuelle Startnachricht ruft der Coach kein SkillPilot-Werkzeug auf. Er gibt nur einen kurzen Hinweis in der Unterhaltungssprache mit dem festen Link https://skillpilot.com/ aus und stoppt. Zu Beginn jedes Learner-Turns muss get_skillpilot_context im aktuellen Assistant-Turn erfolgreich sein. Nach einer erfolgreichen Mutation ist ihr vollständiger Nachfolgerzustand für den Rest desselben Assistant-Turns autoritativ und wird nicht neu geladen. Auf SESSION_REQUIRED, SESSION_RENEWAL_REQUIRED und SESSION_VERSION_UNAVAILABLE gibt der Coach instruction unverändert aus. Fehlt es, verwendet er den exakten Eintrag aus instructions für die letzte autoritative communicationLocale, andernfalls für die aktuelle Unterhaltungssprache. Die exakte startUrl wird nur ergänzt, wenn sie nicht bereits in der Instruktion steht. Es folgen keine Fachantwort, kein Retry der alten Session und kein OAuth-Reconnect; die Fortsetzung erfolgt über die WebGUI und die neu vorbereitete Nachricht in einem neuen Chat.

Der Draft bindet genau zwei aktive content-addressierte MCP-Apps-Ressourcen:

  • render_skillpilot_goal_visualization bindet ausschließlich die aktive bild-only Lernzielressource;
  • start_skillpilot_memory_practice bindet ausschließlich die aktive Karteikartenressource; die Kartenbewertung bleibt app-only und ungebunden.

Der aktuelle 1.1.3-Kandidat hat 14 Werkzeuge. Vollständige Kontextantworten enthalten den fertigen Lernplanstatus als learningPlanToday für die dauerhaft gewählte Tages- oder Wochenbasis; jedes Fach wird unabhängig ausgewertet. resume_skillpilot_learning_plan und switch_skillpilot_learning_plan_subject ergänzen die planorientierte Fortsetzung beziehungsweise den expliziten Fachwechsel. Der verbindliche Lernplanstatus legt die gemeinsame Mengenbilanz und Formulierung fest. Der Coach übernimmt learningPlanToday.text wörtlich und die separate activeGoalAnnouncement einmal beim Unterrichtseinstieg. Nach erfülltem Periodenpensum stoppt die automatische Zielauswahl; zulässige aktive Ziele bleiben erhalten und weiteres Lernen ist auf ausdrücklichen Wunsch möglich. Export und tatsächlich gesendete Tool-Ergebnisse enthalten keine eigene Gesamtampel, Gesamtsummen oder alten Plan-Zählfelder wie extraCompletedToday; das gilt auch für vollständige Folgeantworten nach Zustandsänderungen. Der früher nur lokal entworfene get_skillpilot_daily_plan-Aufruf gehört nicht zur aktuellen Oberfläche. Für die neue Einreichung müssen genau dieser Export, die aktuellen Testfälle und das tatsächliche Verhalten übereinstimmen.

Alle bereits an reale Test-Clients beworbenen Bild-Hash-URIs bleiben mit ihren exakten Bytes passiv lesbar. Bei einer frischen goalVisualization plus Renderer-Freigabe läuft der Renderer einmal als unmittelbar nächster Werkzeugaufruf mit der unveränderten goalId; die Top-Level-stateVersion wird in dessen Eingabe expectedStateVersion kopiert. Eine alte oder bereits versuchte Freigabe wird nicht wiederverwendet. Der Textpfad bleibt vollständig, auch wenn der Host die optionale UI nicht darstellt.

Sessiongebundene Operationen und Write-Replays benötigen mindestens PT1H Restlaufzeit; exakt eine Stunde ist gültig. Ein bereits committeter identischer Write darf sein gespeichertes Resultat nur bei verfügbaren gepinnten Workflow-/Curriculumversionen und unveränderter kanonischer Learner-Revision replayen und führt keine Mutation erneut aus.

Für den kontrollierten Live-Test darf nur der First-Party-Launch das optionale diagnosticSessionTtlSeconds akzeptieren. Das Feld ist ausschließlich bei aktivem Diagnose-Gate, als ganze Zahl von 3601..86400 und höchstens bis zur normalen PT24H-Laufzeit zulässig. Es gilt nur für die von diesem Request erzeugte Session. Bereits der nächste Launch ohne Feld verwendet automatisch wieder PT24H; die globale TTL wird für den Test nicht geändert.

Maschinenlesbare Quellen der Wahrheit sind:

  • .codex-plugin/plugin.json für Paket-SemVer und Listing;
  • release/line.json für Contract Major, Endpoint und Zustandsversionen;
  • release/lifecycle.json für Support-, Publikations- und Startstatus sowie die monotone policyRevision;
  • contracts/drafts/openai/skillpilot-coach-v1/<version>-SNAPSHOT/ für den fortschreibbaren aktuellen Draft; das abgelehnte 1.0.0-SNAPSHOT bleibt als historische Evidenz separat unveränderlich;
  • contracts/published/openai/skillpilot-coach-v1/<version>/ und contracts/openai/skillpilot-coach-v1/release-index.json ausschließlich für tatsächlich im OpenAI-Portal veröffentlichte Versionen.

Der Product Owner hat die Review-Sperre nach der Ablehnung ausdrücklich beendet. 1.1.3 besitzt einen eigenen kohärenten Draft; 1.0.0 wird nicht umetikettiert oder überschrieben. Eine künftige reale Veröffentlichung versiegelt genau die veröffentlichte Version dauerhaft. Aktuelle fachliche, Sicherheits- und Kompatibilitätstests ersetzen keine echte Client-Abnahme.

1.1 Zieloberflächen und der aktuelle ZIP-Weg

Der aktuelle Submission-Guide unterstützt unser Codex-Paketformat mit .codex-plugin/plugin.json, .mcp.json und gebündeltem Skill. Ein neues Agent-Plugins-Format ist dafür nicht nötig. Review-Fälle und Release Notes werden im ZIP-Manifest unter extensions.com.openai.review beziehungsweise publication importiert.

Weg Verfügbarkeit und aktueller Nachweis
Bestehender Git-Marketplace Desktop; Windows-Installation und Lernstart vom Owner bestätigt, vollständige Voice-Bildfolge weiter offen
Benutzerdefiniertes Remote-MCP-Plugin im eigenen Konto Dokumentierter Weg für gezielte Web-Verbindungstests; Kontoberechtigung, exaktes hosted OAuth-Profil und tatsächlich geladene Skillbytes prüfen
Veröffentlichtes Remote-MCP-Verzeichnis-Plugin Ziel für Desktop, Web und mobile ChatGPT-App; erst nach Review, Veröffentlichung und eigener Abnahme anbieten
Lokale schmale Browseransichten Technische Vorprüfung der UI, keine Abnahme von iOS, Android oder ChatGPT Web

OpenAI markiert über Git importierte Plugins mit einer direkten MCP-Deklaration als Desktop only, auch bei einer HTTPS-URL. Ein Workspace-Import desselben Git-Pakets erweitert diesen Weg nicht auf Web oder Mobilgeräte. Die bestehende GUI-Auswahl bleibt deshalb bis zu nachgewiesener Verfügbarkeit ChatGPT Desktop (Beta). Siehe Pluginverwaltung und öffentliche Plugin-Oberflächen.

Die aktuelle deterministische Vorbereitung lautet vom Repository-Root aus:

node scripts/openai_plugin_release.mjs prepare
node scripts/openai_plugin_submission.mjs prepare
node scripts/openai_plugin_submission.mjs check
node scripts/openai_plugin_submission.mjs package --out-dir tmp/openai-submission-package
node scripts/openai_plugin_submission.mjs audit-zip --zip tmp/openai-submission-package/skillpilot-coach-v1-1.1.3-submission.zip

Das ZIP und submission-package.json sind die konkreten Übergabeartefakte. Der Bericht bindet alle acht Mitglieder und ihre Quellen mit SHA-256 und benennt offene Schritte. Eine fehlende aktuelle Demo leert den importierten Demo-Link ausdrücklich, damit das alte Video des abgelehnten Kandidaten nicht unbemerkt erhalten bleibt. CI baut und prüft dasselbe ZIP und stellt es als Artefakt bereit; die öffentliche Verzeichnis-Einreichung erfolgt dadurch nicht.

Hosted OAuth für Web und Mobil prüfen

Das Paket erklärt OAuth mit client.mode=cimd. Diese Registrierungspräferenz wählt keinen Lernenden, erzeugt keinen neuen Client und lockert keine serverseitige Bindung. Der native Client unter /oauth/codex/... mit Loopback-Callback bleibt sein eigener Public-Client mit PKCE. Für den hosted Client gelten dessen exakt konfigurierte CIMD-Identität, JWKS und Callback.

Die aktuelle Auth-Anleitung beschreibt für hosted CIMD OpenAIs verwaltete Signierschlüssel und öffentliche JWKS. Die fehlende Schlüssel-Eingabemaske für einen manuell vorregistrierten JWT-Client ist damit keine grundsätzliche Sperre für automatisches CIMD.

Für die tatsächliche Verbindung:

  1. Im vorgesehenen Konto den dokumentierten Remote-MCP-Testweg verwenden, beziehungsweise den Remote-Server des hochgeladenen ZIPs verbinden. Der Endpunkt bleibt exakt https://mcp-coach-v1.skillpilot.com/mcp.
  2. Die tatsächlich angezeigte hosted CIMD-URL und Redirect-URI mit der geschützten Serverkonfiguration vergleichen. Aktuelle Verbindungen können callback-spezifische URLs besitzen. Weder eine neue ID erraten noch den nativen Desktop-Pin dafür verwenden. Öffentliche Discovery beweist nicht, welcher konkrete hosted Client im Betrieb konfiguriert ist.
  3. OAuth-Verbindung und Erneuerung, tatsächlich geladenen Coach-Skill, Werkzeugaufrufe, bestätigte Speicherung und Fortsetzung mit zwei Bildern gegen den real deployten Kandidaten prüfen. Erst ein geladener Remote-Server ohne den richtigen Skill belegt noch keinen vollständigen Coach.
  4. Web, iOS und Android jeweils separat protokollieren. Text und Voice sind getrennte Prüfungen; lokale Browsergrößen ersetzen sie nicht. Keine echten Lernendenkonten oder Session-Capabilities in öffentliche Nachweise übernehmen.

Die technische Voraussetzung ist weiter ein einziger öffentlicher MCP-Endpunkt mit getrennten, exakt gebundenen OAuth-Profilen und unabhängiger Lernsession. Portalzugänge, Geheimnisse, Produktionseinstellungen und die eigentliche Veröffentlichung bleiben explizite operative Schritte nach den lokalen Prüfungen.

2. Release vorbereiten

Die folgenden lokalen Vorbereitungsschritte sind für den neuen Nachfolger freigegeben. Der maschinelle Guard schützt weiterhin die abgelehnte Historie und tatsächlich veröffentlichte Versionen, nicht alte Live-Dateihashes.

  1. Release Notes, Lifecycle, Listing, Skill, Policy, Serververtrag, aktuelle Testfälle und zentrale Dokumentation gemeinsam für den aktuellen Kandidaten 1.1.3 prüfen. Bereits veröffentlichte Git-Paketbytes bleiben unverändert; weitere Paketkorrekturen benötigen eine neue Version. Die aktuelle Veröffentlichung verwendet ausschließlich den MCP-Server; die frühere .app.json-Referenz gehört nicht in das neue Installationspaket. Das Installationsarchiv behält seine eigene Allowlist. Der neue Submission- ZIP enthält dieselben Installationsdateien sowie LICENSE; allein sein Manifest erhält die aus den geprüften Quellen abgeleiteten öffentlichen Review-Felder und Release Notes. Private Review-Zugänge gehören nicht hinein.
  2. Die V1-URLs bleiben feste Vertragswerte im Backend-Artefakt. Geheimnisse und OAuth-Clientwerte bleiben ausschließlich in geschützter Konfiguration.
  3. Generische und versionsspezifische Gates ausführen:
./scripts/verify_openai_v1_mtls_edge.sh --static
npm --prefix "ai/openai app" test
node scripts/check_openai_plugin_review_freeze.mjs
node scripts/check_openai_plugin_versioning.mjs
node scripts/check_skillpilot_coach_plugin.mjs
node scripts/openai_plugin_release.mjs candidate
  1. Den internen Draft erzeugen oder aktualisieren:
node scripts/openai_plugin_release.mjs prepare

prepare ersetzt nur den aktuellen unveröffentlichten Portal-Draft-Snapshot. Es ändert weder SemVer noch Published-Index und stoppt bei der abgelehnten 1.0.0, tatsächlich im OpenAI-Portal veröffentlichten Versionen, fehlenden versionierten Installationsdateien oder Symlinks. Alte Snapshot-/Video-Bytes bleiben exakt. 5. Quellen und Draft reproduzierbar prüfen:

node scripts/openai_plugin_release.mjs verify
npm --prefix app run check:docs-links
npm --prefix app run check:docs-indexes
git diff --check
  1. Nur nach separater Rollout-Freigabe Backend und V1-Edge geordnet ausrollen: Die aktuelle Entwicklungsfreigabe umfasst dies nicht. In der geschützten Backend-EnvironmentFile zunächst observe vorbereiten; CA-Bundle, root-eigene Modusdatei und Loopback-Verifier mit install_openai_v1_mtls_edge.sh --mode observe staged installieren und prüfen; anschließend die Nginx-Vorlage installieren. Der Installer editiert, testet oder reloadet Nginx niemals. Vor der Aktivierung folgen als root verify_openai_v1_mtls_edge.sh --preflight --expected-mode observe und ein explizites nginx -t; danach zuerst das Backend neu starten und erst dann Nginx reloaden. Abschließend den Runtime-Smoke und einen realen ChatGPT-Toolaufruf nachweisen. Der spätere Wechsel auf enforce folgt derselben EnvironmentFile → Installer → Preflight → nginx -t → Backend-Restart → Nginx-Reload → Runtime-/ChatGPT-Evidence-Reihenfolge.
  2. Erst nach diesen Nachweisen die App-Metadaten aktualisieren und in einem frischen Chat erneut scannen.

3. Release-Acceptance

Vor einer Portalaktualisierung sind mindestens folgende Nachweise erforderlich:

  1. Discovery, Domain-Challenge, OAuth/PKCE, Resource-/Audience-Prüfung, Callback-Allowlist, Scope-Fehler und Revocation sind grün; Geheimnisse erscheinen weder in Antworten noch Logs.
  2. Der root-eigene und der Backend-mTLS-Modus stehen beide auf enforce. Ein externer /mcp-Aufruf ohne Clientzertifikat endet mit 403; ein realer ChatGPT-Toolaufruf erhöht mtls_edge_verified, ohne einen Reject im Journal des mTLS-Verifiers oder einen Backend-Assertion-Reject (mtls_edge_rejected) für diesen Aufruf zu erzeugen. Metadata und Domain-Challenge bleiben ohne Clientzertifikat erreichbar.
  3. CREATE und EXISTING, Providerhinweis und alle Level-2-Dimensionen funktionieren ausschließlich im First-Party-WebGUI.
  4. Zwei aufeinanderfolgende WebGUI-Starts erzeugen verschiedene Sessionwerte und jeweils einen neuen Chat. Permanente SkillPilot-ID, OAuth-Werte und interne Lernziel-ID erscheinen nicht in der Startnachricht.
  5. Ohne aktuelle Startnachricht erfolgt kein Toolaufruf, sondern nur der feste WebGUI-Hinweis. Mit Startnachricht läuft zu Beginn jedes Learner-Turns ein erfolgreicher aktueller Kontextabruf. Nach einer erfolgreichen Mutation wird ihr vollständiger Nachfolgerzustand im selben Assistant-Turn ohne redundanten Kontextabruf verwendet.
  6. Die drei Session-Recovery-Codes ergeben ausschließlich die servereigene Instruktion und nötigenfalls die nicht duplizierte startUrl; Fachantwort, OAuth-Neuverbindung und Weiterarbeit mit der alten Session bleiben aus.
  7. Chatseitig funktionieren nur die ausdrücklichen Level-3-Änderungen von Fokus und aktivem Ziel. Level 2 wird weder abgefragt noch mutiert.
  8. resources/list enthält genau zwei aktiv gebundene UI-Ressourcen und alle beworbenen Vorgänger byte-identisch passiv. Bild- und Kartenwerkzeug binden ausschließlich ihre jeweilige aktive Ressource.
  9. Das Lernzielbild erscheint nur bei frischer passender Projektion und Freigabe. Ohne Bild, bei Clusterzielen oder nach veralteter Freigabe gibt es keinen Renderer-Aufruf und keine leere UI; der Text bleibt vollständig.
  10. Normales Karteikartenlernen verändert nur die Wiederholungsplanung und bleibt vom strengen Verified Recall getrennt. Orientierung, dialogisches Lernen, Mastery und Prüfung erfüllen ihre jeweiligen Evidenz- und Feedbackregeln.
  11. Der Session-Guard akzeptiert exakt PT1H, lehnt Operationen und Replays darunter ab und replayt einen zulässigen identischen Write nur bei unveränderter kanonischer Learner-Revision ohne neue Mutation.
  12. Der requestlokale Test mit 3660 Sekunden oder optional 5400 Sekunden zeigt den Guard-Übergang. 3600, 86401, Werte über der normalen Laufzeit und das Feld bei deaktiviertem Gate scheitern fail-closed. Der unmittelbar folgende Launch ohne Feld liefert wieder PT24H.
  13. Sicherheits-, Datenschutz-, Rechts-, Client- und Verhaltensabnahme sind dokumentiert. Dieses Runbook behauptet keinen zusätzlichen ID-in-Komponente-Submission-Blocker; die V1-Identitätsverarbeitung liegt im First-Party-WebGUI.
  14. Das historische 1.0.0-Reviewvideo bleibt ohne Anmeldung unter https://skillpilot.com/api/public/openai/review/skillpilot-coach-v1/1.0.0/sha256-20f5327535513df8b1c088b553195baf6ae339d57fc417b303488ae597644deb.mp4 erreichbar und byte-identisch. Es ist keine Verhaltensabnahme des neuen 1.1.2-Kandidaten. Vor einer erneuten Einreichung muss eine passende aktuelle Aufnahme gesondert erstellt, geprüft und unter eigener content-addressierter URL bereitgestellt werden; Größe, SHA-256, video/mp4, Byte-Range-Abruf und OpenAI-Origin/CORS-Preflight für GET und Range sind erneut nachzuweisen.

Erst nach erfolgreichem Publish im OpenAI-Portal wird der geprüfte Draft unveränderlich registriert:

Die jetzige Entwicklungsfreigabe enthält ausdrücklich keine Publikationsregistrierung. record-published bleibt auch mit beiden Flags gesperrt. Erst nach realem Portal-Publish und separater Autorisierung darf der Status mit dem aktuellen Kandidaten und Nachweisen fortgeschrieben werden.

node scripts/openai_plugin_release.mjs record-published \
  --confirm-openai-published \
  --confirm-mtls-enforced-and-verified

Vorher darf release-index.json die Version nicht als veröffentlicht führen.

4. mTLS-Betrieb und CA-Pflege

Mindestens alle 90 Tage werden die offiziellen OpenAI-Root- und Connectors- Intermediate-Dateien gegen die gepinnten Repositorydateien, Hashes, Fingerprints, Gültigkeitszeiträume und die dokumentierte Kette geprüft. Es gibt keinen automatischen Download in Produktion. Eine Änderung wird als reviewpflichtige CA-Rotation gemäß der CA-Provenienz mit statischem Gate, Preflight, Runtime-Smoke und realem ChatGPT-Positivtest ausgerollt; bei überlappenden OpenAI-Ketten wird ein überlappender Trust-Cutover geplant. Spätestens 90 Tage vor CA-Ablauf muss die Nachfolgestrategie bestätigt sein. Im Regelbetrieb werden mtls_edge_verified, mtls_edge_observed_no_cert und der Backend-Assertion-Counter mtls_edge_rejected überwacht. Zertifikats- und No-Certificate-Rejects entstehen bereits vor Spring und werden deshalb über das begrenzte Journal des mTLS-Verifiers sowie den öffentlichen 403-Edge- Status beobachtet. Fehlende verifizierte Aufrufe oder steigende Reject-Signale werden vor dem nächsten Release geklärt.

5. Rollback innerhalb von V1

Ein Rollback ändert weder Plugin-Identität noch Contract Major, MCP-Origin oder OAuth-Resource.

  1. Schreiboperationen bei Datenintegritätsrisiko über den Kill-Switch deaktivieren.
  2. Den letzten grünen Backend-/Edge-Build wiederherstellen.
  3. Für eine veröffentlichte Version nur den unveränderten Snapshot unter contracts/published/ verwenden.
  4. Fehlerhafte veröffentlichte Skill- oder Listing-Metadaten mit einer neuen kompatiblen Patchversion beheben; eine publizierte Version nie neu befüllen.
  5. OAuth-Tokens oder Lernsessionen nur bei einem konkreten Sicherheits- oder Datenintegritätsgrund pauschal widerrufen.

6. Deprecation, Unpublish und Löschung

Die Zustandsänderung beginnt in release/lifecycle.json:

  • SUPPORTED: funktionsfähig und sicherheitsgepflegt, aber nicht empfohlen;
  • DEPRECATED: funktionsfähig mit Nachfolger und veröffentlichten Fristen;
  • UNPUBLISHED: keine Neuinstallation, bestehende Installationen bleiben bis zum dokumentierten Supportende funktionsfähig;
  • RETIRED: kontrollierte Ablehnung ohne Verlust globalen Lernstands.

Unpublish ist kein technischer Shutdown. Eine Linie wird erst gelöscht, wenn Support-, Unpublish- und Löschfristen abgelaufen sind, keine unterstützten Installationen oder Migrationspfade verbleiben und globale Mastery unabhängig erhalten bleibt. Veröffentlichte Snapshots, Release Notes und Auditnachweise bleiben unveränderlich. MCP-Origin, OAuth-Resource und UI-Artefakte werden erst nach dem letzten unterstützten Client entfernt.

Eine zukünftige V2 überschreibt V1 nie still. Beide Linien besitzen getrennte Identitäten, Origins, Resources, Skills, Snapshots, Telemetrie und Lebenszyklen.