ticket: split plugin runtime redesign

.yoi/objectives/00001KVG0HR9M/item.md

@@ -2,8 +2,8 @@
 title: "Plugin platform roadmap"
 state: "active"
 created_at: "2026-06-19T13:18:58Z"
-updated_at: "2026-06-19T13:18:58Z"
-linked_tickets: ["00001KV5R5V2S", "00001KV5W3PHA", "00001KV5W3PHW", "00001KV5W3PJ3", "00001KVFD3YSV", "00001KVFDX9AF", "00001KVFDX9AY", "00001KVG0HR96"]
+updated_at: "2026-06-24T19:55:00Z"
+linked_tickets: ["00001KV5R5V2S", "00001KV5W3PHA", "00001KV5W3PHW", "00001KV5W3PJ3", "00001KVFD3YSV", "00001KVFDX9AF", "00001KVFDX9AY", "00001KVG0HR96", "00001KVXHVCR5", "00001KVXK0WD3", "00001KVXK0WDH", "00001KVXK0WDQ", "00001KVXK0WDX", "00001KVXK0WE4", "00001KVXK0WEA"]
 ---
 
 ## Goal
@@ -42,10 +42,10 @@ Research of common Wasm extension systems points to the same pattern: mature sys
   - Package presence never registers a Tool/Hook, executes Wasm, starts a Service, reads files, opens network, or injects context.
   - Explicit enablement and Plugin grants are required before registration/execution/host API use.
   - Tool calls/results continue through ordinary ToolRegistry and Worker history paths.
-- Treat Component Model as the preferred future Plugin runtime shape.
+- Treat Component Model as the active Plugin runtime shape before public release.
   - New typed Plugin host APIs should be designed in WIT-compatible terms.
-  - `runtime.kind = "wasm-component"` should become the preferred runtime once implemented.
-  - Current `yoi-plugin-wasm-1` raw core-Wasm ABI remains a compatibility / migration bridge until Component Model execution and authoring are validated.
+  - `runtime.kind = "wasm-component"` is the current Plugin runtime authority for new work.
+  - The earlier `yoi-plugin-wasm-1` raw core-Wasm compatibility bridge is retired from the active roadmap because Plugin has not been publicly released and compatibility would preserve the wrong boundary.
 - Sequence the platform in usable layers:
   1. Package discovery / explicit enablement / digest-pinned restore. Completed foundation.
   2. Tool surface registration. Completed foundation.
@@ -53,30 +53,49 @@ Research of common Wasm extension systems points to the same pattern: mature sys
   4. Permission grants. Completed foundation.
   5. Read-only Plugin CLI inspection (`yoi plugin list/show`) for debugging discovery/enablement/grants/runtime metadata.
   6. `https` and `fs` host APIs for Tool Plugins, grant-gated and WIT-compatible.
-  7. Component Model runtime migration and authoring model.
-  8. Guest SDK/PDK, examples, `check`/`pack`/`new` authoring tooling.
-  9. Service / Ingress / WebSocket or inbound HTTP only after Tool + host API foundations are stable.
+  7. Remove the raw core-Wasm compatibility bridge and reject legacy runtime manifests.
+  8. Component Model runtime and authoring model become the only active Plugin runtime path.
+  9. Guest SDK/PDK, examples, `check`/`pack`/`new` authoring tooling target Component Model only.
+  10. Service / Ingress runtime is developed as host-managed lifecycle, event queue, output command, and diagnostics slices.
+  11. WebSocket support for long-lived integrations is host-owned connection driver + ingress event delivery + output command, not Plugin-owned polling with `recv(timeout)`.
 - Keep Discord-style bridge goals split into two stages.
   - Outbound Discord/webhook Tool is possible after `https`.
   - Bidirectional Discord bridge requires Service + Ingress + WebSocket or inbound HTTP and host routing policy.
 
