@specpow/framework 0.5.9 → 0.5.11

package/.specpow/schemas/spec-driven/schema.yaml

@@ -1,87 +0,0 @@
-# SpecPow 默认 Schema: spec-driven
-# 四阶段工件流: proposal → specs → design → tasks → apply
-# 融合 OpenSpec 的规范驱动 + Superpowers 的执行方法论
-
-name: spec-driven
-description: |
-  规格驱动开发工作流。
-  在 AI 写代码之前，让人类和 AI 对"要构建什么"达成一致。
-  然后通过 SDD 子代理驱动引擎高质量地执行实现。
-
-apply:
-  requires:
-    - tasks    # 实施前必须完成所有工件
-
-artifacts:
-  - id: proposal
-    name: 提案
-    description: 为什么做这个变更？解决什么问题？
-    requires: []
-    template: proposal.md
-    instruction: |
-      创建变更提案。回答：
-      1. 为什么要做这个变更？（动机）
-      2. 要解决什么问题？
-      3. 成功标准是什么？
-      4. 影响范围和风险？
-      
-      注意：先使用 brainstorming 技能进行需求探索，再写提案。
-    output: proposal.md
-
-  - id: specs
-    name: 规范
-    description: 系统必须做什么？（行为契约，不是实现计划）
-    requires:
-      - proposal
-    template: spec.md
-    instruction: |
-      创建 Delta 规范。使用增量操作描述变更：
-      - ADDED Requirements: 新增的需求
-      - MODIFIED Requirements: 修改的需求（包含完整更新内容）
-      - REMOVED Requirements: 移除的需求（含原因和迁移方案）
-      - RENAMED Requirements: 重命名的需求
-      
-      规范是行为契约，描述系统做什么，不描述怎么做。
-      每个需求必须可验证。
-    output: specs/<capability>/spec.md
-
-  - id: design
-    name: 设计
-    description: 怎么做？技术方案和架构决策
-    requires:
-      - proposal
-      - specs
-    template: design.md
-    instruction: |
-      创建技术设计文档。包含：
-      1. 架构决策（ADR 格式）
-      2. 模块划分和接口定义
-      3. 数据模型设计
-      4. 前后端分工
-      5. 关键实现路径
-      
-      如果变更较小（< 3个文件），可以跳过此工件。
-    output: design.md
-    conditional: true
-
-  - id: tasks
-    name: 任务
-    description: 实施步骤（SDD 引擎将逐个执行）
-    requires:
-      - proposal
-      - specs
-      - design
-    template: tasks.md
-    instruction: |
-      创建实现任务列表。每个任务应该：
-      1. 足够小（2-5分钟完成）
-      2. 包含精确的文件路径
-      3. 包含完整的代码或明确的修改指令
-      4. 包含验证步骤
-      5. 任务之间尽量独立（便于 SDD 并行）
-      
-      格式：
-      - [ ] Task 1: <标题>
-        <详细描述，包含精确文件路径和代码>
-        验证: <如何验证>
-    output: tasks.md

package/.specpow/schemas/spec-driven/templates/design.md

@@ -1,54 +0,0 @@
-# 技术设计: <变更名称>
-
-## 架构决策
-
-### ADR-001: <决策标题>
-
-**状态**: 已采纳
-
-**背景**: <为什么需要这个决策>
-
-**决策**: <选择了什么方案>
-
-**备选方案**:
-- 方案 A: <描述> — 优点/缺点
-- 方案 B: <描述> — 优点/缺点
-
-**后果**: <这个决策带来的影响>
-
----
-
-## 模块划分
-
-```
-<模块图>
-```
-
-## 接口定义
-
-### <接口名>
-
-- **路径**: `METHOD /api/xxx`
-- **请求**: 
-- **响应**: 
-- **错误码**: 
-
-## 数据模型
-
-### <表名/实体名>
-
-| 字段 | 类型 | 说明 | 约束 |
-|------|------|------|------|
-|      |      |      |      |
-
-## 前后端分工
-
-| 功能 | 前端 | 后端 | 说明 |
-|------|------|------|------|
-|      |      |      |      |
-
-## 关键实现路径
-
-1. <步骤 1>
-2. <步骤 2>
-3. <步骤 3>

package/.specpow/schemas/spec-driven/templates/proposal.md

