総合演習：品質改善プロジェクト

# TaskFlow コードレビュー規約

## 基本ルール
- 全てのコード変更はPRを通す（直接pushは禁止）
- 最低1人のApproveが必要（セキュリティ関連は2人）
- PRは24時間以内に初回レビュー
- PRサイズは400行以内（それ以上は分割）

## コメント規約
- プレフィックスを使用: [Must Fix] / [Should Fix] / [Nit] / [Praise]
- 各PRに最低1つの[Praise]を含める
- 指摘には理由と改善案を添える

## レビュー観点
1. 正確性（バグ、エッジケース）
2. セキュリティ（SQLi, XSS, 認証認可）
3. テスト（新コードに対するテストの有無）
4. 可読性（命名、ネスト、マジックナンバー）
5. 設計（SRP、依存関係）

## レビュアーのローテーション
- 週ごとにプライマリレビュアーを交代
- CODEOWNERSで専門領域の自動アサイン

<!-- .github/pull_request_template.md -->
## 変更の概要
<!-- この PR で何を変更したか -->

## 関連 Issue
<!-- closes #123 -->

## 変更の種類
- [ ] 新機能
- [ ] バグ修正
- [ ] リファクタリング
- [ ] テスト追加・更新
- [ ] ドキュメント更新

## テスト方法
<!-- レビュアーがどう検証すればよいか -->

## チェックリスト
- [ ] テストを追加・更新した
- [ ] テストが全て通る（npm test）
- [ ] リントが通る（npm run lint）
- [ ] 破壊的変更はない（ある場合は詳細を記載）
- [ ] セキュリティに影響する変更はない

# TaskFlow テスト戦略

## 目標
- カバレッジ: 15% → 80%（3ヶ月以内）
- E2Eテスト: 主要ユーザーフロー5つをカバー
- CI統合: PRごとに全テスト自動実行

## テストピラミッド

| レベル | ツール | カバー範囲 | 目標テスト数 |
|--------|--------|-----------|-------------|
| ユニットテスト (70%) | Vitest | Value Object, Service, Utils | 200件 |
| インテグレーション (20%) | supertest + テストDB | API, Repository | 50件 |
| E2Eテスト (10%) | Playwright | 主要ユーザーフロー | 10件 |

## フェーズ計画
Phase 1（月1）: ドメイン層のユニットテスト → カバレッジ 40%
Phase 2（月2）: APIインテグレーションテスト → カバレッジ 65%
Phase 3（月3）: E2E + 残りのテスト → カバレッジ 80%

## タスク作成のテストケース

### 境界値分析: タイトル（1〜100文字）
| テストケース | 入力値 | 期待結果 |
|-------------|--------|---------|
| 空文字 | "" | ValidationError |
| 1文字 | "a" | 成功 |
| 100文字 | "a" x 100 | 成功 |
| 101文字 | "a" x 101 | ValidationError |

### 同値分割: 優先度
| クラス | 入力値 | 期待結果 |
|--------|--------|---------|
| 有効値 | "low" | 成功 |
| 有効値 | "medium" | 成功 |
| 有効値 | "high" | 成功 |
| 無効値 | "urgent" | ValidationError |
| 無効値 | "" | ValidationError |

### デシジョンテーブル: タスク操作の権限
| 条件 | 作成者 | チーム管理者 | 他メンバー |
|------|--------|------------|----------|
| 閲覧 | OK | OK | OK |
| 更新 | OK | OK | NG |
| 削除 | OK | OK | NG |
| ステータス変更 | OK | OK | 担当者のみ |

name: Quality Gate
on:
  pull_request:
    branches: [main, develop]

