feat: エージェントとして Grok (xAI) に対応する

[takecchi]

closes #107

grok CLI（xAI の Grok Build 1.0.0）を 3 つ目の provider として追加します。一覧・詳細の /agent で選べ、/model で Grok 自身のモデル一覧から選択でき、セッション一覧には実際に動いているモデル名が出ます。許可・質問ダイアログも効きます（Codex では諦めていた機能）。

なぜ ACP（JSON-RPC over stdio）なのか

grok の非対話モードは 2 つあります。

モード	形	許可・質問
grok -p … --output-format streaming-json	1 ターン 1 プロセス、NDJSON を一方向に吐く	上げられない
grok agent stdio	JSON-RPC 2.0（ACP）の双方向ストリーム	session/request_permission / _x.ai/ask_user_question が飛んでくる

Codex に倣うなら前者ですが、それだと Codex と同じく permissions: false に落ちます。後者ならエージェント側からの要求を codiva のダイアログにそのまま繋げるので、ACP を選びました。

構成（Claude / Codex と同じ 3 点セット + 型と I/O）

ファイル	役割
core/grok-events.ts	ACP メッセージの型と受理ガード。通知が session/update と _x.ai/session_notification の2 本のレールで来るのをここで吸収
core/grok-parse.ts	通知 → AgentEvent。本文の区切りが通知に無いので、ここだけは状態（溜めた本文・思考）を持ち、ツール呼び出しとターン終了で確定させる
core/grok-errors.ts	retry_state.error_type（CLI 自身の分類）を優先し、api だけ文言判定へ落とす（401 を素の failed に格下げしないため）
core/grok-adapter.ts	1 セッション 1 プロセス + 要求 id の対応表。許可・質問・中断・resume・モデル切替
core/grok-models.ts / utils/grok.ts	カタログは initialize の _meta.modelState から（grok models は人間向けテキストのみ）

• createJsonlSplitter は provider 非依存なので core/jsonl.ts へ切り出して Codex と共用（振る舞いは不変）。
• モデルカタログの受け渡しは modelsByAgent の表に一般化し、ビュー側の agent === 'codex' ? … を廃止しました（4 つ目の provider は 1 行で足せます）。
• 新しい設定項目はありません。agent: "grok" を受理し、自動選択の順に grok を足しただけです。

実測で分かった要点（詳細は docs/TECH_NOTES.md）

• session/cancel は通知。id を付けると -32601 Method not found になる
• エージェントからの要求には必ず答える（放置するとターンが永久に終わらない）ので、知らない要求にも -32601 を返す
• 継続は session/load ではなく session/resume（load は過去の会話を全部流し直す）
• systemPrompt は session/new の _meta.rules（systemPromptOverride は Grok 自身の system prompt を潰す）
• 解決済みモデルは provider が自分で報告するので、Codex のような rollout 探索は不要
• grok models は未認証でも終了コード 0 なので、ログイン判定には使えない（~/.grok/auth.json / XAI_API_KEY の有無で見る）
• authenticate を勝手に呼ぶと応答が返らないままブラウザ OAuth を待ち続けるので、ログインは必ずユーザー操作（/login = grok login --device-auth）から

capability

	permissions	interrupt	setModel	resume	modelCatalog	usage	cost	transcript
Claude	✓	✓	✓	✓	✓	✓	✓	✓
Codex	✗	✓	✓	✓	✓	✗	✗	✗
Grok	✓	✓	✓	✓	✓	✗	✗	✗

テスト

• フィクスチャは実バイナリから採取しました（src/core/__fixtures__/grok-*.jsonl）。実 grok 1.0.0 を、モデル側だけローカルのモック Responses API に差し替えて走らせた実出力です（ACP のフレーミング・ツール実行・許可要求・質問要求はすべて本物）。採取手順は docs/TECH_NOTES.md に残してあります。
• 新規 174 テスト（events / parse / errors / models / adapter / utils）。全体で 2905 passed。
• 実バイナリ + 実アダプタコードの E2E も通しました: 「思考 → 許可ダイアログ → ツール実行 → 本文ストリーム → 完了」まで到達し、セッション状態は completed、モデル欄は grok-4.5、resume id も取れています。

test plan

• npm run lint（この worktree の node_modules に biome のネイティブバイナリが無いため、同バージョンを別の場所へ展開して実行）
• npm run typecheck
• npm test（2905 passed / カバレッジ閾値も維持）
• npm run build
• モックバックエンド + 実 grok 1.0.0 での E2E（許可ダイアログ・ツール実行・完了・モデル表示）
• 実アカウント（SuperGrok / X Premium+ もしくは XAI_API_KEY）での手動確認 — 認証が要るためエージェントセッションでは実行できません。/agent で Grok を選び、1 ターン流して「モデル名が一覧に出る」「許可ダイアログが出る」「Ctrl+C で中断できる」「再開できる」あたりをご確認ください

