@chongyan/autospec 1.0.2 → 1.0.4

package/knowledge/03-guides/14-check-consistency.md

@@ -1,177 +0,0 @@
----
-name: consistency-checker
-description: 当需要执行跨产物一致性检查（DP18）时触发。检测需求、设计、代码、测试之间的重复、歧义、规格不全、宪法对齐、覆盖缺口、术语漂移。
-type: review
----
-
-## 定位
-
-跨产物一致性检查专用技能（DP18实现）。在阶段交付前或全流程完成后，检查六维一致性。
-
-## 输入
-
-- 必须输入：
-  - 需求文档（.autospec/specs/{feature}/requirement.md）
-  - 技术方案（.autospec/specs/{feature}/design.md）
-  - 代码实现（变更文件列表 + 代码内容）
-  - 测试报告（如果有）
-- 可选输入：
-  - 历史版本的文档（用于检测术语漂移）
-  - 架构图、API契约文档
-
-## 输出
-
-```markdown
-## 跨产物一致性检查报告（DP18六维检测）
-
-### 检查结论：✅ 通过 / ⚠️ 有警告 / ❌ 不通过
-
-### 1. 重复检测
-| 位置A | 位置B | 重复内容摘要 | 严重程度 |
-|-------|-------|--------------|----------|
-| ... | ... | ... | ... |
-
-### 2. 歧义检测
-| 术语/描述 | 出现的文档 | 不同解释 | 建议 |
-|-----------|------------|----------|------|
-| ... | ... | ... | ... |
-
-### 3. 规格不全检测
-| 需求条目 | 设计覆盖 | 代码实现 | 测试验证 | 缺失环节 |
-|----------|----------|----------|----------|----------|
-| 收藏功能 | ✅ | ✅ | ❌ | 缺少测试 |
-
-### 4. 宪法对齐检测
-| 宪法条款 | 相关文档段落 | 对齐状态 | 问题描述 |
-|----------|--------------|----------|----------|
-| DP6 Layer1必须执行 | 设计.md第15行 | ✅ | ... |
-
-### 5. 覆盖缺口检测
-| 需求点 | 设计覆盖 | 代码覆盖 | 测试覆盖 | 状态 |
-|--------|----------|----------|----------|------|
-| ... | ... | ... | ... | ... |
-
-### 6. 术语漂移检测
-| 术语 | 需求用词 | 设计用词 | 代码用词 | 漂移程度 |
-|------|----------|----------|----------|----------|
-| 用户收藏 | favorite | bookmark | collection | ⚠️ 中等 |
-
-### 必须修复（Critical/High）
-- ...
-
-### 建议改进（Medium/Low）
-- ...
-
-### 检查者信息
-- 检查Agent：autospec-consistency
-- 置信度：{高/中/低}
-- 六维雷达图：[重复, 歧义, 规格, 宪法, 覆盖, 术语] = [5,4,3,5,2,4] /5
-```
-
-## 执行步骤
-
-### Step 1: 收集产物（确定性）
-
-读取所有相关产物：
-1. 需求文档：提取用户故事、验收标准、关键术语
-2. 技术方案：提取数据模型、API定义、模块划分
-3. 代码实现：提取实际实现的功能点、API端点、数据结构
-4. 测试报告：提取测试覆盖的功能点、测试用例关联的需求
-
-### Step 2: 重复检测（两两比对）
-
-**检测逻辑**：
-- 段落级别：相同或相似的段落出现在多个文档中
-- 代码级别：相同逻辑在多个地方重复实现
-- 配置级别：配置与代码中的硬编码重复
-
-**输出**：重复内容的位置、相似度、建议（保留一处+引用）
-
-### Step 3: 歧义检测（术语多义）
-
-**检测逻辑**：
-- 同一术语在不同文档中有不同解释
-- 示例："用户"在需求中指"终端用户"，在代码中指"系统用户"
-
-**输出**：术语、出现的文档、不同解释、建议（统一术语）
-
-### Step 4: 规格不全检测（追踪矩阵）
-
-**检测逻辑**：
-建立需求→设计→代码→测试的追踪矩阵：
-- 每个需求ID是否有对应设计？
-- 每个设计点是否有代码实现？
-- 每个代码功能是否有测试验证？
-
-**输出**：缺失环节的清单
-
-### Step 5: 宪法对齐检测（红线检查）
-
-**检测逻辑**：
-检查各产物是否符合宪法条款：
-- DP6: Layer 1验证是否有真实执行日志
-- DP2: 审查是否独立执行
-- DP10: 不可逆操作是否有安全审计
-- DP7: 反模式清单是否被提及
-
-**输出**：违反宪法条款的具体位置
-
-### Step 6: 覆盖缺口检测
-
-**检测逻辑**：
-- 需求中的边界条件在设计中是否覆盖
-- 设计中的异常处理在代码中是否实现
-- 代码中的功能在测试中是否验证
-
-**输出**：未覆盖点的清单和风险评估
-
-### Step 7: 术语漂移检测
-
-**检测逻辑**：
-- 提取各文档中同一概念的不同用词
-- 计算术语一致性分数
-
-**示例漂移**：
-- 需求："收藏商品"
-- 设计："加入收藏夹"
-- 代码：saveToFavorites()
-- 测试："bookmark功能"
-
-**输出**：术语对照表、漂移程度、建议统一用词
-
-### Step 8: 汇总报告
-
-输出结构化报告，包含：
-- 六维雷达图（可视化一致性评分）
-- 必须修复项（Critical/High）
-- 建议改进项（Medium/Low）
-- 总体通过/不通过结论
-
-## 反模式清单（DP7）
-
-1. **假阳性泛滥**：将正常的同义词使用标记为术语漂移
-   - 检测：区分术语漂移和合理同义词
-
-2. **忽视上下文**：不考虑产物间的正常演进关系
-   - 检测：设计比需求详细是合理的，不是规格不全
-
-3. **机械化比对**：只比对字面而不理解语义
-   - 检测：使用语义相似度而非字面匹配
-
-4. **忽略优先级**：把所有不一致同等对待
-   - 检测：按严重程度分级处理
-
-## 适用场景与边界
-
-- **适用**：
-  - 阶段交付前（尤其是交付部署前）
-  - 全流程完成后归档前
-  - 发现跨阶段不一致问题时
-
-- **不适用**：
-  - 单阶段内部审查（不需要跨产物检查）
-  - 初始阶段（只有需求文档时无其他产物可对比）
-
-- **触发时机**：
-  - 自动：/autospec:archive 命令执行前自动触发
-  - 手动：/consistency 命令

