サブエージェント連携モード

src/services/ ディレクトリ下のすべてのサービスのパブリックインターフェースを分析する
UserService を参照しているすべてのファイルを見つける
認証ミドルウェアのワークフローを理解する

キャッシュ層のアーキテクチャ設計案を作成する
REST から GraphQL への移行の実現可能性を評価する
データベースのテーブル分割戦略を策定する

バックグラウンドで完全なテストスイートを実行する
API ドキュメントを生成する
コードフォーマットを実行する

このプロジェクトを引き継いだばかりなので、アーキテクチャを全体的に把握するのを手伝ってください：
1. サブエージェントでバックエンドのディレクトリ構造とコアモジュールを分析する
2. サブエージェントでフロントエンドのコンポーネントツリーと状態管理を分析する
3. サブエージェントでデータベースの schema とエンティティ関係を分析する
そのうえで三つの側面の情報を総合して、プロジェクトのアーキテクチャ概要をください。

プロジェクト用にメッセージキューを選ぶ必要があります。以下の方式をそれぞれ調査してください：
1. Redis Streams — 既存の Redis 設定が対応しているか確認する
2. RabbitMQ — 新しい依存関係を導入するコストを評価する
3. PostgreSQL の LISTEN/NOTIFY を直接使う
各方式について、メリット・デメリットと、私たちのプロジェクトとの互換性を分析してください。

プロジェクトの完全なテストスイートをバックグラウンドで実行してください。私は他の作業を続けます。
テストが終わったら結果を教えてください。

サブエージェントで以下の操作を試してください：
1. 一時ブランチに切り替える
2. React を 19.x にアップグレードしてみる
3. ビルドを実行し、互換性エラーがいくつ出るか確認する
4. エラーのリストを私に送る
メインブランチでは操作しないでください。

このプロジェクトを引き継いだ初日なので、プロジェクトへの理解を素早く築くのを手伝ってください。
サブエージェントを使って以下の側面を並列に分析してください：

1. プロジェクト構造とエントリポイント — ディレクトリ構造をスキャンし、main エントリ、ルーティング定義、設定ファイルを見つける
2. データモデル — すべての model ファイルを分析し、エンティティ関係を描き出す
3. ビジネスロジック — services ディレクトリを分析し、コアとなるビジネスプロセスを理解する
4. 外部依存関係 — requirements.txt と実際の import を分析し、主要な依存関係を見つける

最後にすべての情報を総合して、500 字以内のプロジェクト概要をください。

4 個のサブエージェントを起動して並列分析を開始しています...

[サブエージェント 1] プロジェクト構造を分析中...

  - 52 個の Python ファイルをスキャン
  - エントリポイントを発見：main.py → FastAPI app
  - ルーティング定義は routers/ ディレクトリ（8 個のルーティングモジュール）
  - 設定：config.py + .env

[サブエージェント 2] データモデルを分析中...

  - 12 個の SQLAlchemy モデルを発見
  - コアエンティティ：User, Organization, Project, Task, Comment
  - 主要な関係：User ← many-to-many → Organization, Project → has-many → Task

[サブエージェント 3] ビジネスロジックを分析中...

  - 9 個の service ファイル
  - コアプロセス：ユーザー管理、プロジェクト管理、タスク割り当て、通知システム
  - 非同期タスク処理に Celery を使用

[サブエージェント 4] 外部依存関係を分析中...

  - 32 個の直接依存関係
  - 主要な依存関係：FastAPI, SQLAlchemy, Celery, Redis, Alembic
  - 未使用の依存関係を 2 個発見（requests, beautifulsoup4）

プロジェクトにリアルタイム通知機能を追加する必要があります。以下の三つの方式を並列で評価してください：

方式 A：WebSocket（FastAPI 内蔵の WebSocket サポートを使用）
方式 B：Server-Sent Events（SSE）
方式 C：ポーリング（Polling）

各方式について、以下を分析してください：
1. 既存アーキテクチャとの互換性（既存のコードを確認）
2. 実装の複雑さ（おおよそ何ファイルを変更する必要があるか）
3. パフォーマンスとスケーラビリティ
4. クライアントの互換性

そのうえで、比較表とあなたの推奨をください。

3 個のサブエージェントが分析を完了しました。総合的な比較は以下のとおりです：

