## 作成 LocalTicketBackend によって作成されました。 --- ## Intake summary Marked ready by `yoi ticket state`. --- ## State changed Marked ready by `yoi ticket state`. --- ## State changed Ticket を `workspace-panel` が queued にしました。 --- ## Decision Routing decision: implementation_ready Reason: - Workspace Dashboard Queue により、この Ticket は Orchestrator routing 対象として明示許可された。 - Ticket body は Plugin instance model / registry、new Component instance world、legacy Tool adapters、manifest/static validation、plugin check/list/show reporting、Service/Ingress lifecycle/status、Ingress test path、per-surface grants、docs/templates/PDK updates、validation を詳細に定義している。 - 未解決 relation blocker はない。 - 現在 queued はこの Ticket のみ、inprogress は 0 件、spawned child implementation Pods はなし、matching branch/worktree はなし、Orchestrator worktree は clean。 - Risk domain は plugin / wasm-component / service / ingress / lifecycle / grants / runtime architecture だが、Ticket は no hidden context injection、ToolRegistry run-stability、legacy Tool compatibility、no ambient WASI network/socket、per-surface grants、host-mediated outputs を明示している。bounded context check 後も implementation 前に必要な追加 human decision は見つからなかった。 Evidence checked: - Ticket `00001KVJHYP4Q` body / thread / relations / artifacts。 - `TicketRelationQuery(00001KVJHYP4Q)`: no blockers。 - `TicketOrchestrationPlanQuery(00001KVJHYP4Q)`: no previous plan records; accepted plan recorded now。 - Workspace state: - Orchestrator worktree clean at `7f06e656`。 - queued: this Ticket only。 - inprogress: 0。 - visible Pods are self/peers only; spawned children 0。 - no matching implementation branch/worktree。 IntentPacket: Intent: - Move Plugin runtime semantics from per-Tool artifact execution to host-managed `PluginInstance` / `PluginInstanceRegistry`。 - Treat Tool / Service / Ingress as surfaces of the same Plugin instance, sharing instance state/config/diagnostics while preserving explicit authorization and ordinary visible output paths。 - Preserve existing Tool-only component/raw wasm Plugin packages through compatibility adapters。 Binding decisions / invariants: - Existing Tool Plugin packages must continue to work through instance registry compatibility path。 - Tool execution remains model/user initiated and returns through ordinary Tool result/history path。 - Service/Ingress must not secretly call model Tools or mutate context/history directly。 - Plugin outputs/events must use Tool results or explicit durable/visible host-mediated paths; no hidden context injection。 - Tool schemas remain run-stable and model-visible only through normal ToolRegistry construction。 - Per-surface grants are independent: Tool, Service, Ingress grants must be validated separately; sharing an instance must not bypass authorization。 - Host APIs remain separately grant-gated。 - No raw ambient WASI network/socket authority。 - Ingress events are bounded typed untrusted inputs。 - If a safe host action path does not exist, expose diagnostics/status rather than inventing unsafe paths。 Requirements / acceptance criteria: - Add `PluginInstanceRegistry` or equivalent host-managed instance boundary。 - ToolRegistry dispatch goes through Plugin instance handles。 - Add new Component instance world/resource files and Rust PDK support。 - Add legacy Tool component/raw wasm adapters behind the instance registry。 - Extend manifest/static validation for Service/Ingress declarations and runtime compatibility。 - Update `yoi plugin check/list/show` reporting for legacy Tool-only vs instance-capable packages and rejected surfaces。 - Add host-managed start/status/stop lifecycle and bounded diagnostics。 - Add Ingress dispatch API and at least one bounded in-process ingress delivery test path。 - Validate Tool/Service/Ingress grants independently。 - Update docs/templates for instance-oriented authoring。 - Focused tests cover manifest validation, legacy compatibility, instance state persistence across Tool calls, Tool/Ingress shared instance dispatch, grant denial, timeout/trap/failure diagnostics。 - Validation includes `cargo fmt --check`, relevant tests/checks, `git diff --check`, `yoi ticket doctor`, and `nix build .#yoi --no-link`。 Escalate if: - The instance boundary cannot be implemented without broad Worker/ToolRegistry redesign beyond Ticket scope。 - Preserving legacy Tool runtime while adding instance runtime would substantially distort architecture。 - Safe Service/Ingress host action semantics require a product decision not already specified。 - WIT/PDK interface shape requires a compatibility-breaking public API decision beyond this Ticket。 Next action: - Record `queued -> inprogress` and commit Ticket records before creating implementation worktree and spawning Coder。 --- ## State changed Ticket body/thread, relation metadata, Orchestrator worktree state, visible Pods, existing branch/worktree, and bounded Plugin instance lifecycle context were checked. There is no unresolved blocking dependency, no inprogress/capacity blocker, and no missing planning decision. Accepting this queued Ticket for implementation before worktree/Pod side effects. --- ## Implementation report Implementation orchestration start: - Acceptance records were committed on Orchestrator branch: `5ec8bae9 ticket: accept plugin instance lifecycle`。 - Created implementation worktree `/home/hare/Projects/yoi/.worktree/00001KVJHYP4Q-plugin-instance-lifecycle` on branch `impl/00001KVJHYP4Q-plugin-instance-lifecycle` at `5ec8bae9`。 - Spawned Coder Pod `yoi-coder-00001KVJHYP4Q` with write scope limited to the implementation worktree and read-only root scope only for runtime workspace identity。 - Coder task explicitly forbids root/original workspace implementation, unsafe hidden context/action paths, broad ToolRegistry bypasses, merge, Ticket close, and cleanup。 Next action: - Wait for Coder implementation report, then inspect branch diff/validation evidence and route to Reviewer。 --- ## Implementation report Coder implementation report received from `yoi-coder-00001KVJHYP4Q`. Implementation commit: - `147a6005 plugin: add instance lifecycle surface` Changed areas reported: - Manifest support for Service/Ingress declarations and permissions。 - New `yoi:plugin/instance@1.0.0` WIT/resource surface。 - Host-managed `PluginInstanceRegistry` / `PluginInstanceHandle` in Pod plugin feature layer。 - Plugin Tool registration/dispatch now routes through instance handles。 - Legacy raw-wasm and `yoi:plugin/tool@1.0.0` component Tool runtimes preserved through registry adapter path。 - Instance lifecycle/status/stop/diagnostics surfaces and bounded Ingress dispatch API added。 - Independent Tool/Service/Ingress grant validation added。 - Static inspection / Plugin CLI diagnostics extended for Service/Ingress eligibility。 - Rust PDK instance-oriented types/trait/macro support added。 - Rust component instance template resources added。 - Plugin component model docs updated。 - Tests added/updated for manifest validation, CLI reporting/templates, legacy compatibility, grant checks, and in-process shared Tool/Ingress dispatch。 Coder validation reported as passing: - `cargo test -p manifest plugin -- --nocapture` - `cargo test -p pod plugin -- --nocapture` - `cargo test -p yoi plugin -- --nocapture` - `cargo check -p yoi` - `cargo check -p yoi-plugin-pdk` - `cargo fmt --check` - `git diff --check` - `yoi ticket doctor` - `nix build .#yoi --no-link` Dependency/package impact: - No new Rust dependencies。 - Added package/resource files under `resources/plugin/templates/rust-component-instance/` and `resources/plugin/wit/yoi-plugin-instance-v1.wit`。 - No `Cargo.lock` or `package.nix` changes required; Nix build succeeded。 Known risks / deferrals: - Instance Component ABI is intentionally minimal string-JSON host dispatch (`start`, `handle-tool`, `handle-ingress`, `status`, `stop`) and should be reviewed before treating it as stable public low-level ABI。 - Service lifecycle is surfaced as host-managed registration/status/stop diagnostics; no unsafe hidden model/tool/context action path was added。 - Rust PDK instance macro provides author-facing instance helpers, but full cargo-component generated glue ergonomics may need follow-up polish if public PDK shape becomes stricter。 Orchestrator evidence checked before review dispatch: - Implementation worktree is clean。 - HEAD is `147a6005`。 - Diff from acceptance `5ec8bae9..HEAD` is one implementation commit touching 12 files, about 1399 insertions / 34 deletions。 - `git diff --check 5ec8bae9..HEAD` produced no diagnostics。 Next action: - Dispatch Reviewer for r1 review against Ticket requirements, with focus on instance registry boundary, legacy compatibility, ToolRegistry run-stability, no hidden context/action paths, per-surface grants, Service/Ingress lifecycle semantics, static inspection/CLI reporting, WIT/PDK/template correctness, bounds/resource limits, and validation evidence。 --- ## Plan Review dispatch: - Spawned Reviewer Pod `yoi-reviewer-00001KVJHYP4Q-r1` against implementation branch `impl/00001KVJHYP4Q-plugin-instance-lifecycle`。 - Review target commit: `147a6005 plugin: add instance lifecycle surface`。 - Review baseline: `5ec8bae9`。 - Reviewer task focuses on instance registry boundary, legacy Tool compatibility, ordinary Tool result/history path, Service/Ingress no hidden action/context paths, ToolRegistry run-stability, per-surface and host API grant independence, no ambient WASI/network authority, bounded ingress/events/diagnostics, static inspection no-exec behavior, WIT/PDK/template coherence, tests, and Nix/package evidence。 - Reviewer is instructed not to edit source, commit, merge, close the Ticket, or use TicketReview directly; it will report verdict/evidence back to Orchestrator。 ---