@haaaiawd/anws 1.2.4 → 2.0.0

package/templates/.agent/skills/git-forensics/references/ANALYSIS_METHODOLOGY.md

@@ -1,193 +0,0 @@
-# Git Forensics 分析方法论
-
-## 概述
-
-Git Forensics 的核心价值不仅是数据抓取，更重要的是**分析**和**可操作建议**。本文档定义了分析的方法论和决策规则。
-
-## 核心指标
-
-### 1. 共改频率 (Co-change Frequency)
-
-**定义**：
-```
-frequency = 共改次数 / 目标文件总提交次数
-```
-
-**风险等级判定**：
-
-| 频率范围 | 风险等级 | 标记 | 解读 |
-|---|---|---|---|
-| ≥ 0.70 | 🔴 HIGH | `HIGH_COUPLING` | 强逻辑耦合，修改一个必须考虑另一个 |
-| 0.40 - 0.69 | 🟡 MEDIUM | `MEDIUM_COUPLING` | 中等耦合，建议关注 |
-| < 0.40 | 🟢 LOW | (无标记) | 偶发性共改，可能是巧合 |
-
-### 2. 文件类型分类
-
-不同类型的文件有不同的耦合性质：
-
-| 类型 | 匹配模式 | 耦合性质 | 处理方式 |
-|---|---|---|---|
-| 测试文件 | `*test*`, `*spec*`, `__tests__/` | ✅ 合理耦合 | 正常，测试应跟随代码变化 |
-| 配置文件 | `*config*`, `.env*`, `*.yaml`, `*.json` | ⚠️ 需警惕 | 可能存在硬编码或配置管理问题 |
-| 文档文件 | `*.md`, `README*`, `CHANGELOG*` | ✅ 合理耦合 | 正常，文档应随代码更新 |
-| 生产代码 | 其他 | ❓ 需深入分析 | 高频率 + 无物理依赖 = 隐性耦合 |
-
-### 3. 时间衰减因素
-
-近期的共改比远期的更有参考价值：
-
-| 时间范围 | 权重建议 | 说明 |
-|---|---|---|
-| 最近 30 天 | 1.5x | 最近的修改模式更能反映当前状态 |
-| 30-90 天 | 1.0x | 标准权重 |
-| 90-180 天 | 0.7x | 历史参考，权重降低 |
-| > 180 天 | 0.5x | 仅作参考 |
-
-**注意**：当前脚本实现尚未包含时间衰减，作为后续优化项。
-
----
-
-## 分析建议生成规则
-
-### 规则 1：高频生产代码耦合
-
-**条件**：
-- 两个生产代码文件
-- 共改频率 ≥ 0.70
-- 无物理依赖（即 A 不 import B）
-
-**建议**：
-- "考虑将 A 和 B 合并为同一模块"
-- "或者提取公共接口，明确依赖关系"
-- "检查是否存在隐性的数据依赖"
-
-### 规则 2：跨模块高频耦合
-
-**条件**：
-- 两个文件属于不同目录/模块
-- 共改频率 ≥ 0.50
-
-**建议**：
-- "可能需要重新划分模块边界"
-- "考虑使用事件/消息解耦"
-- "评估是否应该合并为同一模块"
-
-### 规则 3：配置文件高频耦合
-
-**条件**：
-- 生产代码与配置文件共改频率 ≥ 0.30
-
-**建议**：
-- "检查是否存在硬编码的配置值"
-- "考虑使用环境变量或配置中心"
-- "评估配置管理策略"
-
-### 规则 4：测试覆盖率信号
-
-**条件**：
-- 生产代码没有对应的测试文件共改
-- 或测试文件共改频率 < 0.30
-
-**建议**：
-- "该文件可能缺少测试覆盖"
-- "修改时未同步更新测试可能有风险"
-
-### 规则 5：单点责任人风险
-
-**条件**：
-- 某个文件 80% 以上的修改来自同一作者
-
-**建议**：
-- "存在知识单点风险"
-- "建议进行知识转移或代码评审"
-
----
-
-## 输出结构
-
-### 标准输出字段
-
-```json
-{
-  "target_file": "分析的目标文件",
-  "analysis_period_days": 180,
-  "total_commits_modifying_target": 25,
-  "co_changed_files": [
-    {
-      "file": "共改文件路径",
-      "co_change_count": 20,
-      "frequency": 0.80,
-      "warning": "HIGH_COUPLING|MEDIUM_COUPLING",
-      "category": "PRODUCTION|TEST_FILE|CONFIG_FILE|DOC_FILE"
-    }
-  ],
-  "last_modified_date": "2024-12-20",
-  "primary_authors": ["Alice", "Bob"],
-  "analysis": {
-    "high_risk_files": ["高风险文件列表"],
-    "recommendations": ["可操作的建议列表"]
-  }
-}
-```
-
-### 建议的格式
-
-建议应该是**可操作的**，而不是泛泛的描述：
-
-✅ **好的建议**：
-- "考虑将 `login.ts` 和 `session.ts` 合并，因为它们在 80% 的提交中一起修改"
-- "文件 `config.ts` 与多个生产代码共改，检查是否应该使用环境变量"
-
-❌ **差的建议**：
-- "存在耦合"（太模糊）
-- "需要注意"（没有行动指导）
-
----
-
-## 边界情况处理
-
-### 大规模重构 Commit
-
-**问题**：一次重构可能修改几十个文件，干扰分析。
-
-**解决方案**：
-- 识别修改文件数 > 20 的 commit
-- 可选择忽略这类 commit
-- 或降低其权重
-
-**当前实现**：未处理，作为后续优化项。
-
-### 新文件
-
-**问题**：新创建的文件历史太短。
-
-**解决方案**：
-- 如果文件存在时间 < 30 天，标记分析结果为"数据不足"
-- 建议等待更多历史数据
-
-### 删除的文件
-
-**问题**：历史中引用了已删除的文件。
-
-**解决方案**：
-- 在输出中标记 `[DELETED]`
-- 仍然报告历史耦合关系
-
----
-
-## 与其他 Skills 的配合
-
-1. **与 `build-inspector` 对比**：
-   - build-inspector 提供构建边界和版本漂移风险
-   - git-forensics 提供逻辑耦合
-   - 两者交叉 = 跨构建根的耦合（最高风险）
-
-2. **与 `runtime-inspector` 结合**：
-   - 在高耦合文件中检查 IPC 相关代码
-   - 这些文件的协议漂移风险更高
-
-3. **输出给 Scout 功能冲突分析**：
-   - 高风险文件列表
-   - 生成的建议
-   - 耦合关系图数据
-