fix: DEV_AGENT.md 增加 Issue 关闭规范 + 研究型修复 + 禁止模式 - Closes #79

- Issue 关闭规范: 必须包含问题/根因/修复/验证四要素
- 研究型修复流程: 根因不明时开 investigation Issue 阻断原 Issue
- 禁止模式: 反复小改动试错、不跑 pipeline 关质量 Issue 等

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

agents/DEV_AGENT.md

@@ -122,15 +122,26 @@ python scripts/agent_poller.py --action get --issue N
 
 ### 3. 开发 / 修复
 
+**第零步：判断修复类型。** 不同修复类型走不同验证路径，**必须在开发前确认**：
+
+| 类型 | 特征 | 示例 | 验证方式 |
+|------|------|------|----------|
+| **代码级修复** | 确定性逻辑错误、字段缺失、类型不对 | null check、type 标准化、字段补齐 | UT + pytest |
+| **质量级修复** | 涉及 LLM 输出质量、覆盖率、语义判断 | Layer C audit、覆盖率提升、prompt 优化 | **必须 pipeline + e2e** |
+
+**质量级修复必须在步骤 5-6 中实际运行 pipeline 并确认 Layer A+B+C 全部通过。**
+如果无法运行 pipeline（API 不可用等），**禁止关闭 Issue** — 在 PR 和 Issue 中标注 `⚠ 待 e2e 验证`，保持 Issue open 等待 verifier 执行。
+
 ```
-1. git pull origin main
-2. git checkout -b dev/issue-N-<slug>
-3. 修改功能代码 + 更新/补充 UT 和接口集成测试
-4. python -m pytest -v              # 本地全量 UT/集成测试
-5. python scripts/run_pipeline.py --input "input/<文档>.docx"  # 运行完整 pipeline
-6. python -m pytest tests/acceptance/ -v --run-acceptance       # e2e 验收 (Layer A+B+C)
-7. git commit -m "fix: <描述> - Closes #N"
-8. git push origin dev/issue-N-<slug>
+1. [判定] 是代码级修复还是质量级修复？
+2. git pull origin main
+3. git checkout -b dev/issue-N-<slug>
+4. 修改功能代码 + 更新/补充 UT 和接口集成测试
+5. python -m pytest -v              # 本地全量 UT/集成测试
+6. [仅质量级修复] python scripts/run_pipeline.py --input "input/<文档>.docx"
+7. [仅质量级修复] python -m pytest tests/acceptance/ -v --run-acceptance
+8. git commit -m "fix: <描述> - Closes #N"
+9. git push origin dev/issue-N-<slug>
 ```
 
 **开发原则：**
@@ -138,8 +149,21 @@ python scripts/agent_poller.py --action get --issue N
 - 新增功能必须有对应的测试覆盖
 - 关注 IR 一致性：对同一输入的多次运行结果应尽量稳定
 - 关注功能覆盖率：确保 IR 覆盖了输入文档中的功能点
-- **验证是实际功能验证，不是 dry-run**：`pytest` 通过只是门槛，必须用真实输入文档实际运行 pipeline 确认功能生效
-- **PR 前必须通过 e2e 验收 (Layer A+B+C)**：防止修复引入回归。若无法运行完整 pipeline（API 不可用等），至少在 PR 描述中注明
+- **代码级修复**：UT 通过即可关闭 Issue
+- **质量级修复**：必须 pipeline + e2e 全部通过才能关闭 Issue。无法运行 pipeline 时，PR 和 Issue 标注 `⚠ 待 e2e 验证`，**Issue 保持 open**
+
+**质量级修复批处理策略：**
+
+e2e 测试耗时且消耗大量 LLM token。对于质量级修复（Layer C audit、覆盖率、prompt 优化），**单个小改动看不出效果** — 只有 pytest 是无效测试。
+
+| 策略 | 说明 |
+|------|------|
+| **批量改动** | 将同一方向的质量级 Issue（如多个 Layer C 问题）合并到一个分支，打包测试 |
+| **集中验证** | 一批改动只跑一次 pipeline + e2e，避免每个小 PR 重复消耗 token |
+| **改动-测试成本匹配** | 跑一次完整 e2e 的 token 成本值得对应多个相关改动的验证 |
+| **禁止逐个微调** | 不允许对同一个质量 Issue 反复做单行改动 → 跑 pytest → 关 Issue → 被重开 的循环 |
+
+**质量级修复闭环：** 分析 → 打包相关 Issue → 合并在一个分支改动 → 跑一次 pipeline + e2e → Layer A+B+C 全部通过 → 关 Issue
 
 ### 4. 提交 PR
 
@@ -151,9 +175,15 @@ python scripts/agent_poller.py --action create-pr \
   --body "## Summary
 - <改动摘要>
 
+## 修复类型
+- [ ] 代码级修复（UT 可验证）
+- [ ] 质量级修复（需 pipeline + e2e 验证）
+
 ## Test
 - [x] pytest 全量通过 (XX passed, Y skipped)
 - [x] UT / 集成测试已更新
+- [ ] pipeline 运行通过（仅质量级修复）
+- [ ] e2e 验收 Layer A+B+C 通过（仅质量级修复）
 
 Closes #N"
 ```
@@ -255,6 +285,48 @@ QE-Agent 开 Issue (qe-feedback / bug / ci-failure)
     --title "[test] issue 标题" --labels test-code --body "..."
   ```
 - 多个 label 用逗号分隔，如 `--labels "ci-failure,product-code"`
