npm - @chongyan/autospec - Versions diffs - 1.0.1 → 1.0.2 - Mend

@chongyan/autospec 1.0.1 → 1.0.2

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.

Files changed (283) hide show

package/knowledge/templates/system-design.md DELETED Viewed

@@ -1,227 +0,0 @@
-# Design: {需求名}/{系统名}
-> **版本**: v1.0
-> **模板来源**: 业界系统设计最佳实践 / 结构化设计方法
-> **适用范围**: 所有系统设计文档
-> **生成模式**: 两步生成（Phase 1 大纲 → Phase 2 详设）
----
-## 1. 项目背景
-**目标**: {一句话描述}
-**参与人**: PM: xx, 开发：xx, 测试：xx
-**相关文档**: [proposal.md](../proposal.md)
----
-## 2. 业务用例
-{从 proposal.md 中提取本系统相关的用例，使用 Mermaid flowchart}
-```mermaid
-flowchart TB
-    subgraph 本系统
-        A[功能 A] --> B[功能 B]
-    end
-```
----
-## 3. 功能设计
-### 3.1 功能点列表
-> **Phase 1 输出**: 仅列表，全部标记为 `- [ ]` 未完成
-> **Phase 2 完成后**: 所有功能点标记为 `- [x]` 完成
-- [ ] **FP-01**: {功能点 1 名称} - {简要描述}
-- [ ] **FP-02**: {功能点 2 名称} - {简要描述}
-- [ ] **FP-03**: {功能点 3 名称} - {简要描述}
-### 3.2 详细设计
-> **Phase 1**: 仅占位符 `> ⏳ 待细化`
-> **Phase 2**: 逐个功能点细化，每完成一个立即更新 3.1 打钩
-#### 3.2.1 FP-01: {功能点 1 名称}
-> ⏳ 待细化
-#### 3.2.2 FP-02: {功能点 2 名称}
-> ⏳ 待细化
-#### 3.2.3 FP-03: {功能点 3 名称}
-> ⏳ 待细化
----
-## 4. 领域模型 (可选)
-> ⏳ 待补充
-### 4.1 模型设计
-{领域模型类图}
-```mermaid
-classDiagram
-    class AggregateRoot {
-        +id: String
-        +behavior()
-    }
-    class Entity {
-        +id: String
-    }
-    class ValueObject {
-        +value: Type
-    }
-    AggregateRoot *-- Entity
-    AggregateRoot *-- ValueObject
-```
-### 4.2 聚合设计（DDD增强，可选）
-> 适用于复杂业务系统，定义一致性边界
-| 聚合名称 | 聚合根 | 包含实体 | 包含值对象 | 一致性规则 |
-|---------|--------|---------|-----------|-----------|
-| | | | | |
-**聚合设计原则**：
-- 小聚合优于大聚合
-- 通过ID引用其他聚合
-- 聚合边界 = 一致性边界 = 事务边界
-### 4.3 领域事件（DDD增强，可选）
-> 适用于事件驱动架构，聚合间通信
-| 事件名称 | 触发条件 | 携带数据 | 订阅方 |
-|---------|---------|---------|--------|
-| | | | |
-**事件命名规范**：过去时（OrderCreated, PaymentCompleted）
-### 4.4 状态机
-{状态流转图}
-```mermaid
-stateDiagram-v2
-    [*] --> 初始状态
-    初始状态 --> 状态A: 事件1
-    状态A --> 状态B: 事件2
-    状态B --> [*]: 事件3
-```
-### 4.5 数据库设计
-{ER 图或表结构}
----
-## 5. 发布依赖 (涉及共享组件/依赖库变更时必须)
-> ⏳ 待补充
-| 组件/依赖库 (groupId:artifactId) | 当前版本 | 升级版本 | 变更内容 | 需升级的系统 |
-|--------------------------------|---------|---------|---------|-------------|
-| {groupId:artifactId} | {当前版本} | {新版本} | {变更说明} | {系统列表} |
----
-## 6. 风险分析 (可选)
-> ⏳ 待补充
-| 风险项 | 影响 | 缓解措施 |
-|-------|------|---------|
-| {风险 1} | {影响} | {措施} |
----
-# 详细设计模板（单个功能点）
-> 将以下内容填充到每个功能点的详细设计中
-## {功能点名称}
-### 概述
-{功能点的业务目标和实现思路}
-### 流程图 (可选)
-```mermaid
-sequenceDiagram
-    participant U as 用户/上游
-    participant S as 本系统
-    participant D as 下游系统
-    U->>S: 1. 请求描述
-    S->>D: 2. 调用下游
-    D-->>S: 3. 返回结果
-    S-->>U: 4. 响应
-```
-### 下游交互 (可选)
-{描述与下游系统的交互细节}
-### 对外接口 (可选)
-{描述对外提供的接口定义}
-### 异常处理 (可选)
-{描述异常处理逻辑}
-### 业务规则 (可选)
-{描述涉及的业务规则}
----
-## 模板使用说明
-### 两步生成流程
-**Phase 1: 大纲生成**
-1. 填写第 1-2 章（项目背景、业务用例）
-2. 生成 3.1 功能点列表（全部标记 `- [ ]`）
-3. 3.2 详细设计仅占位符
-**Phase 2: 逐个细化**
-1. 对每个功能点编写详细设计
-2. 每完成一个功能点，立即在 3.1 打钩 `- [x]`
-3. 补充第 4-6 章（如需要）
-### 必填章节
-以下章节为必填，缺少则设计文档不完整：
-- [ ] 1. 项目背景
-- [ ] 2. 业务用例
-- [ ] 3.1 功能点列表
-- [ ] 3.2 所有功能点的详细设计
-### 可选章节
-以下章节根据需求复杂度选择性填写：
-- 4. 领域模型（涉及复杂领域模型时需要）
-- 5. 发布依赖（涉及共享组件/依赖库变更时必须）
-- 6. 风险分析（高风险操作需要）
-### 最佳实践
-1. **功能点原子化**: 每个功能点应该是原子的，职责单一
-2. **流程图优先**: 能用图表达的不用文字
-3. **进度可视化**: Phase 2 时每完成一个功能点立即打钩
-4. **领域模型**: 核心业务逻辑应该内聚到领域对象中
-5. **风险分析**: 提前识别风险并制定缓解措施