@@ -1,31 +0,0 @@
-# 变更提案: <变更名称>
-
-## 动机
-
-为什么要做这个变更？解决什么问题？
-
-## 目标
-
-- 目标 1
-- 目标 2
-
-## 成功标准
-
-- [ ] 标准 1
-- [ ] 标准 2
-
-## 影响范围
-
-- 影响的模块：
-- 影响的接口：
-- 影响的数据表：
-
-## 风险评估
-
-| 风险 | 影响 | 概率 | 应对 |
-|------|------|------|------|
-|      |      |      |      |
-
-## 非目标
-
-明确列出这次不做什么。

package/.specpow/schemas/spec-driven/templates/spec.md

@@ -1,42 +0,0 @@
-# 规范: <能力路径>
-
-## ADDED
-
-### Requirement: <需求标题>
-
-**描述**: <系统应该做什么>
-
-**验收标准**:
-- Given <前置条件>
-- When <操作>
-- Then <预期结果>
-
-**约束**:
-- <性能/安全/兼容性约束>
-
----
-
-## MODIFIED
-
-### Requirement: <需求标题>
-
-**变更原因**: <为什么修改>
-
-**更新内容**:
-<完整的新需求描述>
-
----
-
-## REMOVED
-
-### Requirement: <需求标题>
-
-**移除原因**: <为什么移除>
-
-**迁移方案**: <现有用户/数据如何处理>
-
----
-
-## RENAMED
-
-### <旧需求名称> → <新需求名称>

package/.specpow/schemas/spec-driven/templates/tasks.md

@@ -1,98 +0,0 @@
-# 实现任务: <变更名称>
-
-> 这些任务将由 SDD (子代理驱动开发) 引擎逐个执行。
-> 每个任务应该足够小（2-5分钟），包含精确的文件路径和验证步骤。
-
-## 任务定义格式
-
-**推荐格式：YAML Frontmatter**（结构化、易解析、支持依赖关系）
-
-```yaml
----
-tasks:
-  - number: 1
-    title: <任务标题>
-    files:
-      - path/to/file.ts
-    description: <精确的实现指令>
-    verification: <验证步骤>
-    dependsOn: []
-    estimatedEffort: S  # S | M | L
----
-```
-
-**备选格式：Markdown Checkbox**（向后兼容）
-
-```markdown
-- [ ] **Task 1**: <任务标题>
-  **文件**: `path/to/file.ts`
-  **描述**: <精确的实现指令>
-  **验证**: <验证步骤>
-```
-
----
-
-## YAML Frontmatter 格式（推荐）
-
----
-tasks:
-  - number: 1
-    title: <任务标题>
-    files:
-      - path/to/file.ts
-    description: |
-      <精确的实现指令，包含具体的代码或修改>
-    verification: <验证步骤>
-    dependsOn: []
-    estimatedEffort: S
-
-  - number: 2
-    title: <任务标题>
-    files:
-      - path/to/file.ts
-      - path/to/other.ts
-    description: |
-      <精确的实现指令>
-    verification: <验证步骤>
-    dependsOn: [1]
-    estimatedEffort: M
----
-
----
-
-## Markdown Checkbox 格式（备选）
-
-- [ ] **Task 1**: <任务标题>
-
-  **文件**: `path/to/file.ts`
-
-  **描述**:
-  <精确的实现指令，包含具体的代码或修改>
-
-  **验证**:
-  - [ ] <验证步骤 1>
-  - [ ] <验证步骤 2>
-
----
-
-- [ ] **Task 2**: <任务标题>
-
-  **文件**: `path/to/file.ts`, `path/to/other.ts`
-
-  **描述**:
-  <精确的实现指令>
-
-  **验证**:
-  - [ ] <验证步骤>
-
----
-
-- [ ] **Task 3**: <任务标题>
-
-  **文件**: `path/to/file.ts`
-
-  **描述**:
-  <精确的实现指令>
-
-  **验证**:
-  - [ ] <验证步骤>

package/.specpow/skills/business-code-review/SKILL.md

