Plan 命令¶

# Plan: {機能名}

**Source PRD**: {パス}
**Selected Milestone**: {マイルストーンまたはフェーズ名}
**Complexity**: {Small | Medium | Large}

## Summary
{2-3文}

## Patterns to Mirror
| Category | Source | Pattern |
|---|---|---|
| Naming | `path:line` | {短い説明} |
| Errors | `path:line` | {短い説明} |
| Tests | `path:line` | {短い説明} |

## Files to Change
| File | Action | Why |
|---|---|---|
| `path` | CREATE / UPDATE / DELETE | {理由} |

## Tasks
### Task 1: {名前}
- **Action**: {何をするか}
- **Mirror**: {従うパターン}
- **Validate**: {正確性を証明するコマンド}

## Validation
```bash
{プロジェクト固有の検証コマンド}
```

## Risks
| Risk | Likelihood | Mitigation |
|---|---|---|

## Acceptance
- [ ] すべてのタスク完了
- [ ] バリデーション通過
- [ ] パターンをミラー、再発明しない

User: /plan マーケットが解決した時にリアルタイム通知を追加する必要があります

Assistant:
# 実装計画: リアルタイムマーケット解決通知

## 要件の再述
- ユーザーがウォッチしているマーケットが解決した時に通知を送信
- 複数の通知チャネル（アプリ内、メール、webhook）をサポート
- 通知が確実に配信されることを保証
- マーケットの結果とユーザーのポジション結果を含める

## 実装フェーズ

### フェーズ 1: データベーススキーマ
- 通知テーブルを追加（カラム: id, user_id, market_id, type, status, created_at）
- user_notification_preferencesテーブルをチャネル設定用に追加
- パフォーマンスのためにuser_idとmarket_idにインデックスを作成

### フェーズ 2: 通知サービス
- lib/notifications.tsに通知サービスを作成
- BullMQ/Redisを使用した通知キューを実装
- 配信失敗時のリトライロジックを追加
- 通知テンプレートを作成

### フェーズ 3: 統合ポイント
- マーケット解決ロジックにフック（ステータスが"resolved"に変更された時）
- マーケットにポジションを持つすべてのユーザーをクエリ
- 各ユーザーの通知をエンキュー

### フェーズ 4: フロントエンドコンポーネント
- ヘッダーにNotificationBellコンポーネントを作成
- NotificationListモーダルを追加
- Supabaseサブスクリプション経由のリアルタイム更新を実装
- 通知設定ページを追加

## 依存関係
- Redis（キュー用）
- メールサービス（SendGrid/Resend）
- Supabaseリアルタイムサブスクリプション

## リスク
- HIGH: メール配信性（SPF/DKIMが必要）
- MEDIUM: 1000人以上のユーザー/マーケットでのパフォーマンス
- MEDIUM: マーケットが頻繁に解決する場合の通知スパム
- LOW: リアルタイムサブスクリプションのオーバーヘッド

## 推定複雑さ: MEDIUM
- バックエンド: 4-6時間
- フロントエンド: 3-4時間
- テスト: 2-3時間
- 合計: 9-13時間

**確認待ち**: この計画で進めますか？（yes/no/modify）