6.0 KiB
6.0 KiB
| title | state | created_at | updated_at | linked_tickets |
|---|---|---|---|---|
| ネイティブGUIアプリケーション | active | 2026-06-10T07:41:18Z | 2026-06-10T07:41:18Z |
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 に残す。
- 実装は段階的に進める。
- read-only workspace dashboard: Pod / Ticket / Orchestrator 状態を既存 backend から表示する。
- attach / restore / open など、既存 protocol に乗る低リスク操作を追加する。
- composer と role action: Companion / Intake / Orchestrator / coder / reviewer launch を既存 launcher 経由で扱う。
- Ticket body/thread/artifacts、Pod output、validation evidence、review report を閲覧しやすくする。
- 必要に応じて 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 の入力面を担当する。
- LLM-facing prompt は
- 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 は後続段階で扱う。