Expose a safe Runtime extension lifecycle through explicit commands #4

Context

Runtime owns the extension manager and sandbox, but the application currently has no supported product path to load an extension from the Backend-provided resolver, unload it by name, or inspect active extension state. The manager accepts source text directly and has owner-scoped rollback; it did not expose a resolver-backed entry operation or trusted lifecycle inspection methods.

The module resolver prerequisite belongs to Backend and is tracked in Backend issue. This issue owns Runtime lifecycle policy and command/API behavior after a resolver is supplied.

Ownership

Runtime owns extension lifecycle, the public capability facade, command registration/availability, unload semantics and structured errors. It must not access OS paths, files, C pointers or Backend internals.

Acceptance criteria

• Add a resolver-backed manager entry path that loads the plugin's declared entry module for the requesting plugin namespace; preserve explicit-source loading for unit tests/embedding where allowed.
• Add explicit extension.load, extension.unload and extension.list Runtime lifecycle operations through trusted Runtime embedding methods (load_extension, unload_extension, list_extensions) with stable structured errors and deterministic results. These are intentionally not remote Frontend Protocol commands.
• Keep loading disabled/fail-closed when Backend has not supplied an approved resolver/capability.
• Define who may invoke extension lifecycle operations; ordinary remote Frontend Protocol commands must not implicitly gain permission to load arbitrary local code.
• Preserve existing owner-scoped rollback for commands/keymaps/events/styles/themes/syntax after failed init and explicit unload.
• Define collision/reload behavior and ensure duplicate load, nested require failure, unload failure and manager shutdown are deterministic.
• Add Runtime unit/integration tests using a scoped fake resolver; add Backend integration coverage separately after the Backend resolver is merged.
• Update Extension API docs and Host/Spec references without claiming OS-level isolation or hot-swap.

Security constraints

• Do not expose io, os, debug, native handles or unrestricted package loading.
• Do not allow module resolution outside the requesting plugin's namespace.
• Do not treat Lua sandboxing as a security boundary against hostile code; state the process-isolation limitation.
• Do not allow remote observers or untrusted clients to load plugins.

Related

• CDIN release epic: cdin-editor/cdin#111
• Backend resolver prerequisite: cdin-editor/backend
• Extension contract: extension-api.md

Completion — 2026-11-06

Completed by Runtime PR #5 and #6. The public lifecycle is a trusted Runtime embedding API, backed by the Backend-owned resolver; it is deliberately not registered as a remote Frontend command. Resolver failures, failed init rollback, duplicate loads, explicit unload failure cleanup and shutdown semantics are covered by Runtime integration tests. Backend's native resolver and lifecycle integration is delivered in Backend PR #16.