@jspg-ai/coding-bb 0.0.1

package/config/openspec/schemas/spec-driven/templates/design.md

@@ -0,0 +1,475 @@
+# 详细设计技术方案模板（AI版）
+
+> **文档说明**
+>
+> 本模板用于编写详细设计技术方案，供AI理解和生成代码使用。
+>
+> **标记说明：**
+>
+> - `（必选）`：必须填写的内容
+> - `（可选）`：根据实际情况选择填写，不涉及则删除整个章节
+> - <span style="color: rgb(122,134,154);">*灰色斜体文字*</span>：模板说明/示例内容，实际使用时删除并替换为真实内容
+
+---
+
+## 零、知识库参考（必选）
+
+<!-- AI理解要点：此章节记录本次设计参考了哪些知识库文档，确保设计基于已有知识而非凭空构思。
+     通过知识库索引（INDEX.md）逐级定位后，列出实际读取的知识文档路径。 -->
+
+| 序号 | 参考知识点 | 知识库路径 | 对应设计章节 | 备注 |
+| ---- | ---------- | ---------- | ------------ | ---- |
+| 1    | <!-- 知识点名称 --> | <!-- 从INDEX.md逐级定位的完整路径 --> | <!-- 架构设计/领域模型/... --> | <!-- 参考了什么 --> |
+
+<!-- 知识库导航方式：
+1. 从知识库根索引 INDEX.md 出发
+2. 按业务域/技术域逐级定位到具体知识文档
+3. 将实际读取的文档路径填入上表
+4. 如果某章节无对应知识库文档，在备注中标注"知识库暂无覆盖，建议补充"
+-->
+
+---
+
+## 一、需求或项目背景（必选）
+
+<!-- AI理解要点：此章节提供需求的上下文信息，帮助理解业务背景和目标 -->
+
+| 序号 | 事项              | 描述                                                         |
+| ---- | ----------------- | ------------------------------------------------------------ |
+| 1    | 描述需求/项目背景 | <!-- 描述当前存在的问题或业务目标，例如：当前支付成功页有企业入驻广告位，但数据异常（日均UV10），且没有进行精细化运营，浪费了该优质广告位的资源，需要进行优化。 --> |
+| 2    | PRD地址           | <!-- 产品需求文档链接 -->                                    |
+| 3    | DMPT地址          | <!-- 需求管理平台链接 -->                                    |
+
+---
+
+## 二、Checklist事项（必选）
+
+<!-- AI理解要点：此章节用于识别技术风险点，每项检查都有对应的注意事项 -->
+
+| 序号 | 检查项                                               | 是否涉及 | 备注                                                                                                       |
+| ---- | ---------------------------------------------------- | -------- |----------------------------------------------------------------------------------------------------------|
+| 1    | 是否涉及新增应用，或新增接口                         | 是/否    | **注意事项：** 需要进行容量评估和SLA签订（预估多大的QPS，需要多少个实例，限流阈值，数据库容量等），以及评估是否需要进行生产全链路压测，仅列举RPC或REST接口，内部逻辑不在此项范围内       |
+| 2    | 是否涉及修改原有接口（出参字段、入参字段、结果码等） | 是/否    | **注意事项：** 技术方案需要评估新老逻辑的兼容情况，以及对上游相关业务的影响，核心场景还要有灰度能力                                                     |
+| 3    | 是否新增枚举类型                                     | 是/否    | **注意事项：** 要考虑调用方的兼容情况，调用方一般要做对应jar包的升级                                                                   |
+| 4    | 是否涉及新增外部二方/三方服务依赖                    | 是/否    | **注意事项：** 强弱依赖考虑，弱依赖是否可降级，降级方案是怎样的，需要设置合理的超时时间，跟下游二方依赖服务签订SLA                                            |
+| 5    | 是否新建表结构，或新增MQ Topic                       | 是/否    | **注意事项：** 需要考虑涉及的链路是否是压测覆盖的链路，如果是，需要新增对应的影子表和影子Topic；DDL变更需要同步大数据经分同学                                    |
+| 6    | 是否应用新接入sentinel                               | 是/否    | **注意事项：** 由于流控平台默认开启default限流规则（过去一段时间早高峰峰值流量的2倍），但是对于新应用或者老应用新接入sentinel，没有过去的监控数据，所以需要在流控平台评估并手动设置流控规则 |
+| 7    | 是否涉及安全敏感数据                                 | 是/否    | **注意事项：** 是否涉及敏感字段？是否需要脱敏等等？数据库存储是否加密                                                                    |
+| 8    | 是否涉及增加新SQL，或原有SQL修改                     | 是/否    | **注意事项：** 该场景一致性要求是否可以走从库查询；qps多大？是否走索引？尽可能做SQL优化避免慢SQL；数据量多大？是否要考虑分表分库                                  |
+| 9    | 是否涉及历史数据，或历史接口                         | 是/否    | **注意事项：** 需要考虑历史数据和接口的兼容性                                                                                |
+| 10   | 是否使用redis缓存                                    | 是/否    | **注意事项：** 需要考虑redis的使用场景，redis只能当缓存，不能当数据库用；需要做到弱依赖redis；该场景qps是多大？要针对性的设计解决缓存击穿和雪崩问题                    |
+| 11   | 是否增加了验签字段                                   | 是/否    | **注意事项：** 需要考虑字段类型是否有默认值（用包装类，排除默认值）；需要考虑调用方是否会对字段赋默认值；需要考虑上下游发布期间新老容器的兼容                                |
+
+---
+
+## 三、功能拆解（必选）
+
+<!-- AI理解要点：此章节将需求拆解为可执行的功能模块和功能点，是工作量和排期评估的依据 -->
+
+<!--
+字段说明：
+
+- 功能模块：对齐PRD中影响模块
+- 功能点：功能模块拆解之后服务端工作量在0.5-1人天左右的工作量
+- 改动内容：具体改动点，评估工作量的依据，是一个完整独立的小任务
+- FTAPI：提供给前端的接口协议，或作为服务提供方提供的RPC接口
+- 变更类型：新增/修改/删除
+- 变更说明：结合是否新增、变更类型对本次变更做详细说明
+- 工作量：基于改动内容评估的工作量，颗粒度0.5-1人天，再大说明任务拆分不合理
+- 备注：其他情况说明
+  -->
+
+| 功能模块        | 功能点              | 变更类型       | 改动内容            | 变更说明          | FTAPI（Rest/RPC） | 工作量        | 备注              |
+| --------------- | ------------------- | -------------- | ------------------- | ----------------- | ----------------- | ------------- | ----------------- |
+| <!-- 模块名 --> | <!-- 功能点名称 --> | 新增/修改/删除 | <!-- 具体改动点 --> | <!-- 详细说明 --> | <!-- 接口类型 --> | <!-- 人天 --> | <!-- 其他说明 --> |
+
+---
+
+## 四、架构设计（必选）
+
+### 4.1 模块划分
+
+<!-- AI理解要点：重点体现改动的类所在的工程分层和模块 -->
+
+<!-- 在此处描述模块划分 -->
+
+### 4.2 分层依赖关系
+
+<!-- AI理解要点：重点体现改动的代码层级依赖关系 -->
+
+<!-- 在此处描述分层依赖关系 -->
+
+---
+
+## 五、领域模型设计（可选）
+
+<!-- AI理解要点：此章节描述领域模型的变更，包括新增/变更/废弃的领域对象。不涉及则删除整个章节 -->
+
+### 示例域（example）
+
+| 领域对象        | 类型                        | 字段              | 领域行为          | 描述          |
+| --------------- | --------------------------- | ----------------- | ----------------- | ------------- |
+| <!-- 对象名 --> | 聚合根/实体/值对象/领域事件 | <!-- 字段列表 --> | <!-- 行为列表 --> | <!-- 描述 --> |
+
+<!-- 领域对象类型说明：
+
+- 聚合根：一组相关对象的集合，作为修改对象的唯一入口
+- 实体：有唯一标识的领域对象
+- 值对象：无唯一标识，由属性值定义
+- 领域事件：领域内发生的事情，用于解耦
+  -->
+
+---
+
+## 六、核心流程设计（必选）
+
+<!-- AI理解要点：此章节描述跨服务间执行顺序和业务逻辑，是理解业务流程的关键 -->
+
+<!-- 展现形式：
+
+1. 跨应用时序图，表示核心流程调用应用顺序
+2. 跨应用泳道图，表示核心流程在多个应用的重要逻辑
+3. 本应用流程图，表示核心流程在本应用的重要逻辑
+4. 状态机，表示状态枚举和动作
+5. 重要：所有图使用mermaid生成
+
+【时序图范围约束】
+- 时序图仅在功能涉及跨应用调用时绘制
+- participant 命名规则：应用使用英文名（如 OrderApp），外部操作角色使用中文名（如 用户、运营、管理员）
+- 禁止使用类名作为 participant
+- 同一应用禁止重复出现为多个 participant
+- 单应用内部流程使用流程图或泳道图表达
+- 禁止绘制类级别的时序图（代码设计章节同理）
+
+【修改型功能点规则】
+当功能点变更类型为"修改"时，流程图/时序图/类图必须包含：
+1. 触发入口：触发该流程的 REST 接口、RPC 调用、MQ 消费者或 Job
+2. 上游一层：直接调用变更点的调用方节点
+3. 下游一层：变更点直接调用的被调方节点
+4. 所有变更节点使用统一高亮色（配色规则参见 schema.yaml design instruction）
+
+【图表质量准则】
+- 聚焦核心：每张图聚焦单一业务流程或功能点，避免一张图承载过多信息
+- 层次鲜明：通过配色区分入口/新增/修改/删除/未变更节点（配色规则参见 schema.yaml design instruction）
+- 粒度适中：节点粒度为方法或步骤级，避免过度展开内部实现细节
+- 逻辑完整：图中所有路径应有入口和出口，不出现孤立节点或断链
+- 配色丰富：每张图至少使用 3 种以上颜色，入口用 primary，变更用 modified/added/removed，未变更用 secondary
+-->
+
+### 6.1 示例：跨应用时序图（新增型功能点）
+
+<!-- 仅当功能涉及跨应用调用时才绘制时序图。participant 命名：应用用英文名，操作角色用中文名，禁止类名，同一应用不重复 -->
+
+**主流程：**
+
+1. 客户端发起下单请求
+2. 订单服务创建订单
+3. 库存服务扣减库存
+4. 消息服务发送下单通知
+
+```mermaid
+sequenceDiagram
+    participant 用户
+    participant OrderApp as 订单服务
+    participant InventoryApp as 库存服务
+    participant MQApp as 消息服务
+
+    用户->>OrderApp: POST /api/order/create
+    OrderApp->>InventoryApp: RPC deductStock()
+    InventoryApp-->>OrderApp: 扣减结果
+    OrderApp->>MQApp: 发送下单成功消息
+    OrderApp-->>用户: 下单结果
+```
+
+### 6.2 示例：修改型功能点流程图（含触发入口 + 上下各一层上下文 + 变更高亮）
+
+<!-- 修改型功能点必须展示触发入口、变更节点高亮、上下各一层上下文 -->
+
+**变更说明：** 修改订单创建流程，新增库存预占逻辑
+
+```mermaid
+flowchart TD
+    A[REST /api/order/create]:::primary --> B[OrderController.createOrder]:::secondary
+    B --> C[OrderService.createOrder]:::modified
+    C --> D[InventoryService.preDeduct]:::added
+    C --> E[OrderRepo.save]:::secondary
+    C --> F[MqProducer.sendOrderMsg]:::secondary
+    E --> G[(订单表)]:::info
+    D --> H{库存充足?}
+    H -->|是| I[扣减成功]:::success
+    H -->|否| J[返回库存不足]:::removed
+
+    classDef modified fill:#FFF3CD,stroke:#F0AD4E,stroke-width:2px
+    classDef added fill:#D4EDDA,stroke:#28A745,stroke-width:2px
+    classDef removed fill:#F8D7DA,stroke:#DC3545,stroke-width:2px
+    classDef info fill:#D1ECF1,stroke:#17A2B8,stroke-width:2px
+    classDef success fill:#C3E6CB,stroke:#28A745,stroke-width:2px
+    classDef primary fill:#CCE5FF,stroke:#007BFF,stroke-width:2px
+    classDef secondary fill:#E2E3E5,stroke:#6C757D,stroke-width:2px
+```
+
+### 6.3 示例流程C
+
+**主流程：**
+
+1. 业务步骤1
+2. 业务步骤2
+3. 业务步骤3
+
+---
+
+## 七、代码设计（必选）
+
+<!-- AI理解要点：此章节描述单个服务内部的代码组织、执行逻辑，是生成代码的关键参考 -->
+
+<!-- 展现形式：
+
+1. 代码级别 UML 类图（展示类间依赖与调用关系）
+2. 重要：所有图使用 mermaid 生成
+3. 禁止绘制类级别的时序图 — 各层方法职责与调用关系在"八、分层设计"章节以文字描述
+
+【类图规则】
+- 仅当涉及 ≥5 个类或依赖关系复杂时才画类图
+- 修改型功能点：被修改的类使用 classDef modified 高亮
+- 新增的类使用 classDef added 标记
+- 配色规则参见 schema.yaml design instruction
+-->
+
+<!-- 涉及内容：
+
+1. 复杂查询逻辑体现
+2. 数据落表逻辑说明
+3. 对消费消息的处理细节
+4. 对JOB内部的处理细节
+-->
+
+```mermaid
+classDiagram
+    class OrderController {
+        +createOrder()
+    }
+    class OrderService {
+        +createOrder()
+        +validateOrder()
+    }
+    class OrderRepo {
+        +save()
+        +findByOrderNo()
+    }
+    class MqProducer {
+        +sendOrderMsg()
+    }
+    class InventoryService {
+        +preDeduct()
+    }
+
+    OrderController --> OrderService
+    OrderService --> OrderRepo
+    OrderService --> MqProducer
+    OrderService --> InventoryService
+
+    classDef modified fill:#FFF3CD,stroke:#F0AD4E,stroke-width:2px
+    classDef added fill:#D4EDDA,stroke:#28A745,stroke-width:2px
+    classDef primary fill:#CCE5FF,stroke:#007BFF,stroke-width:2px
+    classDef secondary fill:#E2E3E5,stroke:#6C757D,stroke-width:2px
+
+    class OrderService modified
+    class InventoryService added
+    class OrderController primary
+    class OrderRepo secondary
+    class MqProducer secondary
+```
+
+---
+
+## 八、分层设计（必选）
+
+<!-- AI理解要点：此章节描述每一层的方法和职责，不需要具体实现，但需要明确接口契约 -->
+
+### 8.1 Controller层（Rest接口）
+
+<!-- AI理解要点：重点体现改动的接口，最新的接口契约 -->
+
+#### 接口契约设计
+
+**接口地址：** `POST /api/v1/xxxx`
+
+**请求参数：**
+
+| 参数名称        | 参数类型           | 参数长度          | 是否必填 | 描述          | 新增/修改 |
+| --------------- | ------------------ | ----------------- | -------- | ------------- | --------- |
+| <!-- 参数名 --> | String/Integer/... | <!-- 长度限制 --> | 是/否    | <!-- 描述 --> | 新增/修改 |
+
+**响应参数：**
+
+| 参数名称 | 参数类型 | 是否必填 | 描述          | 新增/修改 |
+| -------- | -------- | -------- | ------------- | --------- |
+| success  | boolean  | 是       | 是否成功      | -         |
+| code     | integer  | 是       | 状态码        | -         |
+| data     | object   | 是       | 响应数据      | -         |
+| data.xxx | string   | 否       | <!-- 描述 --> | 新增/修改 |
+
+### 8.2 Facade层（Rpc接口）
+
+<!-- AI理解要点：重点体现改动的RPC接口，最新的接口契约 -->
+
+#### 接口契约设计
+
+**接口地址：** `xxxService.xxxMethod()`
+
+**请求参数：**
+
+| 参数名称        | 参数类型           | 参数长度          | 是否必填 | 描述          | 新增/修改 |
+| --------------- | ------------------ | ----------------- | -------- | ------------- | --------- |
+| <!-- 参数名 --> | String/Integer/... | <!-- 长度限制 --> | 是/否    | <!-- 描述 --> | 新增/修改 |
+
+**响应参数：**
+
+| 参数名称        | 参数类型      | 是否必填 | 描述          | 新增/修改 |
+| --------------- | ------------- | -------- | ------------- | --------- |
+| <!-- 参数名 --> | <!-- 类型 --> | 是/否    | <!-- 描述 --> | 新增/修改 |
+
+### 8.3 Service层
+
+<!-- AI理解要点：重点体现改动的核心方法和职责 -->
+
+#### XxxService
+
+**核心方法：**
+
+- `method1()`：方法说明
+
+**职责：**
+
+1. 职责1
+2. 职责2
+
+### 8.4 Repo层
+
+<!-- AI理解要点：重点体现改动的核心方法和职责 -->
+
+#### XxxRepo
+
+**核心方法：**
+
+- `findById()`：根据ID查询
+- `save()`：保存数据
+
+**职责：**
+
+1. 数据持久化
+2. 数据查询
+
+### 8.5 依赖RPC（可选）
+
+<!-- AI理解要点：描述依赖的外部RPC服务，包括强弱依赖、超时配置、异常处理等 -->
+
+| 序号 | 接口地址          | 提供方                | 是否强依赖 | 超时时间    | 异常处理          | SLA要求      | 备注          |
+| ---- | ----------------- | --------------------- | ---------- | ----------- | ----------------- | ------------ | ------------- |
+| 1    | <!-- 接口地址 --> | <!-- 提供方应用名 --> | 是/否      | <!-- ms --> | <!-- 降级策略 --> | <!-- SLA --> | <!-- 备注 --> |
+
+---
+
+## 九、数据库模型设计（可选）
+
+<!-- AI理解要点：此章节描述数据库表变更，不涉及则删除整个章节 -->
+
+| 序号 | 表结构变更语句              | 变更类型       | 变更说明      | 备注          |
+| ---- | --------------------------- | -------------- | ------------- | ------------- |
+| 1    | ```sql <!-- DDL语句 --> ``` | 新增/变更/废弃 | <!-- 说明 --> | <!-- 备注 --> |
+
+---
+
+## 十、MQ设计（可选）
+
+<!-- AI理解要点：此章节描述消息队列相关变更，不涉及则删除整个章节 -->
+
+| 序号 | 使用场景      | 角色          | 集群名称      | Topic名称      | 应用名称      | 变更类型       | 是否延时 | 是否顺序 | 幂等方案          | 备注          |
+| ---- | ------------- | ------------- | ------------- | -------------- | ------------- | -------------- | -------- | -------- | ----------------- | ------------- |
+| 1    | <!-- 场景 --> | 生产者/消费者 | <!-- 集群 --> | <!-- Topic --> | <!-- 应用 --> | 新增/变更/废弃 | 是/否    | 是/否    | <!-- 幂等方案 --> | <!-- 备注 --> |
+
+---
+
+## 十一、JOB设计（可选）
+
+<!-- AI理解要点：此章节描述定时任务相关变更，不涉及则删除整个章节 -->
+
+| 序号 | 使用场景      | Job名称（JobHandler） | 执行参数格式      | Cron表达式    | 变更类型       | 备注          |
+| ---- | ------------- | --------------------- | ----------------- | ------------- | -------------- | ------------- |
+| 1    | <!-- 场景 --> | <!-- JobHandler名 --> | <!-- 参数格式 --> | <!-- Cron --> | 新增/变更/废弃 | <!-- 备注 --> |
+
+---
+
+## 十二、Redis设计（可选）
+
+<!-- AI理解要点：此章节描述Redis缓存相关变更，不涉及则删除整个章节 -->
+
+| 序号 | 使用场景      | 应用名          | 数据类型                  | key              | value              | ttl               |
+| ---- | ------------- | --------------- | ------------------------- | ---------------- | ------------------ | ----------------- |
+| 1    | <!-- 场景 --> | <!-- 应用名 --> | String/Hash/List/Set/ZSet | <!-- key格式 --> | <!-- value格式 --> | <!-- 过期时间 --> |
+
+---
+
+## 十三、配置设计（可选）
+
+<!-- AI理解要点：此章节描述配置中心相关变更，不涉及则删除整个章节 -->
+
+| 序号 | 应用            | Key              | Value（QA）   | Value（生产）   | 值说明        | 变更类型       | 备注          |
+| ---- | --------------- | ---------------- | ------------- | --------------- | ------------- | -------------- | ------------- |
+| 1    | <!-- 应用名 --> | <!-- 配置key --> | <!-- QA值 --> | <!-- 生产值 --> | <!-- 说明 --> | 新增/变更/废弃 | <!-- 备注 --> |
+
+---
+
+## 十四、测试策略（必选）
+
+<!-- AI理解要点：此章节描述单元测试场景，必须满足TDD（测试驱动开发） -->
+
+| 测试场景       | 验证点           |
+| -------------- | ---------------- |
+| <!-- 场景1 --> | <!-- 验证点1 --> |
+| <!-- 场景2 --> | <!-- 验证点2 --> |
+
+---
+
+## 十五、稳定性设计（必选）
+
+<!-- AI理解要点：此章节描述系统稳定性保障措施，改动小可以简单描述，但必须有这个思考过程 -->
+
+### 15.1 发布方案（必选）
+
+<!-- AI理解要点：描述发布整体方案设计、发布顺序、灰度发布、验证方案、新老兼容性考虑等 -->
+<!-- 目的：避免没有验证的功能影响所有用户，从稳定性角度说就是减少影响范围 -->
+
+### 15.2 回滚方案（必选）
+
+<!-- AI理解要点：描述回滚策略 -->
+<!-- 目的：发现系统存在问题的情况下可以快速止损，从稳定性角度说就是减少影响时长 -->
+
+### 15.3 监控方案（必选）
+
+<!-- AI理解要点：监控的目的是及时知道系统运行情况、判断是否合理、针对不合理的情况及时处理 -->
+
+| 风险点          | 监控方案               | 告警策略          |
+| --------------- | ---------------------- | ----------------- |
+| <!-- 风险点 --> | <!-- 监控指标/方式 --> | <!-- 告警规则 --> |
+
+---
+
+## 十六、防资损设计（必选）
+
+<!-- AI理解要点：此章节描述资金安全相关的设计，改动小可以简单描述，但必须有这个思考过程 -->
+
+| 序号 | 资损场景          | 资金流            | 防控方案          | 资损监控方案      | 备注          |
+| ---- | ----------------- | ----------------- | ----------------- | ----------------- | ------------- |
+| 1    | <!-- 场景描述 --> | <!-- 资金流向 --> | <!-- 防控措施 --> | <!-- 监控方案 --> | <!-- 备注 --> |
+
+---
+
+## 十七、其他风险/遗留问题（可选）
+
+<!-- AI理解要点：此章节描述其他需要关注的风险点或遗留问题，不涉及则删除整个章节 -->
+
+- 风险点1
+- 风险点2
+
+---

