Hare/yoi
1
1
Fork 0
Code Actions Packages Releases Activity

ticket: approve feature provider api

Browse Source
This commit is contained in:
Keisuke Hirata 2026-06-14 15:38:27 +09:00
parent 053a4f90dc
commit d0e8d79106
No known key found for this signature in database
2 changed files with 31 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
.yoi/tickets/00001KTR81P9X/item.md
View File

@ -2,7 +2,7 @@
title: 'Extend pod::feature API for external protocol-backed capability providers'
state: 'inprogress'
created_at: '2026-06-10T07:48:14Z'
updated_at: '2026-06-14T06:30:42Z'
updated_at: '2026-06-14T06:36:23Z'
assignee: null
readiness: 'implementation_ready'
risk_flags: ['feature-api', 'tool-registry', 'permission-scope', 'prompt-context', 'dynamic-registry', 'service-lifecycle']

30
.yoi/tickets/00001KTR81P9X/thread.md
View File

@ -109,4 +109,34 @@ Risks/notes:
- Provider metadata and diagnostics remain install-report data; actual provider tool execution goes through the normal Worker/tool machinery.
---
<!-- event: review author: hare at: 2026-06-14T06:36:23Z status: approve -->
## Review: approve
## Review: approve
Reviewed implementation commit `053a4f90` against Ticket `00001KTR81P9X` and base routing commit `f709fc10`.
Evidence:
- Diff is limited to the Ticket record and `crates/pod/src/feature.rs`.
- The provider API extension stays in `pod::feature` as a contribution/reporting substrate: `ProviderId`, `ProtocolProviderDeclaration`, `ProtocolProviderLifecycleState`, `ProtocolProviderContribution`, lifecycle diagnostics, and `FeatureInstallContext::protocol_providers()` were added without introducing `HostAuthority`, grant replacement types, MCP trust policy, plugin permission policy, subprocess management, or ToolRegistry/history bypasses.
- Startup-discovered provider tools are materialized once during feature installation and then registered through `Worker::register_tools`, preserving stable schemas for the run and normal Worker permission/history/result machinery.
- Ready providers can contribute tools, service declarations, and background task declarations through the existing feature install report/registry surfaces; unavailable providers record lifecycle diagnostics and skip discovered contributions instead of panicking or installing stale tools.
- Diagnostics cover undeclared provider ids, duplicate tool names through the shared tool registrar, and failed lifecycle states.
- API shape is type-oriented and localized; I did not find broad compatibility glue or authority-layer leakage.
Validation performed:
- PASS `cargo fmt --check`
- PASS `git diff --check f709fc10..HEAD`
- PASS `cargo test -p pod feature::tests` (17 passed)
- PASS `cargo check --workspace --all-targets`
- FAIL `cargo test -p pod`: 323 passed / 2 failed in the same prompt assertion tests reported by Coder (`prompt::catalog::tests::pod_orchestration_guidance_section_renders_resource_body`, `prompt::system::tests::pod_orchestration_guidance_is_included_for_pod_management_tools`, both expecting `worktree status, diff, and test results`). The reviewed diff does not touch prompt resources or those prompt modules, so I classify this as unrelated/pre-existing for this Ticket.
Risks / notes:
- I did not rerun `nix build`; Coder reported a final-link `No space left on device` after Rust compilation. Focused Rust validation passed.
- Permission denial and bounded-result behavior are not reimplemented in this diff; they are intentionally inherited because provider tools are installed as ordinary Worker tools.
---