@@ -7,6 +7,15 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 ---
 
+## Unreleased — 2026-09-30
+
+### Dokumentation
+- Plattformgerechte Release-, Paket- und Backend-Updatewege für WordPress, Shopware 6 und JTL Shop 5 ergänzt.
+- Geschützte Update-Kanäle für private PHP-Plugins und die separate öffentliche Binär-Release-Strecke der MGD Academy beschrieben.
+- Prüfmatrix und Grenzen von GitHub-Release, CI, Digest und realem Installationstest festgehalten.
+
+---
+
 ## [1.1.0] - 2026-06-23
 
 ### Added
 
@@ -20,6 +20,8 @@ Der Skill begleitet dich in 2 Phasen:
 
 Für Desktop-Apps (Flutter, Electron, Tauri, Swift), Mobile Apps, Web-Apps, SaaS und Backend-Systeme.
 
+Neu: [CMS-Plugin-Updates für WordPress, Shopware und JTL Shop](wiki/17-CMS-Plugin-Updates.md) sowie die [konkrete In-App-Update-Strecke von MGD Academy](wiki/18-MGD-Academy-In-App-Updates.md). Beide Anleitungen trennen Erkennung, Paket, Backend-Installation und realen Funktionstest.
+
 ---
 
 ## Was ist dieser Skill?
 
@@ -14,6 +14,8 @@ Der Skill besteht aus zwei Phasen:
 
 Der Skill ist **technologie-neutral**: Desktop (Electron, Tauri, Flutter), Mobile (Flutter, React Native, Swift), Web (React, Vue, Next.js), Backend (Node.js, Python, Go), Games (Unity, Godot).
 
+Für konkrete Plattformen nach der Planung: [CMS-Plugin-Updates (WordPress, Shopware, JTL Shop)](../wiki/17-CMS-Plugin-Updates.md) und [MGD Academy In-App-Updates](../wiki/18-MGD-Academy-In-App-Updates.md). Ein Release-Tag beweist noch keine Erkennung oder Installation im Produkt.
+
 ---
 
 ## Kernregel — Erst planen, dann implementieren
 