| 評価軸 | WebSocket | SSE | ポーリング |
|----------|-----------|-----|------|
| アーキテクチャ互換性 | 新しい WebSocket ルートの追加が必要 | 既存の HTTP ルートを再利用可能 | 完全に互換 |
| 実装の複雑さ | 高（約 8 ファイル） | 中（約 4 ファイル） | 低（約 2 ファイル） |
| リアルタイム性 | 最良（全二重） | 良好（サーバー側プッシュ） | 普通（ポーリング間隔に依存） |
| スケーラビリティ | WebSocket の負荷分散が必要 | CDN が利用可能 | 最もシンプル |
| Celery 統合 | 追加のメッセージブリッジが必要 | Celery イベントを直接消費可能 | データベースをポーリングするだけでよい |

**推奨**：すでに Celery + Redis を使用していることを考慮すると、SSE が最良の選択です。
Redis チャンネルを購読して Celery イベントを直接取得でき、実装の複雑さは中程度で、
かつ追加のインフラストラクチャも不要です。

バックグラウンドで pytest を実行し、テストスイート全体を走らせてください。私はコードの修正を続けるので、終わったら教えてください。

バックグラウンドのテストが完了しました。結果：

- 合計：247 個のテスト
- 成功：241 個
- 失敗：4 個
- スキップ：2 個

失敗したテスト：
1. test_order_service.py::test_calculate_total_with_discount
   AssertionError: 99.99 != 100.0
2. test_user_service.py::test_create_user_duplicate_email
   IntegrityError: テストデータベースが正しくクリーンアップされていない
3. ...

これらの失敗したテストの分析をお手伝いしましょうか？

## サブエージェント使用規範

### いつサブエージェントを使うか

- 10 ファイルを超える分析タスクには、サブエージェントを使用すべき
- 複数の方式を比較する必要があるときは、各方式ごとに独立したサブエージェントを起動する
- テストの実行はバックグラウンドサブエージェントで行うべき

### サブエージェントのタスク記述テンプレート
サブエージェントを起動するとき、タスク記述には以下を含めるべき：
1. 明確な目標（何をするか）
2. 範囲の制限（何をしないか）
3. 出力フォーマット（どのような結果を返すか）

### サブエージェントの結果処理
サブエージェントの結果には、以下を含めるべき：

- 分析サマリー（200 字以内）
- 主要な発見のリスト
- 関連するファイルパス
- 潜在的なリスクや問題

サブエージェントで（読み取り専用で）src/models/ ディレクトリ下のすべてのモデルの関係を分析してください。

バックグラウンドで以下の二つのことをしてください：
1. 完全な lint チェックを実行する
2. すべての依存関係に既知のセキュリティ脆弱性がないか確認する
私はコードの修正を続けるので、完了したら結果を教えてください。

サブエージェントで、さっき言ったあの問題をチェックしてください。

サブエージェントで src/services/payment_service.py の
process_refund() メソッドが、並行する払い戻しリクエストを正しく処理しているかどうかを確認してください。
データベーストランザクションの分離レベルと楽観ロックの使用に注目してください。

以下のタスクを並列で実行してください：
1. [サブエージェント A] フロントエンドコードのすべての API 呼び出し箇所を分析する
2. [サブエージェント B] バックエンドの API エンドポイントとパラメータ定義を分析する
3. [サブエージェント C] API ドキュメントが実際のインターフェースと一致しているか確認する

三つのタスクが完了したら、API が一致していない箇所をまとめてください。

サブエージェントが payment_service.py の 127 行目に問題があると言っていました。
このファイルの 120-140 行を見せてください。

サブエージェントで実験をしてみてください：
1. 一時ディレクトリ /tmp/experiment を作成する
2. src/models/user.py をそこにコピーする
3. SQLAlchemy の宣言型モデルを dataclasses で置き換えてみる
4. どんな問題が出るか確認する

プロジェクトのファイルには一切手を触れないでください。

（Plan モードにて）
サブエージェントで以下の問題を調査してもらい、その調査結果に基づいて移行計画を立ててください：
1. 現在のすべての REST API のエンドポイントリストと呼び出し頻度
2. すでに GraphQL の同等実装があるエンドポイントはどれか
3. クライアントコードにおける REST API への依存度

サブエージェントでデータベースに接続し、以下の内容を分析してください：
1. 各テーブルのデータ量
2. スロークエリ Top 10
3. 不足しているインデックス
データベースの MCP ツールを使ってクエリを実行してください。

{
  "hooks": {
    "Notification": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "curl -X POST https://hooks.slack.com/... -d '{\"text\": \"$MESSAGE\"}'"
          }
        ]
      }
    ]
  }
}