@chongyan/autospec 1.0.2 → 1.0.4

package/knowledge/03-guides/40-detect-ai-anomaly.md

@@ -1,213 +0,0 @@
----
-name: ai-anomaly-analyzer
-description: AI 分析执行过程中的异常模式
-type: support
----
-
-## 定位
-
-实时分析执行日志，检测异常模式并生成智能建议，帮助快速定位和解决问题。
-
-## 输入
-
-- 必须输入：
-  - recentEvents: 最近 N 分钟的 trace 事件
-- 可选输入：
-  - currentStage: 当前阶段上下文
-  - historicalPatterns: 历史异常模式
-
-## 输出
-
-```json
-{
-  "anomalies": [
-    {
-      "type": "repeated_failures",
-      "severity": "high",
-      "pattern": "Layer1 测试连续失败 3 次",
-      "rootCause": "测试依赖的服务未启动",
-      "evidence": [
-        "Error: Connection refused to localhost:5432",
-        "所有失败都与数据库连接相关"
-      ],
-      "suggestion": "检查数据库服务是否启动，或配置 mock 服务",
-      "autoFixAvailable": false
-    }
-  ],
-  "summary": {
-    "totalAnomalies": 2,
-    "highSeverity": 1,
-    "mediumSeverity": 1,
-    "lowSeverity": 0
-  },
-  "recommendations": [
-    {
-      "priority": "immediate",
-      "action": "启动数据库服务或配置 mock",
-      "reason": "阻塞当前阶段进展"
-    }
-  ]
-}
-```
-
-## 异常模式类型
-
-### 1. 重复失败模式 (repeated_failures)
-
-**检测条件**：同一类型操作连续失败 >= 3 次
-
-**分析维度**：
-- 失败类型分布
-- 失败时间窗口
-- 共同错误特征
-
-**根因分析**：
-| 失败类型 | 可能根因 |
-|---------|---------|
-| 测试失败 | 依赖服务不可用、代码缺陷 |
-| 构建失败 | 依赖缺失、语法错误 |
-| Lint 失败 | 代码风格问题 |
-
-### 2. 长时间无产出 (no_artifact)
-
-**检测条件**：超过阈值时间（默认 10 分钟）无关键产物生成
-
-**分析维度**：
-- 当前阶段预期产物
-- 最近操作类型
-- 是否卡在某个步骤
-
-**建议**：
-- 检查是否需要人工决策
-- 检查是否有阻塞的操作
-
-### 3. 回退循环 (rollback_loop)
-
-**检测条件**：短时间内回退次数 >= 5 次
-
-**分析维度**：
-- 回退原因分布
-- 回退阶段分布
-- 是否在同一问题循环
-
-**建议**：
-- 可能需要升级人工
-- 可能需要重新设计方案
-
-### 4. 资源异常 (resource_anomaly)
-
-**检测条件**：Token 使用量异常高或操作频率异常
-
-**分析维度**：
-- Token 消耗趋势
-- 操作频率趋势
-- 是否存在无限循环
-
-### 5. 决策异常 (decision_anomaly)
-
-**检测条件**：人工介入率异常高或自动决策失败率高
-
-**分析维度**：
-- 决策类型分布
-- 人工介入原因
-- 自动决策失败原因
-
-## 严重程度定义
-
-| 级别 | 说明 | 响应要求 |
-|-----|------|---------|
-| **high** | 阻塞进度，需要立即处理 | 立即告警 |
-| **medium** | 影响效率，建议处理 | 记录并建议 |
-| **low** | 轻微问题，可忽略 | 仅记录 |
-
-## 执行步骤
-
-### Step 1: 收集最近事件
-
-```
-1. 获取最近 N 分钟（默认 5 分钟）的 trace 事件
-2. 过滤出关键事件类型
-3. 按时间排序
-```
-
-### Step 2: 检测重复失败
-
-```
-1. 统计各类型失败次数
-2. 分析失败时间窗口
-3. 提取共同错误特征
-4. 推断根因
-```
-
-### Step 3: 检测无产出
-
-```
-1. 确定当前阶段预期产物
-2. 检查最近产物生成时间
-3. 判断是否超时
-```
-
-### Step 4: 检测回退循环
-
-```
-1. 统计回退次数
-2. 分析回退原因
-3. 检测是否循环
-```
-
-### Step 5: 检测资源异常
-
-```
-1. 分析 Token 消耗
-2. 分析操作频率
-3. 检测异常模式
-```
-
-### Step 6: 生成报告
-
-```
-1. 汇总异常列表
-2. 按严重程度排序
-3. 生成建议
-```
-
-## 与实时预警的集成
-
-通过 Hook 触发，实时检测异常：
-
-```javascript
-// 在 pipeline-observer.js 中调用
-const anomalies = await analyzeAnomalies(recentEvents, currentStage);
-
-if (anomalies.some(a => a.severity === 'high')) {
-  // 立即输出告警
-  outputAlert(anomalies);
-}
-```
-
-## 自动修复建议
-
-对于可自动修复的问题，提供自动修复选项：
-
-| 异常类型 | 自动修复方式 |
-|---------|------------|
-| 依赖缺失 | 自动安装 |
-| 配置错误 | 自动修正 |
-| 代码风格 | 自动格式化 |
-
-## 反模式清单 (DP7)
-
-1. **过度告警**：对轻微问题也告警
-   - 检测：只有 high 级别才告警
-
-2. **误报**：将正常操作报告为异常
-   - 检测：验证异常的真实性
-
-3. **建议不可执行**：建议过于笼统
-   - 检测：每个建议必须具体可执行
-
-## 适用场景
-
-- 实时监控（通过 Hook）
-- 阶段完成检查
-- 手动执行 `/autospec:status --analyze`

