bug-fix

name	bug-fix
description	バグ報告から修正完了までの完全ワークフロー（Issue作成→実装→PR→マージ）

バグ修正完全ワークフロー

バグ発見から修正完了までの完全なライフサイクルを自動化します。

---

全体フロー

Phase	名称	内容
0	バグ報告検出	会話からバグ報告を自動検出
1	Issue確認/作成	既存Issue確認、または新規作成提案
1.5	環境選択	worktree or host
2	実装	実装フェーズ呼出（Bugfix Rule適用）
2.5	ユーザー承認	approval-gate skill ※PR作成前
3	PR作成	バグ修正専用テンプレートでPR作成
4	CI監視 & マージ	CI成功→自動マージ
5	クリーンアップ	環境削除

Phase規約: workflow-phase-convention skill を参照

---

サーキットブレーカー

条件	アクション
Issue作成拒否	修正を中断
CI修正3回失敗	Draft PR化、手動確認依頼
品質レビュー3回失敗	Draft PR作成 → ユーザー判断

---

自動検出トリガー

Sisyphusが会話からバグ報告を自動検出します。

優先度	パターン	アクション
高	"Issue #XX を修正して"	即座に修正開始
高	"PR #XX のレビュー指摘"	既存環境再開 → 修正 → push
中	"-w 2が反映されない"	Issue作成 → 原因特定 → 修正
低	"〇〇が動かない"	Issue作成提案 → 承認後に修正

検出パターン

# 明示的Issue/PR番号（優先度: 高）
issue_match = re.search(r'Issue #(\d+).*(修正|fix|直)', user_message)
pr_match = re.search(r'PR #(\d+).*(レビュー|指摘|修正)', user_message)

# 具体的不具合（優先度: 中）- LLM判定で誤検知回避
patterns = [r'(.+)が反映されない', r'(.+)が動作しない', r'(.+)がエラーになる']

# 一般キーワード（優先度: 低）- ユーザー確認必須
keywords = ["バグ", "bug", "不具合", "動かない", "エラー"]

誤検知回避

リスク	回避策
設計議論との混同	除外パターン: 動かない.*べき
調査依頼との混同	除外パターン: 調査.*動かない + LLM判定
質問との混同	LLM判定で文末の疑問符を検出

---

Phase 1: Issue確認/作成

既存Issue確認

# ユーザーが明示的にIssue番号を指定した場合
gh issue view {issue_id} --json state,title

# 類似Issueを検索
gh issue list --state open --label bug --limit 20 --json number,title

Issue作成提案

既存Issueがない場合、ユーザーに作成を提案:

## バグ報告 - Issue作成提案

- **タイトル**: `fix: {summary}`
- **ラベル**: `bug`
- **説明**: 現象、期待動作、再現手順

**このIssueを作成して修正を開始しますか？**
- `作成`: Issue作成 → 修正開始
- `既存利用 #XX`: 既存Issue #XX を使用
- `キャンセル`: 中断

---

Phase 1.5: 環境選択

条件	環境	理由
通常のバグ修正	worktree	並行作業のため環境分離
簡易な修正	host	worktree作成コスト回避

詳細: worktree-workflow skill

---

Phase 2: 実装（実装フェーズ呼出）

バグ修正は実装フェーズを内部で呼び出して実行。 違いは以下のBugfix Ruleのみ:

項目	Feature開発	バグ修正
ブランチ名	feature/issue-XX-*	fix/issue-XX-*
修正方針	新規機能追加	最小変更（Bugfix Rule）
テスト追加	新規テスト	Regression Test必須

Bugfix Rule（実装ガイドライン）

ルール	説明	検証者
最小変更	バグの根本原因のみを修正（リファクタリング禁止）	backend-reviewer
Regression Test	バグを再現するテストケースを必ず追加	実装者
原因記録	修正前にコメントで根本原因を記録	backend-reviewer
影響範囲確認	修正が他の機能に影響しないか確認	実装者

リファクタリング判定基準

指標	閾値	判定
変更行数	修正ファイルの30%以上	要レビュー
変更ファイル数	3ファイル以上	要レビュー
関数名変更	あり	リファクタリングの可能性

Regression Test免除条件

条件	免除可否	代替要件
既存テストがバグを検出していた	免除可	既存テストの修正のみ
タイポ修正（コメント・文字列）	免除可	影響範囲が限定的であることを明記
ロジック修正	必須	例外なし

---