package/knowledge/templates/task-breakdown.md DELETED Viewed

@@ -1,107 +0,0 @@
-# Tasks: {需求名}/{系统名}
-> **版本**: v1.0
-> **模板来源**: 业界任务管理最佳实践 / 结构化任务分解方法
-> **适用范围**: 所有任务分解文档
-> **上游文档**: [design.md](./design.md)
----
-## Meta
-- **design**: {design.md 路径}
-- **system**: @wiki/system/apps/{系统名}/
----
-## Tasks
-### T1: {任务名}
-**Goal**: {一句话说明任务目标}
-**Depends**: 无 | T{n}
-**Files**:
-- CREATE: {新建文件路径}
-- MODIFY: {修改文件路径}
-- DELETE: {删除文件路径}（如需要）
-**Done when**: {验收标准，一句话}
----
-### T2: {任务名}
-**Goal**: {一句话说明任务目标}
-**Depends**: T1
-**Files**:
-- CREATE: {新建文件路径}
-- MODIFY: {修改文件路径}
-**Done when**: {验收标准，一句话}
----
-### T3: {任务名}
-{同上}
----
-## Progress
-- [ ] T1: {任务名}
-- [ ] T2: {任务名}
-- [ ] T3: {任务名}
----
-## Validation
-- [ ] `mvn test -pl {module}`
-- [ ] `mvn checkstyle:check`
----
-## 模板使用说明
-### 任务拆解原则（ATOMIC）
-每个任务必须满足以下原则：
-| 原则 | 说明 | 检查项 |
-|------|------|--------|
-| **A**utonomous | 可独立执行 | 不依赖其他任务的中间状态 |
-| **T**estable | 有明确的验证标准 | 不是"看起来对" |
-| **O**bservable | 执行结果可观测 | 有输出、有日志 |
-| **M**odest | 2-4 小时工作量 | 当前 AI sweet spot |
-| **I**nformed | 包含完整上下文 | 不假设执行者知道任何背景 |
-| **C**onstrained | 明确边界 | 做什么、不做什么、不能碰什么 |
-### 依赖类型
-| 类型 | 说明 | 示例 |
-|------|------|------|
-| `→data` | 数据依赖 | 上游产出作为下游输入 |
-| `→logic` | 逻辑依赖 | 业务流程顺序约束 |
-| `→res` | 资源依赖 | 共享资源需串行访问 |
-| `→contract` | 契约解耦 | 通过定义标准产出物解耦 |
-| `→mock` | Mock 并行 | 下游基于 Mock 开发 |
-### 任务规模
-| 规模 | 工时 | 适用场景 |
-|------|------|---------|
-| Task | 2-4 小时 | 基本任务单元 |
-| Phase | 4-16 小时 | 子系统/大功能 |
-### 最佳实践
-1. **从 design.md 提取**: 每个功能点拆解为 1-N 个任务
-2. **明确验收标准**: Done when 必须清晰可判断
-3. **文件级精确**: CREATE/MODIFY 精确到文件路径
-4. **依赖可视化**: Progress 列表清晰展示完成度
-5. **可并行任务**: 无依赖的任务可并行执行