package/knowledge/03-guides/15-run-unit-tests.md

@@ -1,83 +0,0 @@
----
-name: unit-test-runner
-description: 当需要执行项目的单元测试、验证代码正确性时触发
-type: execute
----
-
-## 定位
-
-测试执行阶段的"执行"类skill。负责运行项目的单元测试，分析测试结果，判断是否通过。
-
-> **使用场景**：代码实现完成后，需要运行测试验证正确性。
-
-## 输入
-
-- 必须输入：项目代码、可运行测试文件
-- 可选输入：测试框架配置、测试命令
-
-## 执行步骤
-
-### Step 1: 检测测试框架
-
-1. 检测项目使用的测试框架：
-   - Python: pytest, unittest, nose2
-   - Java: JUnit (Maven/Gradle)
-   - JS/TS: Jest, Vitest, Mocha
-   - Go: testing, go test
-
-2. 确定测试命令：
-   - pytest: `pytest [options]`
-   - JUnit: `mvn test` 或 `gradle test`
-   - Jest: `npm test` 或 `yarn test`
-
-### Step 2: 执行单元测试
-
-1. 并行执行单元测试（如有多个测试文件/模块）
-2. 收集测试输出和结果
-
-### Step 3: 分析测试结果
-
-1. 解析测试输出
-2. 统计：通过/失败/跳过/错误
-3. 记录失败的测试用例和错误信息
-
-## 输出格式
-
-```
-## 测试执行结果
-
-### 基本信息
-- 测试框架：{framework}
-- 测试命令：{command}
-- 总测试数：{total}
-- 通过：{passed}
-- 失败：{failed}
-- 跳过：{skipped}
-- 错误：{errors}
-
-### 执行时间
-- 开始时间：{start_time}
-- 结束时间：{end_time}
-- 总耗时：{duration}
-
-### 失败详情（如有）
-| 测试文件 | 测试用例 | 错误信息 |
-|----------|----------|----------|
-| ... | ... | ... |
-
-### 结论
-- 测试通过：✅ 是/❌ 否
-- 需要修复：{需要修复的测试数}
-```
-
-## 判定标准
-
-- **通过**：所有测试通过（失败数=0）
-- **不通过**：有测试失败，需要修复
-- **需要人工介入**：测试错误（环境问题、配置问题）
-
-## 适用场景
-
-- 适用：代码实现完成后需要验证正确性
-- 不适用：需要生成新测试用例（使用 test-generator）
-- 对应做类skill：test-generator（生成测试）

