@chongyan/autospec 1.0.1 → 1.0.3

package/knowledge/domain/flows/README.md

@@ -1,194 +0,0 @@
-# 业务流程图规范
-
-> 使用 Mermaid 格式可视化业务流程。
-
-## 流程图规范
-
-### 命名规范
-
-- 文件名：`{流程名}-flow.md`
-- 示例：`order-creation-flow.md`、`user-registration-flow.md`
-
-### 格式规范
-
-每个流程图文件包含以下内容：
-
-```markdown
-# [流程名称]流程
-
-## 流程描述
-（简要说明流程目的和触发条件）
-
-## 流程图
-
-​```mermaid
-flowchart TD
-    A[开始] --> B{条件判断}
-    B -->|是| C[动作1]
-    B -->|否| D[动作2]
-    C --> E[结束]
-    D --> E
-​```
-
-## 异常处理
-（描述异常分支处理方式）
-
-## 相关规则
-- BR-XX: 相关业务规则
-
-## 版本历史
-| 版本 | 日期 | 修改人 | 修改说明 |
-|-----|------|--------|---------|
-| v1.0 | YYYY-MM-DD | | 初始版本 |
-```
-
-## Mermaid 语法参考
-
-### 基本元素
-
-```mermaid
-flowchart TD
-    A[矩形节点] --> B{菱形判断}
-    B -->|是| C((圆形节点))
-    B -->|否| D[[子程序]]
-    C --> E>不对称节点]
-```
-
-### 连线类型
-
-| 语法 | 效果 |
-|------|------|
-| `-->` | 实线箭头 |
-| `---` | 实线无箭头 |
-| `-.->` | 虚线箭头 |
-| `==>` | 粗线箭头 |
-
-### 子图分组
-
-```mermaid
-flowchart TD
-    subgraph 模块A
-        A1[步骤1] --> A2[步骤2]
-    end
-    subgraph 模块B
-        B1[步骤3] --> B2[步骤4]
-    end
-    A2 --> B1
-```
-
-### 样式标记
-
-```mermaid
-flowchart TD
-    A[正常节点] --> B{判断节点}
-    B -->|成功| C[成功节点]
-    B -->|失败| D[失败节点]
-
-    %% 样式定义
-    style C fill:#90EE90
-    style D fill:#FFB6C1
-```
-
-## 流程类型
-
-### 业务主流程
-
-描述核心业务流程，如：下单流程、支付流程...
-
-**特点**：
-- 覆盖完整业务链路
-- 包含所有关键分支
-- 标注关键业务规则
-
-### 异常处理流程
-
-描述异常场景处理，如：超时重试、失败回滚...
-
-**特点**：
-- 明确异常触发条件
-- 描述异常处理步骤
-- 标注恢复机制
-
-### 状态流转图
-
-描述对象状态变化，如：订单状态、任务状态...
-
-**特点**：
-- 使用状态机图（stateDiagram）
-- 标注状态转换条件
-- 明确初始和终止状态
-
-## 与设计阶段的关系
-
-| 阶段 | 使用方式 |
-|------|---------|
-| 需求分析 | 产出业务流程图，描述业务逻辑 |
-| 方案设计 | 产出时序图，需与业务流程图对应 |
-| 测试验证 | 基于流程图设计测试场景 |
-
-## 流程图质量检查
-
-### 完整性检查
-
-- [ ] 有明确的开始和结束节点
-- [ ] 覆盖所有业务场景（正常+异常）
-- [ ] 每个判断节点有明确的分支条件
-- [ ] 异常处理路径完整
-
-### 一致性检查
-
-- [ ] 术语与 glossary.md 一致
-- [ ] 规则引用与 rules.md 一致
-- [ ] 与设计文档的时序图对应
-
-### 可读性检查
-
-- [ ] 节点命名清晰
-- [ ] 分支条件明确
-- [ ] 层次结构合理
-- [ ] 样式标记恰当
-
-## 示例
-
-### 示例：订单创建流程
-
-```markdown
-# 订单创建流程
-
-## 流程描述
-用户提交订单，系统校验后创建订单并支付。
-
-## 流程图
-
-​```mermaid
-flowchart TD
-    A[用户提交订单] --> B{库存校验}
-    B -->|充足| C{价格校验}
-    B -->|不足| D[返回库存不足]
-    C -->|有效| E[创建订单]
-    C -->|无效| F[返回价格异常]
-    E --> G{支付处理}
-    G -->|成功| H[订单完成]
-    G -->|失败| I[订单取消]
-    I --> J[释放库存]
-
-    style D fill:#FFB6C1
-    style F fill:#FFB6C1
-    style H fill:#90EE90
-​```
-
-## 异常处理
-- 库存不足：返回错误，提示用户调整数量
-- 价格异常：返回错误，提示用户刷新重试
-- 支付失败：取消订单，释放库存
-
-## 相关规则
-- BR-01: 库存必须充足才能创建订单
-- BR-02: 订单创建后30分钟内需完成支付
-```
-
----
-
-**维护者**: 项目团队
-**进化分区**: 自由区
-**关联文档**: `knowledge/domain/glossary.md`, `knowledge/domain/rules.md`

