@chongyan/autospec 1.0.1 → 1.0.3

package/plugins/skills/benchmark-generator/SKILL.md

@@ -1,349 +0,0 @@
----
-name: benchmark-generator
-description: "When benchmarks need to be created for a stage, generate stage-specific benchmarks based on project characteristics, tech stack, and environment"
----
-
-# Benchmark Generator — 阶段 Benchmarks 自动生成器
-
-## 定位
-
-根据**实战项目特点**、**技术栈**、**环境配置**，自动生成各阶段（exploration/requirement/design/implementation/testing）的 benchmarks。
-
-## 触发时机
-
-1. **阶段首次执行** - 自动生成该阶段的 benchmarks
-2. **环境变化检测** - 项目结构/技术栈变化时，更新 benchmarks
-3. **手动触发** - `/benchmark --generate --stage={stage}`
-
-## 输入
-
-```yaml
-project_context:
-  project_type: "e-commerce" | "saas" | "data-platform" | "ai-service"
-  tech_stack:
-    frontend: "react" | "vue" | "angular"
-    backend: "nodejs" | "java" | "go" | "python"
-    database: "mysql" | "postgres" | "mongodb"
-  is_multi_system: boolean
-  complexity: 1-10
-  existing_benchmarks: []  # 已有的 benchmarks（如有）
-```
-
-## 输出
-
-```yaml
-benchmarks_file: ".autospec/benchmarks/auto-generated/{stage}-{timestamp}.yaml"
-generated_benchmarks:
-  stage: string
-  version: "1.0"
-  generated_from: object  # 生成依据
-  test_cases: []          # 测试用例列表
-```
-
----
-
-## 执行步骤
-
-### Step 1: 项目特征扫描
-
-```
-1. 检测技术栈
-   - 读取 package.json / pom.xml / go.mod / requirements.txt
-   - 识别前端框架、后端语言、数据库
-
-2. 检测项目结构
-   - 单系统 vs 多系统
-   - 子系统划分
-   - 代码组织方式
-
-3. 检测现有配置
-   - Lint 规则
-   - 测试框架
-   - CI/CD 配置
-   - 已有 benchmarks（避免重复）
-```
-
-### Step 2: 选择 Benchmarks 模板
-
-根据项目特征，选择对应的模板组合：
-
-| 项目特征 | Exploration | Requirement | Design | Implementation | Testing |
-|---------|-------------|-------------|--------|----------------|---------|
-| React+Node.js | 澄清完整性 | 用户故事规范 | 组件设计 | React最佳实践 | 组件测试 |
-| Java+Spring | 澄清完整性 | 领域模型 | 分层架构 | Java规范 | 单元+集成 |
-| 多系统 | 跨系统需求 | 契约定义 | 接口设计 | 一致性 | 契约测试 |
-| AI项目 | 效果指标 | 评测方案 | 模型设计 | 推理优化 | 效果测试 |
-
-### Step 3: 生成阶段特定 Benchmarks
-
-#### Exploration 阶段
-
-```yaml
-generate_exploration_benchmarks:
-  test_cases:
-    - id: "EXP-001"
-      name: "需求澄清完整性"
-      criteria:
-        - "澄清问题数量 >= 3"
-        - "问题覆盖功能/非功能/边界条件"
-        - "每个问题有推荐答案"
-      validation:
-        type: "layer2-review"
-
-    - id: "EXP-002"
-      name: "复杂度评估准确性"
-      criteria:
-        - "复杂度评分有依据"
-        - "考虑了技术风险"
-        - "考虑了团队熟悉度"
-      scoring:
-        - coverage: 50%
-        - accuracy: 50%
-```
-
-#### Requirement 阶段
-
-```yaml
-generate_requirement_benchmarks:
-  test_cases:
-    - id: "REQ-001"
-      name: "需求文档完整性"
-      criteria:
-        - "必须字段完整率 >= 90%"
-        - "验收标准可测试"
-        - "边界条件已定义"
-      validation:
-        type: "schema-check"
-        schema: "requirement-schema.json"
-
-    - id: "REQ-002"
-      name: "非功能需求覆盖"
-      criteria:
-        - "性能指标已定义（如适用）"
-        - "安全要求已说明（如适用）"
-        - "扩展性考虑已记录（如适用）"
-
-    - id: "REQ-003"
-      name: "多系统需求一致性（如适用）"
-      criteria:
-        - "跨系统接口需求已定义"
-        - "数据一致性要求已说明"
-      condition: "is_multi_system"
-```
-
-#### Design 阶段
-
-```yaml
-generate_design_benchmarks:
-  test_cases:
-    - id: "DES-001"
-      name: "架构设计完整性"
-      criteria:
-        - "架构图存在且清晰"
-        - "技术选型有理由"
-        - "非功能需求有设计方案"
-
-    - id: "DES-002"
-      name: "API 设计规范性"
-      criteria:
-        - "API 契约文件存在"
-        - "符合 RESTful 规范"
-        - "错误处理统一"
-        - "版本管理策略"
-
-    - id: "DES-003"
-      name: "数据模型设计"
-      criteria:
-        - "ER图或模型文档"
-        - "字段类型定义清晰"
-        - "索引设计考虑"
-
-    - id: "DES-004"
-      name: "设计-需求一致性"
-      criteria:
-        - "所有需求都有对应设计"
-        - "设计无超出需求范围"
-      validation:
-        type: "traceability-check"
-        upstream: "requirement.md"
-```
-
-#### Implementation 阶段
-
-```yaml
-generate_implementation_benchmarks:
-  test_cases:
-    - id: "IMP-001"
-      name: "代码-设计一致性"
-      criteria:
-        - "代码实现符合设计"
-        - "API 实现符合契约"
-      validation:
-        type: "consistency-check"
-
-    - id: "IMP-002"
-      name: "代码质量基准"
-      criteria:
-        - "圈复杂度 < 10"
-        - "无重复代码"
-        - "测试覆盖率 > 80%"
-        - "Lint 无错误"
-      auto_fixable: true
-
-    - id: "IMP-003"
-      name: "功能完整性"
-      criteria:
-        - "所有需求已实现"
-        - "验收标准可验证"
-      validation:
-        type: "requirement-coverage"
-```
-
-#### Testing 阶段
-
-```yaml
-generate_testing_benchmarks:
-  test_cases:
-    - id: "TST-001"
-      name: "测试覆盖率"
-      criteria:
-        - "行覆盖率 >= 80%"
-        - "分支覆盖率 >= 70%"
-        - "核心功能 100%"
-
-    - id: "TST-002"
-      name: "测试质量"
-      criteria:
-        - "无 Flaky test"
-        - "测试执行时间 < 5分钟"
-        - "测试数据独立"
-
-    - id: "TST-003"
-      name: "集成测试（多系统）"
-      criteria:
-        - "关键路径有集成测试"
-        - "契约测试覆盖"
-      condition: "is_multi_system"
-```
-
-### Step 4: 自适应调整
-
-根据项目历史数据调整 benchmarks：
-
-```
-if 项目有历史评测数据:
-  - 识别经常失败的 benchmarks → 降低阈值或拆分
-  - 识别总是通过的 benchmarks → 提高阈值或移除
-  - 识别新出现的问题模式 → 添加新的 benchmarks
-```
-
-### Step 5: 保存 Benchmarks
-
-```yaml
-output:
-  file: ".autospec/benchmarks/auto-generated/{stage}-{timestamp}.yaml"
-  format: "yaml"
-  include_metadata: true
-  metadata:
-    generated_at: ISO8601
-    generator_version: "1.0"
-    project_fingerprint: "hash of project config"
-```
-
----
-
-## 生成规则
-
-### 规则1: 技术栈特定规则
-
-```yaml
-# React 项目特定
-react_rules:
-  - "组件必须有 displayName"
-  - "Props 必须有类型定义"
-  - "Hooks 依赖数组完整"
-
-# Java 项目特定
-java_rules:
-  - "类必须有包声明"
-  - "公共方法必须有文档"
-  - "异常必须正确处理"
-
-# 多系统特定
-multi_system_rules:
-  - "接口契约一致性"
-  - "共享逻辑抽离"
-  - "依赖循环检查"
-```
-
-### 规则2: 复杂度自适应
-
-```yaml
-complexity_adaptation:
-  low (1-3):
-    - benchmarks 数量: 3-5
-    - 阈值: 宽松
-
-  medium (4-6):
-    - benchmarks 数量: 5-8
-    - 阈值: 标准
-
-  high (7-10):
-    - benchmarks 数量: 8-12
-    - 阈值: 严格
-    - 增加架构相关 benchmarks
-```
-
-### 规则3: 避免重复
-
-```
-检查已有 benchmarks:
-  - 相同 ID 不重复生成
-  - 相似内容合并
-  - 过期 benchmarks 标记
-```
-
----
-
-## 反模式
-
-1. **过度生成** - 生成过多 benchmarks 导致评测缓慢
-   - 限制：每个阶段最多 12 个 benchmarks
-
-2. **脱离实际** - benchmarks 与项目实际情况不符
-   - 缓解：基于实际代码/配置生成
-
-3. **阈值不合理** - 阈值过高或过低
-   - 缓解：根据项目历史数据调整
-
----
-
-## 使用示例
-
-```bash
-# 自动生成所有阶段 benchmarks
-/benchmark --generate --all
-
-# 生成特定阶段 benchmarks
-/benchmark --generate --stage=requirement
-
-# 重新生成（覆盖已有）
-/benchmark --generate --stage=design --force
-
-# 预览将要生成的 benchmarks（不保存）
-/benchmark --generate --stage=implementation --dry-run
-```
-
----
-
-## 产出物
-
-```
-.autospec/benchmarks/
-└── auto-generated/
-    ├── exploration-20240326-001.yaml
-    ├── requirement-20240326-001.yaml
-    ├── design-20240326-001.yaml
-    ├── implementation-20240326-001.yaml
-    └── testing-20240326-001.yaml
-```

