ADR-0016: A plugin is a protocol participant

Status: Accepted, not implemented (the general plugin platform is deferred)
Date: 2026-06-24
Deciders: jka
Decision: D16

Context

rio should be extensible for architectural reasons: a small core with clean seams ages better. rio is not trying to attract an ecosystem, and supporting several scripting languages one by one would bloat the core.

Decision

A plugin attaches to the same protocol as a frontend (ADR-0011). There are two tiers with the same contribution API, differing only in transport:

Out-of-process, any language (primary). The core spawns the plugin and speaks JSONL over its standard streams or a socket. A crashing plugin cannot take down the core.
In-process Tcl (opt-in). Loaded as a Tcl package with direct calls, for trusted or performance-sensitive extensions.

rio supports one protocol rather than individual languages. Thin per-language SDKs live outside the core; the core ships a Tcl SDK and one reference SDK.

Consequences

Multi-language support follows from the existing boundary at little cost.
Out-of-process isolation makes sandboxing possible later.
The general platform (contribution API, manifests, SDKs) waits until real consumers exist. The extension kinds rio does ship today (syntax, modes, themes, providers) use narrower seams: ADR-0032, ADR-0038, ADR-0024, ADR-0066.
Chatty contributions such as per-keystroke highlighting may need the in-process tier or batching; that threshold is an open question.