hotplex-arch-analyzer

# 架构深度分析器 ## 工作流概览 每次调用 = **一个分析周期**在**一个模块**上覆盖**2-3 个方面**。专为 `/loop` 设计：`/loop 10m /hotplex-arch-analyzer`。深度分析在独立 subagent 中执行，主会话只处理 JSON 结果（上下文隔离）。状态持久化在 `.claude/arch-analysis/progress.json`，跨会话存活。 每次调用遵循两种模式之一，由**步骤 1.5（模式检测）**决定： **分析模式**（默认）： ``` 加载进度 → 选择模块 → 选择方面 → [Subagent 深度分析+分诊] → 去重检查 → 创建/更新 Issue → 更新进度 → 报告 ``` **审计模式**（open issues ≥ 阈值时激活）： ``` 加载进度 → 选择 Issue → [Subagent 验证代码] → 分类处理 → 更新进度 → 报告 ``` **为什么需要双模式**：分析模式持续发现新问题，但问题积累后会降低团队信任度和审查效率。审计模式定期清理存量 issue，关闭误报、更正偏差���保持 issue backlog 的健康。两个模式交替运行，既不停止分析，也不让 issue 失控。 ### 步骤 1：加载进度 读取 `.claude/arch-analysis/progress.json`。 **如果未找到** — 运行初始化： 1. 发现模块（见下面的模块发现） 2. 创建进度文件，所有模块的所有 aspects 待处理 3. 输出发现的模块列表 4. 继续到步骤 2 ### 步骤 1.5：模式检测 每次调用开始时，检查是否应该进入审计模式： ```bash # 获取当前 open architecture issues 数量 OPEN_COUNT=$(gh issue list --label "architecture" --state open --json number --limit 200 | python3 -c "import json,sys; print(len(json.load(sys.stdin)))") echo "Open architecture issues: $OPEN_COUNT" ``` **决策规则**（按优先级）： 1. **用户显式指定模式** → 遵循用户指令（如 "审计 issue"、"review issues"、"audit mode"） 2. **Open issues ≥ 30** → 进入**审计模式**，审计 3-5 个最旧的 issue 3. **Open issues < 30** → 继续**分析模式**（步骤 2-7） **审计与分析的交替**：当 open issues 在阈值附近波动时，审计和分析交替执行。每审计一轮后检查：如果 open issues 仍 ≥ 30 → 继续审计；否则切回分析模式。 **为什么阈值是 30**：经验表明，超过 30 个 open issues 时： - 团队审查负担过重，新 issue 被忽略的概率激增 - 存量 issue 中积累了足够多的误报和过时发现值得清理 - 清理 backlog 比创建新 issue 产生更大的实际价值 ### 步骤 2：选择目标模块 优先级（第一个匹配胜出）： 1. `analysis_count == 0` — 从未分析，最高优先级 2. 最低 `analysis_count...