@@ -0,0 +1,59 @@
+# 17 — Plugins in WordPress, Shopware und JTL Shop aktualisieren
+
+Stand: 30.09.2026. Diese Anleitung unterscheidet bewusst **Update erkennen**, **Paket bereitstellen**, **Installation im Backend** und **live geprüft**. Ein GitHub-Release allein löst in keinem der drei Systeme magisch ein Update aus.
+
+## Gemeinsamer Release-Vertrag
+
+1. Eine versionierte Plugin-Datei, ein Tag `vX.Y.Z` und der installierbare ZIP-Inhalt müssen dieselbe Version tragen. Teste diese Gleichheit im Release-Workflow.
+2. Veröffentliche einen **fest benannten** Paket-Asset. GitHubs automatisch erzeugte „Source code“-ZIPs sind keine verlässlichen Installationspakete.
+3. Baue das ZIP reproduzierbar mit exakt dem erwarteten Plugin-Hauptordner; schließe `.env`, Zugangsdaten, Tests und Build-Verzeichnisse aus. Prüfe Dateiliste, ZIP-Integrität, Größe und nach Möglichkeit SHA-256 sowie gefährliche Pfade/Symlinks.
+4. Prüfe neue Versionen mit Cache, manueller Aktualisierungsmöglichkeit und eindeutigem Fehlerstatus. Zeige keine Beta-Version als Stable-Update.
+5. Installiere erst nach Staging-Update, Backup, Rollback-Plan und realem Backend-Test. Ein grüner CI-Lauf beweist keine funktionierende Kundeninstallation.
+6. Dokumentiere die Zustände getrennt: Code vorbereitet → PR geprüft → Release veröffentlicht → Backend erkennt → Backend installiert → Storefront und Admin geprüft.
+
+## Öffentliche und private Repositories
+
+Bei öffentlichen Repositories kann das CMS Release-Metadaten und Paket ohne Schlüssel laden. Bei **privaten** Repositories bleibt auch das ZIP privat. Jede Kundeninstallation bekommt einen eigenen, auf genau das Repository beschränkten Read-only-Token im Server-Secret-Store oder in einer nicht versionierten Konfigurationsdatei. Nie im Plugin, Client, Log oder Support-Screenshot. Bei einem GitHub-Asset-Aufruf geht `Authorization` nur an die passende GitHub-API; bei der Weiterleitung zum Download-Host muss der Header entfernt werden. Ohne gültigen Token **kein** öffentlicher Fallback. Tokenrotation und Entzug pro Kunde vorsehen.
+
+Ein öffentliches Release-Repository wie bei MGD Academy legt seine Binärpakete offen. Dieses Muster eignet sich **nicht** für privaten Plugin-Code, wenn das ZIP den PHP-Quellcode enthält.
+
+## WordPress
+
+- Plugin-Header `Version` und bei externem Anbieter `Update URI` korrekt setzen. Die WordPress-Update-Information muss zum exakten Plugin-Basename und Slug passen.
+- Bei öffentlichen Plugins können WordPress-Filter oder ein gepflegter Update-Checker GitHub-Releases integrieren. Bei privaten Plugins muss derselbe Mechanismus Metadaten **und** Paket authentifiziert abrufen. Ein Token nur für die Versionsprüfung ist unzureichend.
+- Der installierbare ZIP-Hauptordner muss stabil bleiben, zum Beispiel `fragebogen/`. Der Update-Checker darf nicht auf Tag-/Branch-Archive zurückfallen, wenn das freigegebene Release-Asset fehlt.
+- Die eigentliche Installation soll WordPress über „Plugins“ oder „Dashboard → Aktualisierungen“ durchführen. WordPress-Auto-Updates nur nach ausdrücklicher Produktentscheidung aktivieren.
+- Besonders kritisch: Daten, die fälschlich innerhalb des Plugin-Verzeichnisses liegen, können beim Ersetzen des Ordners verloren gehen. Vor dem ersten Update migrieren und sichern.
+
+## Shopware 6
+
+- Composer-/Plugin-Version, Tag und ZIP-Paket synchronisieren; Shopware-kompatible Ordnerstruktur prüfen.
+- Ein Shopware-Plugin kann GitHub-Releases prüfen und ein neues Paket **vorbereiten**. Die Anwendung des Pakets soll durch Shopwares native Plugin-Verwaltung und deren Update-/Migrationsablauf erfolgen. Ein Dateikopieren direkt über die laufende Installation ist kein sicheres Backend-Update.
+- Paket nur aus stabilem Release, mit fester Asset-Bezeichnung, Integritätsprüfung und atomarer Staging-Ablage akzeptieren. Anschließend Plugin-Refresh, Update und Cache-/Theme-Kompilierung nach Shopware-Verfahren testen.
+- „Jede Stunde prüfen“ bedeutet nur Erkennung nach Cache-/Cron-Lauf, nicht GitHub-Push-Benachrichtigung und nicht automatisches Installieren. Einen manuellen „Jetzt prüfen“-Knopf für Administratoren anbieten.
+
+## JTL Shop 5
+
+- Die `info.xml`-Version und das JTL-Plugin-ZIP müssen exakt zusammenpassen. Der Hauptordner im ZIP ist entscheidend.
+- GitHub-Release-Prüfung kann im JTL-Backend eine neue Version und einen Download anzeigen. **Das ist noch kein Ein-Klick-Update aus GitHub.** Der bisherige MGD-Weg lädt das ZIP herunter, lädt es in die JTL-Pluginverwaltung und führt das Update dort aus.
+- Für einen echten „Update“-Knopf ohne manuellen ZIP-Upload muss das neue Paket kontrolliert serverseitig in die erwartete Plugin-Ablage gelangen und der JTL-Pluginmanager es als neue Version erkennen. Dies nur gegen die konkret eingesetzte JTL-Version und mit Backup testen; kein direktes Überschreiben aktiver PHP-Dateien.
+- Cache-Häufigkeit und Backend-„Jetzt prüfen“ sind getrennte Einstellungen. Frontend-Requests dürfen GitHub nicht synchron belasten.
+
+## Testprotokoll pro Plugin
+
+| Nachweis | Erwartetes Ergebnis |
+|---|---|
+| Ohne neue Version | Keine falsche Update-Anzeige |
+| Stable-Release mit gültigem ZIP | Exakte Version und richtiger Slug im Backend |
+| Fehlender/ungültiger Token (privat) | Sichere Fehlermeldung, keine Token-Ausgabe, kein Fallback |
+| Beta/Draft oder fehlendes Asset | Nicht als Stable-Update installierbar |
+| Manipuliertes/falsches Paket | Abbruch vor Installation |
+| Staging-Update | Einstellungen und Kundendaten bleiben erhalten; Funktion im Admin und Frontend |
+| Rollback | Vorherige Version und Daten aus Backup wiederherstellbar |
+
+## Quellen und Beispielimplementierungen
+
+- [WordPress-Plugin-Header mit Update URI](https://developer.wordpress.org/plugins/plugin-basics/header-requirements/), [externer Update-Filter](https://developer.wordpress.org/reference/hooks/update_plugins_hostname/) und [Hook vor dem Download](https://developer.wordpress.org/reference/hooks/upgrader_pre_download/).
+- [GitHub Release Assets API](https://docs.github.com/en/rest/releases/assets): geschützte Asset-Downloads.
+- [Plugin Update Checker](https://github.com/YahnisElsts/plugin-update-checker): `setAuthentication()` für private Repositories; Asset- und Fallback-Verhalten der verwendeten Version prüfen.
+- MGD-Referenzen: `MGD_WordPress-MCP` (WordPress, öffentlich), `MGD-AI-Kennzeichnung-Shopware-6` (Shopware, öffentlich), `MGD-AI-Kennzeichnung-JTL-Shop-5` (JTL, Backend-Hinweis). Referenzen sind Muster, **kein** pauschaler Live-Funktionsnachweis.
@@ -0,0 +1,32 @@
+# 18 — MGD Academy: In-App-Updates über separates Release-Repository
+
+Stand: 30.09.2026. Diese Anleitung beschreibt die **im Quellcode vorhandene** macOS-Strecke und ihre Grenzen, nicht eine allgemeine Update-Garantie für jede Plattform.
+
+## Architektur
+
+Der Quellcode der Flutter-App liegt getrennt vom öffentlichen [`MGD-Academy-Releases`](https://github.com/MichaelGahnDESIGN/MGD-Academy-Releases). Ein macOS-Release-Workflow im privaten Quellrepository baut die `.app`, ein Installations-DMG und ein besonderes In-App-ZIP. Er veröffentlicht die Artefakte als GitHub-Release im privaten Quellrepository **und** im öffentlichen Release-Repository. Das öffentliche Repository enthält die installierbaren Dateien, nicht automatisch den privaten Quellcode. Ein Token gehört nicht in die App.
+
+Die installierte App fragt `https://api.github.com/repos/MichaelGahnDESIGN/MGD-Academy-Releases/releases/latest` ab, vergleicht den Tag mit der installierten Version und wählt unter den Assets `MGD-Academy-*-macOS-update.zip`. Nutzer sehen Version, Hinweise und einen Installationsweg. Die App lädt das ZIP in ein temporäres Verzeichnis und vergleicht SHA-256 mit dem `digest` des GitHub-Assets. Fehlt der Digest oder stimmt er nicht, wird abgebrochen. **SHA-256 schützt hier gegen beschädigte/abweichende Downloads; da Digest und Paket aus demselben Release-Konto stammen, ersetzt dies keine unabhängige Signatur oder Apple-Notarisierung.**
+
+## macOS-Installation
+
+Der Installer verweigert den automatischen Austausch, wenn die App direkt aus einem DMG unter `/Volumes/` läuft. Ansonsten wartet ein losgelöstes Hilfsskript auf das Ende der laufenden App, entpackt das ZIP, kopiert die neue `.app` zunächst als `APP.new`, verschiebt die alte nach `APP.old` und startet die neue App. Schlägt der Start fehl, stellt es `APP.old` zurück und versucht den alten Start. Persönliche SQLite-Daten liegen getrennt im Application-Support-Verzeichnis und sollen nicht Teil des App-Bundles sein.
+
+Wichtig: Der gezeigte Skript-Rollback prüft einen erfolgreichen `open`-Aufruf und kurze Wartezeit, **keine** vollständige Funktionsprüfung der neuen Version. Signierung, Hardened Runtime und Apple-Notarisierung müssen für eine belastbare externe macOS-Verteilung gesondert überprüft werden. Im öffentlich sichtbaren Release-README wird fehlende Notarisierung genannt. Die Windows-Strecke im Update-Service erkennt zwar einen Setup-Assetnamen, der automatische Installer ist dort noch nicht freigeschaltet.
+
+## Release- und Abnahmeregeln
+
+1. Versionsdatei, Flutter-Paketversion, Tag und Dateinamen abgleichen; Artefakte aus genau einem getesteten Commit bauen.
+2. Build- und Inhaltstests durchführen. DMG und Update-ZIP getrennt bauen; SHA-256 für beide veröffentlichen.
+3. Public-Release erst nach erfolgreichem privaten Build und Signier-/Paketprüfung veröffentlichen. Keine zweite manuelle Veröffentlichung parallel zum CI-Workflow starten.
+4. Mit einer **installierten älteren Version** den echten Ablauf testen: Hinweis → Download → Hashprüfung → Austausch → Neustart → Versionsanzeige → lokale Daten erhalten. Ein GitHub-Release oder grüner Build allein reicht nicht.
+5. Auch Abbruchfälle prüfen: offline, 404, fehlender Asset/Digest, falscher Hash, Startfehler, fehlende Schreibrechte und Start direkt vom DMG.
+
+## Relevante Quellorte
+
+- Im privaten `MGD-Academy`-Quellrepository: `lib/services/update_service.dart`, `lib/ui/screens/update_install_screen.dart`, `.github/workflows/release.yml`, `docs/UPDATES.md`.
+- Im öffentlichen [`MGD-Academy-Releases`](https://github.com/MichaelGahnDESIGN/MGD-Academy-Releases): Release-Historie und herunterladbare Pakete. Zum Prüfzeitpunkt war `v0.11.0` mit macOS-DMG, Update-ZIP und Prüfsummen vorhanden.
+
+## Nicht auf private CMS-Plugins übertragen
+
+Bei Academy darf das öffentliche ZIP die verteilbare Binär-App enthalten. Ein WordPress-, Shopware- oder JTL-ZIP enthält in der Regel lesbaren PHP-Code. Falls der Plugin-Code privat bleiben soll, muss auch der Downloadkanal geschützt sein: per-installation Read-only-Zugang am Server oder eigener authentifizierter Update-Dienst, niemals ein eingebetteter gemeinsamer Token.