From 96223148c0c708b459e9c4090bccf018b34c02ad Mon Sep 17 00:00:00 2001 From: Hare Date: Sat, 20 Jun 2026 17:00:17 +0900 Subject: [PATCH] ticket: clarify mcp runtime-discovered tools --- .yoi/objectives/00001KTR80WMN/item.md | 21 ++- .../00001KVHR3WS6/artifacts/relations.json | 2 +- .yoi/tickets/00001KVHR3WS6/item.md | 12 +- .yoi/tickets/00001KVHR3WSW/item.md | 2 +- .yoi/tickets/00001KVHX0WBE/artifacts/.gitkeep | 0 .yoi/tickets/00001KVHX0WBE/item.md | 161 ++++++++++++++++++ .yoi/tickets/00001KVHX0WBE/thread.md | 23 +++ 7 files changed, 210 insertions(+), 11 deletions(-) create mode 100644 .yoi/tickets/00001KVHX0WBE/artifacts/.gitkeep create mode 100644 .yoi/tickets/00001KVHX0WBE/item.md create mode 100644 .yoi/tickets/00001KVHX0WBE/thread.md diff --git a/.yoi/objectives/00001KTR80WMN/item.md b/.yoi/objectives/00001KTR80WMN/item.md index 139a9e38..d7ee76b8 100644 --- a/.yoi/objectives/00001KTR80WMN/item.md +++ b/.yoi/objectives/00001KTR80WMN/item.md @@ -10,7 +10,7 @@ linked_tickets: ['00001KTR81P9X', '00001KV0SP0TY', '00001KVHR3WRF', '00001KVHR3W Add MCP local stdio integration to Yoi without weakening Worker history, prompt-context, scoped tool permission, or Plugin/Feature layering invariants. -MCP is a protocol-backed integration layer on top of `pod::feature`. `pod::feature` supplies contribution/lifecycle/dynamic registration substrate; MCP owns its own enablement, local server trust model, command/env/secret policy, and MCP-specific permission decisions. MCP is not the Plugin model, and Plugin permission policy is not implemented by feature-layer authority grants. +MCP is a protocol-backed integration layer on top of `pod::feature`. `pod::feature` supplies contribution/lifecycle/runtime-discovered registration substrate; MCP owns its own enablement, local server trust model, command/env/secret policy, and MCP-specific permission decisions. MCP is not the Plugin model, and Plugin permission policy is not implemented by feature-layer authority grants. ## Strategic direction @@ -29,14 +29,14 @@ MCP is a protocol-backed integration layer on top of `pod::feature`. `pod::featu ## Layering decisions - `pod::feature` is an API/contribution substrate. - - It owns contribution declarations, provider/service lifecycle hooks, diagnostics, dynamic registration plumbing, and integration with normal Worker/ToolRegistry paths. + - It owns contribution declarations, provider/service lifecycle hooks, diagnostics, runtime-discovered registration plumbing, and integration with normal Worker/ToolRegistry paths. - It does not own Plugin permission policy or MCP server trust policy. - Plugin is a user-facing package/config/runtime layer over `pod::feature`. - Plugin permissions are Plugin-layer policy. - Plugin package discovery/enablement must not be conflated with MCP local server execution. - MCP is a separate feature-backed integration layer. - MCP enablement, command/env/secret handling, server trust, and MCP-specific permission decisions live in MCP config/implementation. - - MCP dynamic tools/resources/prompts are exposed through the feature API and ordinary Yoi tool paths. + - MCP provider-discovered tools/resources/prompts are exposed through the feature API and ordinary Yoi tool paths. ## Concrete implementation tickets @@ -52,7 +52,7 @@ Concrete MCP implementation sequence: 2. `00001KVHR3WRY` — MCP stdio JSON-RPC lifecycle client. - subprocess lifecycle, initialize/capability negotiation, diagnostics, shutdown. 3. `00001KVHR3WS6` — MCP tools/list registration into ToolRegistry. - - stable namespacing, schema validation, untrusted metadata normalization, no tools/call yet. + - provider-discovered tools, stable namespacing, schema validation, untrusted metadata normalization, no tools/call yet. 4. `00001KVHR3WSD` — MCP tools/call execution through ordinary Tool path. - PreToolCall gate before server call, bounded result serialization, history path. 5. `00001KVHR3WSN` — MCP resources/prompts as explicit tool operations. @@ -62,6 +62,19 @@ Concrete MCP implementation sequence: The old broad implementation Ticket `00001KTR82RB7` is superseded by this sequence and should not be used as an implementation work item. +## Terminology + +Use `runtime-discovered` or `provider-discovered` for MCP tools/resources/prompts discovered from `tools/list`, `resources/list`, or `prompts/list`. Avoid `dynamic tools` / `dynamic registry` in new MCP design prose because those phrases imply that model-visible tool schemas may change during an active LLM run. + +The intended invariant is: + +```text +provider-discovered at startup / provider initialization; +registered into the ordinary ToolRegistry before model exposure; +run-stable for the duration of a model request/run; +refreshed only at a safe boundary or reported as a diagnostic. +``` + ## Later follow-ups - Richer MCP task/task-support integration if ordinary tool-call fallback is insufficient. diff --git a/.yoi/tickets/00001KVHR3WS6/artifacts/relations.json b/.yoi/tickets/00001KVHR3WS6/artifacts/relations.json index 880212d9..cbfbe4dc 100644 --- a/.yoi/tickets/00001KVHR3WS6/artifacts/relations.json +++ b/.yoi/tickets/00001KVHR3WS6/artifacts/relations.json @@ -13,7 +13,7 @@ "ticket_id": "00001KVHR3WS6", "kind": "related", "target": "00001KTR81P9X", - "note": "MCP tool registration uses feature dynamic contribution plumbing.", + "note": "MCP tool registration uses feature runtime-discovered contribution plumbing.", "author": "yoi ticket", "at": "2026-06-20T05:33:03Z" } diff --git a/.yoi/tickets/00001KVHR3WS6/item.md b/.yoi/tickets/00001KVHR3WS6/item.md index 7cb6d4b5..9e305c96 100644 --- a/.yoi/tickets/00001KVHR3WS6/item.md +++ b/.yoi/tickets/00001KVHR3WS6/item.md @@ -12,9 +12,9 @@ queued_at: '2026-06-20T05:58:58Z' ## Background -Once a configured MCP stdio server can initialize, Yoi should expose discovered MCP tools as ordinary model-visible Yoi tools through the existing ToolRegistry path. Server-provided tool metadata and schemas are untrusted data. +Once a configured MCP stdio server can initialize, Yoi should expose provider-discovered MCP tools as ordinary model-visible Yoi tools through the existing ToolRegistry path. Server-provided tool metadata and schemas are untrusted data. -This Ticket only registers tools discovered through `tools/list`. It does not implement `tools/call` execution. +This Ticket only registers tools discovered through `tools/list` at provider initialization / safe refresh boundaries. It does not implement `tools/call` execution and does not allow model-visible tool schema mutation during an active run. ## Requirements @@ -23,17 +23,19 @@ This Ticket only registers tools discovered through `tools/list`. It does not im - Normalize MCP tool names into stable namespaced Yoi tool names that include server namespace. - Validate/normalize tool descriptions and input schemas as untrusted metadata. - Reject invalid schemas, duplicate names, and collisions fail-closed with diagnostics. -- Register contributions through `pod::feature` / normal ToolRegistry path; no private MCP bypass. +- Register provider-discovered tool contributions through `pod::feature` / normal ToolRegistry path; no private MCP bypass. +- Keep model-visible tool schema run-stable; `list_changed` handling is a later safe-boundary refresh/diagnostic problem, not mid-run mutation. - Do not register resources/prompts in this Ticket. ## Acceptance criteria -- MCP mock server tool appears as model-visible Yoi tool with stable namespaced name. +- Provider-discovered MCP mock server tool appears as model-visible Yoi tool with stable namespaced name. - Invalid schema is rejected with bounded diagnostic. - Duplicate/colliding names are rejected fail-closed. - Server metadata cannot weaken Yoi instructions/scope/permissions. - No `tools/call` request is sent during registration. -- Tests cover valid registration, pagination/bounds, invalid schema, duplicate/collision, and untrusted metadata normalization. +- Active-run model-visible schema is not mutated by this registration path. +- Tests cover valid registration, pagination/bounds, invalid schema, duplicate/collision, untrusted metadata normalization, and run-stable schema behavior. ## Non-goals diff --git a/.yoi/tickets/00001KVHR3WSW/item.md b/.yoi/tickets/00001KVHR3WSW/item.md index 8cfd58f0..07cd72d7 100644 --- a/.yoi/tickets/00001KVHR3WSW/item.md +++ b/.yoi/tickets/00001KVHR3WSW/item.md @@ -12,7 +12,7 @@ queued_at: '2026-06-20T05:59:05Z' ## Background -MCP servers can notify that tools/resources/prompts lists changed. Yoi must not silently go stale, but it also must not mutate the model-visible tool schema or context in a way that violates history/prompt-cache invariants during a run. +MCP servers can notify that tools/resources/prompts lists changed. Yoi must not silently go stale, but it also must not mutate the active run's model-visible tool schema or context in a way that violates history/prompt-cache invariants. This Ticket defines provider tool-list refresh behavior at safe boundaries. ## Requirements diff --git a/.yoi/tickets/00001KVHX0WBE/artifacts/.gitkeep b/.yoi/tickets/00001KVHX0WBE/artifacts/.gitkeep new file mode 100644 index 00000000..e69de29b diff --git a/.yoi/tickets/00001KVHX0WBE/item.md b/.yoi/tickets/00001KVHX0WBE/item.md new file mode 100644 index 00000000..6bd8206b --- /dev/null +++ b/.yoi/tickets/00001KVHX0WBE/item.md @@ -0,0 +1,161 @@ +--- +title: 'Dashboard / Console 呼称導入と TUI モジュール境界整理' +state: 'ready' +created_at: '2026-06-20T06:55:49Z' +updated_at: '2026-06-20T06:55:57Z' +assignee: null +readiness: 'implementation_ready' +risk_flags: ['ux-naming', 'module-boundary', 'public-cli', 'test-coverage'] +--- + +## Background + +TUI まわりの user-facing surface 名と code/module 境界を明確にする。 + +- **Dashboard**: `yoi panel`。workspace-level の Ticket / Pod / Companion / Orchestrator / Intake 状態と action を扱う surface。 +- **Console**: 通常の単一 Pod に接続して会話する chat/client surface。 +- **TUI**: Dashboard / Console / picker / setup UI などを実装する terminal UI crate/layer の総称。 + +事前調査では `crates/tui/src/multi_pod.rs` は約 9452 lines で、実態は multi-Pod list というより workspace Dashboard 本体だった。主な責務分布は次の通り。 + +```text + 1- 307 entry/runtime loop + 308- 451 background reload/notice handles + 452- 792 intake launch/handoff helpers + 793- 1160 diagnostics/e2e dashboard structs + 1161- 2422 MultiPodApp state + key/mouse/composer methods + 2423- 3377 snapshot/lifecycle/load + 3378- 4986 companion/orchestrator/ticket actions/queue handoff + 4987- 6258 row classification/layout/render + 6259- 9452 tests +``` + +関連ファイル規模の目安: + +```text + 9452 crates/tui/src/multi_pod.rs + 2812 crates/tui/src/workspace_panel.rs + 2346 crates/tui/src/single_pod.rs + 3689 crates/tui/src/app.rs + 1851 crates/tui/src/ui.rs + 1209 crates/tui/src/pod_list.rs + 556 crates/tui/src/role_session_registry.rs +``` + +`multi_pod.rs` は unit test / async test も多く、挙動維持の根拠としてテストを活かしながらまとめて整理する。 + +## Requirements + +- `Dashboard` / `Console` / `TUI` の呼称を導入し、help / docs / comments / test names / internal naming を可能な範囲で揃える。 +- `Dashboard` は `yoi panel` の user-facing surface 名とする。 +- `Console` は単一 Pod 接続チャットクライアントの user-facing surface 名とする。 +- `TUI` は terminal UI implementation layer の総称として扱い、Dashboard / Console の代替 mode 名として乱用しない。 +- `yoi panel` command 名は維持する。 +- `yoi dashboard` などの不要な互換 alias は追加しない。 +- Dashboard の起動 entrypoint を Console / `single_pod` 側から分離する。 +- Dashboard から Pod を開いて Console に入る bridge は残すが、narrow API として責務を明確にする。 +- `crates/tui/src/multi_pod.rs` を Dashboard module 境界へ寄せる。 +- `multi_pod.rs` の巨大化を解消するため、少なくとも次の責務を分離・整理する。 + - Dashboard entry/runtime loop + - Dashboard app state / action dispatch + - Dashboard snapshot/lifecycle loading + - Companion / Orchestrator / Intake / Ticket action glue + - Dashboard render/layout/row classification + - Dashboard e2e diagnostics structs + - Dashboard tests +- `workspace_panel.rs` は Dashboard view model builder としての責務を確認し、必要なら名前・配置・参照を Dashboard 語彙に寄せる。 +- `single_pod.rs` は Console 側の起動・接続・spawn/resume・chat loop を主責務にする。 +- 挙動変更は目的にしない。主眼は naming / module boundary / maintainability refactor。 + +## Acceptance criteria + +- `yoi panel` が Dashboard として説明されている。 +- 単一 Pod UI が Console として説明されている。 +- `TUI` が Dashboard / Console の総称 implementation layer として整理されている。 +- `LaunchMode::Panel` が `single_pod::run_panel` のような Console module entrypoint に直接流れない。 +- Dashboard entrypoint が Dashboard module 側にある。 +- Console module は単一 Pod chat/connect/spawn/resume の責務を主に持つ。 +- Dashboard から Console を開く bridge の境界が読み取れる。 +- `multi_pod.rs` 相当の責務が Dashboard module 配下へ移され、巨大単一ファイル状態が改善されている。 +- render/list/layout、action/lifecycle、diagnostics/tests などの境界が reviewer に分かる形になっている。 +- 既存の workspace panel / action model の設計と矛盾しない。 +- `yoi panel` の Ticket-centric workspace cockpit という意味を保つ。 +- `yoi panel` が scheduler/backend であるかのような実装・説明になっていない。 +- 既存テストを維持・更新し、refactor による挙動退行が検出できる状態にする。 +- reviewer が diff から、単なる rename ではなく Dashboard / Console の責務境界が改善されたことを確認できる。 + +## Binding decisions / invariants + +- **Dashboard = `yoi panel`**。 +- **Console = single-Pod chat/client surface**。 +- **TUI = terminal UI implementation layer / crate-level umbrella**。 +- `panel` / Dashboard は単一 Pod Console の名前には使わない。 +- Console は Dashboard の subordinate mode ではなく、別の user-facing surface として扱う。 +- Dashboard は Console の一部ではない。 +- Dashboard は workspace-level cockpit/action surface であり、scheduler/backend ではない。 +- `yoi panel` command 名は維持する。 +- 不要な compatibility alias は追加しない。 +- テストが維持できる範囲では、過度に分割を避ける必要はない。大きな file move / module split を許容する。 + +## Implementation latitude + +- 最終的な module 構成は実装者判断でよいが、次の方向を推奨する。 + +```text +crates/tui/src/ + console/ + mod.rs # user-facing Pod Console launch API + app_loop.rs # current single_pod run loop 相当 + nested.rs # Dashboard から Pod Console を開く bridge + terminal.rs # Console fullscreen/mouse helpers + dashboard/ + mod.rs # user-facing Dashboard launch API + app.rs # Dashboard app state / selection / key handling + runtime.rs # current multi_pod::run loop 相当 + snapshot.rs # Dashboard snapshot loading + lifecycle.rs # companion/orchestrator ensure/observe + actions.rs # Ticket/Intake/Companion/Orchestrator actions + render.rs # layout/draw/list rendering + e2e.rs # dashboard-specific e2e structs/events + tests.rs or tests/ +``` + +- 互換性や reviewability のため、type 名の rename は段階的でもよい。ただし module / docs / entrypoint は Dashboard / Console 語彙へ寄せる。 +- `MultiPodApp` などの既存名は必要なら一時的に残せるが、最終的な方向性が Dashboard であることをコード上から読めるようにする。 +- tests は同一 commit 内で移動・更新してよい。test coverage 維持を優先する。 +- exact string test がある場合は、新しい Dashboard / Console 呼称に合わせて期待値を更新する。 + +## Readiness + +- readiness: implementation_ready +- risk_flags: [ux-naming, module-boundary, public-cli, test-coverage] + +Risk flags は stop gate ではなく reviewer focus として扱う。主な確認点は public CLI/help の不要な互換増加、Dashboard / Console 境界、既存 panel authority/action model の保持、テスト維持。 + +## Escalation conditions + +- `Dashboard` / `Console` の二分では説明しきれない第三の user-facing surface が見つかった場合は確認する。 +- `yoi panel` command 名を変える必要が出た場合は確認する。 +- `yoi dashboard` などの alias 追加が必要だと判断した場合は確認する。 +- module split の過程で Ticket state transition authority、Pod lifecycle、Orchestrator handoff の挙動変更が必要になった場合は確認する。 +- テスト維持では覆えない user-visible behavior change が必要になった場合は確認する。 + +## Validation + +- `cargo test -p tui` +- `cargo test -p yoi` +- `cargo check --workspace --all-targets` +- `cargo fmt --check` +- `git diff --check` +- 必要に応じて CLI help / docs / resources grep で `Dashboard` / `Console` / `TUI` / `panel` / `multi_pod` の残存表現を確認する。 + +## Related work + +- `00001KTCSRS61` Workspace orchestration panel design +- `00001KTCSRS62` Workspace panel action model +- `00001KSKBPYER` Multi-Pod view UI +- `crates/tui/src/multi_pod.rs` +- `crates/tui/src/single_pod.rs` +- `crates/tui/src/workspace_panel.rs` +- `crates/tui/src/lib.rs` +- `yoi panel` diff --git a/.yoi/tickets/00001KVHX0WBE/thread.md b/.yoi/tickets/00001KVHX0WBE/thread.md new file mode 100644 index 00000000..59065e41 --- /dev/null +++ b/.yoi/tickets/00001KVHX0WBE/thread.md @@ -0,0 +1,23 @@ + + +## 作成 + +LocalTicketBackend によって作成されました。 + +--- + + + +## Intake summary + +ユーザー合意に基づき、Dashboard / Console 呼称導入、`yoi panel` Dashboard 境界、単一 Pod Console 境界、`multi_pod.rs` の Dashboard module への移設・分割、docs/help/tests 更新を 1 つの concrete implementation Ticket として整理した。readiness は `implementation_ready`。risk flags は stop gate ではなく reviewer focus として扱う。 + +--- + + + +## State changed + +要件・受け入れ条件・binding decisions・validation が揃っており、Orchestrator が実装 routing 可能。 + +---