report-format

完整报告模板（范围较大或用户要"完整报告"时用）

范围小用 SKILL.md 里的精简版即可。下面是全量审计的结构化报告。

## 架构审查报告

### 📊 审查概览

| 维度 | 通过 | 警告 | 违规 |
|-----|------|------|------|
| 概念建模 | X | X | X |
| 职责划分 | X | X | X |
| 机制/策略分离 | X | X | X |
| 因果与不变量 | X | X | X |
| 属性建模 | X | X | X |
| 模块化 | X | X | X |
| SOLID | X | X | X |
| GRASP | X | X | X |
| YAGNI | X | X | X |

总体健康度：X/100
（已滤除 M 个低置信/假阳性 finding）

---

### 🏗️ 概念与结构

#### 概念地图 (Concept Map)
├── [概念A] - 定义清晰 ✅  位置: src/domain/conceptA/  职责: <一句话>
├── [概念B] - 边界模糊 ⚠️  位置: 散落在 src/services/, src/utils/  问题: 概念碎片化
└── [概念C] - 缺失 ❌      业务需要但代码中没有对应实体

#### 目录结构评估
当前结构 → 问题标注（✅职责清晰 / ⚠️过大混合 / ❌垃圾堆）
建议结构 → 按领域/分层重组方案

#### 依赖关系图
A → B → C ✅ 单向依赖
D ↔ E ❌ 循环依赖（必须基于工具验证，不能臆测）
F → (interface) ← G ✅ 依赖倒置

---

### 🔴 严重问题（必须修复，置信度 ≥80）
#### [问题类型] - `path/to/file:line`
- 问题：<具体描述>
- 影响：<对可维护性/扩展性/正确性的实质影响>
- 修复：<具体步骤>

### 🟡 警告（建议修复）
...

### 🟢 改进建议（打磨项）
...

### ✅ 良好实践
<值得借鉴的代码示例，1-2 条即可，不堆砌>

---

### 📋 重构路线图（--plan 时转成客户端任务清单或 Markdown checklist）

#### Phase 1: 概念澄清（优先）
| 任务 | 目标 | 工作量 |
| 识别并命名缺失概念 | 建立统一语言 | S |
| 合并碎片化概念 | 提高内聚 | M |

#### Phase 2: 结构重组
| 按领域重组目录 | 清晰边界 | L |
| 清理 utils 垃圾堆 | 消除混乱 | M |

#### Phase 3: 依赖治理
| 消除循环依赖 | 解耦 | M |
| 引入依赖倒置 | 可测试性 | L |

审查优先级（健康度打分与排序依据）

1. 概念是否正确识别和命名 ← 最重要
2. 概念之间的关系是否合理（实体关系）
3. 职责划分是否清晰（数据 + 行为同位）
4. 机制与策略是否分离（稳定层 vs 易变层）
5. 因果关系是否显式（single-writer、不变量、传播路径）
6. 属性建模是否准确（identity/value/derived 分类）
7. 目录结构是否反映概念边界
8. 模块是否高内聚低耦合
9. 文件是否符合大小限制
10. 代码是否遵循 SOLID/GRASP/YAGNI

模式识别清单（扫描这些代码异味）

• 上帝类/模块
• 概念混乱 / 概念碎片化
• 依赖混乱 / 循环依赖
• 过度抽象 ↔ 抽象不足
• 贫血模型
• 魔法状态 / 多写者
• derived 缓存无 invalidation