@chongyan/autospec 1.0.1

package/knowledge/templates/database-design.md

@@ -0,0 +1,132 @@
+# 数据库设计模板
+
+> 规范化数据库设计文档，确保数据模型清晰、一致。
+
+## 使用说明
+
+1. 每个数据库或模块使用独立的 .md 文件
+2. 文件命名：`{数据库名}-{模块名}.md`，如 `order-db.md`
+3. 表结构变更需更新版本历史
+
+## 数据库概述
+
+| 字段 | 值 |
+|------|-----|
+| 数据库名 | {database_name} |
+| 数据库类型 | MySQL / PostgreSQL / MongoDB |
+| 字符集 | utf8mb4 |
+| 排序规则 | utf8mb4_unicode_ci |
+
+## ER 图
+
+```mermaid
+erDiagram
+    USER ||--o{ ORDER : places
+    USER {
+        bigint id PK
+        varchar username
+        varchar email
+        datetime created_at
+    }
+    ORDER ||--|{ ORDER_ITEM : contains
+    ORDER {
+        bigint id PK
+        bigint user_id FK
+        decimal total_amount
+        varchar status
+        datetime created_at
+    }
+    ORDER_ITEM {
+        bigint id PK
+        bigint order_id FK
+        bigint product_id FK
+        int quantity
+        decimal price
+    }
+```
+
+## 表结构
+
+### {表名}
+
+**表说明**：{表的业务含义}
+
+| 字段名 | 类型 | 可空 | 默认值 | 说明 |
+|-------|------|------|-------|------|
+| id | BIGINT | 否 | AUTO_INCREMENT | 主键 |
+| {field} | VARCHAR(255) | 否 | - | {说明} |
+| created_at | DATETIME | 否 | CURRENT_TIMESTAMP | 创建时间 |
+| updated_at | DATETIME | 否 | CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP | 更新时间 |
+
+**索引设计**
+
+| 索引名 | 类型 | 字段 | 说明 |
+|-------|------|------|------|
+| PRIMARY | 主键 | id | 聚簇索引 |
+| idx_{field} | 普通 | {field} | 查询优化 |
+| uk_{field} | 唯一 | {field} | 唯一约束 |
+
+**DDL 语句**
+
+```sql
+CREATE TABLE `{table_name}` (
+  `id` BIGINT NOT NULL AUTO_INCREMENT,
+  `{field}` VARCHAR(255) NOT NULL COMMENT '{说明}',
+  `created_at` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,
+  `updated_at` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
+  PRIMARY KEY (`id`),
+  INDEX `idx_{field}` (`{field}`)
+) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci COMMENT='{表说明}';
+```
+
+## 字段命名规范
+
+| 规则 | 示例 |
+|------|------|
+| 主键 | `id` |
+| 外键 | `{referenced_table}_id` |
+| 布尔值 | `is_{action}` / `has_{feature}` |
+| 时间 | `{action}_at` / `{action}_time` |
+| 数量 | `{entity}_count` / `{entity}_num` |
+| 金额 | `{entity}_amount` / `{entity}_fee` |
+
+## 状态枚举
+
+### {状态类型}
+
+| 值 | 名称 | 说明 |
+|-----|------|------|
+| 0 | INIT | 初始状态 |
+| 1 | PROCESSING | 处理中 |
+| 2 | SUCCESS | 成功 |
+| 3 | FAILED | 失败 |
+| -1 | CANCELLED | 已取消 |
+
+## 数据一致性保障
+
+### 事务边界
+
+| 场景 | 事务范围 | 隔离级别 |
+|------|---------|---------|
+| {场景1} | {表列表} | READ COMMITTED |
+| {场景2} | {表列表} | READ COMMITTED |
+
+### 并发控制
+
+| 场景 | 控制方式 | 说明 |
+|------|---------|------|
+| 库存扣减 | 乐观锁 | version 字段 |
+| 余额变更 | 悲观锁 | SELECT FOR UPDATE |
+| 订单创建 | 分布式锁 | Redis Lock |
+
+## 版本历史
+
+| 版本 | 日期 | 修改人 | 修改说明 |
+|-----|------|--------|---------|
+| v1.0 | YYYY-MM-DD | | 初始版本 |
+
+---
+
+**维护者**: 后端团队
+**进化分区**: 受控区
+**关联文档**: `design-knowledge/architecture/{name}.md`

