yoi/tickets/tui-pod-spawn-ui.md

TUI: 新しい Pod を spawn する UI の設計

背景

Insomnia は複数 Pod を同時に走らせられるアーキテクチャを想定しているが、TUI は現在単一 Pod のみを表示する前提で作られている。Pod を増やすには TUI を起動し直すしかなく、作業文脈の並列性がユーザーに見えていない。

TUI から新しい Pod を生やす操作と、複数 Pod を扱う UI モデルを設計する。実装の前に使い方の合意が必要なため、本チケットは設計フェーズの成果物を完了条件に含む。

要件

成果物（設計フェーズ）

• ユースケース記述: どういう場面で Pod を増やしたくなるか、複数 Pod 間で何をするか、現行 Pod をどう区別・切替するか
• UI モデル: タブ / 分割ペイン / リスト + 単一表示 のどれにするか、根拠つきで
• 状態遷移図: Pod の spawn / active / background / shutdown のライフサイクル
• spawn 時の入力: manifest をどう指定するか（ファイル選択 / テンプレート / 新規編集）
• 既存チケットとの整合: tui-pod-shutdown.md の shutdown 操作が「単一 Pod を閉じる」意味にちゃんとなるか、tui-notification-channel.md の通知が「どの Pod の通知か」を表現できるか
• 上記を docs/tui-pod-spawn.md 等にまとめる

実装フェーズ（設計合意後）

• spawn UI のエントリポイントを TUI に実装
• 複数 Pod を扱うための内部データモデル（Pod リスト、アクティブ Pod 管理）
• Pod 間の切替操作
• 各 Pod の shutdown 操作との統合

設計で決めること

• 並列実行の扱い: 全 Pod を常に走らせるか、フォーカスしている Pod のみ走らせて他は suspend か
• リソース共有: scope 排他制御（tickets/scope-exclusion.md）との関係。同一パスを同時 write できない制約を UI でどう表現するか
• shutdown との関係: 「この Pod を閉じる」と「TUI を閉じる」を区別するキーバインド
• 通知の帰属: 通知チャネル（tickets/tui-notification-channel.md）が Pod 別に表示されるべきか、TUI 全体で集約するか

完了条件

設計フェーズ

• docs/tui-pod-spawn.md（または同等の設計ドキュメント）がレビュー可能な形で存在する
• 上記の「設計で決めること」すべてに結論が出ている
• 他の TUI チケット（通知・shutdown）との整合が確認できている

実装フェーズ

• TUI から新しい Pod を spawn できる
• 複数 Pod が spawn された状態で、ユーザーがそれらを切り替えられる
• 各 Pod は独立して実行・通知・shutdown できる

範囲外

• Pod 間のメッセージパッシングや依存関係（Pod A の出力を Pod B の入力に繋ぐ等）
• Pod の保存済みテンプレートからの呼び出し UI（設計に含めるかは検討）
• 分散実行・リモート Pod（ローカル TUI の中での複数 Pod のみ扱う）