74 lines
6.0 KiB
Markdown
74 lines
6.0 KiB
Markdown
---
|
|
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 は後続段階で扱う。
|