jobs:
  lint-and-type-check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: '20', cache: 'npm' }
      - run: npm ci
      - run: npm run lint
      - run: npm run type-check

  unit-test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: '20', cache: 'npm' }
      - run: npm ci
      - run: npm run test:unit -- --coverage
        env:
          CI: true
      - name: Coverage threshold check
        run: |
          npx vitest run --coverage --reporter=json \
            --coverage.thresholds.lines=80

  integration-test:
    runs-on: ubuntu-latest
    services:
      postgres:
        image: postgres:15
        env:
          POSTGRES_DB: taskflow_test
          POSTGRES_USER: test
          POSTGRES_PASSWORD: test
        ports: ['5432:5432']
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: '20', cache: 'npm' }
      - run: npm ci
      - run: npx prisma migrate deploy
        env:
          DATABASE_URL: postgresql://test:test@localhost:5432/taskflow_test
      - run: npm run test:integration

  e2e-test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: '20', cache: 'npm' }
      - run: npm ci
      - run: npx playwright install --with-deps
      - run: npx playwright test
      - uses: actions/upload-artifact@v4
        if: failure()
        with:
          name: playwright-report
          path: playwright-report/

slos:
  - name: "API可用性"
    sli: "HTTP 200-499 レスポンスの割合"
    target: 99.9%
    window: 30d

  - name: "APIレイテンシ"
    sli: "p95 レスポンスタイム 500ms 以内の割合"
    target: 99%
    window: 30d

  - name: "タスクデータ正確性"
    sli: "作成・更新が正しく反映される割合"
    target: 99.99%
    window: 30d

| 残量 | アクション |
|------|-----------|
| 75-100% | 通常リリース |
| 50-75% | カナリアリリース必須 |
| 25-50% | 機能リリース最小限、信頼性改善優先 |
| 0-25% | 機能リリース凍結、全員で改善 |

1. 手動デプロイの自動化
   現状: 週2回の手動デプロイ（各30分）
   対策: GitHub Actions + AWS ECS自動デプロイ
   効果: 4h/月 削減 + デプロイミスの排除

2. 障害対応の標準化
   現状: 対応が属人化、手順が不明確
   対策: ランブック作成 + PagerDutyによるオンコール自動化
   効果: 障害対応時間 50% 短縮

3. ログ監視の自動化
   現状: 手動でログを確認
   対策: CloudWatch アラーム + Slack通知
   効果: 異常の早期検出（MTTR 改善）

# ポストモーテム: [インシデントタイトル]

## 概要
- 発生日時:
- 検出日時:
- 解決日時:
- 影響範囲:
- 影響ユーザー数:
- エラーバジェット消費:

## タイムライン
| 時刻 | イベント |
|------|---------|
| HH:MM | 異常検出 |
| HH:MM | 調査開始 |
| HH:MM | 原因特定 |
| HH:MM | 修正適用 |
| HH:MM | 復旧確認 |

## 根本原因
（5 Why 分析の結果）

## 再発防止策
| アクション | 担当 | 期限 | 優先度 |
|-----------|------|------|--------|
| | | | |

## 教訓
（チームとして何を学んだか）

## 注意: このポストモーテムは blame-free です。
個人を責めることが目的ではなく、システムの改善が目的です。

# TaskFlow 品質改善ロードマップ

## 目標
- テストカバレッジ: 15% → 80%
- 本番障害: 月3-5件 → 月0-1件
- レビュー文化: 形骸化 → 建設的で効率的なレビュー

## Month 1: 基盤構築
Week 1-2:
  - レビュー規約の策定と共有
  - CODEOWNERS、PRテンプレートの導入
  - SLI/SLOの定義と計測開始

Week 3-4:
  - ドメイン層のユニットテスト作成
  - CI/CDパイプラインへのテスト統合
  - デプロイ自動化

KPI: カバレッジ 40%、レビュー24h以内率 80%

## Month 2: テストとSRE強化
Week 1-2:
  - APIインテグレーションテスト作成
  - エラーバジェット運用開始
  - ログ監視の自動化

Week 3-4:
  - E2Eテスト（主要フロー5つ）
  - ポストモーテム文化の導入
  - トイル削減の実施

KPI: カバレッジ 65%、障害月2件以下

## Month 3: 定着と最適化
Week 1-2:
  - 残りのテスト作成（カバレッジ80%達成）
  - レビュー勉強会の開催
  - SLO目標値の見直し

Week 3-4:
  - 品質ダッシュボードの構築
  - 運用改善の振り返り
  - チームへの知識移転

KPI: カバレッジ 80%、障害月0-1件、トイル率10%以下