chore: SETUP.md + 测试报告脚本 + 文档更新

- SETUP.md: 完整环境搭建指南（同事用）
- SETUP_QUICK.md: 快速搭环境（4步）
- s22~s26: TNA端到端、覆盖率报告、回归检查
- procedure_grammar.lark: 实验性Lark语法

Co-Authored-By: Claude <noreply@anthropic.com>

docs/gap-analysis-report.md

@@ -0,0 +1,65 @@
+# テストカバレッジ 真のギャップ分析レポート
+
+## ギャップ1: `pure_vs_mixed` の判定ロジックが一度も検証されていない
+
+`resolve_pure_vs_mixed()` は `has_switch AND has_counter AND if_count >= 3` の場合のみ `混合マッチング` を返す。この条件を満たすテストプログラムが存在しないため、**この分岐は一度も通過したことがない**。未テストのreturn文が存在する。
+
+```
+resolve_pure_vs_mixed():
+  if has_switch and has_counter and if_count >= 3:
+    return "混合マッチング"  ← 未テスト
+  else:
+    return "unknown"         ← これしか通らない
+```
+
+## ギャップ2: `mn_output_mode` が `select_files` dict に脆く依存
+
+extract_structure() は FILE-CONTROL パースに成功したときのみ `select_files` に値を入れる。SELECT...ASSIGN TO パターンにマッチしないファイル定義（例：古いCOBOLのASSIGN TO なし）では空dictになる → `len({}) == 0` → `file_count` も0 → 判定バイパス。
+
+これは他の混淆組にも波及する: `matching_vs_keybreak` の `file_count` が0になるため、マッチング判定がファイル数条件を満たさない。
+
+## ギャップ3: L1キーワードの文字列マッチが脆弱
+
+`EXEC SQL`, `CALL`, `SYSIN`, `ORGANIZATION IS` などのキーワードは **部分文字列マッチ** であり、以下のFPを引き起こす可能性がある：
+
+| キーワード | FPシナリオ | 現状 |
+|:-----------|:-----------|:------|
+| `EXEC SQL` | `DISPLAY 'EXEC SQL...'` の文字列リテラル | FP確認済み |
+| `CALL` | `COMPUTE WS-CALL = WS-X` の変数名 | FP確認済み |
+| `MAP` | `WS-MAP` という変数名 | FP確認済み（CICSと判定） |
+| `SYSIN` | `SYSIN` という変数名 | FP確認済み |
+| `ORGANIZATION IS` | コメント内の `ORGANIZATION IS` | 未確認だがリスクあり |
+
+## ギャップ4: 8つのCOBOL文が実パイプラインで未テスト
+
+以下のCOBOL文はL0(解析)テストではカバーされているが、実際の `classify_program()` パイプラインを通すテストが存在しない：
+
+| 文 | L0テスト | パイプラインテスト | リスク |
+|:---|:---------|:-------------------|:-------|
+| SEARCH ALL | ✅ | ❌ | Lark OCCURS＋ASCENDING KEY に依存、崩れる可能性 |
+| SEARCH(逐次) | ❌ | ❌ | INDEXED BY の添字解決に依存 |
+| SORT INPUT/OUTPUT PROCEDURE | ❌ | ❌ | PROCEDURE段落の展開が必要 |
+| MERGE OUTPUT PROCEDURE | ❌ | ❌ | 同上 |
+| RELEASE/RETURN | ❌ | ❌ | SORT/MERGEサブ文、パーサー素通り |
+| ALTER | ❌ | ❌ | 旧式だが大型機には残っている |
+| USE Declaratives | ❌ | ❌ | パーサーが完全未対応 |
+| MOVE CORRESPONDING | ❌ | ❌ | CORR 句が非対応 |
+
+## ギャップ5: パーサー例外時の分類パイプラインの挙動が未検証
+
+`extract_structure()` が失敗（日本語変数名、固定形式の不正など）した場合、`classify_program()` は空の `structure` dict でパイプラインを続行する。このとき：
+
+1. `keyword_matches` は空（detect_keyword は extract_structure 非依存だが source_upper を再生成しない）
+2. `max_keyword_confidence = 0.0` → Path C(fallback)
+3. `structure = {}` → `features = {}` → 全混淆組が unknown
+4. 最終的に `項目チェック(重複含まず) conf=0.12` のデフォルト値になる
+
+構造抽出に失敗しても「静かに誤った分類を返す」という設計が、問題の隠蔽を引き起こしている。
+
+## 総評
+
+現在のテストスイートは「正常系」と「既知のFP」をカバーしているが、**以下の3つが完全に欠落している**：
+
+1. **ルールエンジンの全分岐カバレッジ** — pure_vs_mixed、mn_output_mode の特定条件分岐が未到達
+2. **実COBOL構文のパイプライン結合テスト** — 8つの重要文がパイプライン通過未検証
+3. **パーサー障害時の異常系テスト** — 抽出失敗→デフォルト値の挙動が未確認