package/config/openspec/schemas/spec-driven/templates/proposal.md

@@ -0,0 +1,58 @@
+## 一、为什么
+
+<!-- 说明这次变更的动机。要解决什么问题？为什么是现在？ -->
+
+## 二、变更摘要
+
+<!-- 1-3 句话最精简易读地描述本需求要做的事情。 -->
+
+## 三、变更清单
+
+<!-- 能力维度的变更盘点（新增 / 修改 / 删除）。每个能力对应 `openspec/specs/<name>/spec.md`。
+     表格同时承载"能力本身的静态信息（identifier / 中文名 / 简述）"和"本次变更对它的动作"。
+     第四章"代码改动清单"是落到代码层的具体改动点。两章通过 identifier 字段双向关联。
+     **identifier 与展示名解耦**：identifier 列填英文 kebab-case（用于 path / CLI / 跨引用）；`中文名` 列填人类阅读用名，可与 identifier 不同。 -->
+
+### 新增能力
+
+<!-- 引入的新能力。`能力名` 用 kebab-case，对应新建一份 `specs/<name>/spec.md`。 -->
+
+| 能力名 | 中文名 | 简述 | 备注 |
+| ------ | ------ | ---- | ---- |
+
+### 修改能力
+
+<!-- REQUIREMENTS 将发生变化（不只是实现细节）的已有能力。每个对应一份 delta spec 文件，用 `openspec/specs/` 下已有的 spec 名；没有需求变更则留整段。 -->
+
+| 现有 spec 名 | 中文名 | 需求级变更说明 | 备注 |
+| ------------ | ------ | -------------- | ---- |
+
+### 删除能力
+
+<!-- 整段能力下线。spec 文件**保留**并写 `## REMOVED Requirements` 段，避免后续误用。
+     迁移路径在 design.md > 迁移设计 / proposal.md > 影响 的叙述里展开。
+     没有删除则留整段。 -->
+
+| 已废弃 spec 名 | 中文名 | 删除原因 | 迁移到 | 备注 |
+| -------------- | ------ | -------- | ------ | ---- |
+
+## 四、代码改动清单
+
+<!-- 代码入口级别的改动盘点：每个 entry = 一个具体代码入口（方法 / 接口 / SQL / 配置 / 常量 / 枚举 等）。
+     `所属能力` 列强制填写：填第三章的能力名（含删除能力）；无对应能力的纯基础设施改动（SQL 数据迁移、监控埋点、公用 job 调度、独立 bug 修复）填 `（基础设施）`。 -->
+
+| 应用 | 变更类型 | 代码入口类型 | 代码入口 | 所属能力 | 变更简述 | 备注 |
+| ---- | -------- | ------------ | -------- | -------- | -------- | ---- |
+
+## 五、影响
+
+<!-- 受影响的代码、接口、依赖、上下游系统。**复杂影响分析**（灰度步骤、回滚方案、跨团队协作清单）进入 § design 阶段。
+     本节只承担上游 Impact 的"列出来谁会被波及"角色，单段或简短 bullet。 -->
+
+## 六、决策记录
+
+<!-- 撰写 proposal 过程中，遇到需求逻辑矛盾、信息缺失、潜在风险、方案取舍等不确定的点，向用户确认后逐条记录于此。 -->
+
+| 序号 | 决策点 | 用户决策 | 影响 |
+| ---- | ------ | -------- | ---- |
+| 1 | | | |