package/knowledge/domain/glossary.md

@@ -1,143 +0,0 @@
-# 业务术语表
-
-> 统一业务概念定义，消除沟通歧义。
-
-## 使用说明
-
-1. 每个术语包含：术语名、英文缩写、定义、相关术语、来源
-2. 需求分析阶段自动从需求文档提取候选术语
-3. 术语定义冲突时，以本文档为准
-
-## 术语列表
-
-| 术语 | 缩写 | 定义 | 相关术语 | 来源 |
-|-----|------|------|---------|------|
-| | | | | |
-
-> 空表格，由各项目自行填充
-
-## 自动提取规则
-
-从需求文档中识别候选术语：
-
-| 提取条件 | 说明 |
-|---------|------|
-| 高频词 | 出现次数 > 3 |
-| 首字母缩写 | 如 API、SDK、CRUD |
-| 专用名词 | 如"XX系统"、"XX模块" |
-| 业务概念 | 具有特定业务含义的词 |
-
-提取后需人工确认定义。
-
-## 术语分类
-
-建议按以下分类组织术语：
-
-### 业务实体
-
-业务操作的核心对象，如：订单、用户、商品...
-
-| 术语 | 缩写 | 定义 | 相关术语 | 来源 |
-|-----|------|------|---------|------|
-| | | | | |
-
-### 业务动作
-
-业务操作的行为，如：下单、支付、发货...
-
-| 术语 | 缩写 | 定义 | 相关术语 | 来源 |
-|-----|------|------|---------|------|
-| | | | | |
-
-### 业务状态
-
-业务对象的状态，如：待支付、已支付、已取消...
-
-| 术语 | 缩写 | 定义 | 相关术语 | 来源 |
-|-----|------|------|---------|------|
-| | | | | |
-
-### 业务规则
-
-业务约束条件，如：限额、时效、条件...
-
-| 术语 | 缩写 | 定义 | 相关术语 | 来源 |
-|-----|------|------|---------|------|
-| | | | | |
-
-### 领域模型术语（DDD增强）
-
-领域驱动设计核心概念，用于复杂业务建模。
-
-| 术语 | 缩写 | 定义 | 适用上下文 | 来源 |
-|-----|------|------|-----------|------|
-| 聚合 Aggregate | AGG | 一致性边界内的对象集合，包含实体和值对象 | 设计阶段 | DDD |
-| 聚合根 Aggregate Root | AR | 聚合的唯一入口实体，负责维护聚合内部一致性 | 设计阶段 | DDD |
-| 实体 Entity | - | 有唯一标识的领域对象，具有生命周期和可变状态 | 设计阶段 | DDD |
-| 值对象 Value Object | VO | 无唯一标识、不可变的对象，通过属性值判断相等性 | 设计阶段 | DDD |
-| 领域事件 Domain Event | DE | 领域中发生的业务事实，用于聚合间通信 | 设计阶段 | DDD |
-| 领域服务 Domain Service | DS | 不属于任何实体或值对象的无状态领域操作 | 设计阶段 | DDD |
-| 仓储 Repository | - | 聚合的持久化抽象，提供集合语义的查询和保存 | 设计阶段 | DDD |
-| 工厂 Factory | - | 封装复杂对象创建逻辑，解耦创建与使用 | 设计阶段 | DDD |
-
-### 限界上下文术语（DDD增强）
-
-限界上下文是语言一致性边界，每个上下文有独立的统一语言。
-
-| 术语 | 缩写 | 定义 | 所属上下文 | 来源 |
-|-----|------|------|-----------|------|
-| 限界上下文 Bounded Context | BC | 语言一致性边界，边界内术语含义统一 | 战略设计 | DDD |
-| 上下文映射 Context Map | CM | 描述限界上下文之间关系的图示 | 战略设计 | DDD |
-| 核心域 Core Domain | - | 业务核心竞争力，必须自研重点投入 | 战略设计 | DDD |
-| 支撑域 Supporting Domain | - | 支撑核心业务的能力，可外包 | 战略设计 | DDD |
-| 通用域 Generic Domain | - | 通用能力，可用现成方案 | 战略设计 | DDD |
-| 防腐层 Anticorruption Layer | ACL | 隔离外部模型的适配层，保护内部模型纯净 | 上下文集成 | DDD |
-
-| 术语 | 缩写 | 定义 | 相关术语 | 来源 |
-|-----|------|------|---------|------|
-| | | | | |
-
-### 业务动作
-
-业务操作的行为，如：下单、支付、发货...
-
-| 术语 | 缩写 | 定义 | 相关术语 | 来源 |
-|-----|------|------|---------|------|
-| | | | | |
-
-### 业务状态
-
-业务对象的状态，如：待支付、已支付、已取消...
-
-| 术语 | 缩写 | 定义 | 相关术语 | 来源 |
-|-----|------|------|---------|------|
-| | | | | |
-
-### 业务规则
-
-业务约束条件，如：限额、时效、条件...
-
-| 术语 | 缩写 | 定义 | 相关术语 | 来源 |
-|-----|------|------|---------|------|
-| | | | | |
-
-## 术语冲突处理
-
-当发现术语定义冲突时：
-
-1. **记录冲突**：在需求分析阶段标记
-2. **澄清确认**：与业务方确认准确定义
-3. **更新文档**：更新本文档，标注变更历史
-4. **通知相关方**：通知设计、开发、测试团队
-
-## 版本历史
-
-| 版本 | 日期 | 修改人 | 修改说明 |
-|-----|------|--------|---------|
-| v1.0 | YYYY-MM-DD | | 初始版本 |
-
----
-
-**维护者**: 项目团队
-**进化分区**: 自由区
-**关联文档**: `knowledge/domain/rules.md`

