# 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 のみ扱う）