package/plugins/skills/delivery-stage/SKILL.md

@@ -1,203 +0,0 @@
----
-name: delivery-stage
-description: "When deployment preparation, release checklist verification, or production delivery is needed — loads AutoSpec delivery process and safety checks."
----
-
-# AutoSpec 交付部署（Stage 06）
-
-你正在执行交付部署阶段。此阶段将测试通过的代码安全部署到目标环境。
-
-## 前置检查
-
-1. 确认QA测试阶段已完成（检查 `.autospec/runtime/state.json`）
-2. 读取 `${KNOWLEDGE}/principles/constitution.md` → 确认红线（特别注意：部署必须可回滚、不可逆动作必须人工确认）
-3. 读取发布检查清单：`${KNOWLEDGE}/checklists/release.md` → 逐项核对
-4. **检查是否为多系统项目**：读取 `.autospec/runtime/config.json` 的 `subsystems` 字段
-5. **检查是否需要效果验收**：检查是否有 ai 类型子系统或 needsEvaluation=true
-6. 如有角色配置，加载 `${KNOWLEDGE}/guides/stages/{角色}-profile.md` 中**交付部署阶段**关注点（如后端关注DB迁移脚本/监控指标）
-
-## 执行
-
-### Step 1: 确定模式
-
-读取 `.autospec/runtime/config.json`，检查 `subsystems` 字段：
-- **无 subsystems 或长度为1** → 单系统模式
-- **有 subsystems 且长度>1** → 多系统模式
-
-检查是否需要效果验收：
-- 有 `type: ai` 的子系统或 `needsEvaluation: true` → 需要效果验收
-
-### Step 2: 单系统模式
-
-1. **【强制】** 加载skill：读取 `${KNOWLEDGE}/guides/stages/release-checker.md` → **逐项检查**
-2. **【强制】** 加载skill：读取 `${KNOWLEDGE}/guides/stages/consistency-checker.md` → **跨产物一致性检查**
-3. 加载认知增强原则：读取 `${KNOWLEDGE}/principles/core-principles.md` → 本阶段重点 CP10(自我质检)、CP8(偏航检测)
-4. 执行发布前检查清单
-5. 生成交付清单和部署文档
-
-### Step 3: 多系统模式
-
-1. **各子系统发布检查**：
-   ```
-   for subsystem in config.subsystems:
-     a. 检查 {subsystem.path} 变更内容
-     b. 确认 {subsystem.build} 成功
-     c. 确认 {subsystem.test} 通过
-     d. 检查依赖版本
-     e. 记录发布项
-   ```
-
-2. **跨系统一致性检查**：
-   - 确认跨系统接口变更已同步
-   - 确认部署顺序合理
-
-3. **汇总检查结果**
-
-### Step 4: 效果验收（AI/模型功能）
-
-当项目包含 AI/模型 相关功能时，需要额外验收：
-
-1. **检查评测报告**：
-   - 评测数据集是否覆盖典型场景
-   - 效果指标是否达到设计阶段定义的基线
-   - Badcase是否已分析和处理
-
-2. **效果指标验收**：
-   - 核心效果指标是否达标
-   - 业务效果指标是否达标（如有）
-   - 未达标指标是否有改进计划
-
-3. **智能体验收**（如适用）：
-   - 任务完成率是否达标
-   - 响应质量是否达标
-   - 工具使用正确率是否达标
-
-4. **产出验收结论**：
-   - 通过：效果达标，可发布
-   - 有风险：效果部分达标，需确认是否接受
-   - 不通过：效果未达标，阻止发布
-
-### Step 5: 数据系统验收
-
-当项目包含数据系统时：
-
-1. **数据质量验收**：完整性、一致性、准确性检查结果
-2. **ETL流程验收**：数据转换正确性、性能是否满足要求
-3. **数据回滚方案验收**：回滚脚本是否准备、回滚是否可执行
-
-## 认知纪律（本阶段：收敛 + 安全优先）
-
-- **CP10 自我质检**：交付前终极自问清单：
-  - 所有需求的验收标准都满足了吗？
-  - Layer 1 全部 PASS 且有真实日志吗？
-  - 跨产物一致性检查通过了吗？
-  - 回滚方案准备好了吗？
-  - **效果指标达标了吗？**（AI/模型功能）
-- **CP8 偏航检测**：对照需求文档做最终偏航扫描。任何未实现的需求点 = 不能交付
-
-## 安全红线（本阶段特别强调）
-
-- **部署操作 = 不可逆动作**
-- **数据库迁移 = 不可逆动作**
-- **模型部署 = 不可逆动作**（AI/模型功能）
-- 部署方案必须包含回滚计划
-- 灰度发布优先于全量发布
-
-**不可逆操作的双模式处理**：
-- 交互模式：安全审计通过后，阻塞等待用户确认
-- 自动模式：安全审计通过后，生成部署方案但**不执行部署**，标记为 `REQUIRE_REVIEW`，记录到 `pendingConfirmations`
-- 两种模式下，安全审计结论为"不安全" → **均阻止执行**（这是唯一一个自动模式也会阻塞的场景）
-
-### 安全审计（不可逆操作前必做）
-
-在执行任何不可逆操作前，使用 **safety-auditor** Agent 执行独立安全审查：
-```
-**【强制】** 调用 Agent 工具：
-  prompt: 请对以下不可逆操作执行安全审计。
-    操作类型：{DB迁移/部署/外部API调用/模型部署/...}
-    变更文件列表：{相关文件}
-    部署方案：{回滚计划、灰度策略}
-    宪法红线：${KNOWLEDGE}/principles/constitution.md
-```
-
-安全审计报告结论为"不安全" → **阻止执行**，必须先修复。
-安全审计报告结论为"安全"或"有风险" → 提交报告要点给用户确认。
-
-## 跨产物一致性检查
-
-在交付前，使用 **consistency-checker** Agent 执行全量一致性分析：
-```
-**【强制】** 调用 Agent 工具：
-  prompt: 请执行跨产物一致性分析。
-    检查以下产物之间的一致性：
-    1. 需求文档: .autospec/specs/{feature}/requirement.md
-    2. 技术方案: .autospec/specs/{feature}/design.md（或 design/ 目录）
-    3. 代码实现（变更文件列表）
-    4. 测试报告（或 tests/ 目录）
-    六维检测：重复/歧义/规格不全/宪法对齐/覆盖缺口/术语漂移
-```
-
-## 阶段门禁（所有自主级别）
-
-使用 **stage-gate-evaluator** Agent 评估产出物是否达到准出标准：
-```
-**【强制】** 调用 Agent 工具：
-  prompt: 请评估交付部署阶段的产出物是否达到准出标准。
-    当前阶段：Stage 06 交付部署
-    产出物：部署方案 + 交付清单
-    准出标准：${KNOWLEDGE}/checklists/release.md
-    一致性检查报告 + 安全审计报告
-    效果验收报告（如有AI/模型功能）
-    自主级别：{自主/交互}
-```
-
-**根据自主级别处理评估结果**：
-- **交互模式**：评估结果提交人工确认，AI 等待用户批准后继续
-- **自主模式**：评估通过后自动进入下一阶段，评估不通过进入精准回退
-
-## 完成
-
-- 交互模式：检查通过 + 安全审计通过 + 效果验收通过 + 用户确认 → 执行部署 → 更新 `.autospec/runtime/state.json` → 流程完成
-- 自动模式：检查通过 + 安全审计通过 + 效果验收通过 → 生成部署方案（不执行）→ 标记 `pendingConfirmations` → 更新状态 → 进入收尾
-- 不通过 → 精准回退：
-  - Level 1: 内联重试（单次）
-  - Level 2: 修正循环（最多3次，只重处理失败项）
-  - Level 3: 3次后使用 **failure-diagnostician** Agent 执行根因分析，再升级用户
-
-## 交付后自动触发：实践记录 + 进化信号
-
-交付完成后，**必须执行以下收尾步骤**（不可跳过）：
-
-### Step 1: 记录 practice-log（必须执行）
-1. 从 `.autospec/runtime/state.json` 收集执行度量：
-   - Layer 1/2 通过率（每个阶段）
-   - 回退次数（哪个阶段、什么原因）
-   - 人工介入次数
-   - **效果指标结果**（AI/模型功能）
-2. 总结经验：做得好的 / 做得不好的 / 改进点
-3. 确定编号：扫描 `.autospec/evolution/practice-log/` 已有文件，取下一个编号
-4. 写入 `.autospec/evolution/practice-log/{NNN}-{feature}.md`，末尾标注 `状态: Pending`
-
-### Step 2: 快速进化扫描（必须执行）
-**读取 `${KNOWLEDGE}/guides/support/skill-distiller.md` 的"识别"部分**，快速检查：
-- 本次流程中是否有反复出现的操作模式？
-- 是否有频繁需要人工介入的环节？
-- 是否有可提取的新 skill？
-
-**读取 `${KNOWLEDGE}/guides/support/methodology-extractor.md` 的"执行步骤"前4步**，快速检查：
-- 本次实践中哪些做法有效、哪些踩坑？
-- 是否需要更新 `${KNOWLEDGE}/checklists/` 中的检查项？
-- 是否需要更新 `${KNOWLEDGE}/principles/core-principles.md`？
-
-### Step 3: 处理进化信号
-如有发现：
-- **自由区变更** → 自动执行 + 读取 `${KNOWLEDGE}/guides/support/skill-validator.md` 验证
-- **受控区变更** → 生成提案到 `.autospec/evolution/proposals/`，**立即告知用户**：
-  "本次流程产生了 {N} 个进化提案，请在方便时审批：`.autospec/evolution/proposals/`"
-- **冻结区** → 仅在 practice-log 中标记建议
-- 记录到 `.autospec/evolution/evolution-log.json`
-
-### Step 4: 进化积累检查
-扫描 `.autospec/evolution/practice-log/` 中 Pending 条目数量：
-- 如果 ≥ 5 → **建议用户运行 `/evolve` 执行完整进化循环**
-- 如果 < 5 → 告知用户当前积累数量