package/knowledge/domain/rules.md

@@ -1,138 +0,0 @@
-# 业务规则库
-
-> 规则ID化，便于追溯和校验。
-
-## 规则格式
-
-每个业务规则包含：
-
-| 字段 | 说明 | 必填 |
-|------|------|------|
-| 规则ID | BR-{NN} 格式，便于追溯 | ✅ |
-| 规则名称 | 简短描述 | ✅ |
-| 规则描述 | 详细说明规则内容 | ✅ |
-| 适用场景 | 何时需要遵守此规则 | ✅ |
-| 校验方式 | 如何检验是否遵守 | ✅ |
-| 来源 | 需求文档章节/业务方确认 | ❌ |
-| 优先级 | P0/P1/P2 | ❌ |
-
-## 规则列表
-
-> 空表格，由各项目自行填充
-
-| 规则ID | 规则名称 | 规则描述 | 适用场景 | 校验方式 | 来源 | 优先级 |
-|--------|---------|---------|---------|---------|------|--------|
-| | | | | | | |
-
-## 规则分类
-
-### 数据校验规则
-
-数据有效性约束，如：格式、范围、必填...
-
-| 规则ID | 规则名称 | 规则描述 | 适用场景 | 校验方式 |
-|--------|---------|---------|---------|---------|
-| | | | | |
-
-### 业务逻辑规则
-
-业务流程约束，如：状态流转、条件判断...
-
-| 规则ID | 规则名称 | 规则描述 | 适用场景 | 校验方式 |
-|--------|---------|---------|---------|---------|
-| | | | | |
-
-### 安全合规规则
-
-安全与合规约束，如：权限、审计、脱敏...
-
-| 规则ID | 规则名称 | 规则描述 | 适用场景 | 校验方式 |
-|--------|---------|---------|---------|---------|
-| | | | | |
-
-### 性能约束规则
-
-性能相关约束，如：响应时间、并发量...
-
-| 规则ID | 规则名称 | 规则描述 | 适用场景 | 校验方式 |
-|--------|---------|---------|---------|---------|
-| | | | | |
-
-### 领域模型规则（DDD增强）
-
-领域驱动设计相关规则，适用于复杂业务系统建模。
-
-| 规则ID | 规则名称 | 规则描述 | 适用场景 | 校验方式 | 来源 |
-|--------|---------|---------|---------|---------|------|
-| DDD-01 | 聚合边界一致性 | 聚合内部必须保证强一致性，单个聚合=单个事务 | 聚合设计 | 代码审查 | DDD |
-| DDD-02 | 聚合根唯一入口 | 外部只能通过聚合根访问聚合内部，不可直接操作内部实体 | 代码实现 | 代码审查 | DDD |
-| DDD-03 | 跨聚合ID引用 | 聚合之间只能通过ID引用，不能直接持有其他聚合对象引用 | 代码实现 | 代码审查 | DDD |
-| DDD-04 | 领域事件幂等 | 事件处理必须幂等，同一事件多次处理结果相同 | 事件处理 | 测试验证 | DDD |
-| DDD-05 | 统一语言一致性 | 代码命名必须与业务术语一致，消除沟通歧义 | 全流程 | 术语表对照 | DDD |
-| DDD-06 | 聚合大小控制 | 聚合应保持小规模，避免并发冲突和性能问题 | 聚合设计 | 设计评审 | DDD |
-| DDD-07 | 仓储查询限制 | 仓储只按聚合根ID查询，不暴露复杂查询能力 | 仓储设计 | 接口审查 | DDD |
-| DDD-08 | 领域服务无状态 | 领域服务必须无状态，不持有聚合实例 | 服务设计 | 代码审查 | DDD |
-| DDD-09 | 事件命名规范 | 领域事件命名使用过去时，如OrderCreated、PaymentCompleted | 事件定义 | 命名检查 | DDD |
-| DDD-10 | 值对象不可变 | 值对象必须不可变，修改应返回新实例 | 值对象设计 | 代码审查 | DDD |
-
-## 使用方式
-
-### 需求分析阶段
-
-1. 从需求文档提取业务规则
-2. 分配规则ID（BR-01, BR-02...）
-3. 填写规则详情
-4. 标注来源和优先级
-
-### 方案设计阶段
-
-1. 设计方案时明确如何满足每条规则
-2. 在设计文档中引用规则ID
-3. 记录规则满足方式
-
-### 代码审查阶段
-
-1. 检查代码是否遵循业务规则
-2. 对照规则ID逐项验证
-3. 记录未遵循的规则
-
-### 测试用例阶段
-
-1. 为每条规则设计测试场景
-2. 正向用例：规则满足场景
-3. 反向用例：规则违反场景
-
-## 规则校验方式
-
-| 校验方式 | 说明 | 示例 |
-|---------|------|------|
-| 代码检查 | 静态分析代码逻辑 | Lint规则、类型检查 |
-| 测试用例 | 编写测试验证规则 | 单元测试、集成测试 |
-| 数据校验 | 运行时数据检查 | 数据库约束、接口校验 |
-| 人工审查 | 需要人工判断 | 代码Review、业务验收 |
-
-## 规则变更流程
-
-```
-识别变更需求 → 评估影响范围 → 更新规则定义 → 通知相关方 → 更新代码/测试
-```
-
-### 变更类型
-
-| 类型 | 说明 | 审批要求 |
-|------|------|---------|
-| 新增规则 | 新增业务约束 | 无需审批，记录即可 |
-| 修改规则 | 修改规则内容 | 需评估影响范围 |
-| 废弃规则 | 规则不再适用 | 需确认无依赖后废弃 |
-
-## 版本历史
-
-| 版本 | 日期 | 修改人 | 修改说明 |
-|-----|------|--------|---------|
-| v1.0 | YYYY-MM-DD | | 初始版本 |
-
----
-
-**维护者**: 项目团队
-**进化分区**: 受控区
-**关联文档**: `knowledge/domain/glossary.md`, `knowledge/domain/flows/README.md`

