@chongyan/autospec 1.0.1 → 1.0.2

package/knowledge/config/README.md

@@ -1,44 +0,0 @@
-# 配置目录
-
-本目录包含 AutoSpec 的配置文件，定义验证模式和团队触发器。
-
-## 目录结构
-
-```
-config/
-├── validation-patterns.yaml  # 验证模式配置
-└── team-triggers.yaml        # 团队触发器配置
-```
-
-## 配置文件说明
-
-### validation-patterns.yaml
-
-定义各阶段的验证模式：
-
-```yaml
-# 验证模式示例
-patterns:
-  - name: "build-check"
-    stage: "implementation"
-    commands:
-      - "npm run build"
-    required: true
-```
-
-### team-triggers.yaml
-
-定义团队协作触发器：
-
-```yaml
-# 团队触发器示例
-triggers:
-  - name: "code-review-request"
-    condition: "pull_request.opened"
-    actions:
-      - "notify: @team-lead"
-```
-
-## 使用方式
-
-配置文件在 `autospec init` 时复制到 `.autospec/knowledge/config/`，可根据项目需求定制。

package/knowledge/config/role-composition.yaml

@@ -1,98 +0,0 @@
-# 角色组合配置（AI Native文化融入）
-# 定义不同阶段、不同复杂度的角色组合规则
-
-compositions:
-  # 需求阶段角色组合
-  requirement:
-    simple:
-      roles: [ceo, product-owner]
-      focus: [商业价值, 用户价值, MVP范围]
-      aiNative: "评估AI能力边界，识别AI增强机会"
-    medium:
-      roles: [ceo, product-owner, tech-lead, ai-engineer]
-      focus: [商业价值, 用户价值, 技术可行性, AI方案可行性]
-      aiNative: "AI工程师参与评估AI方案可行性"
-    complex:
-      roles: [ceo, product-owner, tech-lead, ai-engineer, backend-engineer, frontend-engineer]
-      focus: [商业价值, 用户价值, 技术可行性, AI方案, 实现复杂度]
-      aiNative: "全面评估AI集成方案，制定效果评测计划"
-
-  # 设计阶段角色组合
-  design:
-    simple:
-      roles: [tech-lead]
-      focus: [架构设计, 技术选型]
-      aiNative: "评估AI技术选型，设计AI集成架构"
-    medium:
-      roles: [tech-lead, ai-engineer, backend-engineer, frontend-engineer]
-      focus: [架构设计, 技术选型, AI方案设计, 接口设计]
-      aiNative: "AI工程师参与核心方案设计"
-    complex:
-      roles: [tech-lead, ai-engineer, data-engineer, backend-engineer, frontend-engineer, quality-engineer]
-      focus: [架构设计, 技术选型, AI方案设计, 数据架构, 接口设计, 测试策略]
-      aiNative: "设计AI效果评测方案，规划数据流"
-
-  # 编码阶段角色组合
-  implementation:
-    simple:
-      roles: [backend-engineer]
-      focus: [代码实现, 单元测试]
-      aiNative: "实现AI接口调用，处理AI响应异常"
-    medium:
-      roles: [backend-engineer, frontend-engineer, ai-engineer]
-      focus: [代码实现, 接口对接, AI集成, 单元测试]
-      aiNative: "AI工程师负责AI模块实现"
-    complex:
-      roles: [backend-engineer, frontend-engineer, ai-engineer, data-engineer, quality-engineer]
-      focus: [代码实现, 接口对接, AI实现, 数据管道, 测试覆盖]
-      aiNative: "AI效果评测实现，数据驱动验证"
-
-  # 测试阶段角色组合
-  testing:
-    simple:
-      roles: [quality-engineer]
-      focus: [测试执行, 缺陷报告]
-      aiNative: "AI功能测试，效果验证"
-    medium:
-      roles: [quality-engineer, backend-engineer, ai-engineer]
-      focus: [测试执行, 接口测试, AI效果评测]
-      aiNative: "AI效果评测，Badcase分析"
-    complex:
-      roles: [quality-engineer, ai-engineer, data-engineer, backend-engineer, frontend-engineer]
-      focus: [测试执行, AI效果评测, 数据验证, 集成测试]
-      aiNative: "全面AI效果评测，数据驱动验证"
-
-  # 交付阶段角色组合
-  delivery:
-    simple:
-      roles: [tech-lead, quality-engineer]
-      focus: [发布检查, 部署验证]
-      aiNative: "AI服务部署检查"
-    medium:
-      roles: [tech-lead, quality-engineer, devops-engineer, ai-engineer]
-      focus: [发布检查, 部署配置, AI服务部署]
-      aiNative: "AI模型部署，服务监控配置"
-    complex:
-      roles: [tech-lead, quality-engineer, devops-engineer, ai-engineer, data-engineer, security-engineer]
-      focus: [发布检查, 部署配置, AI服务部署, 数据管道, 安全检查]
-      aiNative: "AI服务全面部署，安全合规检查"
-
-# 角色协作模式
-collaborationModes:
-  # 并行审查模式
-  parallel-review:
-    description: "多个角色并行审查，信息隔离"
-    execution: "parallel"
-    isolation: true
-
-  # 串行确认模式
-  sequential-confirm:
-    description: "按顺序确认，下一角色基于上一角色结果"
-    execution: "sequential"
-    isolation: false
-
-  # 协作讨论模式
-  collaborative-discussion:
-    description: "多角色共同讨论，达成共识"
-    execution: "collaborative"
-    isolation: false

