PluginRuntime: canonical capability lookup/invocation for plugin composition #351

New issue

Open

opened 2026-09-08 02:03:37 +00:00 by nsaspy · 1 comment

nsaspy commented

2026-09-08 02:03:37 +00:00

Owner

Problem

zara-plugins now has domain plugins that must compose without importing each other's internals or creating parallel runtimes. zara-coding specifically needs to consume existing canonical plugin surfaces such as zara-github, zara-context, zara-memory, and zara-shell for issue/PR/CI, transient context, durable project rules, and bounded execution.

Current PluginRuntime exposes configuration, status, runtime command dispatch, event subscription, managed workers, and agent-loop advice, but no canonical plugin capability/tool lookup or invocation seam.

Without a Core seam, a plugin must either duplicate another plugin's implementation, import its private package directly, or invent its own registry/runtime — all undesirable.

Requested contract

Add a narrow, authorization-preserving composition API to PluginRuntime, for example a capability/tool lookup and invocation surface that:

resolves only loaded/enabled plugin capabilities through Core ownership;
preserves the target tool's canonical approval/authorization metadata and principal-scoped checks;
does not expose raw plugin objects or mutable registries;
supports structured request/result values and bounded failure reporting;
fails explicitly when the target plugin/capability is unavailable;
does not allow one plugin to bypass another plugin's policy by calling its Python implementation directly;
participates in plugin shutdown/reload semantics so stale handles fail closed.

Primary consumer

lost-rob0t/zara-plugins#1 (zara-coding) should delegate GitHub issue/PR/CI operations to zara-github, transient context to zara-context, memory to zara-memory, and generic approved execution to zara-shell rather than cloning those domains.

This is an upstream handoff only; no Zara Core code is being modified from the plugin worker.

## Problem `zara-plugins` now has domain plugins that must compose without importing each other's internals or creating parallel runtimes. `zara-coding` specifically needs to consume existing canonical plugin surfaces such as `zara-github`, `zara-context`, `zara-memory`, and `zara-shell` for issue/PR/CI, transient context, durable project rules, and bounded execution. Current `PluginRuntime` exposes configuration, status, runtime command dispatch, event subscription, managed workers, and agent-loop advice, but no canonical plugin capability/tool lookup or invocation seam. Without a Core seam, a plugin must either duplicate another plugin's implementation, import its private package directly, or invent its own registry/runtime — all undesirable. ## Requested contract Add a narrow, authorization-preserving composition API to `PluginRuntime`, for example a capability/tool lookup and invocation surface that: - resolves only loaded/enabled plugin capabilities through Core ownership; - preserves the target tool's canonical approval/authorization metadata and principal-scoped checks; - does not expose raw plugin objects or mutable registries; - supports structured request/result values and bounded failure reporting; - fails explicitly when the target plugin/capability is unavailable; - does not allow one plugin to bypass another plugin's policy by calling its Python implementation directly; - participates in plugin shutdown/reload semantics so stale handles fail closed. ## Primary consumer `lost-rob0t/zara-plugins#1` (`zara-coding`) should delegate GitHub issue/PR/CI operations to `zara-github`, transient context to `zara-context`, memory to `zara-memory`, and generic approved execution to `zara-shell` rather than cloning those domains. This is an upstream handoff only; no Zara Core code is being modified from the plugin worker.

nsaspy commented

2026-09-08 02:13:47 +00:00

Author

Owner

Zara Plugins Auto-RAGE handoff update: zara-coding now has the self-contained direct path through trusted SPEC compile/freeze and current repository verification (zara-plugins #105–#107 merged; #108 adds exact branch evidence and is in exact-head CI). The next acceptance slices that cannot be implemented honestly inside zara-coding are still the cross-plugin ones: issue.* / pr.* / ci.status must invoke zara-github, test.run / build.run must preserve zara-shell approval/cancellation policy, transient request context must come from zara-context, and durable workflow rules from zara-memory. Please keep the composition seam authorization-preserving and stale-handle-safe; the plugin worker will not import those private implementations or create a second registry/runtime while #400 is open.

Zara Plugins Auto-RAGE handoff update: `zara-coding` now has the self-contained direct path through trusted SPEC compile/freeze and current repository verification (`zara-plugins` #105–#107 merged; #108 adds exact branch evidence and is in exact-head CI). The next acceptance slices that cannot be implemented honestly inside `zara-coding` are still the cross-plugin ones: `issue.*` / `pr.*` / `ci.status` must invoke `zara-github`, `test.run` / `build.run` must preserve `zara-shell` approval/cancellation policy, transient request context must come from `zara-context`, and durable workflow rules from `zara-memory`. Please keep the composition seam authorization-preserving and stale-handle-safe; the plugin worker will not import those private implementations or create a second registry/runtime while #400 is open.