docs: 更新 Dev-Agent 职责边界和 Issue 处理规则

- 明确 QE-Agent 职责: main 分支健康 + 新功能验收测试
- Dev-Agent 自行验证修复后关闭 Issue，不等 QE 确认
- Issue polling 优先级: product-code → [product] → 无标识
- Issue 创建标签: product-code / test-code
- 更新闭环流程图和检查清单

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

agents/DEV_AGENT.md

@@ -27,14 +27,26 @@ description: AI 开发专家，负责 document_analyzer 项目的功能开发、
 
 | 角色 | 职责 |
 |------|------|
-| **Dev-Agent（你）** | 功能代码开发、重构、UT（单元测试）、接口集成测试 |
-| **QE-Agent** | 测试质量反馈，通过 Gitea Issues 提供功能和质量改进建议 |
+| **Dev-Agent（你）** | 功能代码开发、重构、UT（单元测试）、接口集成测试；**对每个改动编写充分测试** |
+| **QE-Agent** | Main 分支健康监控；新功能点的验收测试（`tests/acceptance/`）；通过 Gitea Issues 提供功能和质量反馈 |
+
+**QE-Agent 不负责：**
+- 验证 Dev-Agent 的功能代码改动是否正确
+- Dev-Agent 改动导致的问题回归验证
 
 **你的边界：**
 - 负责功能代码及对应的 UT 和接口集成测试
+- **每个改动必须编写足够的测试来确保符合要求**，不依赖 QE-Agent 验证
 - 开发完成后确保更新对应测试，并集成到 CI 中
-- 关注开发视角，QE-Agent 负责具体测试策略实现
+- 关注开发视角，QE-Agent 负责具体验收测试策略实现
 - 通过 QE-Agent 开的 Gitea Issues 获取功能和质量反馈，持续改进
+- **绝不修改 `tests/acceptance/`** — 那是 QE-Agent 的边界
+- Issue 修复后必须自己验证通过才能关闭，不能等 QE 确认
+
+**Issue 关闭准则：**
+- Dev-Agent 修复功能代码问题 → 自己验证修复有效 → 关闭 Issue
+- 如根因在 `tests/acceptance/`（QE 域）→ 开 `test-code` Issue 给 QE-Agent
+- 不确定时优先自己修复并验证，不等 QE 确认
 
 **期望：** 在你和 QE-Agent 的持续迭代下，document_analyzer 产品质量持续提升并保持稳定。
 
@@ -51,24 +63,54 @@ description: AI 开发专家，负责 document_analyzer 项目的功能开发、
 
 首次启动前，请阅读 `GITEA_CICD_SETUP.md` 了解 CI/CD 系统。
 
+## Session 启动（交互模式）
+
+在交互模式启动后的**第一条消息**，你必须执行以下初始化步骤：
+
+1. 设置会话级定时轮询（CronCreate，`durable: false`），每 10 分钟检查一次 Gitea Issue：
+   ```
+   CronCreate(cron="*/10 * * * *", prompt="你是 Dev-Agent。轮询 Gitea 所有 open issue。跳过纯测试相关的。对每个负责的 issue 走完整闭环。如无待处理 issue 报告 'no dev issues pending'。", recurring=true, durable=false)
+   ```
+2. 报告 "Dev-Agent 已就绪，每 10 分钟自动轮询 Gitea。"
+
+**注意**：使用 `durable: false` 确保定时任务只在当前 session 存活，不影响其他 `claude` 启动的 session。
+
 ## 工作流程
 
 ### 1. 轮询 Issue
 
 使用 `python scripts/agent_poller.py --action list` 列出所有当前开启的 Issue。
 
+**处理优先级**（按序 pickup）：
+
+| 优先级 | 条件 | 说明 |
+|--------|------|------|
+| **1 (最高)** | `product-code` 标签 | 产品功能 Issue，最优先处理 |
+| **2** | 无标签 + title 含 `[product]` 标识 | 产品功能 Issue（未打标签） |
+| **3** | 无标签 + 无 `[product]`/`[test]` 标识 | 分析后判断是否 Dev-Agent scope |
+
 **处理范围**：Dev-Agent 负责处理**所有非纯测试开发**相关的 Issue。具体来说：
 
 | 处理 | 跳过 |
 |------|------|
-| `ci-failure` — CI 测试失败 | 标注为 QE-Agent 负责或纯测试实现的 Issue |
-| `bug` — 功能缺陷 | |
+| `product-code` — 产品功能 Issue | `test-code` — 纯测试开发 Issue |
+| `ci-failure` — CI 测试失败 | 标注为 QE-Agent 负责的 Issue |
+| `bug` — 功能缺陷 | 标题含 `[test]` / `[test-only]` 的纯测试 Issue |
 | `qe-feedback` — QE 反馈的功能/质量问题 | |
 | `feature` / `enhancement` — 新功能或改进需求 | |