package/knowledge/environment/README.en.md

@@ -1,36 +0,0 @@
-# Environment Integration Protocol
-
-This directory contains AutoSpec's environment integration protocol for stable, secure, and efficient integration with different organizations' middleware, components, and custom frameworks.
-
-## Directory Structure
-
-```
-environment/
-├── overview.md              # Detailed environment integration protocol
-├── templates.md             # Knowledge template definitions
-└── detection-patterns.yaml  # Detection pattern configuration
-```
-
-## Core Features
-
-### Auto Detection
-
-`autospec init` automatically scans project code to identify:
-
-- **Middleware usage**: MySQL, Redis, Kafka, MongoDB, Elasticsearch, RabbitMQ, PostgreSQL
-- **Tech stack**: Java/Spring, Node.js/Express, Python/Django, etc.
-- **Project structure**: backend/, frontend/, ai/, data/ subsystems
-
-### Knowledge Management
-
-- **Minimal format**: Only `name` + `envVars` needed, AI auto-completes details
-- **Detailed format**: Complete best practices, anti-patterns, code templates
-- **Organization import**: Import organizational knowledge from Git/npm
-
-### Auto Activation
-
-Detected knowledge is automatically registered and activated, with context injected in subsequent flows.
-
-## Detailed Documentation
-
-For complete environment integration protocol documentation, see [overview.md](overview.md).