package/knowledge/templates/test-case.md DELETED Viewed

@@ -1,170 +0,0 @@
-# Testcase: {需求名}/{系统名}
-> **版本**: v1.0
-> **模板来源**: 业界测试用例设计最佳实践 / 结构化测试方法
-> **适用范围**: 所有测试用例文档
-> **来源模式**: A/B/C/D 四种来源
----
-## 1. 测试概要
-- **需求**: {需求名称}
-- **系统**: {系统名}
-- **来源**: design.md | design.md + code-diff
-- **相关文档**:
-  - [design.md]({相对路径})
-  - [proposal.md]({相对路径})
-- **代码变更**: {M}个文件（来源 D 时）
-- **用例统计**: 共 {N} 个 (P0: {X}, P1: {Y}, P2: {Z})
----
-## 2. 交叉验证结果（仅交叉验证时输出）
-### 2.1 需求覆盖度
-| proposal 需求点 | design.md 功能点 | 状态 | 备注 |
-|----------------|-----------------|------|------|
-| {需求 1} | FP-01 | 已覆盖 | |
-| {需求 2} | FP-02 | 已覆盖 | |
-### 2.2 疑点清单
-| 编号 | 类型 | 描述 | 严重程度 | 对应测试用例 |
-|------|------|------|---------|-------------|
-| Q-01 | 需求遗漏 | {描述} | 高/中/低 | TC-CV-001 |
----
-## 3. 测试用例
-### 正向场景 (P0)
-| 用例编号 | 场景 | 优先级 | 前置条件 | 测试步骤 | 预期结果 |
-|----------|------|--------|----------|----------|----------|
-| TC-P-001 | {场景} | P0 | {前置条件} | 1. {步骤 1}<br>2. {步骤 2} | {预期} |
-| TC-P-002 | {场景} | P0 | {前置条件} | 1. {步骤} | {预期} |
-### 异常场景 (P0)
-| 用例编号 | 场景 | 优先级 | 前置条件 | 测试步骤 | 预期结果 |
-|----------|------|--------|----------|----------|----------|
-| TC-E-001 | {异常场景} | P0 | {前置条件} | 1. {步骤} | {错误处理} |
-| TC-E-002 | {异常场景} | P0 | {前置条件} | 1. {步骤} | {错误处理} |
-### 边界场景 (P1)
-| 用例编号 | 场景 | 优先级 | 前置条件 | 测试步骤 | 预期结果 |
-|----------|------|--------|----------|----------|----------|
-| TC-B-001 | {边界场景} | P1 | {前置条件} | 1. {步骤} | {预期} |
-| TC-B-002 | {边界场景} | P1 | {前置条件} | 1. {步骤} | {预期} |
-### 幂等场景 (P1)
-| 用例编号 | 场景 | 优先级 | 前置条件 | 测试步骤 | 预期结果 |
-|----------|------|--------|----------|----------|----------|
-| TC-I-001 | {幂等场景} | P1 | {前置条件} | 1. 首次调用<br>2. 重复调用 | {幂等结果} |
-| TC-I-002 | {幂等场景} | P1 | {前置条件} | 1. 首次调用<br>2. 重复调用 | {幂等结果} |
-### 业务规则补充 (P1)
-| 用例编号 | 场景 | 优先级 | 前置条件 | 测试步骤 | 预期结果 |
-|----------|------|--------|----------|----------|----------|
-| TC-BR-001 | {业务规则} | P1 | {前置条件} | 1. {步骤} | {预期} |
-### 回归场景 (P1)
-| 用例编号 | 场景 | 优先级 | 前置条件 | 测试步骤 | 预期结果 |
-|----------|------|--------|----------|----------|----------|
-| TC-R-001 | {原有功能不受影响} | P1 | {前置条件} | 1. {步骤} | {预期不变} |
-### 交叉验证用例（仅交叉验证时输出）
-| 用例编号 | 场景 | 优先级 | 前置条件 | 测试步骤 | 预期结果 | 关联疑点 |
-|----------|------|--------|----------|----------|----------|----------|
-| TC-CV-001 | {疑点验证} | P0 | {前置条件} | 1. {步骤} | {预期} | Q-01 |
-### 代码风险验证（来源 D 时输出）
-| 用例编号 | 场景 | 优先级 | 前置条件 | 测试步骤 | 预期结果 | 风险类型 |
-|----------|------|--------|----------|----------|----------|----------|
-| TC-CR-001 | {风险验证} | P0 | {前置条件} | 1. {步骤} | {预期} | {异常处理/并发/资金安全} |
----
-## 4. 覆盖矩阵
-| 维度 | 覆盖项 |
-|------|--------|
-| 接口 | {接口列表} |
-| 场景 | {场景列表} |
-| 业务规则 | {规则列表} |
-| 代码变更 | {变更文件覆盖率}（来源 D 时） |
----
-## 5. 覆盖统计
-| 类型 | 数量 | P0 | P1 | P2 |
-|------|------|----|----|-----|
-| 正向 | X | X | X | X |
-| 异常 | X | X | X | X |
-| 边界 | X | X | X | X |
-| 幂等 | X | X | X | X |
-| 业务规则 | X | X | X | X |
-| 回归 | X | X | X | X |
-| 交叉验证 | X | X | X | X |
-| 代码风险 | X | X | X | X |
-| **合计** | **X** | **X** | **X** | **X** |
----
-## 用例编号规则
-| 场景类型 | 编号前缀 | 示例 |
-|----------|----------|------|
-| 正向场景 | TC-P-XXX | TC-P-001, TC-P-002 |
-| 异常场景 | TC-E-XXX | TC-E-001, TC-E-002 |
-| 边界场景 | TC-B-XXX | TC-B-001, TC-B-002 |
-| 幂等场景 | TC-I-XXX | TC-I-001, TC-I-002 |
-| 业务规则 | TC-BR-XXX | TC-BR-001, TC-BR-002 |
-| 回归场景 | TC-R-XXX | TC-R-001, TC-R-002 |
-| 交叉验证 | TC-CV-XXX | TC-CV-001, TC-CV-002 |
-| 代码风险 | TC-CR-XXX | TC-CR-001, TC-CR-002 |
----
-## 模板使用说明
-### 四种来源模式
-| 来源 | 说明 | 适用场景 |
-|------|------|---------|
-| **A** | 基于 design.md | 从设计文档生成测试用例 |
-| **B** | 基于 code-diff-specified | 从指定代码变更生成 |
-| **C** | 基于 code-diff-full | 从完整代码变更生成 |
-| **D** | design.md + code-diff | 设计 + 代码交叉验证 |
-### 必填章节
-以下章节为必填，缺少则测试用例文档不完整：
-- [ ] 1. 测试概要
-- [ ] 3. 测试用例（至少包含正向和异常场景）
-- [ ] 5. 覆盖统计
-### 可选章节
-以下章节根据来源模式选择性填写：
-- 2. 交叉验证结果（仅来源 D 时输出）
-- 代码风险验证（来源 D 时输出）
-### 最佳实践
-1. **P0 优先级**: 核心业务流程必须覆盖
-2. **异常场景**: 每个接口至少一个异常用例
-3. **幂等性**: 写操作必须验证幂等
-4. **回归验证**: 确保变更不影响原有功能
-5. **代码风险**: 关注异常处理、并发、资金安全