package/knowledge/templates/domain-driven-design.md

@@ -0,0 +1,321 @@
+# 领域驱动设计: {项目/系统名}
+
+> **版本**: v1.0
+> **模板来源**: Eric Evans《领域驱动设计》、Vaughn Vernon《实现领域驱动设计》、Microsoft Azure官方指南、DDD Crew最佳实践
+> **适用范围**: 复杂业务系统、核心业务建模、微服务边界划分
+> **生成模式**: 战略设计 → 战术设计 → 实现约束
+
+---
+
+## 1. 战略设计
+
+### 1.1 领域识别
+
+> 识别问题空间，划分核心域、支撑域、通用域
+
+| 领域类型 | 领域名称 | 描述 | 业务价值 | 投入建议 |
+|---------|---------|------|---------|---------|
+| 核心域 | | 核心竞争力，必须自研 | | 重点投入 |
+| 支撑域 | | 支撑核心业务，可外包 | | 适度投入 |
+| 通用域 | | 通用能力，可用现成方案 | | 最小投入 |
+
+**核心域识别标准**：
+- 是否是业务核心竞争力？
+- 是否需要定制开发？
+- 是否难以被替代？
+
+### 1.2 限界上下文
+
+> 定义解空间边界，每个上下文内有独立的统一语言
+
+| 上下文名称 | 职责边界 | 包含聚合 | 统一语言关键术语 | 技术栈 |
+|-----------|---------|---------|-----------------|--------|
+| | | | | |
+
+**限界上下文划分原则**：
+- 按业务能力划分（推荐）
+- 按子域划分
+- 边界内语言一致性
+- 边界间松耦合
+
+### 1.3 上下文映射图
+
+```mermaid
+graph LR
+    subgraph 核心域
+        A[上下文A]
+        B[上下文B]
+    end
+
+    subgraph 支撑域
+        C[上下文C]
+    end
+
+    subgraph 通用域
+        D[上下文D]
+    end
+
+    A -->|模式| B
+    A -->|模式| C
+    B -->|模式| D
+```
+
+### 1.4 上下文集成模式
+
+| 上游上下文 | 下游上下文 | 集成模式 | 说明 | 通信方式 |
+|-----------|-----------|---------|------|---------|
+| | | Partnership | 伙伴关系，共同演进 | 同步/异步 |
+| | | Shared Kernel | 共享内核，共享部分模型 | 共享库 |
+| | | Customer/Supplier | 客户-供应商，下游有话语权 | API |
+| | | Conformist | 跟随者，下游适应上游 | API |
+| | | Anticorruption Layer | 防腐层，隔离外部模型 | 适配器 |
+| | | Open Host Service | 开放主机服务，公开API | REST/gRPC |
+| | | Published Language | 发布语言，共享文档 | Schema |
+
+**集成模式选择指南**：
+
+| 场景 | 推荐模式 |
+|------|---------|
+| 同一团队，紧密协作 | Partnership |
+| 共享核心逻辑 | Shared Kernel |
+| 下游有议价权 | Customer/Supplier |
+| 下游无议价权 | Conformist |
+| 外部系统集成 | Anticorruption Layer |
+| 对外提供服务 | Open Host Service |
+
+---
+
+## 2. 战术设计
+
+### 2.1 统一语言术语表
+
+> 每个限界上下文有独立的术语表，消除沟通歧义
+
+| 术语 | 英文 | 定义 | 所属上下文 | 代码命名 |
+|-----|------|------|-----------|---------|
+| | | | | |
+
+**术语分类**：
+- 业务实体：订单、用户、商品...
+- 业务动作：下单、支付、发货...
+- 业务状态：待支付、已支付、已取消...
+- 业务规则：限额、时效、条件...
+
+### 2.2 聚合设计
+
+> 聚合是一致性边界，包含实体和值对象
+
+| 聚合名称 | 聚合根 | 实体 | 值对象 | 不变量规则 | 所属上下文 |
+|---------|--------|------|--------|-----------|-----------|
+| | | | | | |
+
+**聚合设计原则**：
+- 小聚合优于大聚合
+- 通过ID引用其他聚合
+- 聚合边界 = 一致性边界 = 事务边界
+- 聚合根是唯一入口
+
+### 2.3 聚合根详情
+
+#### {聚合名称}
+
+**标识**: {聚合根ID字段}
+
+**属性**:
+| 字段名 | 类型 | 说明 | 是否值对象 |
+|-------|------|------|-----------|
+| | | | |
+
+**行为**:
+| 方法名 | 前置条件 | 后置条件 | 领域事件 | 业务规则 |
+|-------|---------|---------|---------|---------|
+| | | | | |
+
+**不变量**:
+- 不变量1：{描述}
+- 不变量2：{描述}
+
+**状态机**:
+```mermaid
+stateDiagram-v2
+    [*] --> 初始状态
+    初始状态 --> 状态A: 事件1
+    状态A --> 状态B: 事件2
+    状态B --> [*]: 事件3
+```
+
+### 2.4 领域服务
+
+> 不属于任何实体/值对象的领域操作
+
+| 服务名称 | 职责 | 操作的聚合 | 领域事件 | 无状态 |
+|---------|------|-----------|---------|--------|
+| | | | | ✅ |
+
+**领域服务识别标准**：
+- 涉及多个聚合的协调
+- 不自然属于任何实体
+- 无状态操作
+
+### 2.5 领域事件
+
+> 领域中发生的业务事实，用于聚合间通信
+
+| 事件名称 | 触发条件 | 携带数据 | 发布方 | 订阅方 | 异步 |
+|---------|---------|---------|--------|--------|------|
+| | | | | | |
+
+**领域事件命名规范**：
+- 过去时：OrderCreated, PaymentCompleted
+- 业务语义：描述发生了什么
+- 不可变：事件一旦发生不可修改
+
+### 2.6 仓储接口
+
+> 聚合的持久化抽象，隔离领域层与基础设施
+
+| 仓储名称 | 对应聚合 | 查询方法 | 持久化要求 |
+|---------|---------|---------|-----------|
+| | | | |
+
+**仓储设计规则**：
+- 只按聚合根ID查询
+- 返回完整的聚合（不返回部分）
+- 集合语义：Add, Remove, Get
+- 不暴露SQL细节
+
+---
+
+## 3. 实现约束
+
+### 3.1 聚合边界规则
+
+**强一致性**（聚合内部）：
+- 聚合内部状态变更必须保证强一致性
+- 单个聚合 = 单个事务
+- 聚合根负责维护内部一致性
+
+**最终一致性**（聚合之间）：
+- 聚合之间通过领域事件通信
+- 不允许跨聚合的直接调用
+- 接受最终一致性
+
+**访问规则**：
+- 聚合根是唯一入口
+- 外部不可直接操作内部实体
+- 通过聚合根方法修改内部状态
+
+### 3.2 仓储规则
+
+| 规则 | 说明 | 原因 |
+|------|------|------|
+| 只按ID查询 | 不支持复杂查询 | 保持聚合完整性 |
+| 返回完整聚合 | 不返回部分属性 | 保证不变量 |
+| 持久化原子性 | 整个聚合一起保存 | 保证一致性 |
+| 延迟加载 | 按需加载关联聚合 | 性能优化 |
+
+### 3.3 领域事件规则
+
+| 规则 | 说明 |
+|------|------|
+| 命名规范 | 过去时（OrderCreated, PaymentCompleted） |
+| 不可变 | 事件一旦发生不可修改 |
+| 幂等处理 | 同一事件多次处理结果相同 |
+| 版本控制 | 事件结构变更需版本管理 |
+
+---
+
+## 4. 反模式警示
+
+| 反模式 | 症状 | 风险 | 正确做法 |
+|--------|------|------|---------|
+| 贫血模型 | 只有getter/setter，无行为 | 业务逻辑散落，难以维护 | 富领域模型，行为内聚 |
+| 大聚合 | 聚合包含过多实体 | 并发冲突、性能问题 | 小聚合，按一致性边界划分 |
+| 跨聚合直接引用 | 聚合A直接持有聚合B对象 | 破坏聚合边界 | 通过ID引用 |
+| 领域服务滥用 | 服务承载所有逻辑 | 过程式代码，失去DDD价值 | 优先放在聚合根 |
+| 忽略统一语言 | 代码与业务术语不一致 | 沟通成本高，易出错 | 重构命名，保持一致 |
+| 仓储暴露SQL | 仓储返回部分字段 | 破坏聚合完整性 | 返回完整聚合 |
+| 事件丢失 | 事件发布后未持久化 | 数据不一致 | 事件溯源或发件箱模式 |
+
+---
+
+## 5. 与AutoSpec流程融合
+
+### 需求阶段 → 战略设计
+- 业务域拆解 → 子领域识别（核心域/支撑域/通用域）
+- 用例分析 → 限界上下文边界识别
+- 业务流程 → 上下文集成关系
+
+### 设计阶段 → 战术设计
+- 系统设计 → 聚合设计、领域模型
+- 接口设计 → 领域服务、仓储接口
+- 数据库设计 → 聚合持久化映射
+
+### 实现阶段
+- 代码结构按聚合组织
+- 领域事件驱动解耦
+- 仓储隔离持久化细节
+
+---
+
+## 附录：DDD核心概念速查
+
+### 战略设计概念
+
+| 概念 | 定义 | 关键点 |
+|------|------|--------|
+| 统一语言 Ubiquitous Language | 团队共享的业务术语 | 消除沟通歧义 |
+| 领域 Domain | 问题空间 | 业务问题域 |
+| 子领域 Subdomain | 领域的细分 | 核心域、支撑域、通用域 |
+| 限界上下文 Bounded Context | 解空间边界 | 语言一致性范围 |
+| 上下文映射 Context Map | 上下文间关系 | 集成模式选择 |
+
+### 战术设计概念
+
+| 概念 | 定义 | 关键特征 |
+|------|------|---------|
+| 实体 Entity | 有唯一标识的对象 | ID标识、可变、生命周期 |
+| 值对象 Value Object | 无标识、不可变对象 | 不可变、可替换、相等性 |
+| 聚合 Aggregate | 一致性边界 | 聚合根、事务原子性 |
+| 领域服务 Domain Service | 跨聚合操作 | 无状态、领域概念 |
+| 领域事件 Domain Event | 业务事实 | 过去时、不可变 |
+| 仓储 Repository | 持久化抽象 | 集合语义、按ID查询 |
+| 工厂 Factory | 创建逻辑封装 | 复杂对象创建 |
+
+---
+
+## 模板使用说明
+
+### 必填章节
+
+以下章节为必填，缺少则DDD设计不完整：
+
+- [ ] 1.1 领域识别
+- [ ] 1.2 限界上下文
+- [ ] 2.1 统一语言术语表
+- [ ] 2.2 聚合设计
+
+### 可选章节
+
+以下章节根据复杂度选择性填写：
+
+- 1.3 上下文映射图（多上下文时必填）
+- 1.4 上下文集成模式（多上下文时必填）
+- 2.3 聚合根详情（核心聚合必填）
+- 2.4 领域服务（有跨聚合操作时填写）
+- 2.5 领域事件（有事件驱动时填写）
+- 2.6 仓储接口（有持久化时填写）
+
+### 最佳实践
+
+1. **先战略后战术**：先划分限界上下文，再设计聚合
+2. **小步迭代**：从核心域开始，逐步完善
+3. **统一语言优先**：术语不一致时先解决术语问题
+4. **反模式警觉**：定期检查是否陷入反模式
+5. **适度设计**：简单场景不过度设计
+
+---
+
+**维护者**: AutoSpec 团队
+**进化分区**: 🟡 受控区
+**关联文档**: `knowledge/guides/domain-driven-design.md`, `knowledge/domain/glossary.md`

