# 実行計画（2025-10-26）

## 現在の状況（事実）

### ✅ 実現している部分
1. **BaseStepProcessor は実装済み**
   - `src/noveler/application/use_cases/step_processors/base_step_processor.py` が存在
   - インポート可能（テスト済み）
   - integration テスト 10/10 PASS

2. **Integration テスト正常稼働**
   - `test_interactive_writing_system.py` : 10/10 PASSED (実行時間 6.47s)
   - 基本的なシステム機能は正常

### ❌ 問題のある部分
1. **マージコンフリクト（CRITICAL）**
   - ファイル: `src/mcp_servers/noveler/tools/fix_quality_issues_tool.py`
   - 位置: 行987-996
   - 内容: 方法シグネチャの差異
     ```python
     <<<<<<< Updated upstream
         def _find_split_position(self, cur: str, target_len: int, analyzer: MorphologicalAnalyzerProtocol | None) -> int:
     =======
         def _find_split_position(
             self,
             cur: str,
             target_len: int,
             analyzer: MorphologicalAnalyzerProtocol | None,
         ) -> int:
     >>>>>>> Stashed changes
     ```
   - 影響: テスト収集失敗（30個のERROR）

2. **Stash操作の不完全性**
   - git stash apply時に自動マージできず
   - マージコンフリクトマーカーが残置

---

## 実行計画（段階的）

### **フェーズ1: コンフリクト解決（15分、優先度：CRITICAL）**

#### 手順1.1: コンフリクト内容の確認
```bash
# コンフリクト箇所の確認
git diff src/mcp_servers/noveler/tools/fix_quality_issues_tool.py
```

**差異の説明:**
- `Updated upstream`: 1行形式（元のコード）
- `Stashed changes`: 複数行形式（リフォーマットされたコード）
- どちらも機能的には同一（単なるフォーマットの違い）

#### 手順1.2: 解決方針の選択

**推奨: Stashed changes版を採用（PEP 8準拠）**
理由:
- 複数行フォーマットは PEP 8 に準拠
- プロジェクトの既存スタイルに合致
- 他のメソッドシグネチャと一貫性がある

#### 手順1.3: 修復実行
```bash
# Stashed changes版を採用
git checkout --theirs src/mcp_servers/noveler/tools/fix_quality_issues_tool.py

# 確認
git diff src/mcp_servers/noveler/tools/fix_quality_issues_tool.py | head -20

# ステージング
git add src/mcp_servers/noveler/tools/fix_quality_issues_tool.py

# コミット
git commit -m "fix: Resolve merge conflict in fix_quality_issues_tool.py (use stashed formatting)"
```

---

### **フェーズ2: テスト検証（15分、優先度：HIGH）**

#### 手順2.1: Syntax検証
```bash
# Python構文確認
python -m py_compile src/mcp_servers/noveler/tools/fix_quality_issues_tool.py
```

#### 手順2.2: Unit テスト実行
```bash
# 問題のあったテストファイルの実行
python scripts/run_pytest.py tests/unit/mcp_servers/tools/test_fix_quality_issues_no_wrap.py -v

# 期待: 全テスト PASS
```

#### 手順2.3: 全テストスイート実行
```bash
# 完全なテストスイート
python scripts/run_pytest.py -q --tb=short

# 期待:
# - 8900+ 件のテスト合格
# - 0件のエラー
```

#### 手順2.4: 結果記録
```bash
# テスト結果をファイルに保存
python scripts/run_pytest.py -q --tb=short 2>&1 | tee /tmp/test_results_2025_10_26.txt

# 最後の20行を確認
tail -20 /tmp/test_results_2025_10_26.txt
```

---

### **フェーズ3: メモリファイルの更新（10分、優先度：HIGH）**

#### 手順3.1: 前のメモリの問題点記録
```markdown
# 問題点
- テスト結果が虚偽（実際に実行されていない）
- マージコンフリクトの見落とし
- システム状態の不正確な報告
```

#### 手順3.2: 正確なメモリファイル作成

**新メモリ: Session_2025_10_26_Conflict_Resolution_Complete**
```markdown
# マージコンフリクト解決報告（2025-10-26 修復）

## 問題
- fix_quality_issues_tool.py:987-996 にマージコンフリクトマーカー存在
- テスト収集失敗（30 ERROR）

## 解決方法
- git checkout --theirs で Stashed changes版を採用
- PEP 8 フォーマット準拠

## テスト結果
[実行結果をここに記載]
```

#### 手順3.3: 前のメモリの更新
```
Session_2025_10_26_BaseStepProcessor_Fix_Complete.md
  ↓
  修正: テスト結果を実際の値に更新
  削除: 虚偽の「8953 PASS」記述
  追加: マージコンフリクトの存在を記録
```

---

### **フェーズ4: Git 記録の作成（5分、優先度：MEDIUM）**