@@ -1,78 +0,0 @@
----
-name: business-code-review
-description: SpecPow business-code-review skill
----
-
-# 代码审查
-
-> 对变更进行结构化代码审查，输出审查报告
-
-## 触发条件
-
-- 用户要求审查代码 / review
-- SDD 引擎的审查阶段 - 提交 PR/MR 前
-
-## 铁律
-
-1. **不主观臆断** — 每个 Finding 必须有代码行号引用
-2. **分级明确** — Critical / Major / Minor / Suggestion
-3. **可操作** — 每个 Finding 附带修复建议
-4. **不阻塞小问题** — Suggestion 不阻塞合并
-
-## 审查维度
-
-### 1. 规范合规性
-- 命名规范（类名、方法名、变量名）
-- 代码分层（Controller 不写业务逻辑）
-- 注释完整性
-
-### 2. 代码质量
-- 重复代码
-- 过长方法（>50 行）
-- 过深嵌套（>3 层）
-- 魔法数字
-
-### 3. 安全性
-- SQL 注入风险
-- XSS 风险
-- 敏感信息硬编码
-- 权限校验缺失
-
-### 4. 性能
-- N+1 查询
-- 大对象未分页
-- 循环内数据库调用
-- 未使用索引的查询
-
-### 5. 测试
-- 新增代码是否有测试
-- 测试是否覆盖关键路径
-- Mock 使用是否合理
-
-## 输出格式
-
-```markdown
-# 代码审查报告
-
-## 概要
-- 审查范围: commit abc123..def456
-- 文件数: 12
-- 发现数: 5 (1 Critical, 2 Major, 2 Minor)
-
-## 发现
-
-### [Critical] SQL 注入风险
-- 文件: `XxxMapper.java:45`
-- 问题: 使用字符串拼接构建 SQL
-- 建议: 使用参数化查询 #{param}
-
-### [Major] 缺少事务注解
-- 文件: `XxxServiceImpl.java:78`
-- 问题: 多步数据库操作未加 @Transactional
-- 建议: 添加 @Transactional(rollbackFor = Exception.class)
-```
-
-## 红旗
-
-- 发现 Critical 级别问题 → 必须修复后才能合并
-- 安全漏洞 → 立即通知负责人

package/.specpow/skills/business-db-design/SKILL.md

@@ -1,74 +0,0 @@
----
-name: business-db-design
-description: SpecPow business-db-design skill
----
-
-# 数据库设计
-> 根据 PRD 或需求描述，设计数据库表结构，输出 DDL + 索引建议 + 状态码
-
-## 触发条件
-
-- 用户要求设计数据库/表结构
-- PRD 中包含数据模型需求
-- 用户提到"建表"/"DDL"/"字段设计"
-
-## 铁律
-
-1. **命名规范** — 表名小写下划线，字段名小写下划线
-2. **必备字段** — id, create_time, update_time, is_deleted
-3. **索引合理** — 查询条件建索引，不滥用联合索引
-4. **注释完整** — 表注释、字段注释、枚举值说明
-
-## 工作流
-
-### 阶段 1：需求分析
-1. 读取 PRD 或需求描述
-2. 识别实体和关系（1:1, 1:N, M:N）
-3. 确认字段列表和数据类型
-4. 识别查询场景（决定索引策略）
-
-### 阶段 2：表结构设计
-
-**每个表包含：**
-```sql
-CREATE TABLE `table_name` (
-  `id` bigint(20) NOT NULL AUTO_INCREMENT COMMENT '主键ID',
-  -- 业务字段
-  `create_by` varchar(64) DEFAULT '' COMMENT '创建人',
-  `create_time` datetime DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',
-  `update_by` varchar(64) DEFAULT '' COMMENT '更新人',
-  `update_time` datetime DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '更新时间',
-  `is_deleted` tinyint(1) DEFAULT 0 COMMENT '逻辑删除(0正常 1删除)',
-  PRIMARY KEY (`id`),
-  -- 索引
-) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='表注释';
-```
-
-### 阶段 3：索引设计
-- 等值查询字段 → 单列索引
-- 范围查询 → 联合索引（最左前缀）
-- 唯一约束 → UNIQUE 索引
-- 避免过多索引（单表 ≤ 5 个）
-
-### 阶段 4：状态码/枚举分配
-
-```
-字段: status
-0 - 草稿
-1 - 待审核
-2 - 已通过
-3 - 已拒绝
-```
-
-## 输出格式
-
-1. DDL 脚本（可直接执行）
-2. 索引建议说明
-3. 枚举值对照表
-4. ER 关系图（Mermaid）
-
-## 红旗
-
-- 字段超过 30 个 → 考虑拆表
-- 需要 TEXT/BLOB → 确认是否应该独立表
-- 多对多关系 → 确认中间表设计