package/config/openspec/schemas/spec-driven/templates/spec.md

@@ -0,0 +1,8 @@
+## ADDED Requirements
+
+### Requirement: <!-- requirement name -->
+<!-- requirement text -->
+
+#### Scenario: <!-- scenario name -->
+- **WHEN** <!-- condition -->
+- **THEN** <!-- expected outcome -->

package/config/openspec/schemas/spec-driven/templates/tasks.md

@@ -0,0 +1,9 @@
+## 1. <!-- Task Group Name -->
+
+- [ ] 1.1 <!-- Task description -->
+- [ ] 1.2 <!-- Task description -->
+
+## 2. <!-- Task Group Name -->
+
+- [ ] 2.1 <!-- Task description -->
+- [ ] 2.2 <!-- Task description -->

package/config/workspaces.json

@@ -0,0 +1,15 @@
+{
+  "_comment": "业务空间与 GitLab 仓库映射表，由本项目维护者配置。执行 `cbb setup` 时会列出本表中的所有业务空间让用户选择，并在当前目录自动检测/拉取对应仓库，再继续安装本项目的现有能力。name 用于显示，可含中文；repo 为 `git clone` 命令接受的地址，支持 SSH（git@host:path）与 HTTPS（https://host/path）两种形式；businessLine 用于业务归类（如：直采、增值、KA 等），便于后续按业务线筛选或分组展示。",
+  "workspaces": [
+    {
+      "name": "直采AI开发工作空间",
+      "repo": "git@code.amh-group.com:yzg/ymm-ka-ai-workspace.git",
+      "businessLine": "TMS"
+    },
+    {
+      "name": "ETC业务AI开发工作空间",
+      "repo": "git@code.amh-group.com:etc/etc-ai-workspace.git",
+      "businessLine": "TMS"
+    }
+  ]
+}

package/openspec/.version

@@ -0,0 +1,6 @@
+{
+  "sha": "9d4e5974e5c0d9a09b9c6c1e1eb0975e80ec4461",
+  "branch": "main",
+  "repo": "Fission-AI/OpenSpec",
+  "updatedAt": "2026-09-12T00:00:00.000Z"
+}