From 5680f69e8b0420ebd19b1d4100b457aa894b0b0f Mon Sep 17 00:00:00 2001 From: xj Date: Sun, 22 Feb 2026 19:07:23 -0800 Subject: [PATCH] docs(plugin): prefer subprocess rpc over go .so plugins --- docs/design/plugin-system-roadmap.md | 15 +++++++++++++++ 1 file changed, 15 insertions(+) diff --git a/docs/design/plugin-system-roadmap.md b/docs/design/plugin-system-roadmap.md index 8a8d38ad8..8981f5b0d 100644 --- a/docs/design/plugin-system-roadmap.md +++ b/docs/design/plugin-system-roadmap.md @@ -23,6 +23,7 @@ Compatibility: - No remote plugin marketplace/distribution - No plugin sandboxing model - No stable external plugin ABI yet +- No Go `.so` plugin loading as default direction ## Phase Plan @@ -78,12 +79,26 @@ Exit criteria: Goal: support runtime-loaded plugins only if security and operability are acceptable. +Preferred direction: + +- Runtime plugins run as subprocesses. +- Host and plugin communicate via RPC/gRPC. +- Host manages lifecycle (spawn/health/timeout/restart), not in-process dynamic loading. + +Why this direction: + +- Go native `.so` plugin loading has strict toolchain/ABI coupling with host binary. +- Subprocess RPC model reduces coupling and improves fault isolation. +- Process boundary provides a cleaner place for permissions and sandbox controls. + Preconditions: - Threat model approved - Signature/trust model defined - Sandboxing and permission boundaries defined - Rollback and safe-disable behavior validated +- Versioned RPC handshake and capability negotiation defined +- Process supervision policy defined (timeouts, retries, crash loop backoff) Until then, compile-time registration remains the recommended model.