hotplex-issue-managerlisted

# HotPlex Issue Manager 将分散的 GitHub issues 转化为**一个合并 Pull Request**。分析、排序、批量实施，一次交付。 **核心模式**：多个 issue → 一个分支 → 一个 PR → 一次合并 > 陷阱和反模式见 `references/common-pitfalls.md`（7 个常见错误，含 PR 冲突）。 ## 工作流 ``` Phase 1: 分析验证 → 呈现结果 → Phase 2: ROI 评分 → 呈现排名 → Phase 3: PR 冲突检查 + 选择 → 确认计划 → Phase 4: 实施 ``` 每个 Phase 结束后**呈现结果让用户确认**，再进入下一阶段。不要一口气跑完全部 Phase。 ## Phase 1: 分析与验证 ### 1.1 获取与分析 ```bash gh issue list --limit 100 --state open \ --json number,title,body,labels,state,author,createdAt,comments \ > /tmp/hotplex_issues.json ``` 对每个 issue 检查四个维度： - **完整性** — 能否根据描述实施？（清晰问题陈述、复现步骤/验收标准） - **有效性** — 是真正的 issue 还是模糊不清？ - **重复性** — 搜索关键词，是否已被报告或修复？ - **技术可行性** — 是否符合现有架构？有无阻塞性依赖？ ### 1.2 标签与关闭（Admin 专属） 标签体系（6 类 40+ 个标签，含 P0-P3 优先级、18 个模块标签、领域/状态/辅助/关闭原因）、关闭无效 issue 的完整流程见 `references/label-taxonomy.md`。 ### 1.3 呈现阶段结果 输出 `/tmp/issue_analysis.md`，向用户呈现： - 总数统计：分类标签数、关闭无效数、剩余有效数 - **按模块/领域分组**的 issue 概览 - 发现的重复、无效、已修复 issue 等用户确认后进入 Phase 2。 ## Phase 2: ROI 评分 ### 2.1 评分公式 三个维度（1-10）： **影响力 (I)**：10=关键bug/安全/数据丢失，7-8=高影响bug/重大功能，5-6=可感知改进，3-4=小幅，1-2=锦上添花 **紧急度 (U)**：10=生产故障/阻塞发布，7-8=每日影响，5-6=应尽快修，3-4=有空就修，1-2=无截止日期 **工作量 (E)**（反向 — 越高越容易）：10=琐碎1-2h，7-8=容易半天，5-6=中等1-2天，3-4=困难3-5天，1-2=极难1+周 ``` ROI = (I × U × E) / 10 最大值 = 100 ``` ### 2.2 优先级与依赖 | 优先级 | ROI 范围 | 标签 | |--------|----------|------| | P0 | ≥ 80 | `P0`（紧急：生产故障/数据丢失/安全漏洞） | | P1 | 50-79 | `P1`（关键：阻塞功能/每日影响） | | P2 | 30-49 | `P2`（高：应尽快修） | | P3 | 15-29 | `P3`（中：有空就修） | 检查 issue body 中的 `#XX` 引用识别依赖。被未解决依赖