@chongyan/autospec 1.0.1

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

@@ -0,0 +1,349 @@
+---
+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

@@ -0,0 +1,203 @@
+---
+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 → 告知用户当前积累数量