[takecchi]

1件、修正が必要な問題があります。

[High] session/new 中の Ctrl+C は、cancelを送ったあとに中断対象のpromptを新規開始してしまいます。

interrupt() は sessionId がまだ無いと cancelPending = true にし、start() は session/new の応答後に flushPendingCancel() で session/cancel を送ります。しかし start() が戻ると、同じ drive() は無条件で runTurn(text) を呼び、直後に session/prompt を送ります。つまり実際の順序は次のとおりです。

1. session/new を送信
2. ユーザーがCtrl+C（UIは interrupted）
3. session/new 応答を受信
4. session/cancel 通知を送信（この時点ではprompt/ターンはまだ存在しない）
5. session/prompt を送信して、中断したはずの作業を開始

cancelが未来のpromptへ予約される保証はなく、通常は「現在走っているターン」を止める通知なので、4は空振りし、5の作業がそのままworktreeを変更し得ます。interruptedフラグにより後の完了イベントだけは抑止されるため、UIは中断済みのまま、裏でエージェントだけが動くさらに危険な状態になります。

既存テストはcancel通知が送られたことまでしか見ていません。PR headの同テストへ、数tick後も session/prompt が送られていないことを追加で期待すると失敗し、実際にid 3の session/prompt が記録されることを確認しました。

対処としては、確立前に中断されたターンではセッション確立だけ済ませて元の text を捨て、runTurn()へ進まないのが自然です（またはprompt送信後にcancelし、cancelの対象となるターンが確実に存在する順序にする必要があります）。少なくとも次を固定する回帰テストが必要です。

• session/new待ち中にinterrupt
• new応答後も中断対象の session/prompt を送らない
• 次に新しい指示を送ったときだけ、その新しいtextでpromptが始まる

確認結果:

• 追加回帰テスト以外のGrok関連185テストは成功
• npm run typecheck: 成功
• GitHub CI check: 成功

[takecchi]

レビューありがとうございます。ご指摘のとおりで、修正しました（2b1aae7）。

何が起きていたか

おっしゃる順序 4→5 が完全に正しく、session/cancel は「今走っているターン」向けの通知なので prompt を出す前に送っても空振りし、その直後の session/prompt がそのまま走っていました。しかも完了イベントだけは interrupted フラグで抑止されるので、UI は中断済みのままエージェントだけが worktree を書き換え続けるという、握り潰しより悪い状態でした。前回の「確立後に cancel を送り直す」予約は、対象が存在しない通知を送っていただけで意味がありませんでした。

修正

予約の仕掛け（cancelPending / flushPendingCancel）を撤去し、runTurn の先頭で中断・abort を見てそのターンを始めない（指示ごと捨てる）ようにしました。やり直しはユーザーが改めて送る、という Codex 側（プロセスを殺すので同じ結果になる）と揃った挙動です。interrupt() も、走っているターンが無いときは空振りの通知を送りません。

同じ穴が resume 経路にもありました（sessionId は既にあるのでご指摘の 4 は成立するが、やはり止める対象のターンが無い）。こちらも同時に塞いでいます。

回帰テスト（ご提示の 3 点をそのまま固定）

src/core/grok-adapter.spec.ts に 2 本追加しました。

• 「セッション確立中の Ctrl+C はそのターンを始めない（裏で走り続けさせない）」
  • session/new 待ちで interrupt → cancel を送らないこと
  • new 応答後に 20 tick 回しても session/prompt が送られていないこと / turn_completed も出ないこと
  • 次に別の指示を送ったときだけ、その新しい text で prompt が始まること
• 「resume の最中に Ctrl+C を押しても同じ（prompt を出さない）」

「長寿命プロセスの provider では『プロセスを殺せば止まる』が成り立たないので、中断は指示を捨てることで表現する」という教訓は、次の provider でも踏みそうなので docs/ARCHITECTURE.md と .claude/rules/sdk-integration.md にも残しました。

確認: lint / typecheck / test（2906 passed）/ build いずれも成功しています。

[takecchi]

再レビューしました。前回指摘した、session/new / session/resume の処理中に Ctrl+C で中断しても、その後 session/prompt が送信されてしまう問題は解消されています。

runTurn() が起動処理後の中断状態を確認してプロンプト送信を打ち切るようになり、実際にプロンプトが送られないことと、その次の入力では正常にターンを開始できることも回帰テストで確認されています。

追加の指摘事項はありません。LGTM です。

確認結果:

• 全テスト成功: 115 test files / 2,906 tests
• npm run typecheck 成功
• npm run build 成功
• GitHub CI 成功

補足: ローカルの npm run lint は共有 node_modules に macOS ARM64 用 Biome バイナリがなく起動できなかったため、lint のローカル再実行のみ未確認です。