#### 手順4.1: 修復コミットの確認
```bash
git log --oneline -3
# 期待:
# new_hash fix: Resolve merge conflict in fix_quality_issues_tool.py
# 69d5692 docs: Add BaseStepProcessor fix completion summary
# 4639120 docs: Add DDD refactor decision and next steps roadmap
```

#### 手順4.2: 修復内容の記録
```bash
git show <new_hash> --stat
```

---

### **フェーズ5: 次セッション用ロードマップの作成（10分、優先度：MEDIUM）**

#### 手順5.1: 修復前後の比較メモリ作成
```markdown
# Session_2025_10_26_Execution_Summary

## セッション目標
1. マージコンフリクト解決 ✅
2. テスト検証 ⏳（フェーズ2）
3. メモリファイル更新 ⏳（フェーズ3）
4. 次セッション用ロードマップ作成 ⏳（フェーズ5）

## 解決したコンフリクト
- fix_quality_issues_tool.py:987-996
- 方法シグネチャのフォーマット差異
- 採用: Stashed changes版（PEP 8準拠）

## 現在のシステム状態
- Integration テスト: 10/10 PASS ✅
- Unit テスト: 実行待機中
- マージコンフリクト: 解決済み ✅
- 本番運用準備度: 待機中
```

#### 手順5.2: DDD修復ロードマップの微調整
```markdown
# 修復前状態
- テスト収集失敗（マージコンフリクト原因）
- システム本番不可

# 修復後状態
- テスト実行可能（予定）
- システム本番可能（検証待機）

# 次セッションからは
- DDD違反修復をフェーズ1から開始可能
```

---

## 実行順序と所要時間

| フェーズ | タスク | 所要時間 | 優先度 | 状態 |
|---------|--------|---------|--------|------|
| 1 | コンフリクト解決 | 15分 | CRITICAL | 待機中 |
| 2 | テスト検証 | 15分 | HIGH | 待機中 |
| 3 | メモリ更新 | 10分 | HIGH | 待機中 |
| 4 | Git記録 | 5分 | MEDIUM | 待機中 |
| 5 | ロードマップ | 10分 | MEDIUM | 待機中 |
| **合計** | | **55分** | | |

---

## 成功基準

### フェーズ1: コンフリクト解決
- [ ] `git diff` で変更がない（コンフリクトマーカーなし）
- [ ] `git status` で clean
- [ ] コミットが正常に記録

### フェーズ2: テスト検証
- [ ] `python -m py_compile` で SyntaxError がない
- [ ] `test_fix_quality_issues_no_wrap.py` が実行可能
- [ ] 全テストスイート実行可能（0 ERROR）

### フェーズ3: メモリ更新
- [ ] 新メモリ: `Session_2025_10_26_Conflict_Resolution_Complete.md` 作成
- [ ] 前メモリ: 虚偽内容が正記
- [ ] テスト結果がファイルに記録

### フェーズ4: Git 記録
- [ ] `git log --oneline` に新コミット記録
- [ ] ローカルとリモート（origin/dev）の同期確認

### フェーズ5: ロードマップ
- [ ] メモリ: `Session_2025_10_26_Execution_Summary.md` 作成
- [ ] 次セッション用の明確なロードマップ

---

## リスク評価と対応

### リスク1: Stashed changes版が不完全
**対応**: `git checkout --ours` で upstream版を採用
```bash
git checkout --ours src/mcp_servers/noveler/tools/fix_quality_issues_tool.py
```

### リスク2: テスト失敗が続く
**対応**: コンフリクト解決後も失敗なら、別の修復が必要
```bash
# 原因特定
python -m pytest tests/unit/mcp_servers/tools/test_fix_quality_issues_no_wrap.py --tb=long
```

### リスク3: メモリファイルが多すぎる
**対応**: 古いメモリを統合
```bash
# 前のセッションメモリ3個を新しい1個に統合
# - BaseStepProcessor_Fix_Complete
# - DDD_Refactor_Progress
# - DDD_Violations_Analysis
↓
Session_2025_10_26_Complete_Status_After_Conflict_Resolution.md
```

---

## 実行後の確認項目

### システム準備度
```
✅ テスト実行可能
✅ マージコンフリクト解決
✅ メモリ正確化
⏳ 本番運用準備（フェーズ2の結果待機）
```

### 次セッション開始時
1. このメモリを読む
2. テスト結果を確認
3. DDD修復フェーズ1から開始
4. 警告継続モード（B案）で段階的修復

---

## 資料

- [前のセッション報告](Session_2025_10_26_BaseStepProcessor_Fix_Complete.md)
- [DDD分析](Session_2025_10_26_DDD_Violations_Analysis.md)
- [修復ロードマップ](Session_2025_10_26_DDD_Refactor_Decision_and_Next_Steps.md)

