Phase 2: 補助Div追加
| 何をするか | Phase 1で蓄積した運用ナレッジに基づき、BA（経理統制の高度化）・SA（システムリソース管理・監視）を必要に応じて追加構築 |
| なぜするか | VDU/BAの運用で「ここが足りない」と判明した部分を補完する。実体験なしに作ると過剰設計になる |
| 完了の定義 | BA・SAが運用上必要と判断された機能を実装し、VDU/BAと連携して稼働していること |
Phase 3: 組織完成（6ディビジョン体制）
| 何をするか | H&A（人事・AI管理）・PMO（プロジェクト管理）・OA（品質監査）を構築し、Issue #139で定義した6ディビジョン・Three Linesモデルを完成させる |
| なぜするか | 組織が拡大し、品質管理・プロジェクト管理・リソース管理を自動化する必要が出てくる段階。Phase 1-2のナレッジがあれば一気に展開可能 |
| 完了の定義 | 6ディビジョン全てが稼働し、Three Lines防御モデルが機能している。日次経営会議・PJ型フロー・能動ループが実装されている |
技術的移行ステップ（参考）
以下はIssue #143要件定義書に記載されていた技術的な移行ステップ。Phase 0協議の参考資料として保持する。
現行 vs 新アーキテクチャ（主要差分）
| 項目 | 現行 | 新 |
|---|
| IF層 | bot.py内蔵（ルーティングロジック埋め込み） | Claude CLI常駐（tmux）。bot.pyは薄い中継のみ |
| M層 | subprocess都度起動（3ルート: dev/bo/legal） | tmux常駐（6ディビジョン）。文脈維持 |
| W層 | subprocess都度起動（8種） | 変更なし（都度起動・完了消滅） |
| タスク実行 | 直列パイプライン | DAG定義に基づく依存関係付き並行実行 |
| 駆動モデル | CEO発話のみ（受動） | 能動ループ + 時間/イベントトリガー |
| ディビジョン | dev/bo/legal（3ルート） | VDU/BA/H&A/PMO/OA/SA（6ディビジョン） |
Phase 0: 基盤整備
| ステップ | 内容 | リスク |
|---|
| 0-1 | worktree導入 — coderのみgit worktreeで隔離実行。ファイル競合を防止 | 低 |
| 0-2 | IF層外出し — bot.py内のルーティングロジックをClaude CLI常駐のIF層に移動 | 中 |
| 0-3 | tmux通信基盤 — tmux send-keys / capture-paneによるIF↔M層通信の実装・検証 | 中 |
Phase 1: DAGモデル導入
| ステップ | 内容 | リスク |
|---|
| 1-1 | DAGスケジューラ — M層のDELEGATEループをDAG定義に置換。bot.pyがDAG Schedulerとして実行制御 | 高 |
| 1-2 | M層Planner化 — M層はDAG定義+最終統合の2回のみCLI起動。中間のW層起動はbot.pyが実行 | 中 |
| 1-3 | 6ディビジョン化 — dev/bo/legal→VDU/BA/H&A/PMO/OA/SAに再編。IF層のルーティング更新 | 中 |
Phase 2: 並行制御高度化
| ステップ | 内容 | リスク |
|---|
| 2-1 | 能動ループ — VDU/H&A/SAの能動ループ実装。idle時トークン消費ゼロの設計 | 中 |
| 2-2 | 日次経営会議 — IF層が全M層を招集する定時トリガー実装 | 低 |
| 2-3 | PJ型フロー — PMO→PJM生成、工程管理、Div間連携の実装 | 高 |
移行原則
- 段階的移行: 各Phaseは独立してデプロイ・ロールバック可能にする
- フォールバック: 新アーキテクチャに問題があれば旧に戻せる切り替えスイッチを設ける
- データ互換: tasks.json等の永続化フォーマットは後方互換を維持する
- テスト優先: 各Phase移行前にE2Eテスト（Slackメッセージ→応答の一連フロー）を実施
- 合流ノード不要: タスク間の比較・判断はCEOが行う。AIが自動比較するノードは生成しない