+- **研究调查 Issue** → `investigation` label（根因不明、需实验验证的探索性工作）
+  ```bash
+  python scripts/agent_poller.py --action create-issue \
+    --title "[investigation] issue 标题" --labels investigation --body "..."
+  ```
+  研究 Issue 的用途见下方"研究型修复流程"。
+
+## 研究型修复流程
+
+**当根因不明确时，禁止反复做小改动试错。** 必须走研究 → 确认 → 修复 的路径。
+
+### 判断：我是在修复还是试探？
+
+| 情况 | 行为 | 
+|------|------|
+| 根因明确、修复方案确定 | 直接修复，走正常闭环 |
+| 根因不明确、有多个可能原因 | **开研究 Issue** |
+| 改动后不确定效果、想"试试看" | **开研究 Issue** |
+
+### 研究 Issue 流程
+
+```
+原 Issue (product-code) ← blocked by ← 研究 Issue (investigation)
+                                              ↓
+                                    跑 pipeline → 收集数据 → 对比分析
+                                              ↓
+                                    确认根因 → 关闭研究 Issue → 修复原 Issue
+```
+
+具体步骤：
+
+1. **创建研究 Issue**：`--labels investigation`，描述要验证的假设和实验方法
+2. **阻断原 Issue**：研究 Issue 创建后，在原 Issue 评论"阻塞: #研究Issue"
+3. **实验验证**：在研究分支上跑 pipeline，收集 Layer A/B/C 数据，对比基线
+4. **得出结论**：在研究 Issue 中记录实验结果和根因确认
+5. **修复原 Issue**：确认根因后，在原 Issue 分支上实施修复
+6. **关闭研究 Issue**：根因确认，修复完成，关闭研究 Issue
+
+### 关键原则
+- 一次研究 Issue 可以对应多个原 Issue（同一根因导致的多个症状）
+- 研究 Issue 也遵循正常的 PR + CI 流程（但可以包含调试代码、日志等）
+- 不确定的改动宁可开研究 Issue，也不要直接关原 Issue
 
 ## agent_poller 命令速查
 
@@ -287,9 +359,61 @@ QE-Agent 开 Issue (qe-feedback / bug / ci-failure)
 - [ ] **CI**：`agent_poller.py --action pr-status` 确认 CI 通过
 - [ ] **合并**：`agent_poller.py --action merge-pr` 合并 PR
 - [ ] **验证**：用真实输入文档实际运行 pipeline，确认功能生效（非 dry-run）
-- [ ] **关闭**：验证通过后 `--action close-issue`
+- [ ] **关闭**：验证通过后 `--action close-issue`（关闭 comment 必须符合下方"Issue 关闭规范"）
 - [ ] **复盘**：`agent_poller.py --action lifecycle` 确认全流程完成
 
+## Issue 关闭规范
+
+**关闭 Issue 时的 comment 必须包含以下四个要素，缺一不可：**
+
+```
+## 问题
+<一句话描述 Issue 的症状>
+
+## 根因
+<明确指出导致问题的根本原因，不是表面现象>
+
+## 修复
+<这个改动如何消除根因？为什么这个方案是正确的？>
+
+## 验证
+<具体的验证步骤和结果，不是空泛的"已通过">
+```
+
+**禁止的关闭 comment：**
+- "PR merged, 验证通过" — 没有说明根因和验证方式
+- "自行验证通过，变更已合入 main" — 没有说明验证了什么
+- 任何缺少上述四个要素的关闭 comment
+
+**示例（正确）：**
+```
+## 问题
+_measure_coverage 将 0/0 维度 rate 算作 0%，拉低 overall 均值。
+
+## 根因
+`0 / max(0, 1) = 0%`，diagram 维度无内容时 rate 为 0% 并参与均分。
+
+## 修复
+引入 _safe_rate()：total=0 时 rate=1.0。overall 均分排除 total=0 的维度。
+
+## 验证
+- pytest: 102 passed, 13 skipped
+- test_layer_b_coverage: PASSED, overall 57.4%→86.1%
+- 命令行确认: Section 100% + Table 72.2% → Overall 86.1%
+```
+
+## 禁止模式
+
+以下行为模式被明确禁止。发现自己在做以下任何一件事，立即停止：
+
+| 禁止模式 | 为什么禁止 | 正确做法 |
+|----------|-----------|----------|
+| 单行改动 → 关 Issue → 重开 → 再改 的循环 | 说明根因没找到，在试错 | 开研究 Issue |
+| 不跑 pipeline 就关质量级 Issue | 无法证明修复有效 | 跑 pipeline + e2e，或 Issue 保持 open |
+| 关闭 comment 不写根因 | 无法判断修复是否正确 | 按 Issue 关闭规范写 |
+| 对同一 Issue 连续提交 3 个以上 PR | 说明方向不对 | 暂停，开研究 Issue |
+| pytest 绿了就关 Issue | pytest 只保证无回归，不保证功能正确 | 代码级可关，质量级必须 pipeline |
+
 ## Session 收尾
 
 **当 session 即将结束时（用户要求结束、或完成当前轮询周期后准备退出），执行以下收尾动作：**

skills/ir_generation_skill/prompts/step2_ir_extraction.txt

@@ -186,6 +186,8 @@
 
 8. **开关关闭状态**：开关关闭时所有限制失效，这也必须作为一条规则输出（path: ["...", "开关关闭", "无限制"]）。
 
+9. **功能完整性要求（重要）**：上下文包中的每个表格行、每条文字描述、每个逻辑树路径都必须被至少一条规则覆盖。仔细检查上下文包，确保不遗漏任何数据来源。如果上下文包中有表格，每条表格行至少生成一条对应规则。
+
 {format_feedback}
 
 ## 输出格式