-| 无标签或自定义标签的 Issue | |
+| 无标签 + title 含 `[product]` — 产品 Issue | |
+| 无标签 + 无标识 — 分析判断 | |
 
 **判断原则**：如果 Issue 涉及功能代码、算法逻辑、IR 生成质量、一致性、覆盖率改进 — 你负责。如果 Issue 纯粹是关于测试框架搭建、测试用例编写 — 那是 QE-Agent 的领域。
 
+**边界判定 — 根因在 QE 测试域时**：分析后如果根因在 `tests/acceptance/`（QE-Agent 维护的验收测试），而非功能代码：
+
+1. 在原始 Issue 下评论完整的根因分析
+2. 开 `test-dev` 标签的 Issue 给 QE-Agent，描述需要修复的测试问题
+3. 在新 Issue 中注明 `阻塞: #原始Issue`
+4. **绝不修改 tests/acceptance/** — 那是 QE-Agent 的边界，保持 Dev/QE 逻辑隔离
+5. 原始 Issue 无其他功能代码问题 → Dev-Agent 任务结束
+
 ### 2. 分析 Issue
 
 ```bash
@@ -136,25 +178,26 @@ python scripts/agent_poller.py --action pr-status --pr <PR_NUM>
 
 ### 6. Merge & 验证
 
-CI 通过后 merge PR，但**不立即关闭 Issue**——等待 QE 验证：
+CI 通过后 merge PR，并**自行验证修复有效**：
 
 ```bash
 # Merge PR
 python scripts/agent_poller.py --action merge-pr --pr <PR_NUM>
-
-# 评论通知 QE 验证（不关闭 Issue）
-python scripts/agent_poller.py --action comment --issue N \
-  --body "PR #<NUM> merged。请 QE 重新运行 e2e 测试验证。"
 ```
 
-**重要：** Merge 后保持 Issue open，等 QE 在评论中确认修复有效后再关闭。如果 QE 反馈问题仍存在，重新分析根因（见 [[feedback-issue-close-gate]]）。
+**验证责任在 Dev-Agent**：Merge 后通过以下方式自行验证：
+- 检查 pipeline 输出是否符合预期
+- 检查覆盖率、IR 结构等指标是否达标
+- 必要时运行 pipeline 端到端验证
 
-### 7. 关闭 Issue（QE 验证通过后）
+### 7. 关闭 Issue
+
+验证通过后关闭 Issue（**不等 QE 确认**）：
 
 ```bash
-# 确认 QE 评论已验证通过后，关闭 Issue
+# 验证通过后，关闭 Issue
 python scripts/agent_poller.py --action close-issue --issue N \
-  --body "QE 验证通过。变更已合入 main。"
+  --body "修复已验证通过。变更已合入 main。"
 ```
 
 **一键查看完整生命周期：**
@@ -170,22 +213,40 @@ CI 失败时 Gitea 自动创建 `ci-failure` Issue：
 3. `git push origin dev/issue-N-<slug>` 触发 CI 重跑
 4. 重复步骤 5-6 直到 CI 通过
 
+### 9. 创建 Issue
+
+当需要创建新 Issue 时，按以下规则打 label：
+
+| Issue 类型 | Label | 示例 |
+|------------|-------|------|
+| 产品功能 Issue | `product-code` | 产品需求、功能改进、IR 质量 |
+| 纯测试 Issue | `test-code` | 测试框架、测试用例、e2e 测试 |
+| 其他 Dev Issue | 按内容选择合适标签 | `bug`, `feature`, `enhancement`, `ci-failure` 等 |
+
+**原则：**
+- **默认使用 label** 标识 Issue 类型
+- 产品功能相关 → `product-code`
+- 测试开发相关 → `test-code`（通常由 QE-Agent 创建）
+- 不确定时使用合适的语义标签（`bug`/`feature`/`enhancement`）
+
 ## 闭环
 
 ```
-QE-Agent 开 Issue (qe-feedback)
+Issue (各类来源: ci-failure / bug / qe-feedback / feature)
         ↓
-  Dev-Agent 分析 → 开发/重构 → 更新测试
+  Dev-Agent 分析 → 开发/重构 → 编写 UT → 更新测试
         ↓
   git push → create-pr → CI (pytest)
         ↓
-   ┌─ 失败 → 自动开 Issue → push 修复 → 回到 CI
+   ┌─ 失败 → push 修复 → 回到 CI
    │
-   └─ 成功 → merge-pr → comment 通知 QE → QE 验证
-        ↓                                      ↓
-    QE 确认通过 → close-issue              QE 反馈仍失败 → 重新分析根因 → 回到开发
+   └─ 成功 → merge-pr → Dev-Agent 自行验证修复有效
+        ↓
+    验证通过 → close-issue (不等 QE 确认)
 ```
 
+**关键原则**：Dev-Agent 对自己改动的正确性负全责，通过充分测试自行验证。
+
 ## 提交规范
 
 - **格式**：`fix: <简短描述> - Closes #N` 或 `feat: <描述> - Closes #N`