ticket: record new objectives and tickets
This commit is contained in:
@@ -0,0 +1,73 @@
|
||||
---
|
||||
title: "ネイティブGUIアプリケーション"
|
||||
state: "active"
|
||||
created_at: "2026-06-10T07:41:18Z"
|
||||
updated_at: "2026-06-10T07:41:18Z"
|
||||
linked_tickets: []
|
||||
---
|
||||
|
||||
## Goal
|
||||
|
||||
Yoi の Pod / Ticket / Orchestrator / workflow 操作を、TUI だけでなくネイティブ GUI から扱えるようにする。
|
||||
|
||||
最初の到達点は、既存の runtime / Ticket backend / Pod protocol / Profile / workflow authority を再実装せずに、workspace の状態を視覚的に把握し、選択した Pod・Ticket・role action に対して安全に操作できる desktop GUI client を持つこと。GUI は core authority ではなく client surface とし、既存 CLI/TUI と同じ durable state・同じ protocol・同じ permission/prompt/workflow 境界を使う。
|
||||
|
||||
## Motivation / background
|
||||
|
||||
現在の TUI / Panel は dogfooding 可能な状態まで進んでいるが、複数 Pod・複数 Ticket・Orchestrator 状態・session output・role launch・review/merge dossier を同時に扱うには、terminal UI の表示密度・視覚的状態表現・スクロール/選択/比較操作に限界が出ている。
|
||||
|
||||
ネイティブ GUI があると、以下をより自然に扱える。
|
||||
|
||||
- live / stored Pod、Ticket lane、Orchestrator progress、Companion/Intake 状態の同時表示。
|
||||
- Ticket body/thread/artifacts、Pod output、validation evidence、diff/report の並列閲覧。
|
||||
- composer target、role action、queue/routing/attach/restore の明確な affordance。
|
||||
- long-running orchestration の通知、状態変化、失敗診断の視覚化。
|
||||
- 将来的な review / merge-ready dossier / plan board / settings editor の専用 UI。
|
||||
|
||||
一方で、GUI を理由に runtime authority を分散させたり、Ticket/Pod state を独自 DB として二重管理したり、prompt/workflow 文字列を GUI code に直書きしたりしてはいけない。
|
||||
|
||||
## Strategy / design direction
|
||||
|
||||
- GUI は Yoi core の上に乗る client として作る。
|
||||
- Pod lifecycle、session/history、Ticket storage、Profile resolution、workflow/prompt authority は既存 core を正とする。
|
||||
- GUI 固有 state は selection、layout、local UI preference などに限定する。
|
||||
- 最初に toolkit / architecture の小さな spike を置く。
|
||||
- 評価軸は Rust code reuse、async/runtime 統合、native packaging、Linux dogfooding しやすさ、testability、accessibility、long-running log/output 表示、将来の cross-platform 余地。
|
||||
- toolkit 選定は Objective では固定しない。候補比較と採用理由を Ticket に残す。
|
||||
- 実装は段階的に進める。
|
||||
1. read-only workspace dashboard: Pod / Ticket / Orchestrator 状態を既存 backend から表示する。
|
||||
2. attach / restore / open など、既存 protocol に乗る低リスク操作を追加する。
|
||||
3. composer と role action: Companion / Intake / Orchestrator / coder / reviewer launch を既存 launcher 経由で扱う。
|
||||
4. Ticket body/thread/artifacts、Pod output、validation evidence、review report を閲覧しやすくする。
|
||||
5. 必要に応じて settings/profile/config editor や merge-ready dossier UI を追加する。
|
||||
- TUI は廃止前提にしない。
|
||||
- GUI 導入後も CLI/TUI は fallback / automation / terminal-first workflow として維持する。
|
||||
- GUI で見つかった state model の改善は、TUI と共有できる pure data model / client API に寄せる。
|
||||
- Prompt / workflow / role guidance は GUI code に直書きしない。
|
||||
- LLM-facing prompt は `resources/prompts` または `.yoi/workflow` / configured resources を正とする。
|
||||
- GUI は prompt 文言を所有せず、選択・起動・runtime context の入力面を担当する。
|
||||
- Security / privacy / authority boundary を保つ。
|
||||
- secret-like data は UI diagnostics / logs / model context に漏らさない。
|
||||
- permission / scope / profile の authority は既存 resolver/policy に従う。
|
||||
- GUI convenience action は durable Ticket/Pod state transition と対応付け、暗黙の side effect を避ける。
|
||||
|
||||
## Success criteria / exit conditions
|
||||
|
||||
- 明示コマンドまたは binary で native GUI を起動できる。
|
||||
- GUI は既存 workspace config、Profile、Ticket backend、Pod registry/protocol を使い、独自の authority store を持たない。
|
||||
- 最小 dashboard で live/stored Pod、Ticket lane/state、Orchestrator/role session の概況を確認できる。
|
||||
- GUI から少なくとも attach/restore/open 相当の安全な Pod 操作ができる。
|
||||
- GUI から Ticket Intake または既存 role launcher を使った role action を実行でき、既存の prompt/workflow/resource 境界を壊さない。
|
||||
- Pod output / Ticket body/thread/artifacts を、TUI より見通しよく閲覧できる最小 UI がある。
|
||||
- GUI 固有 state と core durable state の境界が文書化されている。
|
||||
- toolkit / architecture 選定理由、採用しなかった選択肢、packaging 方針が Ticket artifact または design note として残っている。
|
||||
- GUI で使う state transformation / action eligibility は pure model として test 可能で、主要な selection/action state の unit test がある。
|
||||
- GUI 実装は CLI/TUI の既存 workflow を破壊せず、必要な targeted validation が定義されている。
|
||||
|
||||
## Decision context
|
||||
|
||||
- この Objective は中長期の方向性・判断軸を保持する。具体的な toolkit 選定、crate 構成、初期 dashboard 実装、role action 実装、packaging は個別 Ticket に分ける。
|
||||
- GUI は TUI の単純な置換ではなく、複数 Pod / Ticket / Orchestrator を扱う workspace cockpit として設計する。
|
||||
- authority は既存 core に残す。GUI は client/view/controller surface であり、Pod/Ticket/workflow/prompt の正本を所有しない。
|
||||
- Prompt 直書き禁止方針を守る。GUI 実装中に LLM-facing 文言が必要になった場合は、`resources/prompts` または workflow/resource 側に置く。
|
||||
- 初期 target は dogfooding しやすい desktop GUI とし、public release / cross-platform polish / installer は後続段階で扱う。
|
||||
@@ -0,0 +1,63 @@
|
||||
---
|
||||
title: "MCP integration as external capability provider"
|
||||
state: "active"
|
||||
created_at: "2026-06-10T07:47:48Z"
|
||||
updated_at: "2026-06-10T07:47:48Z"
|
||||
linked_tickets: ["00001KST8H4M0", "00001KTR81P9X", "00001KTR82RB7"]
|
||||
---
|
||||
|
||||
## Goal
|
||||
|
||||
Yoi が MCP (Model Context Protocol) server を external capability provider として安全に扱えるようにする。
|
||||
|
||||
到達点は、MCP server が提供する tools / resources / prompts を、Yoi の既存の Pod / Feature / ToolRegistry / permission / scope / history / bounded result 境界に乗せて利用できる状態にすること。MCP は Yoi の plugin model そのものではなく、protocol-bound bridge / external provider runtime として扱う。
|
||||
|
||||
## Motivation / background
|
||||
|
||||
MCP は AI application と外部 system を接続する標準 protocol になりつつあり、server は tools、resources、prompts などを提供する。Yoi にとって MCP support は有用だが、外部 server が返す schema、description、annotation、resource content、prompt template はすべて untrusted data であり、Yoi の instruction hierarchy、scope、permission、history persistence、prompt-context 加工原則を弱めてはいけない。
|
||||
|
||||
現行の `pod::feature` API は static descriptor / static tool contribution を中心にしており、MCP のように startup 時の initialize / capability negotiation / discovery によって surface が決まる provider には不足がある。そのため、MCP 実装だけを先に ad-hoc に入れるのではなく、まず外部 protocol-backed provider を扱える Feature API boundary を整え、その上に MCP implementation を載せる。
|
||||
|
||||
## Strategy / design direction
|
||||
|
||||
- Broad MCP integration Ticket は progress-container として使わず、この Objective に中期方針を移す。
|
||||
- 実装 work item は concrete Ticket に分ける。
|
||||
- `00001KTR81P9X`: `pod::feature` / Worker / ToolRegistry API を external protocol-backed provider に耐える形へ拡張する。
|
||||
- `00001KTR82RB7`: MCP `2025-11-25` local stdio server-feature bridge を実装する。
|
||||
- MCP 実装は local stdio transport から始める。
|
||||
- Streamable HTTP、remote auth/OAuth、MCP Registry distribution、workspace-provided package auto-start は後続判断とする。
|
||||
- tools / resources / prompts は無理に分けず、MCP server features として扱う。
|
||||
- ただし resources/prompts は direct context injection ではなく、明示 tool operation の結果として history に残す。
|
||||
- `resources/read` / `prompts/get` の結果を history に残らない形で context に注入しない。
|
||||
- MCP server は untrusted external capability provider として扱う。
|
||||
- server-provided schema/description/annotation/content/error は instruction ではなく data。
|
||||
- ToolRegistry / PreToolCall permission / history / bounded result path を迂回しない。
|
||||
- local process execution は explicit authority として扱う。
|
||||
- filesystem/network authority から暗黙に subprocess 起動権限を派生させない。
|
||||
- secrets は explicit secret/env references で扱い、diagnostics / logs / model context / project records に plaintext として残さない。
|
||||
- dynamic discovery / list_changed は prompt/tool schema consistency を壊さない範囲で扱う。
|
||||
- live refresh が危険なら next-turn refresh または restart/reinitialize-required diagnostic を選ぶ。
|
||||
- silent stale state は避ける。
|
||||
- Sampling / elicitation は external server が Yoi 側の LLM/user interaction を要求する強い authority なので、初期段階では fail-closed とし、必要なら別 Ticket で approval/resume/UI path を設計する。
|
||||
|
||||
## Success criteria / exit conditions
|
||||
|
||||
- `pod::feature` が external protocol-backed capability provider を表現できる。
|
||||
- local subprocess execution authority が明示的に型・config・grant として扱われる。
|
||||
- Feature-provided long-running service / connection manager を Pod lifetime に安全に接続できる。
|
||||
- discovery 後の dynamic tool contribution が通常 ToolRegistry と permission path に統合される。
|
||||
- MCP spec baseline `2025-11-25` に基づく local stdio server integration がある。
|
||||
- MCP tools が namespaced stable Yoi tool として使える。
|
||||
- MCP resources/prompts が明示 tool operation として使え、取得結果は通常 tool result として history に残る。
|
||||
- server-provided data が system/developer instruction、scope、permission、prompt-context、history persistence rules を弱めない。
|
||||
- secrets / env values / command args containing secrets が diagnostics、logs、model context に plaintext で出ない。
|
||||
- Streamable HTTP、remote auth、distribution、sampling、elicitation の扱いが out-of-scope / fail-closed / follow-up として明示されている。
|
||||
- local mock MCP server による focused tests と、関連 crate tests、`nix build .#yoi` による packaging validation が定義されている。
|
||||
|
||||
## Decision context
|
||||
|
||||
- `00001KST8H4M0` は broad MCP integration Ticket として作られていたが、今後はこの Objective の背景 context として扱い、実装 authority は concrete Tickets に置く。
|
||||
- `00001KTR81P9X` は API/architecture prerequisite。MCP 実装が ToolRegistry / permission / history path を迂回しないための土台を作る。
|
||||
- `00001KTR82RB7` は MCP implementation Ticket。API 拡張の結果に乗って local stdio MCP server features を実装する。
|
||||
- Objective-to-Ticket links は context であり、dependency/scheduling authority ではない。実際の routing / readiness / blockers は各 Ticket の body/thread/artifacts と Orchestrator 判断に置く。
|
||||
- `resources/prompts` は scope 外に固定しない。安全条件は「direct hidden context injection をしない」ことであり、明示 tool result として扱うなら MCP integration の対象に含める。
|
||||
Reference in New Issue
Block a user