package/plugins/commands/validate.md DELETED Viewed

@@ -1,108 +0,0 @@
----
-description: 运行AutoSpec Layer 1确定性验证（编译/测试/lint），支持本地目录和git仓库
----
-# AutoSpec Validate — Layer 1验证
-## 用户输入
-```
-$ARGUMENTS
-```
----
-## 执行指令
-### Step 1: 解析参数
-解析用户输入，提取：
-- 目标路径：本地目录或 git 仓库地址
-- 分支名称（git 仓库时）：--branch <name>
-- 验证类型（可选）：--build | --test | --lint
-- 输出路径（可选）：--output <path>
-**参数格式**：
-```
-[target] [--branch <name>] [--build|--test|--lint] [--output path]
-示例：
-- validate                           # 当前项目
-- validate ./my-project             # 本地目录
-- validate https://github.com/user/repo  # git 仓库
-- validate https://github.com/user/repo --branch main  # 指定分支
-- validate ./src --test            # 只运行测试
-- validate ./src --output ./report.md  # 指定输出
-```
-### Step 2: 处理目标路径
-**规则 1：如果 target 未指定**
-- 默认使用当前项目目录（`.`）
-**规则 2：如果 target 是本地目录**
-- 直接在指定目录执行验证
-**规则 3：如果 target 是 git URL**
-1. 判断是否为 git 仓库（以 http://、https://、git@ 开头）
-2. 确定目标目录：
-   - 有分支指定：`/tmp/autospec-validate-{repo-name}-{branch}`
-   - 无分支指定：`/tmp/autospec-validate-{repo-name}-{default-branch}`
-3. 执行克隆：
-   - 使用 `git clone --depth 1` 减少克隆时间
-   - 指定分支：`git clone -b <branch>`
-4. 在克隆目录执行验证
-### Step 3: 确定验证模式
-**规则 4：如果未指定验证类型**
-- 默认执行全部：build + test + lint
-**规则 5：如果指定验证类型**
-- `--build`：只执行编译检查
-- `--test`：只执行测试
-- `--lint`：只执行 Lint 检查
-### Step 4: 执行Layer1验证
-根据 config.json 判断单系统/多系统，执行：
-- 编译检查
-- 测试执行
-- Lint检查
-- 类型检查（如适用）
-### Step 5: 输出验证报告
-- 默认写入：`.autospec/validation/validation-{timestamp}.md`
-- 或用户指定的输出路径
-- 每项结果附带执行日志
----
-## 输出格式
-```markdown
-## 验证结论：通过 / 部分通过 / 失败
-### 验证目标
-- 目标路径：{本地目录/git URL}
-- 分支：{branch}（如适用）
-- 验证类型：{build/test/lint/all}
-### 验证结果
-| 验证项 | 状态 | 执行命令 | 结果 |
-|--------|------|---------|------|
-| 编译 | ✅ PASS | npm run build | ... |
-| 测试 | ❌ FAIL | npm test | 3 failed |
-| Lint | ✅ PASS | eslint . | 0 errors |
-### 执行日志
-{详细日志}
-```
----
-## 相关命令
-- `/autospec:review` — Layer 2 独立审查
-- `/autospec:status` — 查看流程状态