package/knowledge/config/team-triggers.yaml

@@ -1,198 +0,0 @@
-# 团队角色触发配置
-# 定义复杂度阈值、强制触发规则、阶段-角色映射
-
-# ============================================
-# 复杂度阈值
-# ============================================
-complexity_threshold:
-  simple: 5      # <=5 简单任务，快速通道
-  medium: 8      # 6-8 中等任务，引入核心角色
-  complex: 9     # >=9 复杂任务，引入完整团队
-
-# ============================================
-# 强制触发规则（不受复杂度影响）
-# ============================================
-force_triggers:
-  # 安全相关
-  - id: user_data
-    condition: "涉及用户数据存储或处理"
-    keywords: ["用户数据", "个人信息", "用户信息", "隐私数据", "用户资料"]
-    roles: ["security-engineer"]
-
-  - id: payment
-    condition: "涉及支付或资金交易功能"
-    keywords: ["支付", "付款", "充值", "提现", "转账", "资金交易", "订单支付"]
-    roles: ["security-engineer"]
-
-  - id: external_api
-    condition: "涉及外部API调用"
-    keywords: ["外部API", "第三方接口", "开放平台", "外部服务", "回调接口"]
-    roles: ["security-engineer"]
-
-  # 架构相关
-  - id: new_architecture
-    condition: "涉及新架构或框架引入"
-    keywords: ["新架构", "架构调整", "架构重构", "新框架", "技术栈升级", "框架迁移"]
-    roles: ["tech-lead"]
-
-  - id: cross_system
-    condition: "涉及跨系统变更"
-    keywords: ["跨系统", "多系统", "系统集成", "系统对接", "微服务"]
-    roles: ["tech-lead", "devops-engineer"]
-
-  # 部署相关
-  - id: new_service
-    condition: "涉及新服务部署"
-    keywords: ["新服务", "服务部署", "新模块部署", "独立服务"]
-    roles: ["devops-engineer"]
-
-  - id: db_change
-    condition: "涉及数据库变更"
-    keywords: ["数据库变更", "表结构", "数据迁移", "数据库升级"]
-    roles: ["devops-engineer"]
-
-  - id: infrastructure
-    condition: "涉及基础设施变更"
-    keywords: ["基础设施", "服务器", "容器", "K8s", "云资源", "网络配置"]
-    roles: ["devops-engineer"]
-
-# ============================================
-# 阶段-角色映射
-# ============================================
-stage_role_mapping:
-
-  # 需求阶段
-  requirement:
-    simple:
-      - ceo
-      - product-owner
-    medium:
-      - ceo
-      - product-owner
-      - tech-lead
-    complex:
-      - ceo
-      - product-owner
-      - tech-lead
-      - backend-engineer
-      - frontend-engineer
-      - quality-engineer
-    # 条件触发
-    conditional:
-      - roles: ["security-engineer"]
-        condition: "dataSensitivity >= 2"
-      - roles: ["ai-engineer"]
-        condition: "hasAISubsystem"
-      - roles: ["data-engineer"]
-        condition: "hasDataSubsystem"
-
-  # 设计阶段
-  design:
-    simple:
-      - tech-lead
-    medium:
-      - tech-lead
-      - backend-engineer
-      - frontend-engineer
-    complex:
-      - tech-lead
-      - backend-engineer
-      - frontend-engineer
-      - data-engineer
-      - ai-engineer
-      - quality-engineer
-    conditional:
-      - roles: ["security-engineer"]
-        condition: "dataSensitivity >= 2"
-      - roles: ["devops-engineer"]
-        condition: "deploymentRisk >= 2"
-      - roles: ["devops-engineer"]
-        condition: "hasArchitectureChange"
-
-  # 编码阶段
-  code:
-    simple:
-      - tech-lead
-    medium:
-      - tech-lead
-      - relevant-engineer
-    complex:
-      - tech-lead
-      - backend-engineer
-      - frontend-engineer
-      - data-engineer
-      - ai-engineer
-    conditional:
-      - roles: ["security-engineer"]
-        condition: "dataSensitivity >= 3"
-
-  # 测试阶段
-  test:
-    simple:
-      - quality-engineer
-    medium:
-      - quality-engineer
-      - tech-lead
-    complex:
-      - quality-engineer
-      - tech-lead
-      - backend-engineer
-      - frontend-engineer
-    conditional:
-      - roles: ["security-engineer"]
-        condition: "dataSensitivity >= 3"
-
-  # 交付阶段
-  delivery:
-    simple:
-      - quality-engineer
-      - tech-lead
-    medium:
-      - quality-engineer
-      - tech-lead
-    complex:
-      - quality-engineer
-      - tech-lead
-      - devops-engineer
-    conditional:
-      - roles: ["security-engineer"]
-        condition: "dataSensitivity >= 2"
-      - roles: ["devops-engineer"]
-        condition: "hasDeploymentRisk"
-
-# ============================================
-# 子系统类型-工程师映射
-# ============================================
-subsystem_engineer_mapping:
-  backend: backend-engineer
-  frontend: frontend-engineer
-  web: frontend-engineer
-  mobile: frontend-engineer
-  data: data-engineer
-  ai: ai-engineer
-  ml: ai-engineer
-  model: ai-engineer
-
-# ============================================
-# 复杂度维度权重（用于微调）
-# ============================================
-dimension_weights:
-  requirement: 1.0   # 需求复杂度
-  technical: 1.0     # 技术复杂度
-  data_sensitivity: 1.0  # 数据敏感度
-  business: 1.0      # 业务复杂度
-
-# ============================================
-# 快速通道规则
-# ============================================
-fast_track:
-  enabled: true
-  max_score: 5
-  # 快速通道跳过的检查
-  skip_checks:
-    - expert_review  # 跳过专家审查
-    - full_team_review  # 跳过完整团队审查
-  # 快速通道仍需执行的检查
-  required_checks:
-    - layer1_validation
-    - basic_review