package/knowledge/environment/README.md

@@ -1,87 +0,0 @@
-# 环境衔接协议
-
-> 让 AutoSpec 能够快捷地与不同组织的中间件、组件、自定义框架、集成环境等稳定安全高效衔接。
-
-## 核心概念
-
-### 三层知识体系
-
-```
-Layer 1: Environment Knowledge（环境知识）
-├── 中间件知识：MySQL 配置、Redis 连接池、Kafka 消费者组
-├── 基础设施知识：K8s 部署、CI/CD 流水线、监控告警
-└── 环境变量：开发/测试/预发/生产环境差异化配置
-
-Layer 2: Component Knowledge（组件知识）
-├── 组织组件库：认证组件、支付网关、消息推送
-├── 最佳实践：错误处理模式、日志规范、性能调优
-└── 领域模型：通用领域对象、业务规则、数据字典
-
-Layer 3: Integration Knowledge（集成知识）
-├── CI/CD 对接：GitLab CI、Jenkins、GitHub Actions
-├── 测试知识：测试策略、Mock 方案、环境隔离（自进化）
-└── 部署环境：发布审批、灰度策略、回滚机制
-```
-
-### 进化分区
-
-| 知识类型 | 进化分区 | 变更方式 |
-|---------|---------|---------|
-| 环境知识 | 受控区 | 人工定义 + 自动验证 |
-| 组件知识 | 自由区 | 自动进化 + validator 验证 |
-| 集成知识 | 受控区 | 人工定义 + 自动执行 |
-| 测试知识 | 受控区 | skill-distiller 自动学习 + 人工审批 |
-
-## 目录结构
-
-```
-.autospec/environment/
-├── env-knowledge/          # 环境知识
-│   ├── middleware/         # 中间件配置（mysql.yaml, redis.yaml）
-│   ├── infrastructure/     # 基础设施（k8s.yaml, monitoring.yaml）
-│   └── env-variables/      # 环境变量模板
-│
-├── component-lib/          # 组件知识库
-│   ├── components/         # 组织组件库（auth/, payment/）
-│   ├── best-practices/     # 最佳实践
-│   └── domain-models/      # 领域模型
-│
-├── integration/            # 集成知识
-│   ├── ci-cd/              # CI/CD 配置
-│   ├── testing/            # 测试知识（自进化）
-│   │   └── overview.md     # 集成测试概述
-│   └── deployment/         # 部署配置
-│
-├── detection-patterns.yaml # 自定义检测模式（可选）
-└── registry.json           # 知识注册表
-```
-
-## 知识模板
-
-- [中间件知识模板](./middleware-knowledge.md) - 中间件配置和最佳实践
-- [组件知识模板](./component-knowledge.md) - 组件定义和使用示例
-
-## CLI 命令
-
-| 命令 | 说明 |
-|------|------|
-| `autospec env` | 显示当前环境配置状态 |
-| `autospec env:validate` | 验证环境知识配置 |
-| `autospec env:sync` | 从代码同步环境知识并自动激活 |
-| `autospec env:import [source]` | 导入组织知识库（支持 Git/npm/本地） |
-| `autospec env:export <dir>` | 导出当前项目知识库 |
-| `autospec component` | 列出可用的组织组件 |
-| `autospec component:add <name>` | 添加组件知识 |
-
-## 自动检测机制
-
-`autospec init` 会自动扫描项目代码，检测：
-
-1. **技术栈检测**：识别 Node.js、Python、Java、Go 等项目
-2. **中间件检测**：识别 MySQL、Redis、Kafka、MongoDB 等使用
-3. **组件检测**：识别组织自定义组件的使用
-
-检测到后会自动：
-- 生成环境知识配置
-- 注册到 registry.json
-- 激活知识（后续流程自动注入上下文）