package/knowledge/03-guides/16-run-integration-tests.md

@@ -1,105 +0,0 @@
----
-name: integration-test-runner
-description: 当需要检测并执行项目已有集成测试、验证模块间协作时触发
-type: execute
----
-
-## 定位
-
-集成测试执行阶段的"执行"类skill。负责智能检测项目中的集成测试并执行。
-
-> **使用场景**：单元测试通过后，需要验证模块间协作是否正常。
-
-## 输入
-
-- 必须输入：项目代码、单元测试已通过
-- 可选输入：项目构建配置
-
-## 执行步骤
-
-### Step 1: 智能检测测试框架
-
-1. 检测项目测试框架：
-   - 读取 `package.json`, `pom.xml`, `build.gradle`, `pyproject.toml` 等
-   - 识别测试框架：pytest, JUnit, Jest, Vitest 等
-
-2. 识别测试文件（不限于特定目录）：
-   - 根据框架惯例：test_*.py, *_test.py, *.test.js, *Test.java
-   - 根据测试内容：class Test*, def test_*, it('*'), @Test
-   - 扫描项目根目录和子目录
-
-### Step 2: 区分单元测试 vs 集成测试
-
-1. **单元测试特征**：
-   - 只 import 项目内部模块
-   - 无外部依赖（数据库、API、文件系统）
-   - 使用 mock 替代外部依赖
-
-2. **集成测试特征**：
-   - import 外部模块（数据库、缓存、消息队列）
-   - 涉及真实环境配置
-   - 无 mock 或少量 mock
-   - 测试文件名包含 integration, e2e, endtoend
-
-3. **分类输出**：
-   - 列出识别出的集成测试文件
-   - 说明分类依据
-
-### Step 3: 执行集成测试
-
-1. 准备测试环境（如需要）
-2. 执行集成测试
-3. 收集测试输出和结果
-
-### Step 4: 分析测试结果
-
-1. 解析测试输出
-2. 统计：通过/失败/跳过/错误
-3. 记录失败的测试用例和错误信息
-
-## 输出格式
-
-```
-## 集成测试执行结果
-
-### 测试框架检测
-- 检测到的框架：{framework}
-- 测试命令：{command}
-
-### 测试文件识别
-- 总测试文件数：{total}
-- 单元测试：{unit_count}
-- 集成测试：{integration_count}
-
-### 集成测试列表
-| 文件路径 | 测试用例数 | 分类依据 |
-|----------|------------|----------|
-| ... | ... | ... |
-
-### 执行结果
-- 通过：{passed}
-- 失败：{failed}
-- 跳过：{skipped}
-- 错误：{errors}
-
-### 失败详情（如有）
-| 测试文件 | 测试用例 | 错误信息 |
-|----------|----------|----------|
-| ... | ... | ... |
-
-### 结论
-- 集成测试通过：✅ 是/❌ 否
-- 需要修复：{需要修复的测试数}
-```
-
-## 判定标准
-
-- **通过**：所有集成测试通过
-- **不通过**：有集成测试失败，需要修复
-- **无集成测试**：项目中未发现集成测试，跳过
-
-## 适用场景
-
-- 适用：单元测试通过后，需要验证模块间协作
-- 不适用：需要生成新测试（使用 test-generator）
-- 对应做类skill：test-generator

package/knowledge/03-guides/17-analyze-test-context.md

