fix-bug

# Fix Bug Skill - バグ修正統合スキル

## 役割

バグ修正の全工程を統合的に実行するスキルです。原因調査、修正実装、テスト追加、レビュー、品質保証、PR作成まで、完全なバグ修正フローを自動化します。

## 実行フロー

### Phase 1: 事前確認とブランチ作成

#### 1-1. パラメータ確認
- bug_description: バグの説明確認
- issue_number: Issue番号確認
- target: 修正対象確認（backend/frontend/both）
- suspected_files: 問題が疑われるファイル確認（オプション）

#### 1-2. ブランチ管理
```bash
# 現在のブランチを確認
git branch --show-current

# mainブランチの場合は新しいブランチを作成
# ブランチ名: fix/[bug-description-summary]-[issue_number]
# 例: fix/login-session-error-456

# mainブランチでないことを確認
```

### Phase 2: バグ原因調査

#### 2-1. エラーログ確認
```bash
# Backendログ確認（該当する場合）
grep -r "[bug related keywords]" backend/logs/
grep -r "ERROR" backend/logs/ | tail -50

# Frontendコンソールエラー確認（該当する場合）
# ブラウザDevToolsでエラー確認
```

#### 2-2. 関連コード検索
```bash
# suspected_filesが指定されている場合は優先的に確認
# 指定がない場合は、バグ説明から関連キーワードを抽出して検索

# Backendコード検索
grep -r "[keyword]" backend/src/main/java/

# Frontendコード検索
grep -r "[keyword]" frontend/
```

#### 2-3. 既存テスト確認
```bash
# 関連するテストケースを検索
# Backendテスト
find backend/src/test/java/ -name "*Test.java" | xargs grep -l "[keyword]"

# Frontendテスト
find frontend/ -name "*.test.ts*" | xargs grep -l "[keyword]"
```

#### 2-4. 原因分析レポート作成
```markdown
## バグ原因調査レポート

### バグ概要
- [bug_description]

### 再現手順（推測）
1. [手順1]
2. [手順2]
3. [手順3]

### 原因箇所
- **ファイル**: [ファイルパス]:[行番号]
- **問題**: [具体的な問題内容]
- **根本原因**: [なぜこのバグが発生したか]

### 影響範囲
- [影響を受ける機能や画面]

### 修正方針
- [どのように修正するか]

### テスト方針
- [どのようにテストするか]
```

### Phase 3: バグ修正実装

#### 3-1. Backend修正（target が "backend" または "both" の場合）

**最小限の変更で修正**:
1. 原因箇所を特定
2. 必要最小限のコード変更
3. 既存の動作を壊さないように注意
4. エラーハンドリング追加（必要に応じて）

**修正例（NullPointerException）**:
```java
// Before: バグあり
public User getUser(UUID userId) {
    User user = userMapper.selectById(userId);
    return user; // userがnullの場合、後続処理でNPE発生
}

// After: 修正後
public User getUser(UUID userId) {
    User user = userMapper.selectById(userId);
    if (user == null) {
        throw new UserNotFoundException("User not found: " + userId);
    }
    return user;
}
```

**修正後のチェック**:
- [ ] コンパイルエラーなし
- [ ] Lintエラーなし
- [ ] 既存テストが通る
- [ ] 修正箇所のテストを追加

#### 3-2. Frontend修正（target が "frontend" または "both" の場合）

**最小限の変更で修正**:
1. 原因箇所を特定
2. 必要最小限のコード変更
3. 既存の動作を壊さないように注意
4. エラーハンドリング追加（必要に応じて）

**修正例（useEffectのメモリリーク）**:
```typescript
// Before: バグあり
useEffect(() => {
  fetchData().then(data => setData(data));
}, []);
// コンポーネントアンマウント後にsetDataが呼ばれる可能性

// After: 修正後
useEffect(() => {
  let cancelled = false;

  fetchData().then(data => {
    if (!cancelled) {
      setData(data);
    }
  });

  return () => {
    cancelled = true;
  };
}, []);
```

**修正後のチェック**:
- [ ] TypeScriptエラーなし
- [ ] Lintエラーなし
- [ ] 既存テストが通る
- [ ] 修正箇所のテストを追加

### Phase 4: テスト追加（test-backend/test-frontend）

#### 4-1. Backend テスト追加（Backend修正時）

```
/test-backend target_class="[修正したクラスの完全修飾名]" test_type="unit" coverage_target=90
```

**バグ再現テストの追加**:
```java
@Test
void バグ再現_ユーザーIDがnullの場合は例外を投げる() {
    // given
    UUID userId = null;

    // when & then
    assertThatThrownBy(() -> userService.getUser(userId))
        .isInstanceOf(IllegalArgumentException.class)
        .hasMessageContaining("User ID must not be null");
}

@Test
void バグ再現_存在しないユーザーIDの場合は例外を投げる() {
    // given
    UUID userId = UUID.randomUUID();
    when(userMapper.selectById(userId)).thenReturn(null);

    // when & then
    assertThatThrownBy(() -> userService.getUser(userId))
        .isInstanceOf(UserNotFoundException.class)
        .hasMessageContaining("User not found");
}
```