package/plugins/skills/benchmark-executor/README.md DELETED Viewed

@@ -1,93 +0,0 @@
-# Benchmarks 执行器
-实战流程 AI 评测系统的核心执行组件。
-## 定位
-在 AutoSpec 实战流程各阶段中执行 benchmarks 评测，对比实际产出与预期标准，生成评测报告指导优化迭代。
-## 核心组件
-### 1. BenchmarkEvaluator
-负责加载 benchmarks 配置，执行评测，计算评分，生成报告。
-```javascript
-const evaluator = new BenchmarkEvaluator(projectRoot);
-evaluator.init();
-// 执行评测
-const report = await evaluator.evaluate('design');
-```
-### 2. ChangeDetector
-负责检测阶段产出物变更，自动触发重新评测。
-```javascript
-const detector = new ChangeDetector(projectRoot);
-detector.init();
-// 监听变更
-detector.on('change', (changes) => {
-  console.log('检测到变更:', changes);
-});
-detector.watch('design');
-```
-## 三层验证体系
-| 层级 | 验证类型 | 执行方式 | 用途 |
-|------|---------|---------|------|
-| Layer 1 | 确定性验证 | 自动执行 | Schema校验、规则检查、编译测试 |
-| Layer 2 | AI 审查 | Agent 执行 | 质量评估、一致性检查、深度分析 |
-| Layer 3 | Benchmarks 评测 | 自动+AI | 综合评分、改进建议、准出门禁 |
-## 与阶段技能的集成
-每个阶段技能在验证部分增加 Layer 3 Benchmarks 评测：
-- **requirement-stage**: REQ-001~003 需求完整性评测
-- **design-stage**: DES-001~004 设计规范性评测
-- **implementation-stage**: IMP-001~003 代码质量评测
-- **testing-stage**: TST-001~003 测试充分性评测
-## 触发方式
-1. **自动触发**: 阶段产出物生成/变更后自动执行
-2. **手动触发**: `/benchmark --run --stage={stage}`
-3. **定时触发**: CI 集成，提交前/合并前自动执行
-## 评测结果
-```json
-{
-  "run_id": "20240326-001",
-  "stage": "design",
-  "summary": {
-    "total": 4,
-    "passed": 3,
-    "failed": 1,
-    "overall_score": 87,
-    "grade": "B+"
-  },
-  "results": [...],
-  "recommendations": [...]
-}
-```
-## 准出标准
-- 所有 P0 benchmark 必须通过
-- 综合得分 >= 80
-- 无 critical 级别问题
-## 改进建议
-评测未通过时，自动生成：
-- 问题描述
-- 改进建议
-- 参考示例
-- 预计工作量
-- 是否可自动修复