package/.specpow/skills/business-deploy-check/SKILL.md

@@ -1,72 +0,0 @@
----
-name: business-deploy-check
-description: SpecPow business-deploy-check skill
----
-
-# 部署检查
-> 在部署前执行全面检查，确保代码、配置、依赖就绪
-
-## 触发条件
-
-- 用户提到"部署"/"发布"/"上线"
-- 准备合并到主分支前
-- CI/CD 流水线触发前
-
-## 检查清单
-
-### 1. 代码完整性
-- [ ] 所有任务已完成（tasks.md 全部 [x]）
-- [ ] 无未提交的变更（git status clean）
-- [ ] 分支已 rebase 到最新主分支
-
-### 2. 构建验证
-- [ ] 后端编译通过（mvn clean package）
-- [ ] 前端构建通过（npm run build）
-- [ ] 无编译警告（或警告已评估）
-
-### 3. 测试验证
-- [ ] 单元测试全部通过
-- [ ] 测试覆盖率 ≥ 阈值
-- [ ] 集成测试通过（如有）
-
-### 4. 配置检查
-- [ ] 环境变量已配置
-- [ ] 数据库变更脚本已准备
-- [ ] 配置文件无硬编码敏感信息
-- [ ] 多环境配置一致（dev/test/prod）
-
-### 5. 依赖检查
-- [ ] 无 SNAPSHOT 版本依赖
-- [ ] 新增依赖已审批
-- [ ] 依赖安全扫描通过
-
-### 6. 文档检查
-- [ ] API 文档已更新
-- [ ] 变更日志已编写
-- [ ] 运维手册已更新（如需要）
-
-## 输出格式
-
-```markdown
-# 部署检查报告
-
-## 检查结果: ✅ 通过 / ❌ 未通过
-
-### 通过项 (8/10)
-- ✅ 代码完整性
-- ✅ 构建验证
-...
-
-### 未通过项
-- ❌ 测试覆盖率 58% < 60% 阈值
-  - 建议: 补充 XxxService 的测试用例
-
-### 风险提示
-- 新增依赖: xxx-lib 2.0.0（首次引入）
-```
-
-## 红旗
-
-- 任何"代码完整性"检查失败 → 阻止部署
-- 安全扫描发现高危漏洞 → 阻止部署
-- 配置不一致 → 警告并确认

package/.specpow/skills/business-doc-sync/SKILL.md

@@ -1,72 +0,0 @@
----
-name: business-doc-sync
-description: SpecPow business-doc-sync skill
----
-
-# 文档同步
-
-> 确保代码变更后，相关文档同步更新
-
-## 触发条件
-
-- 代码变更完成后
-- API 接口发生变化
-- 数据库结构发生变更
-- 用户提到"更新文档"/"同步文档"
-
-## 铁律
-
-1. **代码即文档** — 代码变更必须伴随文档更新
-2. **自动检测** — 扫描变更文件，识别需要同步的文档
-3. **不遗漏** — API、数据库、配置变更必须同步
-
-## 检查维度
-
-### 1. API 文档
-- Controller 变更 → 更新 Swagger/接口文档
-- 新增接口 → 添加接口说明
-- 修改参数 → 更新参数说明
-- 删除接口 → 标记废弃
-
-### 2. 数据库文档
-- DDL 变更 → 更新数据字典
-- 新增表 → 添加表说明
-- 修改字段 → 更新字段说明
-
-### 3. 配置文档
-- 新增配置项 → 更新配置说明
-- 修改默认值 → 更新配置示例
-
-### 4. README / CHANGELOG
-- 功能变更 → 更新 README
-- 版本发布 → 编写 CHANGELOG
-
-## 工作流
-
-1. **扫描变更** — 获取 git diff 或变更文件列表
-2. **识别影响** — 判断哪些文档需要同步
-3. **生成更新** — 自动更新受影响的文档
-4. **验证一致性** — 检查文档与代码是否一致
-
-## 输出格式
-
-```markdown
-# 文档同步报告
-
-## 需要同步的文档 (3)
-1. `docs/api/user-api.md` — 新增 2 个接口
-2. `docs/data-dictionary.md` — 新增 1 张表
-3. `CHANGELOG.md` — 添加 v1.2.0 变更记录
-
-## 已自动更新
-- ✓ docs/api/user-api.md
-- ✓ docs/data-dictionary.md
-
-## 需要手动确认
-- ⚠️ README.md — 建议添加新功能说明
-```
-
-## 红旗
-
-- API 变更但无文档更新 → 警告
-- 数据库变更但数据字典未更新 → 警告