package/knowledge/domain/README.md

@@ -1,115 +0,0 @@
-# 业务知识沉淀体系
-
-> 定位：将项目特有的业务知识结构化沉淀，作为上下文注入各阶段。
-
-## 目录结构
-
-```
-knowledge/domain/
-├── README.md      # 本文件：使用指南
-├── glossary.md    # 术语表：统一业务概念定义
-├── rules.md       # 业务规则：规则ID化，便于追溯
-└── flows/         # 业务流程图：Mermaid格式，可视化业务逻辑
-    └── README.md  # 流程图规范
-```
-
-## 使用方式
-
-### 阶段注入
-
-| 阶段 | 注入内容 | 用途 |
-|------|---------|------|
-| 需求分析 | glossary + rules | 理解业务背景，避免歧义 |
-| 方案设计 | glossary + flows | 设计符合业务逻辑的技术方案 |
-| 代码审查 | rules | 检验代码是否遵循业务规则 |
-| 测试验证 | rules + flows | 构造测试场景，覆盖业务流程 |
-
-### 与环境知识的关系
-
-| 知识类型 | 处理层面 | 示例 |
-|---------|---------|------|
-| **环境知识** | 技术层 | 中间件配置、组件库、CI/CD |
-| **业务知识** | 业务层 | 术语定义、业务规则、流程图 |
-
-两者互补，共同构成立体上下文。
-
-### 与项目产出物的关系
-
-业务知识是**项目无关的通用知识**，产出物中的业务规则应引用此处定义：
-
-```
-产出物 requirement.md 中的业务规则
-    ↓ 引用
-knowledge/domain/rules.md 中的 BR-ID
-```
-
-## 进化分区
-
-| 内容 | 进化分区 | 变更方式 |
-|------|---------|---------|
-| glossary.md | 自由区 | 从需求文档自动提取 + 人工确认 |
-| rules.md | 受控区 | 从 practice-log 提取 + 人工审批 |
-| flows/ | 自由区 | 从设计文档提取 + validator 验证 |
-
-## 脱敏原则
-
-业务知识沉淀遵循以下脱敏原则：
-
-- ❌ 不记录具体客户信息
-- ❌ 不记录敏感金额数据
-- ❌ 不使用公司/产品特有名称
-- ✅ 使用通用化示例：用"支付"替代特指渠道
-- ✅ 使用占位符：`user_001`、`order_123`
-
-## 快速开始
-
-### 1. 初始化术语表
-
-```bash
-# 从需求文档提取候选术语
-# 高频词、首字母缩写、专用名词
-```
-
-### 2. 定义业务规则
-
-```markdown
-# 在 rules.md 中添加
-| 规则ID | 规则名称 | 规则描述 | 适用场景 | 校验方式 |
-|--------|---------|---------|---------|---------|
-| BR-01 | （规则名） | （描述） | （场景） | （方式） |
-```
-
-### 3. 绘制业务流程
-
-```markdown
-# 在 flows/ 中创建
-# 使用 Mermaid flowchart 格式
-```
-
-## 维护指南
-
-### 术语冲突处理
-
-当术语定义冲突时：
-1. 以 `glossary.md` 为准
-2. 如有歧义，在需求分析阶段澄清
-3. 澄清后更新 `glossary.md`
-
-### 规则变更流程
-
-1. 识别规则变更需求（来自需求/缺陷/反馈）
-2. 在 `rules.md` 中更新规则
-3. 标注变更版本和原因
-4. 通知相关阶段（设计/测试/审查）
-
-### 流程图更新
-
-1. 业务流程变更时同步更新
-2. 保持与设计文档的一致性
-3. 版本化记录变更历史
-
----
-
-**维护者**: 项目团队
-**进化分区**: 自由区/受控区
-**关联文档**: `knowledge/environment/README.md`

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`