@@ -1,250 +0,0 @@
----
-name: test-context-analyzer
-description: 在生成测试代码前，分析项目现有测试代码的风格和模式，提取可复用的测试基础设施
-type: produce
----
-
-## 定位
-
-测试阶段的前置技能。分析现有测试代码，提取风格、模式、基础设施，供 test-generator 使用。
-
-## 输入
-
-- 必须输入：
-  - 项目源码目录（包含现有测试代码）
-  - config.json 中的测试配置
-- 可选输入：
-  - 环境知识中的测试最佳实践
-
-## 输出
-
-- 测试风格分析报告（写入 `.autospec/specs/{feature}/test-context.md`）
-
-## 执行步骤
-
-### Step 1: 检测测试框架和工具
-
-1. 检查依赖文件：
-   - **Node.js**: `package.json` 的 devDependencies
-   - **Python**: `requirements.txt` 或 `pyproject.toml`
-   - **Java**: `pom.xml` 或 `build.gradle`
-   - **Go**: `go.mod`
-
-2. 识别测试框架：
-
-| 框架类型 | 常见选择 |
-|---------|---------|
-| 单元测试 | Jest, Mocha, pytest, JUnit, TestNG, Go testing |
-| E2E测试 | Cypress, Playwright, Selenium, Puppeteer |
-| API测试 | Supertest, REST-assured, httpx |
-| Mock工具 | Sinon, unittest.mock, Mockito, testify |
-
-3. 检测测试相关配置：
-   - Jest: `jest.config.js`, `jest.setup.js`
-   - pytest: `pytest.ini`, `conftest.py`
-   - Maven: `surefire` 插件配置
-
-### Step 2: 分析测试代码风格
-
-扫描现有测试文件（`tests/`, `__tests__/`, `test/`, `src/**/*.test.*`, `*_test.py` 等）：
-
-1. **命名规范**：
-   - 文件命名：`*.test.js`, `*.spec.ts`, `*_test.py`, `*Test.java`
-   - 函数命名：`describe/it`, `test_`, `@Test`
-
-2. **断言风格**：
-   - Jest: `expect().toBe()`, `expect().toEqual()`
-   - Mocha + Chai: `expect().to.equal()`, `should.equal()`
-   - pytest: `assert x == y`
-   - JUnit: `assertEquals()`, `assertThat()`
-
-3. **组织结构**：
-   - `describe/it` 嵌套层级
-   - `beforeEach/afterEach` 使用模式
-   - `fixture` 文件组织方式
-
-### Step 3: 提取测试基础设施
-
-1. **Setup/Teardown**：
-   - 全局 setup 文件位置和内容
-   - `beforeAll/beforeEach` 中的初始化逻辑
-   - 数据库连接、Mock 初始化
-
-2. **Mock 配置**：
-   - Mock 文件位置（`__mocks__/`, `mocks/`, `fixtures/`）
-   - Mock 策略（自动 mock vs 手动 mock）
-   - 常用 Mock 模式
-
-3. **测试数据**：
-   - Fixtures 目录结构
-   - Factory 模式使用
-   - 测试数据准备脚本
-
-### Step 4: 提取集成测试配置（关键）
-
-1. **环境启动方式**：
-   - `docker-compose.yml` 的使用
-   - `npm scripts` 中的测试环境命令
-   - `Makefile` 中的测试目标
-
-2. **依赖服务配置**：
-   - 测试数据库配置（连接字符串、数据库名）
-   - 测试 Redis 配置
-   - Mock 服务配置
-
-3. **测试数据准备**：
-   - Seed 脚本位置
-   - 测试数据文件
-   - 数据清理策略
-
-### Step 5: 加载环境知识中的测试最佳实践
-
-1. 读取 `.autospec/environment/registry.json` 获取活跃中间件
-2. 加载对应的 `integration/testing/{middleware}-testing.yaml`
-3. 提取可用的测试策略和模板
-
-### Step 6: 输出测试上下文
-
-生成 `.autospec/specs/{feature}/test-context.md`：
-
-```markdown
-## 测试风格分析
-
-### 测试框架
-- 单元测试: Jest
-- E2E测试: Cypress
-- Mock工具: Sinon
-
-### 断言风格
-- 使用 `expect().toBe()` 风格
-- 异步测试使用 `async/await`
-
-### 测试基础设施
-- Setup: `jest.setup.js`
-- Fixtures: `tests/fixtures/`
-- Mocks: `__mocks__/`
-
-### 集成测试配置
-- 环境启动: `docker-compose -f docker-compose.test.yml up -d`
-- 数据库: 使用测试数据库 `test_db`
-- 数据准备: `npm run test:seed`
-
-### 环境知识最佳实践
-- MySQL: 使用 testcontainer 策略
-- Redis: 使用 mock 策略
-
-### 复用建议
-- 新测试文件放在 `tests/` 目录
-- 使用现有的 `testUtils.ts` 工具函数
-- 集成测试复用 `docker-compose.test.yml`
-- 参考 `mysql-testing.yaml` 生成数据库测试
-```
-
-## 检测模式
-
-### Node.js 项目检测
-
-```javascript
-// 检测 package.json
-const pkg = require('./package.json');
-const devDeps = pkg.devDependencies || {};
-
-// 检测测试框架
-const frameworks = {
-  jest: devDeps.jest ? 'Jest' : null,
-  mocha: devDeps.mocha ? 'Mocha' : null,
-  vitest: devDeps.vitest ? 'Vitest' : null,
-  cypress: devDeps.cypress ? 'Cypress' : null,
-  playwright: devDeps['@playwright/test'] ? 'Playwright' : null,
-};
-
-// 检测测试命令
-const testScript = pkg.scripts?.test;
-const testSetup = pkg.scripts?.['test:setup'];
-const testTeardown = pkg.scripts?.['test:teardown'];
-```
-
-### Python 项目检测
-
-```python
-# 检测 requirements.txt 或 pyproject.toml
-# 常见测试框架：
-# - pytest
-# - unittest
-# - nose2
-
-# 检测配置文件
-# - pytest.ini
-# - conftest.py
-# - setup.cfg
-```
-
-### 测试文件扫描
-
-```
-扫描目录：
-- tests/
-- test/
-- __tests__/
-- src/**/*.test.{js,ts}
-- src/**/*.spec.{js,ts}
-- **/*_test.py
-- **/test_*.py
-- src/test/**/*Test.java
-```
-
-## 反模式清单（DP7）
-
-1. **忽略现有测试风格**：生成与项目风格不一致的测试
-   - 检测：必须先分析现有测试再生成
-
-2. **不复用基础设施**：重复创建 setup/teardown
-   - 检测：必须检查并复用现有配置
-
-3. **忽略环境知识**：不使用已定义的测试最佳实践
-   - 检测：必须加载环境知识中的测试配置
-
-## 适用场景与边界
-
-- **适用**：测试阶段开始前、需要生成与现有代码风格一致的测试
-- **不适用**：全新项目（无现有测试代码）
-- **前置**：项目有测试代码或环境知识
-- **后续**：test-generator 使用分析结果生成测试
-
-## 示例
-
-**输入**：一个使用 Jest + MySQL 的 Node.js 项目
-
-**输出**：
-
-```markdown
-## 测试风格分析
-
-### 测试框架
-- 单元测试: Jest v29
-- API测试: Supertest
-
-### 断言风格
-- 使用 `expect().toBe()` 风格
-- 异步测试使用 `async/await` + `resolves/rejects`
-
-### 测试基础设施
-- Setup: `jest.setup.js` - 初始化测试数据库
-- Fixtures: `tests/fixtures/` - JSON 格式测试数据
-- Mocks: `__mocks__/` - 手动 mock 外部服务
-
-### 集成测试配置
-- 环境启动: `npm run test:setup` (docker-compose)
-- 数据库: MySQL testcontainer
-- 数据准备: `tests/seed.ts`
-
-### 环境知识最佳实践
-- MySQL: 项目使用 testcontainer 策略
-- 参考 `mysql-testing.yaml` 中的模板
-
-### 复用建议
-1. 新测试文件放在 `tests/` 目录，命名为 `*.test.ts`
-2. 使用 `tests/utils/testDb.ts` 创建测试数据库连接
-3. 使用 `tests/fixtures/` 中的测试数据
-4. 参考 `tests/api/users.test.ts` 的测试结构
-```