## 作成 LocalTicketBackend によって作成されました。 --- ## State changed Ticket を `workspace-panel` が queued にしました。 --- ## Decision Routing decision: implementation_ready Reason: - Panel Queue により、この Ticket は Orchestrator routing 対象として明示許可された。 - Ticket body には、Component Model runtime path の intent、requirements、acceptance criteria、non-goals、implementation notes、validation が実装可能な粒度で揃っている。 - depends_on の `00001KV5W3PHW` minimal WASM runtime と `00001KV5W3PJ3` permission grant enforcement は closed。 - Related/context work はすべて完了または non-blocking context として確認した。 - `00001KVFD3YSV` Plugin CLI inspection: closed。 - `00001KVFDX9AF` HTTPS host API: closed。 - `00001KVFDX9AY` FS host API: closed。 - `00001KSXRQ4G8` is planning design context, not blocking relation authority。 - Prior waiting-capacity notes の blocker は解消した。現在 inprogress Ticket は 0 件、child implementation Pod はなし、matching branch/worktree はなし、Orchestrator worktree は clean。 - Risk domain は component-model / WIT / runtime-backend / sandbox / packaging / SDK だが、Ticket は existing raw core-Wasm packages を silently reinterpret しない、grants before Tool registration/execution/host API access、no ambient WASI fs/network/env、ordinary Tool history path、runtime kind selected by manifest metadata などの invariants を明示している。bounded context check 後も implementation 前に必要な追加 human decision は見つからなかった。 Evidence checked: - Ticket `00001KVG0HR96` body / thread / artifacts。 - `TicketRelationQuery(00001KVG0HR96)`: depends_on blockers は closed。related records は context link。 - `TicketOrchestrationPlanQuery(00001KVG0HR96)`: previous waiting notes were based on active CLI/HTTPS/FS work; all are now closed. 今回 `accepted_plan` を記録済み。 - Current workspace state: - Orchestrator worktree clean。 - queued: this Ticket only。 - inprogress: 0。 - visible Pods: self + peers only; spawned children 0。 - Code/docs context: - `crates/manifest/src/plugin.rs`: current runtime metadata and `yoi-plugin-wasm-1` validation。 - `crates/pod/src/feature/plugin.rs`: current core-Wasm Plugin runtime, Tool registration/static inspection, HTTPS/FS host APIs, import validation。 - `crates/yoi/src/plugin_cli.rs`: inspection output should report Component runtime metadata without execution。 - Ticket body references `docs/design/plugin-component-model.md`, `docs/design/plugin-packages.md`, and Objective `00001KVG0HR9M` as design context. IntentPacket: Intent: - Add explicit WebAssembly Component Model runtime support for Plugin Tool packages while preserving existing Plugin discovery, enablement, digest pinning, ToolRegistry integration, ordinary Tool history, and Plugin grant enforcement. - Move Plugin authoring/runtime path toward WIT/canonical ABI so future `https`, `fs`, SDK, Service/Ingress APIs do not entrench the raw pointer/length core-Wasm ABI. Binding decisions / invariants: - Existing raw core-Wasm packages must not be silently reinterpreted as components。 - Runtime selection is manifest-driven. Component packages use explicit runtime metadata such as `kind = "wasm-component"`, component artifact path, and expected world。 - Existing raw runtime remains explicit (`kind = "wasm"`, `abi = "yoi-plugin-wasm-1"`) unless a migration/deprecation decision is recorded in this Ticket with tests updated accordingly。 - Package discovery and inspection remain read-only and must not execute components。 - Explicit enablement and digest/version/source pinning remain authoritative。 - Plugin grants are checked before Tool registration/execution and before host API calls。 - WIT imports are not authority by themselves。 - No ambient WASI filesystem/network/env is exposed。 - Component Tool registration still goes through existing ToolRegistry / model-visible schema path。 - Tool calls/results use ordinary Worker/Tool history path; no hidden context injection。 - HTTPS/FS host API security boundaries already implemented must be preserved。 Requirements / acceptance criteria: - A package with `runtime.kind = "wasm-component"` and expected WIT world can be discovered, enabled, registered as a Tool, and executed。 - Sample Component Model Tool Plugin returns a normal Tool result through ordinary Tool path。 - Sample Plugin author source uses generated/SDK bindings rather than raw pointer/length imports/exports。 - Component Tool execution is denied without matching Plugin grants。 - Component host imports cannot bypass Plugin grant model。 - Wrong world / missing export / incompatible component fails closed with bounded diagnostic。 - Existing raw core-Wasm runtime remains explicitly supported, or a migration/deprecation decision is recorded and tests updated。 - `yoi plugin list/show` reports Component runtime metadata without executing components。 - Documentation is updated with authoring/runtime instructions and migration notes。 - Build/package impact is measured and Nix packaging/cargo hash updated if dependencies change。 Implementation latitude: - Use `wasmtime::component` / WIT tooling or another narrow backend consistent with the codebase。 - Choose WIT names that version cleanly, e.g. `yoi:plugin/tool@1.0.0` and `yoi:host/https@1.0.0` / `yoi:host/fs@1.0.0`。 - If a staged approach is unavoidable, escalate before narrowing completion. Do not land manifest parsing alone as if it completes this Ticket。 - Keep compatibility layer and Component runtime dispatch cleanly separated。 - Use focused sample fixtures/tests rather than broad E2E process spawning。 Escalate if: - Component runtime execution cannot be implemented without a broad architecture redesign。 - Dependency/build-size impact is large enough to need product decision。 - WIT/tool request-response typing requires a product/API decision beyond Ticket latitude。 - Preserving both raw core-Wasm and Component runtime would substantially distort implementation。 - SDK/sample generation requires external toolchain not feasible in repository validation。 Validation: - Focused Component Plugin manifest/discovery/static inspection tests。 - Component Tool registration and execution tests。 - Grant denial before Component Tool execution / host API access。 - Wrong world / missing export / incompatible component fail-closed tests。 - Existing raw core-Wasm Plugin runtime tests remain passing or migration decision/tests updated。 - `cargo fmt --check`。 - `git diff --check`。 - relevant `cargo check` / `cargo test`。 - `nix build .#yoi` because component runtime dependencies / packaging are likely to change。 Critical risks / reviewer focus: - WIT imports becoming implicit authority。 - Component runtime bypassing existing Plugin grant enforcement。 - Ambient WASI fs/network/env exposure。 - Component execution bypassing ordinary Tool result/history path。 - Breaking existing raw core-Wasm package behavior without explicit decision/tests。 - Inspection accidentally executing components。 - Unbounded or secret-leaking diagnostics。 - Packaging/Nix/Cargo dependency correctness and binary/build-time impact。 Next action: - `queued -> inprogress` を記録し、Ticket records を Orchestrator worktree に commit してから、専用 implementation worktree を作成し Coder Pod を narrow write scope で起動する。root/original workspace は操作しない。 --- ## State changed Ticket body/thread, relation metadata, orchestration plan records, related completed Tickets, Orchestrator worktree, visible Pods, existing branch/worktree, and bounded Component Model runtime code context were checked. Depends-on blockers are closed, Plugin CLI / HTTPS / FS related work are closed, and no dirty-state blocker or missing planning decision was found. Accepting this queued Ticket for implementation before worktree/Pod side effects. --- ## Implementation report Implementation orchestration start: - Acceptance records were committed on Orchestrator branch: `878517dc ticket: accept plugin component model runtime`. - Created implementation worktree `/home/hare/Projects/yoi/.worktree/00001KVG0HR96-plugin-component-model-runtime` on branch `impl/00001KVG0HR96-plugin-component-model-runtime` at `878517dc`. - Initial `SpawnPod` attempt with only the implementation worktree as readable scope failed because the spawned runtime workspace identity is `/home/hare/Projects/yoi` and that root was not readable under the child scope. No child Pod remained registered. - Retried with read-only scope for `/home/hare/Projects/yoi` plus write scope limited to the implementation worktree. Coder Pod `yoi-coder-00001KVG0HR96` started successfully. The task explicitly instructs the Coder to edit/build/commit only in the implementation worktree and not to operate in the root/original workspace. Next action: - Wait for Coder implementation report, then inspect branch diff/validation evidence and route to Reviewer. ---