+## Current implementation split
+
+The broad Plugin runtime redesign is tracked by `00001KVXHVCR5` as context only; implementation should proceed through concrete Tickets instead of routing that umbrella as a single coding task.
+
+1. `00001KVXK0WD3` Remove legacy raw WASM Plugin runtime.
+   - Deletes the active `LegacyToolAdapter` / raw-Wasm execution path.
+2. `00001KVXK0WDH` Reject legacy Plugin runtime in manifest and CLI diagnostics.
+   - Makes `plugin.toml`, `yoi plugin check/list/show`, docs, and fixtures reflect Component Model only runtime authority.
+3. `00001KVXK0WDQ` Define Plugin Service lifecycle and ingress queue runtime.
+   - Adds host-managed lifecycle, bounded queue, serial dispatch, backpressure, timeout, and diagnostics.
+4. `00001KVXK0WDX` Add Plugin service output command model.
+   - Lets service handlers request side effects as grant-checked commands rather than ambient authority.
+5. `00001KVXK0WE4` Add host-owned WebSocket driver for Plugin services.
+   - Converts incoming WS frames into ingress events and sends outbound frames through output commands.
+6. `00001KVXK0WEA` Update Plugin WIT PDK templates for service event runtime.
+   - Aligns authoring API, WIT, PDK, templates, and docs with the new event/command execution model.
+
 ## Success criteria / exit conditions
 
 - Users can inspect Plugin discovery/enablement/grant/runtime state through a read-only CLI without executing Plugin code.
 - Plugin authors can build a Tool Plugin without writing raw memory/pointer ABI plumbing.
 - Tool Plugins can safely call grant-gated `https` and `fs` host APIs.
-- Component Model support is available or a documented migration path is active, with WIT-compatible host API types and measured packaging/runtime impact.
+- Component Model is the only active Plugin runtime path, with WIT-compatible host API types and measured packaging/runtime impact.
 - Plugin grants remain authoritative over registration, execution, and host API calls.
-- Plugin diagnostics explain missing package, invalid manifest, digest/version mismatch, missing grant, rejected schema, runtime mismatch, and unsupported host API cases safely.
-- Existing raw core-Wasm Plugin tests either remain passing or have an explicit compatibility/deprecation decision.
-- Documentation covers package format, runtime kinds, Component Model direction, host API authority, authoring SDK/templates, and operational debugging.
-- Service/Ingress work starts only after Tool Plugin + host API + diagnostics foundations are usable.
+- Plugin diagnostics explain missing package, invalid manifest, digest/version mismatch, missing grant, rejected schema, runtime mismatch, legacy runtime rejection, and unsupported host API cases safely.
+- Raw core-Wasm Plugin compatibility is removed before public release; tests and docs no longer treat it as a current runtime.
+- Documentation covers package format, Component Model runtime, host API authority, authoring SDK/templates, Service/Ingress event runtime, and operational debugging.
+- Service/Ingress work is host-managed: services have lifecycle/status, ingress uses bounded queues, side effects are output commands, and WebSocket integrations use host-owned connection drivers.
 
 ## Decision context
 
 - This Objective is roadmap context, not Ticket authority. Implementation still requires reading concrete Ticket bodies, threads, artifacts, and relations.
-- Component Model direction supersedes making Yoi's custom raw ABI the long-term authoring interface, but does not require an immediate flag-day rewrite.
+- Component Model direction supersedes Yoi's custom raw ABI as both long-term and current active Plugin runtime authority before public release.
 - `https` / `fs` work should avoid choices that conflict with later WIT typed interfaces.
-- Guest SDK work should either target Component Model directly or keep the raw ABI wrapper clearly transitional.
+- Guest SDK work targets Component Model directly; raw ABI wrappers are not a supported transitional authoring path.
 - Plugin and MCP remain separate. Component Model adoption for Plugin does not imply MCP server execution, MCP prompt/resource injection, or MCP trust policy changes.
 - Plugin surfaces remain Tool / Hook / Service / Ingress; outbound side effects are Tool metadata and host API grants, not a separate surface.