@dtt_siye/atool 1.1.0

package/skills/code-review/rules/architecture.md

@@ -0,0 +1,285 @@
+# 架构合规检测规则（第 5 维度）
+
+本维度评估代码的架构合规性：分层是否正确、依赖方向是否合理、领域模型是否合规、微服务边界是否清晰。
+
+## 前置依赖
+
+本维度需要以下数据：
+1. 源码文件 — 分层、DDD、微服务、包结构检测
+2. `knowledge-graph.json` — Phase 3 生成的全局知识图谱（可选，用于耦合分析）
+3. `multi-dimensional-analysis.json`（可选，project-analyze v5.0 Phase 3a 输出）
+
+> **深度架构评审：** 如本维度发现重度违反（评分 < 40），建议运行 `/software-architecture` skill 进行系统级架构评审。
+> **栈级规范：** 分层规则应与对应 `{stack}-conventions` skill 的分层定义保持一致（如 `java-conventions` 的 Controller/Service/Repository 分层、`web-conventions` 的组件分层）。
+
+## 1. 分层违反检测
+
+### 1.1 Java/Spring 分层规则
+
+扫描所有源文件的 import 语句，检查层间依赖是否合规：
+
+| 层 | 允许依赖 | 禁止依赖 |
+|----|----------|----------|
+| Controller (`*Controller.java`) | Service, DTO, VO, RequestBody, PathVariable | Repository, Entity, Mapper, Dao |
+| Service (`*Service.java`, `*ServiceImpl.java`) | Repository, Entity, DTO, VO, 其他 Service | Controller |
+| Repository (`*Repository.java`, `*Mapper.java`, `*Dao.java`) | Entity, Model | Service, Controller |
+| Entity / Model (`*Entity.java`, `*DO.java`) | 无（纯数据类） | Service, Repository, Controller |
+| DTO / VO (`*DTO.java`, `*VO.java`, `*Request.java`) | 无（纯数据类） | Service, Repository |
+| Config (`*Config.java`, `*Configuration.java`) | Service, Repository（通过注入） | — |
+| Common / Utils | 无 | 业务模块的 Service/Repository |
+
+### 1.2 检测方法
+
+逐文件扫描 import 语句：
+
+```
+# 检查 Controller 是否直接引用 Repository/DAO
+grep -E '^import.*\.(Mapper|Repository|Dao|MapperImpl)' *Controller.java
+
+# 检查 Entity 是否引用 Service
+grep -E '^import.*\.(Service|ServiceImpl)' *Entity.java *DO.java
+
+# 检查 Service 是否引用 Controller
+grep -E '^import.*\.Controller' *Service.java *ServiceImpl.java
+```
+
+### 1.3 严重度定义
+
+| 严重度 | 条件 | 示例 |
+|--------|------|------|
+| Critical | Controller 直接操作数据库层 | `UserController` import `UserMapper` |
+| Warning | 跨层不合理的依赖 | `Entity` 包含业务逻辑方法 |
+| Info | 建议改进的分层模式 | Service 层缺少 DTO 转换，直接返回 Entity |
+
+### 1.4 白名单（排除误报）
+
+以下场景属于合理的跨层访问，不计为违规：
+- `@ControllerAdvice` + `@ExceptionHandler` — 全局异常处理可访问 Service
+- `@Configuration` 类 — 通过 `@Bean` 注入任意组件
+- `*SecurityConfig.java` — 安全配置可注入 `UserDetailsService` 等
+- `*Actuator*.java`, `*HealthCheck*.java` — 监控端点
+- Test 类（`src/test/` 下的文件）— 测试可访问任意层
+- `*Application.java`（启动类）— 可包含 `@Bean` 定义
+
+## 2. DDD 合规检测
+
+**适用条件**：项目使用 DDD 相关包结构（`domain/`、`application/`、`infrastructure/`、`interfaces/`）或 pom.xml 包含 DDD 框架依赖（如 Axon、lagom）。
+
+### 2.1 检测项
+
+| 检测项 | 严重度 | 判定标准 |
+|--------|--------|----------|
+| 聚合根无专属 Repository | Critical | Entity 类无对应的 Repository/Mapper 接口 |
+| 领域服务依赖基础设施层 | Critical | `domain/service/` 下的类 import `infrastructure/` 下的类 |
+| 值对象包含 ID 字段 | Warning | 值对象类（如 Address、Money）有 `@Id` 或 `id` 字段 |
+| 领域事件未在聚合内发布 | Warning | 领域事件类存在但无发布代码 |
+| 应用服务包含业务逻辑 | Warning | `application/service/` 下的类包含 if/for 等业务判断 |
+| 限界上下文边界泄露 | Critical | 一个 bounded context 的领域模型被另一个直接引用 |
+| 聚合边界过大 | Info | 单个聚合根包含 >10 个实体或 >20 个方法 |
+
+### 2.2 聚合根识别
+
+扫描以下特征识别聚合根：
+- `@AggregateRoot` 注解（Axon）
+- `@Entity` 注解 + 有独立的 Repository
+- 类名包含 `Aggregate` 后缀
+- 包含领域事件发布方法（`apply()`, `registerEvent()`）
+
+### 2.3 值对象识别
+
+扫描以下特征识别值对象：
+- 无 `@Id` 注解
+- 所有字段为 final（Java）/ val（Kotlin）
+- 实现 `equals()` 和 `hashCode()` 基于所有字段
+- 无独立 Repository
+
+## 3. 微服务适应性检测
+
+**适用条件**：项目包含 Spring Cloud、Dubbo、gRPC 等微服务框架依赖，或 pom.xml 的 `<modules>` 包含 3+ 个独立服务模块。
+
+### 3.1 检测项
+
+| 检测项 | 严重度 | 判定标准 |
+|--------|--------|----------|
+| 共享数据库 | Critical | 多个服务模块的 application.yml 指向同一数据库 URL |
+| 跨服务直接数据访问 | Critical | 服务 A 的 Mapper/Repository 直接查询服务 B 的表 |
+| 共享业务逻辑库 | Warning | common 模块包含非工具类的业务逻辑（如 `*Service.java`） |
+| 同步链式调用过深 | Warning | Feign/HTTP 调用链 >3 层（A→B→C→D） |
+| 服务无法独立部署 | Critical | 模块间存在编译期依赖（非 API 依赖），无法独立打包 |
+| API 网关仅做路由 | Info | Gateway 模块无聚合、限流、认证等能力 |
+| 缺少服务发现 | Info | 微服务项目无 Nacos/Eureka/Consul 配置 |
+| 缺少熔断/限流 | Info | 无 Sentinel/Resilience4j/Hystrix 配置 |
+
+### 3.2 共享数据库检测方法
+
+```
+# 提取所有模块的数据库 URL
+grep -r 'spring.datasource.url' */src/main/resources/*.yml
+# 或
+grep -r 'jdbc:' */src/main/resources/*.yml
+
+# 如果多个模块指向同一 host:port/database → 共享数据库
+```
+
+### 3.3 跨服务直接数据访问检测
+
+```
+# 检查 ark-modules/ 下的 Mapper XML 是否包含其他服务领域表
+# 如 lead 服务中有 dealer 相关的 SQL
+
+# 检查 import 语句是否引用其他模块的 Entity
+grep -r 'import com.ftms.scrm.dealer.entity' ark-modules/ark-lead/
+```
+
+### 3.4 Feign 调用链深度检测
+
+扫描所有 `@FeignClient` 接口及其实现，构建调用图：
+- 深度 1-2：正常
+- 深度 3：Warning（建议引入异步解耦）
+- 深度 4+：Critical（强耦合，应重构）
+
+## 4. 包结构分析
+
+### 4.1 组织模式识别
+
+| 模式 | 特征 | 评估 |
+|------|------|------|
+| 按层分包 | `controller/`, `service/`, `dao/` 各一个包 | 传统模式，模块边界不清晰 |
+| 按功能分包 | `user/`, `order/`, `product/` 各含完整分层 | DDD 友好，模块边界清晰 |
+| 混合模式 | 顶层按功能，内层按分层 | 推荐模式 |
+
+### 4.2 健康度检测
+
+| 检测项 | 严重度 | 阈值 |
+|--------|--------|------|
+| 大泥球 | Warning | 单个包内 >50 个 .java 文件 |
+| 循环依赖 | Critical | 包 A import 包 B，包 B 也 import 包 A |
+| 包层次过深 | Info | 包路径 >6 层（如 `com.a.b.c.d.e.f.Class`） |
+| 空包 | Info | 存在无 .java 文件的包目录 |
+| 命名不规范 | Info | 包名含大写字母、下划线、特殊字符 |
+
+## 5. 依赖方向验证
+
+### 5.1 规则
+
+- 上层依赖下层：Controller → Service → Repository → Entity
+- 不允许反向依赖
+- 公共模块（common, utils, core）不应依赖业务模块
+- API 模块（仅含接口和 DTO）不应依赖实现模块
+
+### 5.2 检测方法
+
+从所有 pom.xml 的 `<dependencies>` 提取模块间依赖，构建有向图：
+- 检查是否存在环（循环依赖）
+- 检查 common 模块是否依赖业务模块
+- 检查 API 模块是否依赖实现模块
+
+### 5.3 输出
+
+```
+模块依赖方向图：
+┌─────────┐     ┌──────────┐     ┌───────────┐
+│ ark-bff  │────→│ark-modules│────→│ark-common │
+└─────────┘     └──────────┘     └───────────┘
+     │               │
+     ↓               ↓
+┌─────────┐     ┌──────────┐
+│ark-gateway│    │ ark-api   │
+└─────────┘     └──────────┘
+
+违反项：
+- ❌ ark-common 依赖 ark-modules (common 不应依赖业务模块)
+```
+
+## 评分算法
+
+```
+# 分数计算（0-100，越高越差）
+architecture_score = min(weighted_issues / normalization * 100, 100)
+
+# 权重
+Critical: 20 points each
+Warning:  8 points each
+Info:     2 points each
+
+# 标准化因子
+normalization = max(total_modules, 1) * 10
+
+# 示例
+# 5 个模块的项目：
+# 2 Critical + 3 Warning + 5 Info = 2*20 + 3*8 + 5*2 = 74
+# normalization = 5 * 10 = 50
+# score = min(74 / 50 * 100, 100) = 100 → 封顶 100
+```
+
+## 报告格式
+
+### 分层违反
+
+| Severity | File | Layer | Violation | Suggestion |
+|----------|------|-------|-----------|------------|
+| Critical | UserController.java | Controller | import UserMapper | 通过 UserService 间接访问 |
+| Warning | OrderEntity.java | Entity | 包含 calculatePrice() 业务方法 | 移至 OrderDomainService |
+
+### 微服务适应性
+
+| 检测项 | 状态 | 详情 | 建议 |
+|--------|------|------|------|
+| 独立数据库 | ❌ | 3 个服务共享同一 MySQL 实例 | 按服务边界拆分数据库 |
+| 同步耦合 | ⚠️ | Feign 调用链最深 3 层 | 引入 MQ 异步解耦 |
+| 共享业务库 | ❌ | ark-common 含 LeadService | 提取为独立微服务或保留为纯工具库 |
+
+### 包结构
+
+| 检测项 | 状态 | 详情 |
+|--------|------|------|
+| 组织模式 | ⚠️ | 按层分包，建议迁移为按功能分包 |
+| 大泥球 | ✅ | 最大包含 23 个类 |
+| 循环依赖 | ✅ | 未检测到 |
+
+### 重构建议
+
+对每个 Critical/Warning 问题，提供具体重构方案：
+
+1. **重构名称**
+   - 当前状态：问题描述
+   - 目标状态：期望结果
+   - 影响范围：涉及文件列表
+   - 步骤：
+     1. 具体操作步骤 1
+     2. 具体操作步骤 2
+     3. 具体操作步骤 3
+   - 预计工作量：S（<1天）/ M（1-3天）/ L（>3天）
+
+## 6. 知识图谱驱动的耦合分析（v3.0 新增）
+
+**适用条件**：Phase 3 生成的 `knowledge-graph.json` 存在。
+
+当知识图谱可用时，从图谱中提取耦合数据辅助架构合规分析：
+
+- **模块依赖边** → `depends_on` 类型的边用于分层违反检测
+- **循环依赖** → 知识图谱中的 `circular_dependencies` 用于严重度评估
+- **耦合度指标** → `metrics.avg_coupling` 和 `metrics.max_coupling_module` 用于定位问题模块
+
+**集成方式：**
+```
+# 优先使用知识图谱数据
+if knowledge_graph exists:
+    module_coupling = graph.metrics.per_module(module_slug)
+    module_cycles = graph.metrics.circular_dependencies
+else:
+    # 回退到 import 扫描方式（当前逻辑）
+    module_coupling = scan_imports(module_files)
+```
+
+### 6.2 多维分析层违反数据（v5.0 增强）
+
+当 `multi-dimensional-analysis.json` 存在时（project-analyze v5.0 Phase 3a 输出），架构合规分析可利用以下预计算数据：
+
+- `structural.layer_violation_ratio` — 层违反率（0-1，越低越好）
+- `structural.total_cross_layer_edges` — 跨层依赖总数
+- `structural.god_modules` — 上帝模块数量
+- `structural.unstable_cores` — 不稳定核心模块列表
+- `structural.layer_distribution` — 各层节点分布
+
+**使用方式**：如果 `.atool-docs/multi-dimensional-analysis.json` 存在，优先使用其 `structural` 维度数据进行架构层分析，提供更精确的层违反检测。配合 `knowledge-graph.json` 的 `layers.detected` 字段确定层分配。