package/.specpow/skills/business-java-codegen/SKILL.md

@@ -1,97 +0,0 @@
----
-name: business-java-codegen
-description: SpecPow business-java-codegen skill
----
-
-# Java 代码生成
-
-> 根据设计文档和数据库表结构，生成符合项目规范的 Java 后端代码（Entity/Mapper/Service/Controller 四层）
-
-## 技术栈配置
-
-本技能的**默认**技术栈为 MyBatis-Plus + Spring Boot，但会根据项目实际使用的框架自动适配：
-
-- **ORM 框架** — 优先使用项目已有的 ORM（MyBatis-Plus / JPA / MyBatis / JDBC Template）
-- **基类** — 扫描项目已有 BaseEntity、BaseController 等基类并继承
-- **包名规范** — 从已有代码推断包结构，而非硬编码
-- **返回格式** — 使用项目已有的统一返回类型（Result / Response / ApiResponse）
-
-如果项目无已有代码可参考，则在阶段 1 询问用户确认技术选型。
-
-## 触发条件
-
-- 用户要求生成 Java 代码
-- 执行 apply-change 时涉及后端任务
-- 用户提到"生成接口"/"写 Service"/"创建 Controller"
-
-## 铁律
-
-1. **先查 DB 再生成** — 必须确认表结构已存在，字段名以数据库为准
-2. **四层齐全** — Entity、Mapper(XML)、Service(Interface+Impl)、Controller 缺一不可
-3. **不造轮子** — 使用项目已有的基类（BaseEntity、BaseController 等）
-4. **注释完整** — 类注释、方法注释、关键逻辑行注释
-
-## 工作流
-
-### 阶段 1：上下文收集
-
-1. 读取 design.md 获取接口定义和数据模型
-2. 查询数据库表结构（DDL 或已有 Entity）
-3. **扫描项目已有代码，识别技术栈**（ORM 框架、基类、包名、返回格式）
-4. 如果项目无已有代码，询问用户确认技术选型
-
-### 阶段 2：代码生成
-
-按以下顺序生成：
-
-**2.1 Entity（实体类）**
-```
-- 继承 BaseEntity（如有）
-- 字段与数据库列一一对应
-- 使用 @Table、@Column 注解
-- 包含 getter/setter 或 @Data
-```
-
-**2.2 Mapper（数据访问层）**
-```
-- 继承 BaseMapper<T>（MyBatis-Plus）或对应基类
-- 自定义 SQL 写在 XML 中
-- 复杂查询方法命名：select + By + 条件
-```
-
-**2.3 Service（业务逻辑层）**
-```
-- 接口 + 实现分离
-- 继承 IService<T> / ServiceImpl（如有基类）
-- 事务注解 @Transactional 加在实现类方法上
-- 业务异常使用自定义 BusinessException
-```
-
-**2.4 Controller（控制层）**
-```
-- 继承 BaseController（如有）
-- RESTful 风格：GET 查询、POST 创建、PUT 更新、DELETE 删除
-- 参数校验使用 @Valid + DTO
-- 统一返回 Result<T> 格式
-```
-
-### 阶段 3：验证
-
-1. 编译检查：确保无语法错误
-2. 依赖检查：所有 import 可解析
-3. 规范检查：命名、注释、分层符合规范
-
-## 输出格式
-
-每个文件输出时标注：
-```
-文件: src/main/java/com/company/xxx/entity/XxxEntity.java
-类型: Entity
-依赖: BaseEntity, Lombok
-```
-
-## 红旗（立即停止）
-
-- 数据库表不存在 → 先执行 DB 设计
-- 项目无基类且用户未指定 → 询问用户
-- 发现已有同名类 → 报告冲突，不覆盖