- Message-Teile liegen im Feld content (nicht parts — SDK-Typen sagen
parts; beide werden gelesen)
- Persistenz-Lag: Tool-Part ist zur Evaluations-Zeit ggf. noch nicht im
Message-Kontext — Text-Parts der Call-Message gelten dann als Erklärung
(liegen per Definition vor dem Call)
- execute.before-Event: Tool-Call-ID im Feld id (callID-Fallback bleibt)
plus messageID/agent — Shape per Diagnose-Plugin verifiziert
- Event-Namen im Stream: permission.asked/replied (präfix-tolerant)
- inspectCallContext mit DEBUG-Instrumentation (nMsgs/msgFound/partTypes)
E2E vm-test: plugin-loaded 2.0.0, Config-Lesung (Managed+Global+Projekt,
V1-Map), System-Regel je Model-Request (Modell erklärt im Zitat-Block-
Format), evaluate allow+ask (bash→shell-Normalisierung), ask + ask.explained
mit echter Modell-Erklärung. Mock-Tests 17+5 grün.
- notify() mit Plattform-Zweigen: Linux notify-send (unverändert),
macOS osascript, Windows PowerShell-Toast via WinRT + PowerShell-AUMID
(keine App-Registrierung nötig); Titel/Text über env des Child-Prozesses
(injektionssicher), XML-Escape via SecurityElement
- fail-soft Spawn in Node UND Bun (try/catch + error-Listener decken beide
ENOENT-Semantiken ab) — fehlendes Binary/headless = stiller No-Op
- Log-Pfad-Entscheidung: Windows %LOCALAPPDATA%\opencode\ (idiomatisch,
roamt nicht, Fallback ~\AppData\Local), sonst XDG-State unverändert;
dokumentiert im README
- Live verifiziert: Linux permission.asked -> ask/ask.explained/replied im
Audit-Log + Toast; Fail-Soft win32/darwin-Zweige in node+bun ohne Crash
Erstes Plugin im neuen Sammel-Repos opencode-plugins: Baseline-Import
der Solo-Datei von der lokalen Linux-Kiste (SHA-256-verifiziert
identisch) plus README mit Zweck, Env-Variablen, Audit-Log-Anzeige und
Neustart-Hinweis. Repo-Struktur: ein Ordner pro Plugin, pro-Plugin-Tags
<name>/v<version>.
m3ta-chiron
m3tam3re