package/skills/code-review/rules/coupling-cohesion.md

@@ -0,0 +1,309 @@
+---
+name: coupling-cohesion
+dimension: coupling-cohesion
+weight: 0.10
+---
+
+> **栈级规范：** 模块边界和依赖管理约定参考对应 `{stack}-conventions` skill。重度耦合问题建议运行 `/software-architecture` skill 评审。
+
+# 耦合与内聚分析规则（知识图谱驱动）
+
+本维度基于知识图谱的模块依赖关系，计算耦合度、内聚度和稳定性指标。需要 Phase 3 生成的 `knowledge-graph.json` 作为输入。
+
+## 前置依赖
+
+本维度需要以下数据：
+1. `knowledge-graph.json` — Phase 3 生成的全局知识图谱
+2. 模块级 inventory 数据 — Phase 1 生成的 `{module-slug}.json`
+3. `knowledge-graph.json v5.0`（可选，提供预计算 CK Metrics）
+
+如果知识图谱不存在，本维度跳过并标记为 "skipped (no graph data)"。
+
+## 1. 耦合度分析
+
+### 1.1 Afferent Coupling (Ca) — 被依赖度
+
+模块被其他模块依赖（import/调用）的数量：
+
+```
+Ca(M) = count(unique modules that depend on M)
+
+# 从 knowledge-graph.json 计算
+Ca(M) = count(edges where target == "mod:{M}" and type == "depends_on")
+```
+
+**评估：**
+- Ca 高 → 模块是基础设施/核心库，修改需谨慎（影响面大）
+- Ca = 0 → 模块是孤立的，可能是不使用的代码或入口模块
+
+### 1.2 Efferent Coupling (Ce) — 依赖度
+
+模块依赖（import/调用）其他模块的数量：
+
+```
+Ce(M) = count(unique modules that M depends on)
+
+# 从 knowledge-graph.json 计算
+Ce(M) = count(edges where source == "mod:{M}" and type == "depends_on")
+```
+
+**评估：**
+- Ce 高 → 模块是"枢纽"，依赖过多外部模块，难以独立测试和复用
+- Ce = 0 → 模块是完全独立的
+
+### 1.3 Instability (I) — 不稳定性
+
+```
+I(M) = Ce(M) / (Ce(M) + Ca(M))
+
+# 特殊情况
+如果 Ce(M) + Ca(M) == 0: I(M) = 0.5 (无依赖信息)
+```
+
+**评估：**
+- I 接近 1 → 模块是不稳定的（大量外部依赖，被少量模块使用）
+- I 接近 0 → 模块是稳定的（被大量模块依赖，自身依赖少）
+- **主序列（Main Sequence）**: 理想情况下 I 和 Abstractness (A) 应满足 A + I = 1
+
+### 1.4 Abstractness (A) — 抽象度（OO 项目适用）
+
+```
+A(M) = abstract_classes(M) / total_classes(M)
+
+# 抽象类识别
+abstract_classes: 含 abstract 关键字的类、interface、protocol、trait
+total_classes: 所有类/接口/协议/特征的总和
+```
+
+**主序列距离：**
+```
+D(M) = |A(M) + I(M) - 1|
+
+D 接近 0 → 模块在主序列上（良好平衡）
+D 接近 1 → 模块远离主序列（设计问题）
+```
+
+### 1.5 耦合健康度评估
+
+| 指标 | 严重度 | 阈值 |
+|------|--------|------|
+| 过高出度 (Ce) | Critical | Ce > 15（过度依赖，高度耦合） |
+| 过高出度 (Ce) | Warning | Ce > 10 |
+| 零出入度 (Ca=Ce=0) | Warning | 孤立模块（可能的死代码或缺失关联） |
+| 主序列距离 | Warning | D > 0.7（抽象/稳定失衡） |
+| 主序列距离 | Info | D > 0.5 |
+
+## 2. 内聚度分析
+
+### 2.1 模块内聚度（基于知识图谱）
+
+从知识图谱中的函数级和组件级节点计算：
+
+```
+# 模块内函数/组件间的内部连接
+internal_edges(M) = count(edges where source ∈ M and target ∈ M)
+
+# 模块对外连接
+external_edges(M) = count(edges where (source ∈ M and target ∉ M) or (source ∉ M and target ∈ M))
+
+# 内聚比
+cohesion_ratio(M) = internal_edges(M) / max(internal_edges(M) + external_edges(M), 1)
+```
+
+**评估：**
+- cohesion_ratio > 0.7 → 高内聚（良好）
+- cohesion_ratio 0.3-0.7 → 中等内聚
+- cohesion_ratio < 0.3 → 低内聚（模块职责不明确）
+
+### 2.2 Lack of Cohesion in Methods (LCOM) — 类级内聚度
+
+**适用条件**：OO 语言项目（Java, Kotlin, C#, Swift, Dart）。
+
+```
+# LCOM4 方法（推荐）
+# 两个方法如果在类的同一实例变量上操作，则它们是相连的
+# LCOM4 = 方法图中连通分量的数量
+
+LCOM4 = count(connected_components in method_access_graph)
+
+# 评估
+LCOM4 = 1   → 完美内聚（所有方法共享数据）
+LCOM4 = 2-3 → 可接受（可能需要拆分）
+LCOM4 > 3   → 低内聚（建议拆分类）
+```
+
+### 2.3 内聚健康度评估
+
+| 指标 | 严重度 | 阈值 |
+|------|--------|------|
+| LCOM4 > 5 | Critical | 类职责过多，强烈建议拆分 |
+| LCOM4 > 3 | Warning | 类可能有多个职责 |
+| cohesion_ratio < 0.2 | Critical | 模块严重缺乏内聚 |
+| cohesion_ratio < 0.3 | Warning | 模块内聚不足 |
+
+## 3. 循环依赖检测
+
+### 3.1 检测方法
+
+从 knowledge-graph.json 的 `edges` 中提取模块级 `depends_on` 边，构建有向图，使用 DFS 检测环：
+
+```
+# 检测所有强连通分量（SCC）
+# SCC 大小 > 1 的即为循环依赖
+
+循环依赖链示例：
+Module A → Module B → Module C → Module A
+```
+
+### 3.2 严重度
+
+| 循环类型 | 严重度 | 说明 |
+|----------|--------|------|
+| 直接循环 (A→B→A) | Critical | 最严重的耦合问题 |
+| 间接循环 (A→B→C→A) | Critical | 三方及以上循环 |
+| 自引用 (A→A) | Warning | 模块内部循环依赖 |
+| 长链循环 (>4 个模块) | Info | 循环路径长，可能间接影响 |
+
+### 3.3 循环依赖影响分析
+
+对每个检测到的循环，分析：
+1. **影响范围** — 循环涉及的模块及其 Ca 值（被依赖的模块在循环中更危险）
+2. **破坏方式** — 建议引入接口/事件/中介者来打破循环
+3. **风险等级** — 高 Ca 模块在循环中 = 高风险
+
+## 4. CK Metrics（Chidamber-Kemerer，OO 项目适用）
+
+**适用条件**：OO 语言项目（Java, Kotlin, C#, Swift, Dart, Python with classes）。
+
+### 4.1 指标定义
+
+| 指标 | 全称 | 含义 | 检测方法 |
+|------|------|------|----------|
+| WMC | Weighted Methods per Class | 类中方法的复杂度之和 | 统计类中每个方法的 CC 值求和 |
+| DIT | Depth of Inheritance Tree | 继承树深度 | 统计 extends/implements 链长度 |
+| NOC | Number of Children | 直接子类数量 | 统计 extends/继承该类的子类 |
+| CBO | Coupling Between Objects | 耦合对象数 | 统计类中引用的其他类数量（非基础类型） |
+| RFC | Response for a Class | 类的响应集大小 | 统计类的方法 + 被方法调用的外部方法数 |
+| LCOM | Lack of Cohesion in Methods | 方法内聚度缺失 | 见 2.2 LCOM4 |
+
+### 4.2 阈值
+
+| 指标 | Critical | Warning | Info |
+|------|----------|---------|------|
+| WMC | >100 | >50 | >30 |
+| DIT | >6 | >4 | >3 |
+| NOC | >20 | >10 | >5 |
+| CBO | >20 | >10 | >5 |
+| RFC | >100 | >50 | >30 |
+| LCOM | >5 | >3 | >2 |
+
+### 4.1 知识图谱 v5.0 CK 度量数据（增强）
+
+当 `knowledge-graph.json` 由 project-analyze v5.0 生成时，CK Metrics 已由 `lib/knowledge-graph.sh` 的 `compute_ck_metrics()` 预计算并嵌入节点 metrics 中：
+
+- `metrics.WMC` — Weighted Methods per Class
+- `metrics.DIT` — Depth of Inheritance Tree  
+- `metrics.NOC` — Number of Children
+- `metrics.CBO` — Coupling Between Objects
+- `metrics.RFC` — Response For Class
+- `metrics.LCOM` — Lack of Cohesion in Methods
+
+**使用方式**：如果 `.atool-docs/knowledge-graph.json` 存在且 `version >= "5.0"`，直接从节点 metrics 读取 CK 值，无需手动计算。同时 `multi-dimensional-analysis.json` 的 `quality.coupling_index` 提供了复合耦合指数 CI(M) 的预计算结果。
+
+## 5. Dependency Structure Matrix (DSM)
+
+### 5.1 矩阵生成
+
+从知识图谱生成模块依赖矩阵：
+
+```
+        ┌─────┬──────┬──────┬──────┬──────┐
+        │ mod │ auth │ user │ order│ util │
+        ├─────┼──────┼──────┼──────┼──────┤
+  auth  │  -  │  -   │  1   │  0   │  2   │
+  user  │  0  │  2   │  -   │  1   │  3   │
+  order │  0  │  1   │  2   │  -   │  1   │
+  util  │  0  │  0   │  0   │  0   │  -   │
+        └─────┴──────┴──────┴──────┴──────┘
+
+行 = 依赖方（source）
+列 = 被依赖方（target）
+值 = 依赖的符号数量
+```
+
+### 5.2 DSM 分析
+
+- **对角线附近集中** → 模块化良好
+- **右上三角非零** → 可能存在反向依赖（与分层方向相反）
+- **整行/整列密集** → 过度耦合的模块
+
+## 评分算法
+
+```
+coupling_score = 0
+
+# 耦合问题
+for each module with Ce > 15:  coupling_score += 20  # Critical
+for each module with Ce > 10:  coupling_score += 8   # Warning
+for each isolated module:      coupling_score += 8   # Warning
+
+# 循环依赖
+for each direct cycle:    coupling_score += 20  # Critical
+for each indirect cycle:  coupling_score += 20  # Critical
+for each self-reference:  coupling_score += 8   # Warning
+
+# 内聚问题
+for each module with cohesion_ratio < 0.2: coupling_score += 20  # Critical
+for each module with cohesion_ratio < 0.3: coupling_score += 8   # Warning
+
+# CK metrics (OO only)
+for each class with WMC > 100: coupling_score += 15
+for each class with CBO > 20:  coupling_score += 15
+for each class with DIT > 6:   coupling_score += 10
+
+# 主序列距离惩罚
+for each module with D > 0.7: coupling_score += 8
+for each module with D > 0.5: coupling_score += 2
+
+# 标准化
+normalized = min(coupling_score / max(total_modules * 5, 1), 100)
+```
+
+## 报告章节模板
+
+```markdown
+### 耦合与内聚 (Score: {score}/100)
+
+**平均耦合度:** Ca={avg_ca}, Ce={avg_ce}
+**平均内聚比:** {avg_cohesion}
+**循环依赖:** {cycle_count} 个
+**主序列平均距离:** {avg_distance}
+
+#### 模块耦合矩阵
+
+{DSM matrix}
+
+#### 循环依赖
+
+| 循环路径 | 涉及模块数 | 影响范围 | 破坏建议 |
+|----------|-----------|---------|---------|
+| auth → user → auth | 2 | 高（auth Ca=12） | 引入 AuthInterface |
+
+#### 高耦合模块
+
+| 模块 | Ce | Ca | I | D | 建议 |
+|------|-----|-----|---|---|------|
+| order | 15 | 3 | 0.83 | 0.72 | 拆分为 order-core 和 order-integration |
+
+#### 低内聚模块
+
+| 模块 | cohesion_ratio | internal_edges | external_edges | 建议 |
+|------|---------------|----------------|----------------|------|
+| utils | 0.15 | 3 | 17 | 按职责拆分为多个子模块 |
+
+#### CK Metrics 告警（OO 项目）
+
+| 类 | WMC | DIT | CBO | RFC | LCOM | 问题 |
+|----|-----|-----|-----|-----|------|------|
+| OrderService | 87 | 2 | 18 | 95 | 4 | CBO 过高，建议拆分 |
+```