方向転換: 複数並列開発のための開発用ブラウザへ (tmux pane 内ブラウザを第一候補に検証)

## 背景・動機

MVP ロードマップ (#20) は完了し Password Manager まで実装したが、実際の用途を見直した結果、**普段使いブラウザではなく開発用ブラウザ**に方向転換する。普段の閲覧は Chrome に戻す。

「開発用」は Web 開発用という意味ではなく、**複数並列開発のコックピット**という意味:

- 検索のしやすさ、内部ターミナル的な統合、進行中の GitHub PR / issue がすぐ見えること
- 現在の運用は「GitHub issue に要件を書く → その issue 用の tmux window / git worktree を用意する」。これをブラウザのタブのように扱いたい。タブ (window) の中は pane:0 = claude、pane:1 = issue、pane:2 = PR のような一覧
- 総じて、複数並列開発中の「この window では何をしていたっけ」というコンテキストスイッチの迷子をなくす

## 決定事項

1. 開発用ブラウザにする。普段使いは Chrome
2. 方向性の第一候補は「**tmux を使い続けながら、tmux pane の中で内部ブラウザを動かす**」。tmux からの移行はしない。ターミナルは Alacritty に固定せず、画像プロトコル対応端末への乗り換えも選択肢に含める
3. **Password Manager は削除する** (スコープから外す)。手動確認が多く自律開発に向かないため。GitHub ログインの維持など Cookie / セッション永続化の基本機能 (WKWebsiteDataStore 相当) は Password Manager と独立しているので残す
4. tmux の操作性は引き続き維持する。pane 内ブラウザ方向なら分割・window・セッション管理は**本物の tmux がそのまま担う**ため、現アプリが自前実装していた PaneTree / window 管理 / セッション復元は不要になる

「なお良い」要件 (必須ではない):

- ブラウザ pane の様子を Claude Code に気軽にコンテキスト共有できること (例: ブラウザで文字選択している部分をそのまま渡す。画像の受け渡しで代替できるため絶対ではない)
- iOS Simulator も動画ストリーミングで pane から見られること

## 技術検討 (スパイクで実測して決める)

前提: tmux pane 内で「見られる」ブラウザにするには端末の画像描画能力が要る。

- Alacritty は sixel / kitty graphics protocol 未対応。乗り換え候補は Ghostty / WezTerm / kitty (いずれも kitty graphics 対応)。tmux 側の passthrough は設定済み (`allow-passthrough all`、tmux 3.4+)
- 描画方式の候補:
- a. **carbonyl** (Chromium をテキストセルで描画する既製ブラウザ): 導入コスト最小。GitHub の UI 閲覧品質を実測する
- b. **headless Chromium + CDP screencast を kitty graphics で pane に描画する自前クライアント**: フレームレート・入力遅延・実装コストを実測。選択テキストの共有 (`Runtime.evaluate` で `getSelection`) や Simulator ストリーミング (MJPEG) も同じ描画基盤に乗せられる
- c. 既存 Tatami の WKWebView をオフスクリーン化して snapshot を pane へ描画: 既存資産は活きるが、snapshot API ベースの fps に難がある見込み
- フォールバック: pane 内描画の品質が実用に届かない場合は「tmux 主体 + Tatami (macOS アプリ) 連動」型に切り替える (tmux の window 切り替え hook から tatami CLI を叩き、issue 単位のウィンドウ (issue / PR / CI / Simulator のペイン構成) を自動表示する)

## 段階的計画 (子 issue 化は方式確定後)

- Phase 0: スパイク — 上記 a / b / c を「GitHub issue / PR の閲覧・ログイン維持」で品質実測し、端末乗り換えの要否も評価して方式を決める
- Phase 1: 内部ブラウザ pane の MVP (描画 + キー / マウス入力 + URL 入力 + GitHub ログインセッション維持)
- Phase 2: コンテキスト束ね — tmux-issue-setup がブラウザ pane を issue / PR レイアウト付きで起動する。進行中 PR / issue の一覧 pane (これは gh / ghiv ベースでも可)
- Phase 3: iOS Simulator のストリーミング pane
- Phase 4: 選択テキスト等の Claude Code へのコンテキスト共有
- 方式確定後に documents/PROJECT.md / README を新方向で書き換える

## 既存資産の扱い (提案)

- macOS アプリ (現 Tatami): Phase 0 の結果、WKWebView をエンジンに使うなら残し、Chromium 系を採るなら凍結・アーカイブ
- Password Manager 関連の open issue は方向転換により close 対象: #43 (CXF 実測)・#44 (Passkey 実サイト検証)・#45 (Credential Provider 実測)・#46 (ログインフォーム検出改善)
- 未コミットの改善 (ブランチ `tatami-conf-setup`: tatami.conf 反映・分割直後のアドレスバー自動フォーカス・AGENTS.md 追記): 現アプリを残す判断になったら PR 化する
- #21 (公開前チェックリスト)・#22 (デザイン依頼): 新方向での要否を再判断

## やらないこと

- 普段使いブラウザとしての一般機能の拡充 (既定ブラウザ登録まわりの強化等)
- Password Manager への新規投資

## セッション再開

```sh
cd /Users/bannzai/ghq/github.com/bannzai/tatami
claude --resume 084b8924-ccb4-408d-9e26-30e7fecb1b28
```

Start with the Phase 0 spike and compare carbonyl, a headless Chromium/CDP client, and the existing WKWebView approach inside tmux panes. Measure GitHub issue/PR viewing and login-session persistence, including terminal compatibility, then record the selected approach. After the method is fixed, update documents/PROJECT.md and README to reflect the new direction.

Written by the indexing model from the issue text.