Phase 2.5: ユーザー承認ゲート

共通仕様: approval-gate skill を参照

## 承認リクエスト: バグ修正PR作成

**Issue**: #{issue_id}
**修正内容**: {fix_summary}
**変更行数**: {changed_lines}行（{changed_files}ファイル）

### レビュー結果
- スコア: {score}/10
- Regression Test: 追加済み

---
**選択肢**:

1. 続行 → PR作成へ進む
2. 中断 → 修正を中断
3. 修正 → 指摘箇所を修正

> 番号を選択してください（1-3）:

---

Phase 3: PR作成

バグ修正専用PRテンプレート:

## 概要
Closes #{issue_id}

## Root Cause Analysis（根本原因分析）

### 原因
{root_cause_description}

### 修正内容
{fix_description}
**修正行数**: {changed_lines}行（{changed_files}ファイル）

### 影響範囲
{impact_scope}
**デグレードリスク**: 低/中/高

## Regression Test
- `test_fix_issue_{issue_id}_*`: バグ再現テスト
- 修正前: ❌ 失敗 / 修正後: ✅ 成功

## Bugfix Rule遵守チェック
- [x] 最小変更の原則（リファクタリングなし）
- [x] Regression Test追加
- [x] 原因記録
- [x] 影響範囲確認（全テスト通過）

---

CI監視 & マージ & クリーンアップ

詳細: ci-workflow skill, pr-merge-workflow skill

---

レビュー指摘対応（PRコメント対応）

def handle_pr_review_feedback(pr_number: int):
    # 1. 既存環境の再利用確認
    # (worktreeがあるなら移動、なければ作成)
    
    # 2. 修正実施 → push
    bash(
        command="git add . && git commit -m 'fix: レビュー指摘対応' && git push"
    )
    
    # 3. CI再監視
    post_pr_workflow(pr_number)

---

エスカレーション条件

条件	アクション
Issue作成を拒否された	修正を中断
CI修正3回失敗	Draft PR化、手動確認依頼
PRマージ時にコンフリクト	手動マージ依頼
Regression Test作成失敗	再現手順を依頼
設計書と実装の大幅な乖離	/request-design-fix 提案
品質レビュー3回失敗	Draft PR作成 → ユーザー判断

品質レビュー3回失敗時

## ⚠️ 品質レビュー基準未達（3回失敗）

### レビュー履歴
| 回数 | スコア | 主な指摘 |
|------|--------|----------|
| 1 | 7/10 | ... |
| 2 | 8/10 | ... |
| 3 | 8/10 | ... |

### Draft PR作成済み
- **PR**: #{pr_number}

**次のステップを選択してください**:

1. 続行 → さらに修正を試行（最大2回）
2. 手動対応 → Draft PRを手動でレビュー・修正
3. 中断 → Issue再検討

> 番号を選択してください（1-3）:

---

ユースケース例

例1: 会話から自動検出

User: "--timeout 30 オプションが反映されていないようです"

Sisyphus:
1. バグ報告を検出
2. Issue作成提案 → ユーザー承認
3. 実装フェーズ呼出（Bugfix Rule適用）
4. PR作成 → CI → マージ → クリーンナップ

例2: 明示的なIssue番号指定

User: "Issue #64 を修正してください"

Sisyphus:
1. Issue #64 を取得
2. fix/issue-64-* ブランチ作成
3. 実装フェーズ呼出

例3: PRレビュー指摘対応

User: "PR #42 のレビュー指摘に対応してください"

Sisyphus:
1. PR #42 から Issue/環境を特定
2. 既存環境を再開
3. 修正実施 → push → CI再監視

---

関連ドキュメント

スキル/ドキュメント	参照タイミング
worktree-workflow skill	並行作業環境
ci-workflow skill	PR作成後のCI監視
pr-merge-workflow skill	PRマージ〜クリーンアップ
approval-gate skill	ユーザー承認ゲート
workflow-phase-convention skill	Phase命名規約
プラットフォーム例外	固有コードの修正時
設計書同期ポリシー	設計書更新時
テスト戦略	Regression Test追加時

---

まとめ

フェーズ	自動化内容
Issue作成	会話から自動検出 → 作成提案 → 承認後に作成
実装	実装フェーズ呼出（Bugfix Rule遵守）
完了	PR作成 → CI監視 → マージ → クリーンナップ

ユーザーは「バグがある」と報告するだけで、残りは全自動で完了します。