package/knowledge/03-guides/41-diagnose-ai-test.md

@@ -1,133 +0,0 @@
----
-name: ai-test-diagnostics
-description: 当测试执行失败或需要评估测试质量时，进行深度分析诊断和质量评估，提供修复建议和改进方向。
-type: ai
----
-
-## 定位
-
-AI 专用技能。接收测试输出，进行深度分析诊断和质量评估，输出结构化的诊断报告和改进建议。
-
-## 输入
-
-- 必须输入：测试执行输出（stdout/stderr）
-- 可选输入：
-  - 测试命令
-  - 测试覆盖率报告
-  - 相关代码文件
-  - 项目技术栈信息
-  - 代码变更列表
-
-## 输出
-
-```json
-{
-  "diagnosis": {
-    "summary": "测试失败分析摘要",
-    "errorCount": 5,
-    "errors": [
-      {
-        "type": "import",
-        "severity": "high",
-        "message": "Cannot find module './utils'",
-        "file": "src/index.js",
-        "line": 3,
-        "suggestion": "检查模块路径是否正确，或运行 npm install"
-      }
-    ],
-    "rootCause": {
-      "type": "import",
-      "confidence": 0.9,
-      "description": "主要问题是模块导入路径错误"
-    },
-    "fixSuggestions": [
-      {
-        "priority": "high",
-        "action": "fix_import",
-        "description": "修复导入路径",
-        "files": ["src/index.js"]
-      }
-    ]
-  },
-  "quality": {
-    "score": 75,
-    "grade": "B",
-    "metrics": {
-      "passRate": { "score": 80, "value": "80%" },
-      "testCoverage": { "score": 70, "value": "65%" },
-      "codeQuality": { "score": 75 },
-      "stability": { "score": 80 }
-    }
-  },
-  "improvements": [
-    {
-      "area": "test_coverage",
-      "priority": "high",
-      "description": "增加对 utils 模块的测试覆盖",
-      "suggestedTests": ["utils/format.test.js"]
-    }
-  ],
-  "testFramework": "vitest",
-  "language": "javascript"
-}
-```
-
-## 执行步骤
-
-### Step 1: 解析测试输出
-
-1. 识别测试框架（vitest/jest/pytest/mocha 等）
-2. 提取错误信息、文件位置、行号
-3. 识别错误类型（语法/导入/类型/逻辑/运行时）
-4. 统计通过/失败数量
-
-### Step 2: 深度诊断
-
-1. **错误分类**：使用 AI 判断错误属于哪类
-2. **影响评估**：评估错误影响的范围（单文件/多文件/整个模块）
-3. **根因分析**：分析最可能的根本原因
-4. **修复优先级**：按影响范围和严重程度排序
-
-### Step 3: 质量评估
-
-1. **通过率分析**：计算测试通过率
-2. **覆盖率分析**：评估测试覆盖是否充分（如有报告）
-3. **代码质量**：基于错误模式评估代码质量
-4. **稳定性**：基于历史数据分析稳定性趋势
-
-### Step 4: 生成建议
-
-1. 针对每个错误给出具体修复建议
-2. 识别测试覆盖缺口
-3. 提出具体改进方向
-4. 优先级排序
-
-### Step 5: 输出综合报告
-
-输出 JSON 格式，包含：
-- 诊断部分：错误统计、根因分析、修复建议
-- 质量部分：质量分数、各维度指标、改进建议
-
-## 规则
-
-- 必须输出结构化 JSON 格式
-- 每个错误必须包含：类型、严重程度、文件位置、修复建议
-- 质量分数范围 0-100
-- 等级：A(90+), B(80+), C(70+), D(60+), F(<60)
-- 优先输出可执行的修复命令
-- 识别哪些问题可以自动修复，哪些需要人工介入
-
-## 反模式清单
-
-1. **只报告错误不分析根因**：必须提供根因分析
-2. **修复建议过于笼统**：必须给出具体可执行的建议
-3. **忽略测试框架差异**：必须识别并适配不同框架的输出格式
-4. **质量评估脱离实际**：必须基于实际数据而非猜测
-5. **改进建议无优先级**：必须按影响和紧急程度排序
-
-## 适用场景
-
-- 测试执行失败，需要诊断原因
-- 需要评估测试质量和覆盖率
-- 需要识别代码质量问题和改进方向
-- 持续集成失败，需要快速定位问题

