feat!: explain-permissions v2.0.0 — V2-only-Port auf die V2-Plugin-API (az-fleet-7x8)

Plugin.define({id: "az.explain-permissions", setup}) als Default-Export;
Hooks via ctx.permission.hook("evaluate"), ctx.session.hook("context"),
ctx.tool.hook("execute.before"); Event-Stream permission.v2.asked/replied;
Config-Lesung per fs mit V1+V2-Parser (JSONC-tolerant) statt hooks.config;
Action-Renames bash→shell/task→subagent, lsp/doom_loop verworfen.
KEIN V1-Export mehr (V2-only-Cut) — V1-Fleet bleibt gepinnt auf v1.3.0.

Verifikation: Mock-ctx-Tests 21/21 grün (Config-Parsing beider Formen,
System-Regel, evaluate/ask-Pfad, Hook↔Event-Dedup, replied, ENFORCE);
E2E vm-test folgt laut Issue.

explain-permissions/README.md

@@ -45,9 +45,27 @@ ln -sf ~/p/AZ/opencode-plugins/explain-permissions/explain-permissions.js ~/.con
 Danach opencode neu starten (siehe unten). Wichtig: nur EINE Datei dieses
 Namens im Plugin-Ordner — sonst lädt opencode das Plugin doppelt.
 
+### opencode V2 (ab v2.0.0 — V2-only)
+
+Die Datei exportiert `Plugin.define({id: "az.explain-permissions", setup})`
+als Default-Export und wird in `opencode.json(c)` unter dem V2-Schlüssel
+`plugins` referenziert (Einzel-Datei-Eintrag, absolute `file:///`-URL):
+
+```jsonc
+{
+  "plugins": [{ "package": "file:///C:/ProgramData/opencode/plugins/explain-permissions.js" }]
+}
+```
+
+Alternativ läuft die Datei auch unverändert als Datei-Plugin in
+`~/.config/opencode/plugins/` bzw. `.opencode/plugins/` (dort wird sie
+automatisch entdeckt, kein Config-Eintrag nötig). Benötigt opencode V2
+(Core 2.0.x); V1 (1.18.x) lädt sie bewusst NICHT (V2-only-Cut) — die V1-Fleet
+bleibt auf der gepinnten v1.3.0.
+
 ### Fleet
 
-Pin auf ein Tag (z. B. `explain-permissions/v1.1.0`) oder `main`; anonymes
+Pin auf ein Tag (z. B. `explain-permissions/v2.0.0`) oder `main`; anonymes
 `git clone` über HTTPS reicht, kein Token nötig.
 
 ## Konfiguration via Environment-Variablen
@@ -107,9 +125,48 @@ Relevante Events:
 **Plugin-Änderungen greifen erst nach Neustart von opencode** — eine neue
 Chat-Session im laufenden Prozess reicht nicht. Der Audit-Log-Eintrag
 `plugin-loaded` (mit Version) zeigt an, welche Version wann geladen wurde.
+Unter V2 gilt zusätzlich: Der Background-Service besitzt und cachet die
+Konfiguration — Config-/Plugin-Änderungen wirken erst nach
+`opencode service restart`; Änderungen an beobachteten Plugin-Verzeichnissen
+laden automatisch neu.
+
+## V2-Migrationsmappe (v2.0.0, az-fleet-7x8)
+
+| V1 (1.18.x) | V2 (2.0.x) |
+|---|---|
+| `export const ExplainPermissionsPlugin = async ({client}) => …` (Hooks-Objekt) | `export default Plugin.define({id: "az.explain-permissions", async setup(ctx)})`, Hooks via `ctx.*.hook()` registriert |
+| Config-Schlüssel `"plugin": ["file:///…"]` | `"plugins": [{"package": "file:///…"}]` (Einzel-Datei-Einträge unterstützt) |
+| `hooks.config` (liest permission-Sektion) | entfallen — Config-Dateien direkt per `fs` gelesen (Managed-Verzeichnis, Global, Projekt, `OPENCODE_CONFIG`), **beide** Formate: V1-`permission`-Map + V2-`permissions`-Array; Action-Renames bash→shell, task→subagent, write/patch→edit; `lsp`/`doom_loop` sind in V2 tote Actions und werden verworfen |
+| `permission.ask`-Hook + `permission.asked/updated`-Events | `ctx.permission.hook("evaluate")` — feuert für allow UND ask nach Regel-Evaluation, vor Dialog/Ausführung (explizites deny ruft den Hook nicht); Effect `ask` → `recordAsk` + `explainAndNotify` |
+| `permission.replied`-Event | `permission.v2.replied` im öffentlichen Event-Stream (`ctx.event.subscribe`), Payload `{sessionID, requestID, reply}` |
+| `experimental.chat.system.transform` | `ctx.session.hook("context")` → `event.system.push({type: "text", text})` — Agent-Loop inkl. Tool-Continuations |
+| `tool.execute.before` (ENFORCE) | `ctx.tool.hook("execute.before")` — Event `{tool, sessionID, callID, input}` |
+| `client.session.messages({path:{id}})` | `ctx.session.context({sessionID})` — Tool-Parts tragen die Call-ID als `id` (matcht `source.id` der Permission-Evaluation) |
+| `plugin-loaded`-Audit-Eintrag beim Laden | in `setup()` (jetzt mit Plugin-ID, opencode-Version, Location) |
+
+Unverändert übernommen: Notification-Logik je Plattform (PowerShell-WinRT-AUMID,
+injektionssicher), JSONL-Audit-Log samt Env-Flags, fail-soft-Muster, das
+Erklär-Format (Zitat-Block) und die ENFORCE-Semantik (greift nur auf Calls,
+die durch einen Freigabe-Dialog gegangen sind).
+
+Der `@opencode/plugin`-Import ist bewusst dynamisch mit Fallback auf die
+Rohestform `{id, setup}`: Schlägt die Paketauflösung fehl (Einzel-Datei-Package
+außerhalb eines npm-Kontexts), bleibt der Fleet-Load fail-soft und das Plugin
+trotzdem aktiv, statt beim Laden der ganzen Datei zu werfen.
 
 ## Versionierung
 
+- `explain-permissions/v2.0.0` — V2-only-Port auf die V2-Plugin-API (Core
+  2.0.x, az-fleet-7x8): `Plugin.define`-Default-Export, Hooks via
+  `ctx.permission.hook("evaluate")` / `ctx.session.hook("context")` /
+  `ctx.tool.hook("execute.before")`, Event-Stream `permission.v2.asked` /
+  `permission.v2.replied`, Config-Lesung per `fs` mit V1+V2-Parser
+  (JSONC-tolerant) statt `hooks.config`, Action-Namen auf V2
+  (bash→shell, task→subagent; lsp/doom_loop verworfen). KEIN V1-Export mehr
+  (V2-only-Cut, Entscheidung 25.09.) — V1-Fleet bleibt gepinnt auf v1.3.0.
+  Verifikation: Mock-ctx-Tests 21/21 grün (Config-Parsing beider Formen,
+  System-Regel-Injektion, evaluate/ask-Pfad, Hook↔Event-Dedup, replied-Audit,
+  ENFORCE); E2E auf vm-test laut Issue az-fleet-7x8.
 - `explain-permissions/v1.3.0` — Erklärungs-Format überarbeitet: Zitat-Block
   (`>`) mit fetten Labels (`**WAS passiert:**` usw.), jeder Punkt auf eigener
   Zeile — bessere Lesbarkeit und visuelle Hervorhebung in TUI und Desktop