#### 4-2. Frontend テスト追加（Frontend修正時）

```
/test-frontend target_file="[修正したファイルのパス]" test_type="component" coverage_target=90
```

**バグ再現テストの追加**:
```typescript
it('バグ再現: コンポーネントアンマウント後にAPIレスポンスが返ってきてもエラーにならない', async () => {
  const { unmount } = render(<UserProfile userId="123" />);

  // コンポーネントを即座にアンマウント
  unmount();

  // APIレスポンスを待つ
  await waitFor(() => {
    // エラーが発生しないことを確認
    expect(console.error).not.toHaveBeenCalled();
  });
});
```

### Phase 5: サーバー起動による動作確認

#### 5-1. Backend修正の場合
```bash
cd backend
./gradlew bootRun
```

**確認事項**:
- [ ] サーバーが正常に起動すること
- [ ] 修正した機能が正常に動作すること
- [ ] エラーログが出力されていないこと
- [ ] バグが再現しないことを確認

#### 5-2. Frontend修正の場合
```bash
cd frontend
pnpm dev
```

**確認事項**:
- [ ] サーバーが正常に起動すること
- [ ] 修正した画面/コンポーネントが正常に動作すること
- [ ] コンソールエラーが出力されていないこと
- [ ] バグが再現しないことを確認

### Phase 6: アーキテクチャレビュー（review-architecture）

```
/review-architecture target="[target]"
```

**実行内容**:
- コーディング規約準拠確認
- 修正内容の妥当性確認
- 副作用がないか確認

**判定**:
- ✅ 合格 → Phase 7へ
- ❌ 不合格 → Phase 3へ戻って修正

### Phase 7: 品質保証（qa-check）

```
/qa-check target="[target]"
```

**実行内容**:
- Lintチェック
- 既存テスト + 新規テストの実行
- ビルド検証
- カバレッジ確認

**判定**:
- ✅ 合格 → Phase 8へ
- ❌ 不合格 → Phase 3へ戻って修正

### Phase 8: PR作成（create-pr）

```
/create-pr issue_number=[issue_number]
```

**PR説明文に含める内容**:
- バグの概要
- 原因
- 修正内容
- テスト追加内容
- 確認事項

### Phase 9: 完了報告

```markdown
## Fix Bug 完了報告

### バグ概要
- [bug_description]

### Issue番号
- #[issue_number]

### PR URL
- [PR URL]

### 原因
- **ファイル**: [ファイルパス]:[行番号]
- **問題**: [具体的な問題内容]
- **根本原因**: [なぜこのバグが発生したか]

### 修正内容
- [具体的な修正内容]

### 影響範囲
- [影響を受ける機能や画面]

### テスト追加
- バグ再現テスト: [テストケース数] ケース
- 境界値テスト: [テストケース数] ケース
- 既存テスト: すべて成功

### 品質保証結果
- ✅ アーキテクチャレビュー: 合格
- ✅ QAチェック: 合格
- ✅ テストカバレッジ: [数値]%
- ✅ Lint/ビルド: 成功
- ✅ サーバー起動・動作確認: 完了
- ✅ バグ再現しないことを確認: 完了

### 次のステップ
Pull Requestのレビューを依頼してください。
```

## エラーハンドリング

### 原因特定できない場合
1. より広範囲にコード検索
2. 関連するログをすべて確認
3. 類似のバグ報告を検索
4. ユーザーに追加情報を依頼

### 修正が複雑になる場合
1. 修正方針を再検討
2. より小さな単位に分割
3. リファクタリングが必要か判断
4. ユーザーに相談

### テストが通らない場合
1. 修正内容を見直し
2. テストの期待値を確認
3. 副作用がないか確認
4. 修正を調整

## 重要な注意事項

### 最小限の変更
- バグ修正は必要最小限の変更に留める
- 関係ない箇所はリファクタリングしない
- 既存の動作を壊さない

### テストの追加必須
- バグ再現テストを必ず追加
- 同様のバグが再発しないようにする
- 境界値・異常系のテストも追加

### ドキュメント更新
- 新規エラーコードを追加した場合は error-codes.md に追記
- DB変更した場合は database-design.md を更新

## 使用するスキル一覧

1. **test-backend**: バックエンドテスト追加（Backend修正時）
2. **test-frontend**: フロントエンドテスト追加（Frontend修正時）
3. **review-architecture**: アーキテクチャレビュー
4. **qa-check**: 品質保証
5. **create-pr**: PR作成

## 参照ドキュメント

### 必須参照
- `documents/development/development-policy.md`: 開発ガイドライン
- `documents/development/coding-rules/`: コーディング規約
- `documents/development/error-codes.md`: エラーコード一覧

### バグ調査に役立つドキュメント
- `documents/architecture/database-design.md`: データベース設計
- `documents/architecture/system-architecture.md`: システムアーキテクチャ
- `documents/features/[機能名]/specification.md`: 機能仕様書