package/knowledge/03-guides/42-apply-ddd.md

@@ -1,345 +0,0 @@
-# 领域驱动设计方法论
-
-> **定位**: DDD方法论的实践指南，指导何时、如何应用DDD
->
-> **版本**: v1.0
-> **最后更新**: 2026-03-26
-> **权威来源**: Eric Evans《领域驱动设计》、Vaughn Vernon《实现领域驱动设计》
-
----
-
-## 何时使用DDD
-
-### 适用场景评估
-
-| 场景 | 推荐程度 | 原因 | 投入建议 |
-|------|---------|------|---------|
-| 核心业务系统 | ⭐⭐⭐ 强烈推荐 | 领域复杂度高，值得投入 | 重点建模 |
-| 支撑系统 | ⭐⭐ 可选 | 复杂度中等，按需使用 | 关键模块建模 |
-| CRUD系统 | ⭐ 不推荐 | 过度设计，简单方案即可 | 不需要DDD |
-| 快速原型 | ⭐ 不推荐 | 迭代太快，建模成本高 | 后期重构 |
-
-### 复杂度评估标准
-
-**推荐DDD的条件**（满足2个以上）：
-1. 业务概念数量 > 20个
-2. 业务规则复杂度 > 简单CRUD
-3. 需要跨团队协作
-4. 预期生命周期 > 2年
-5. 业务逻辑频繁变更
-
-**不推荐DDD的条件**：
-1. 简单CRUD操作为主
-2. 业务逻辑稳定不变
-3. 团队规模 < 3人
-4. 快速迭代原型阶段
-
----
-
-## DDD与AutoSpec流程融合
-
-### 需求阶段 → 战略设计
-
-| 需求阶段活动 | DDD对应活动 | 产出物 |
-|-------------|------------|--------|
-| 业务域拆解 | 子领域识别 | 核心域、支撑域、通用域划分 |
-| 用例分析 | 限界上下文边界识别 | 上下文定义、边界划分 |
-| 业务流程 | 上下文集成关系 | 上下文映射图 |
-| 术语提取 | 统一语言建立 | 术语表 |
-
-### 设计阶段 → 战术设计
-
-| 设计阶段活动 | DDD对应活动 | 产出物 |
-|-------------|------------|--------|
-| 系统设计 | 聚合设计、领域模型 | 聚合定义、实体、值对象 |
-| 接口设计 | 领域服务、仓储接口 | 服务定义、仓储契约 |
-| 数据库设计 | 聚合持久化映射 | 表结构、索引设计 |
-| 状态设计 | 聚合根状态机 | 状态流转图 |
-
-### 实现阶段
-
-| 实现阶段活动 | DDD实践 | 注意事项 |
-|-------------|---------|---------|
-| 代码组织 | 按聚合组织包结构 | 一个聚合一个包 |
-| 依赖管理 | 领域层不依赖基础设施 | 依赖倒置 |
-| 事件处理 | 领域事件驱动解耦 | 幂等处理 |
-| 持久化 | 仓储隔离持久化细节 | 聚合完整性 |
-
----
-
-## DDD核心实践
-
-### 统一语言（Ubiquitous Language）
-
-**定义**：团队共享的业务术语，消除沟通歧义
-
-**实践要点**：
-- 代码命名与业务术语一致
-- 文档与代码术语同步
-- 术语冲突必须消除
-- 新术语需要团队共识
-
-**常见问题**：
-| 问题 | 症状 | 解决方案 |
-|------|------|---------|
-| 术语不一致 | 同一概念多个名称 | 统一到术语表 |
-| 技术术语污染 | 代码用技术术语而非业务术语 | 重构命名 |
-| 术语漂移 | 不同阶段术语含义变化 | 定期审查术语表 |
-
-### 聚合设计原则
-
-**核心原则**：
-1. **小聚合优于大聚合**：减少并发冲突
-2. **通过ID引用其他聚合**：保持边界清晰
-3. **聚合边界 = 一致性边界**：事务边界
-
-**聚合大小判断**：
-```
-理想聚合大小：
-- 1个聚合根
-- 0-3个内部实体
-- 若干值对象
-- 不超过5个字段变更频繁的属性
-```
-
-**聚合划分信号**：
-| 信号 | 说明 | 行动 |
-|------|------|------|
-| 并发冲突频繁 | 多用户同时修改同一聚合 | 考虑拆分 |
-| 加载性能差 | 聚合数据量大 | 考虑拆分 |
-| 事务失败率高 | 事务涉及多个独立变更 | 考虑拆分 |
-| 部分字段很少使用 | 某些字段很少被访问 | 考虑拆分 |
-
-### 领域事件驱动
-
-**事件设计原则**：
-- 命名：过去时（OrderCreated, PaymentCompleted）
-- 不可变：事件一旦发生不可修改
-- 幂等：同一事件多次处理结果相同
-
-**事件驱动模式**：
-```
-聚合A变更 → 发布事件 → 事件总线 → 聚合B订阅 → 聚合B变更
-```
-
-**事件存储**：
-| 模式 | 说明 | 适用场景 |
-|------|------|---------|
-| 直接发布 | 事件直接发送到消息队列 | 允许丢失 |
-| 事件表 | 事件先存库再发送 | 不允许丢失 |
-| 事件溯源 | 事件作为状态存储 | 需要历史追溯 |
-
----
-
-## 上下文集成模式详解
-
-### 模式选择决策树
-
-```
-上下文关系类型？
-├── 同一团队
-│   └── Partnership（伙伴关系）
-├── 不同团队，下游有话语权
-│   └── Customer/Supplier（客户-供应商）
-├── 不同团队，下游无话语权
-│   ├── 需要隔离模型
-│   │   └── Anticorruption Layer（防腐层）
-│   └── 可以接受上游模型
-│       └── Conformist（跟随者）
-├── 共享核心逻辑
-│   └── Shared Kernel（共享内核）
-└── 对外提供服务
-    └── Open Host Service（开放主机服务）
-```
-
-### 模式详解
-
-#### Partnership（伙伴关系）
-
-**适用场景**：同一团队或紧密协作的团队
-
-**特点**：
-- 共同演进
-- 同步协调
-- 共享责任
-
-**实践建议**：
-- 定期同步会议
-- 共享代码仓库
-- 统一部署节奏
-
-#### Anticorruption Layer（防腐层）
-
-**适用场景**：集成外部系统或遗留系统
-
-**特点**：
-- 隔离外部模型
-- 适配器模式
-- 保护内部模型
-
-**实践建议**：
-- 定义清晰的适配接口
-- 外部模型不渗透到内部
-- 适配逻辑集中管理
-
----
-
-## 反模式警示
-
-### 贫血模型（Anemic Domain Model）
-
-**症状**：
-- 实体只有getter/setter
-- 业务逻辑全在服务层
-- 失去面向对象价值
-
-**风险**：
-- 业务逻辑散落
-- 难以维护
-- 重复代码
-
-**解决方案**：
-```
-// 错误：贫血模型
-class Order {
-    String status;
-    // 只有getter/setter
-}
-
-class OrderService {
-    void pay(Order order) {
-        order.setStatus("PAID");  // 业务逻辑在服务层
-    }
-}
-
-// 正确：富领域模型
-class Order {
-    String status;
-
-    void pay() {
-        if (!canPay()) throw new BusinessException();
-        this.status = "PAID";
-        publishEvent(new OrderPaidEvent(this.id));
-    }
-}
-```
-
-### 大聚合（Large Aggregate）
-
-**症状**：
-- 聚合包含过多实体
-- 加载性能差
-- 并发冲突频繁
-
-**风险**：
-- 性能问题
-- 可扩展性差
-- 用户体验差
-
-**解决方案**：
-```
-// 错误：大聚合
-class Order {
-    List<OrderItem> items;      // 可能有几十个
-    List<Payment> payments;     // 可能有多个
-    List<Refund> refunds;       // 可能有多个
-    List<Logistics> logistics;  // 可能有多个
-}
-
-// 正确：拆分小聚合
-class Order {
-    String id;
-    String status;
-    Money totalAmount;
-    // 只保留核心属性
-}
-
-class OrderItem { /* 独立聚合 */ }
-class Payment { /* 独立聚合 */ }
-class Refund { /* 独立聚合 */ }
-```
-
-### 领域服务滥用
-
-**症状**：
-- 服务承载所有逻辑
-- 实体变成数据容器
-- 过程式代码
-
-**风险**：
-- 失去DDD价值
-- 代码难以理解
-- 测试困难
-
-**解决方案**：
-```
-// 错误：逻辑在服务
-class OrderService {
-    void calculateTotal(Order order) {
-        // 计算逻辑在服务
-    }
-}
-
-// 正确：逻辑在实体
-class Order {
-    Money calculateTotal() {
-        return items.stream()
-            .map(Item::getPrice)
-            .reduce(Money.ZERO, Money::add);
-    }
-}
-```
-
----
-
-## DDD实施检查清单
-
-### 战略设计阶段
-
-- [ ] 识别核心域、支撑域、通用域
-- [ ] 定义限界上下文边界
-- [ ] 绘制上下文映射图
-- [ ] 确定上下文集成模式
-- [ ] 建立统一语言术语表
-
-### 战术设计阶段
-
-- [ ] 设计聚合边界
-- [ ] 定义聚合根、实体、值对象
-- [ ] 设计领域服务
-- [ ] 定义领域事件
-- [ ] 设计仓储接口
-
-### 实现阶段
-
-- [ ] 代码结构按聚合组织
-- [ ] 领域层不依赖基础设施
-- [ ] 领域事件驱动解耦
-- [ ] 仓储隔离持久化细节
-- [ ] 统一语言一致性检查
-
----
-
-## 参考资料
-
-### 权威书籍
-
-1. **Eric Evans《Domain-Driven Design: Tackling Complexity in the Heart of Software》**
-   - DDD奠基之作
-   - 战略设计核心概念
-
-2. **Vaughn Vernon《Implementing Domain-Driven Design》**
-   - 实践指南
-   - 战术设计详解
-
-### 在线资源
-
-- Microsoft Azure Architecture Center - Tactical DDD
-- DDD Crew GitHub - Bounded Context Canvas, Context Mapping
-- Martin Fowler - CQRS, Event Sourcing
-
----
-
-**维护者**: AutoSpec 团队
-**进化分区**: 🟡 受控区
-**关联文档**: `knowledge/09-templates/12-domain-model.md`