package/knowledge/templates/product-proposal.md

@@ -0,0 +1,201 @@
+# Proposal: {需求名称}
+
+> **版本**: v1.0
+> **模板来源**: 业界需求工程最佳实践 / 结构化需求分析方法
+> **适用范围**: 所有需求提案文档
+
+---
+
+## 1. 背景与价值
+
+### 1.1 业务背景
+
+{描述业务背景：当前面临的问题、市场机会、用户需求等}
+
+### 1.2 业务价值 (Why)
+
+{描述为什么要做这个需求，预期的业务价值是什么}
+
+---
+
+## 2. 目标与范围
+
+### 2.1 目标 (Success Criteria)
+
+{用可衡量的指标描述成功标准，例如：
+- 支持 X 场景
+- 性能提升 Y%
+- 用户体验改善（具体指标）
+}
+
+### 2.2 范围 (包含/不包含)
+
+**包含**:
+- {功能范围 1}
+- {功能范围 2}
+
+**不包含**:
+- {明确排除的范围 1}
+- {明确排除的范围 2}
+
+---
+
+## 3. 业务架构设计
+
+### 3.1 总体架构图
+
+```mermaid
+flowchart TB
+    subgraph 功能域 1
+        A[模块 A] --> B[模块 B]
+    end
+
+    subgraph 功能域 2
+        C[模块 C] --> D[模块 D]
+    end
+```
+
+### 3.2 需求用例图
+
+```mermaid
+flowchart TB
+    subgraph 角色 1
+        A[用例 A]
+        B[用例 B]
+    end
+
+    subgraph 角色 2
+        C[用例 C]
+    end
+```
+
+### 3.3 业务域拆解
+
+| 场景类型 | 是否涉及 | 业务域 | 识别依据 |
+|---------|---------|--------|---------|
+| 银行/机构对接 | Y/N | {业务域名称} | {识别依据} |
+| 数据管道 | Y/N | {业务域名称} | {识别依据} |
+| AI/模型 | Y/N | {业务域名称} | {识别依据} |
+
+### 3.4 资金流方案 (涉及资金链路时必须)
+
+```mermaid
+flowchart LR
+    账户 A -->|金额/时间 | 账户 B
+    账户 B -->|金额/时间 | 账户 C
+```
+
+### 3.5 用例业务流程
+
+#### 3.5.1 用例 1: {用例名}
+
+```mermaid
+sequenceDiagram
+    participant U as 用户
+    participant S as 系统
+    participant D as 下游
+
+    U->>S: 1. 请求
+    S->>D: 2. 调用
+    D-->>S: 3. 响应
+    S-->>U: 4. 结果
+```
+
+#### 3.5.2 用例 2: {用例名}
+
+{同上}
+
+### 3.6 跨域接口 (概要)
+
+| 接口名 | 调用方 | 被调用方 | 协议 | 说明 |
+|-------|--------|---------|------|------|
+| {接口 1} | {系统 A} | {系统 B} | HTTP/RPC | {说明} |
+
+### 3.7 数据一致性保障
+
+{描述数据一致性方案：
+- 分布式事务（2PC/SAGA）
+- 中间态 + 定时任务重试
+- 消息队列（RocketMQ）
+}
+
+---
+
+## 4. 关键决策
+
+| 决策点 | 选项 | 决策 | 理由 |
+|-------|------|------|------|
+| {决策 1} | 选项 A/B | {决策} | {理由} |
+
+---
+
+## 5. 风险与缓解
+
+| 风险项 | 影响 | 概率 | 缓解措施 |
+|-------|------|------|---------|
+| {风险 1} | 高/中/低 | 高/中/低 | {措施} |
+
+---
+
+## 6. 非目标与约束
+
+### 6.1 非目标
+
+{明确说明本次需求不包含的内容}
+
+### 6.2 知识库缺失识别
+
+| 缺失项 | 影响 | 补充计划 |
+|-------|------|---------|
+| {缺失 1} | {影响} | {计划} |
+
+---
+
+## 7. Open Questions
+
+| 问题 | 提出人 | 日期 | 状态 | 决议 |
+|------|--------|------|------|------|
+| {问题 1} | {人名} | {日期} | Open/Closed | {决议} |
+
+---
+
+## 8. 参考资料
+
+| 类型 | 标题 | 链接 |
+|------|------|------|
+| 需求文档 | {标题} | {链接} |
+| 设计文档 | {标题} | {链接} |
+| 接口文档 | {标题} | {链接} |
+
+---
+
+## 模板使用说明
+
+### 必填章节
+
+以下章节为必填，缺少则提案不完整：
+
+- [ ] 1.1 业务背景
+- [ ] 1.2 业务价值
+- [ ] 2.1 目标
+- [ ] 2.2 范围
+- [ ] 3.2 需求用例图
+- [ ] 3.5 用例业务流程
+
+### 可选章节
+
+以下章节根据需求复杂度选择性填写：
+
+- 3.1 总体架构图（复杂系统需要）
+- 3.3 业务域拆解（涉及多业务域需要）
+- 3.4 资金流方案（涉及资金操作必须）
+- 3.6 跨域接口（涉及跨系统调用需要）
+- 3.7 数据一致性保障（涉及跨系统数据需要）
+
+### 最佳实践
+
+1. **用例原子化**: 每个用例应该是原子的，不可再拆分
+2. **流程图优先**: 能用图表达的不用文字
+3. **明确边界**: 清晰定义包含和不包含的范围
+4. **关键决策记录**: 记录重要技术选型和方案取舍
+5. **风险前置**: 提前识别风险并制定缓解措施