統一ランタイムストリーミングリファクタ計画

目的

main、subagent、acp のすべてのランタイムが同一の結合、チャンク分割、配信順序、クラッシュ回復動作を得られるよう、1つの共有ストリーミングパイプラインを提供する。

背景

• 現在の動作は、複数のランタイム固有の整形パスに分割されている。
• フォーマット/結合のバグが1つのパスで修正されても、他のパスには残る可能性がある。
• 配信の一貫性、重複抑制、回復セマンティクスの推論が困難である。

目標アーキテクチャ

単一パイプライン、ランタイム固有アダプタ:

1. ランタイムアダプタは正規イベントのみを発行する。
2. 共有ストリームアセンブラがテキスト/ツール/ステータスイベントを結合・最終化する。
3. 共有チャネルプロジェクタがチャネル固有のチャンク分割/フォーマットを一度だけ適用する。
4. 共有配信台帳が冪等な送信/再生セマンティクスを強制する。
5. 送信チャネルアダプタが送信を実行し、配信チェックポイントを記録する。

正規イベント契約:

• turn_started
• text_delta
• block_final
• tool_started
• tool_finished
• status
• turn_completed
• turn_failed
• turn_cancelled

作業項目

1) 正規ストリーミング契約

• コアに厳密なイベントスキーマと検証を定義する。
• 各ランタイムが互換性のあるイベントを発行することを保証するためのアダプタ契約テストを追加する。
• 不正な形式のランタイムイベントを早期に拒否し、構造化された診断情報を表示する。

2) 共有ストリームプロセッサ

• ランタイム固有の結合/プロジェクタロジックを1つのプロセッサに置き換える。
• プロセッサがテキストデルタのバッファリング、アイドルフラッシュ、最大チャンク分割、完了フラッシュを担当する。
• ACP/main/subagent の設定解決を1つのヘルパーに移動し、差異を防止する。

3) 共有チャネル投影

• チャネルアダプタはシンプルに保つ: 最終化されたブロックを受け取り送信する。
• Discord固有のチャンク分割の特殊処理はチャネルプロジェクタのみに移動する。
• 投影前のパイプラインはチャネル非依存に保つ。

4) 配信台帳 + 再生

• ターンごと/チャンクごとの配信IDを追加する。
• 物理的な送信の前後にチェックポイントを記録する。
• 再起動時、保留中のチャンクを冪等的に再生し、重複を回避する。

5) 移行と切り替え

• フェーズ1: シャドウモード (新しいパイプラインが出力を計算するが、古いパスが送信する; 比較する)。
• フェーズ2: ランタイムごとの切り替え (acp、次に subagent、次に main、またはリスクに応じて逆順)。
• フェーズ3: レガシーのランタイム固有ストリーミングコードを削除する。

対象外

• このリファクタではACPのポリシー/権限モデルは変更しない。
• 投影互換性修正以外のチャネル固有機能拡張は行わない。
• トランスポート/バックエンドの再設計は行わない (イベントパリティに必要な場合を除き、acpxプラグイン契約は現状維持)。

リスクと対策

• リスク: 既存のmain/subagentパスでの動作退行。対策: シャドウモードでの差分比較 + アダプタ契約テスト + チャネルe2eテスト。
• リスク: クラッシュ回復時の重複送信。対策: 永続的な配信ID + 配信アダプタでの冪等再生。
• リスク: ランタイムアダプタが再び分岐する。対策: すべてのアダプタに必須の共有契約テストスイート。

受け入れ基準

• すべてのランタイムが共有ストリーミング契約テストに合格する。
• Discord ACP/main/subagent が、小さなデルタに対して同等の間隔/チャンク分割動作を生成する。
• クラッシュ/再起動時の再生で、同じ配信IDに対して重複チャンクが送信されない。
• レガシーACPプロジェクタ/結合パスが削除されている。
• ストリーミング設定解決が共有され、ランタイム非依存である。

ACPスレッドバインドエージェントブラウザ評価CDPリファクタ