@shirayner/ace 0.1.4 → 0.1.5

package/templates/openspec/issues/design-issues.md

@@ -1,218 +0,0 @@
-# 设计问题清单
-
-## 变更信息
-- **变更名称**: [change-name]
-- **当前阶段**: `analyzing` | `clarifying` | `clarified` | `resolved`
-- **最后更新**: [YYYY-MM-DD]
-- **下次检查**: [YYYY-MM-DD]
-
----
-
-## 设计维度问题矩阵
-
-<!--
-说明：
-1. 按设计问题分类学维度组织
-2. 每个设计维度下列出具体问题
-3. 问题 ID 格式：D[维度序号]-[序号] 例如 D1-001
--->
-
----
-
-### 维度 1: 架构决策
-
-#### 问题列表
-
-| 问题 ID | 问题描述 | 严重程度 | 状态 | 决策结果 |
-|---------|----------|----------|------|----------|
-| D1-001 | [如：架构模式选择未定] | 🔴 High / 🟡 Medium / 🟢 Low | `open` / `clarifying` / `clarified` | [决策结论] |
-| D1-002 | [如：服务边界划分不清晰] | | | |
-
-**D1-001 详细说明**:
-- **问题类型**: 架构方案不确定
-- **具体表现**: [详细描述]
-- **影响范围**: [对系统的影响]
-- **可选方案**:
-  - A) [描述 + 优缺点]
-  - B) [描述 + 优缺点]
-  - C) [描述 + 优缺点]
-  - D) 自定义...
-- **决策结果**: [交互式澄清后的决策]
-- **决策理由**: [为什么选这个方案]
-- **澄清时间**: [YYYY-MM-DD]
-- **澄清人**: [@name]
-
----
-
-### 维度 2: 技术选型
-
-| 问题 ID | 问题描述 | 严重程度 | 状态 | 决策结果 |
-|---------|----------|----------|------|----------|
-| D2-010 | [如：消息队列选型未定] | | | |
-| D2-011 | [如：缓存方案未确定] | | | |
-
-**D2-010 详细说明**:
-- **问题类型**: 核心框架/库未确定
-- **具体表现**:
-- **影响范围**:
-- **可选方案**:
-- **决策结果**:
-- **决策理由**:
-
----
-
-### 维度 3: 接口设计
-
-| 问题 ID | 问题描述 | 严重程度 | 状态 | 决策结果 |
-|---------|----------|----------|------|----------|
-| D3-020 | [如：API 版本管理策略未定] | | | |
-
-**D3-020 详细说明**:
-- **问题类型**: API 契约未定 / 数据流不清晰 / 异步处理机制
-- **具体表现**:
-- **影响范围**:
-- **可选方案**:
-- **决策结果**:
-- **决策理由**:
-
----
-
-### 维度 4: 数据与状态
-
-| 问题 ID | 问题描述 | 严重程度 | 状态 | 决策结果 |
-|---------|----------|----------|------|----------|
-| D4-030 | [如：订单状态机未定义] | | | |
-
-**D4-030 详细说明**:
-- **问题类型**: 数据模型未定 / 状态机未定义 / 数据迁移方案
-- **具体表现**:
-- **影响范围**:
-- **可选方案**:
-- **决策结果**:
-- **决策理由**:
-
----
-
-### 维度 5: 安全与合规
-
-| 问题 ID | 问题描述 | 严重程度 | 状态 | 决策结果 |
-|---------|----------|----------|------|----------|
-| D5-040 | [如：权限模型未设计] | | | |
-
-**D5-040 详细说明**:
-- **问题类型**: 认证授权未设计 / 数据安全 / 审计与日志
-- **具体表现**:
-- **影响范围**:
-- **可选方案**:
-- **决策结果**:
-- **决策理由**:
-
----
-
-### 维度 6: 性能与可靠性
-
-| 问题 ID | 问题描述 | 严重程度 | 状态 | 决策结果 |
-|---------|----------|----------|------|----------|
-| D6-050 | [如：缓存一致性策略未定] | | | |
-
-**D6-050 详细说明**:
-- **问题类型**: 性能瓶颈未识别 / 缓存策略未定 / 降级与熔断
-- **具体表现**:
-- **影响范围**:
-- **可选方案**:
-- **决策结果**:
-- **决策理由**:
-
----
-
-### 维度 7: 部署与运维
-
-| 问题 ID | 问题描述 | 严重程度 | 状态 | 决策结果 |
-|---------|----------|----------|------|----------|
-| D7-060 | [如：灰度发布策略未定] | | | |
-
-**D7-060 详细说明**:
-- **问题类型**: 部署方案未定 / 监控告警 / 配置管理
-- **具体表现**:
-- **影响范围**:
-- **可选方案**:
-- **决策结果**:
-- **决策理由**:
-
----
-
-## 问题统计
-
-| 设计维度 | 总计 | 已澄清 | 待澄清 | 已解决 |
-|----------|------|--------|--------|--------|
-| 架构决策 | 0 | 0 | 0 | 0 |
-| 技术选型 | 0 | 0 | 0 | 0 |
-| 接口设计 | 0 | 0 | 0 | 0 |
-| 数据与状态 | 0 | 0 | 0 | 0 |
-| 安全与合规 | 0 | 0 | 0 | 0 |
-| 性能与可靠性 | 0 | 0 | 0 | 0 |
-| 部署与运维 | 0 | 0 | 0 | 0 |
-| **总计** | 0 | 0 | 0 | 0 |
-
----
-
-## 澄清记录
-
-### 交互式澄清会话 1: [YYYY-MM-DD]
-- **参与者**: [@name1, @name2, ...]
-- **澄清模式**: 命令行交互式
-- **澄清的问题**: [问题 ID 列表]
-- **设计决策**:
-  1. [决策 1]
-  2. [决策 2]
-- **设计变更**: [design.md 的更新内容]
-- **任务调整**: [tasks.md 的调整]
-
-### 交互式澄清会话 2: [YYYY-MM-DD]
-
-[同上结构...]
-
----
-
-## 状态流转说明
-
-```
-analyzing:      AI 正在分析设计方案，发现问题
-                → 发现问题后自动转为 clarifying
-
-clarifying:     问题已列出，等待交互式澄清
-                → 使用命令行界面一问一答澄清
-                → 每题回答后立即同步到本文档
-                → 支持 'q' 退出，下次自动恢复
-                → 支持 's' 跳过 Low 优先级问题
-
-clarified:      所有 High 和 Medium 问题已澄清
-                → 可以创建/更新 tasks
-                → 根据澄清更新 design.md
-                → 状态可转为 resolved
-
-resolved:       设计已根据澄清更新，问题已解决
-                → 可以创建/更新 tasks
-```
-
-**当前状态**: `[current-status]`
-
-**状态变更历史**:
-- [YYYY-MM-DD]: `analyzing` → `clarifying` (AI 完成问题分析)
-- [YYYY-MM-DD]: `clarifying` → `clarified` (完成澄清会话 1)
-- [YYYY-MM-DD]: `clarified` → `resolved` (design.md 已更新)
-
----
-
-## 关联文档
-
-- **技术方案**: `design.md`
-- **实施任务**: `tasks.md`
-- **需求问题清单**: `spec/requirement-issues.md`
-- **分类学参考**: `openspec/templates/design-issue-taxonomy.md`
-
----
-
-## 备注
-
-<!-- 任何补充说明 -->

package/templates/openspec/issues/requirement-issues.md

@@ -1,214 +0,0 @@
-# 需求问题清单
-
-## 变更信息
-- **变更名称**: [change-name]
-- **当前阶段**: `discovering` | `clarifying` | `clarified` | `superseded`
-- **最后更新**: [YYYY-MM-DD]
-- **下次检查**: [YYYY-MM-DD]
-
----
-
-## 功能点问题矩阵
-
-<!--
-说明：
-1. 按 OpenSpec Capabilities 结构组织
-2. 每个功能点下按问题分类维度列出具体问题
-3. 问题 ID 格式：R[功能点序号]-[分类序号][序号] 例如 R1-001
--->
-
----
-
-### 功能点 1: [功能点名称]
-
-#### 基本信息
-- **功能点 ID**: [kebab-case-id]
-- **对应 Spec**: `specs/[功能点ID]/spec.md`
-- **优先级**: P0 / P1 / P2
-- **负责人**: [@name]
-
-#### 问题列表
-
-##### 1. 功能完整性问题
-| 问题 ID | 问题描述 | 严重程度 | 状态 | 澄清结果 |
-|---------|----------|----------|------|----------|
-| R1-001 | [一句话描述问题] | 🔴 High / 🟡 Medium / 🟢 Low | `open` / `clarifying` / `clarified` | [澄清后的结论] |
-| R1-002 | | | | |
-
-**R1-001 详细说明**:
-- **问题类型**: 功能边界模糊 / 功能流程缺失 / 功能依赖未说明
-- **具体表现**: [详细描述问题现象，引用需求原文]
-- **影响范围**: [如果不澄清会导致什么后果]
-- **建议选项**:
-  - A) [选项A描述]
-  - B) [选项B描述]
-  - C) [选项C描述]
-  - D) 自定义...
-- **澄清后**: [交互式澄清后自动填写]
-- **澄清时间**: [YYYY-MM-DD]
-- **澄清人**: [@name]
-
----
-
-##### 2. 数据相关问题
-| 问题 ID | 问题描述 | 严重程度 | 状态 | 澄清结果 |
-|---------|----------|----------|------|----------|
-| R1-010 | | | | |
-| R1-011 | | | | |
-
-**R1-010 详细说明**:
-- **问题类型**: 数据定义模糊 / 数据量级未明确 / 数据一致性问题
-- **具体表现**:
-- **影响范围**:
-- **建议选项**:
-- **澄清后**:
-
----
-
-##### 3. 用户体验问题
-| 问题 ID | 问题描述 | 严重程度 | 状态 | 澄清结果 |
-|---------|----------|----------|------|----------|
-| R1-020 | | | | |
-| R1-021 | | | | |
-
-**R1-020 详细说明**:
-- **问题类型**: 用户场景缺失 / 交互方式未确定 / 性能体验要求
-- **具体表现**:
-- **影响范围**:
-- **建议选项**:
-- **澄清后**:
-
----
-
-##### 4. 边界与异常
-| 问题 ID | 问题描述 | 严重程度 | 状态 | 澄清结果 |
-|---------|----------|----------|------|----------|
-| R1-030 | | | | |
-| R1-031 | | | | |
-
-**R1-030 详细说明**:
-- **问题类型**: 边界条件未定义 / 异常场景缺失 / 权限与安全
-- **具体表现**:
-- **影响范围**:
-- **建议选项**:
-- **澄清后**:
-
----
-
-##### 5. 集成与依赖
-| 问题 ID | 问题描述 | 严重程度 | 状态 | 澄清结果 |
-|---------|----------|----------|------|----------|
-| R1-040 | | | | |
-| R1-041 | | | | |
-
-**R1-040 详细说明**:
-- **问题类型**: 外部系统集成 / 内部模块依赖 / 环境依赖
-- **具体表现**:
-- **影响范围**:
-- **建议选项**:
-- **澄清后**:
-
----
-
-##### 6. 优先级与范围
-| 问题 ID | 问题描述 | 严重程度 | 状态 | 澄清结果 |
-|---------|----------|----------|------|----------|
-| R1-050 | | | | |
-| R1-051 | | | | |
-
-**R1-050 详细说明**:
-- **问题类型**: 必需 vs 可选 / 时间约束 / 资源约束
-- **具体表现**:
-- **影响范围**:
-- **建议选项**:
-- **澄清后**:
-
----
-
-### 功能点 2: [功能点名称]
-
-#### 基本信息
-- **功能点 ID**: [kebab-case-id]
-- **对应 Spec**: `specs/[功能点ID]/spec.md`
-- **优先级**: P0 / P1 / P2
-- **负责人**: [@name]
-
-#### 问题列表
-
-[同上结构...]
-
----
-
-## 问题统计
-
-| 分类 | 总计 | 已澄清 | 待澄清 | 已解决 |
-|------|------|--------|--------|--------|
-| 功能完整性 | 0 | 0 | 0 | 0 |
-| 数据相关 | 0 | 0 | 0 | 0 |
-| 用户体验 | 0 | 0 | 0 | 0 |
-| 边界与异常 | 0 | 0 | 0 | 0 |
-| 集成与依赖 | 0 | 0 | 0 | 0 |
-| 优先级与范围 | 0 | 0 | 0 | 0 |
-| **总计** | 0 | 0 | 0 | 0 |
-
----
-
-## 澄清记录
-
-### 交互式澄清会话 1: [YYYY-MM-DD]
-- **参与者**: [@name1, @name2, ...]
-- **澄清模式**: 命令行交互式
-- **澄清的问题**: [问题 ID 列表]
-- **达成的决策**:
-  1. [决策 1]
-  2. [决策 2]
-- **更新后的状态**: `clarifying` → `clarified`
-- **下一步行动**: [如果有]
-
-### 交互式澄清会话 2: [YYYY-MM-DD]
-
-[同上结构...]
-
----
-
-## 状态流转说明
-
-```
-discovering:    AI 正在分析需求，发现问题
-                → 发现问题后自动转为 clarifying
-
-clarifying:     问题已列出，等待交互式澄清
-                → 使用命令行界面一问一答澄清
-                → 每题回答后立即同步到本文档
-                → 支持 'q' 退出，下次自动恢复
-                → 支持 's' 跳过 Low 优先级问题
-
-clarified:      所有 High 和 Medium 问题已澄清
-                → 可以创建/更新 proposal
-                → AI 检查是否发现新问题（可能回到 discovering）
-
-superseded:     需求已变更，本文档已过时
-                → 创建新的问题清单
-```
-
-**当前状态**: `[current-status]`
-
-**状态变更历史**:
-- [YYYY-MM-DD]: `discovering` → `clarifying` (AI 完成问题发现)
-- [YYYY-MM-DD]: `clarifying` → `clarified` (完成澄清会话 1)
-- ...
-
----
-
-## 关联文档
-
-- **提案文档**: `proposal.md`
-- **功能规格**: `specs/*/spec.md`
-- **设计问题清单**: `spec/design-issues.md`
-- **分类学参考**: `openspec/templates/requirement-issue-taxonomy.md`
-
----
-
-## 备注
-
-<!-- 任何补充说明 -->

package/templates/openspec/issues/retrospective-notes.md

@@ -1,40 +0,0 @@
-# 实施观察笔记
-
-> **用途**: 在实施（apply）阶段记录轻量观察，归档时自动汇入复盘报告。
-> **何时填写**: 当以下情况发生时，随手记录。
-
----
-
-## 需求层面的意外
-
-> 当初澄清没有覆盖，但实际很重要的问题。
-> 填写格式：描述问题 + 影响
-
-- （无）
-
----
-
-## 设计层面的意外
-
-> 设计方案不明确，需要临时决策的问题。
-> 填写格式：描述问题 + 临时决策
-
-- （无）
-
----
-
-## 好的实践
-
-> 某个澄清问题明确避免了返工的情况。
-> 填写格式：哪个问题 + 避免了什么
-
-- （无）
-
----
-
-## 风险事件
-
-> 发现高风险代码区域或意外的技术问题。
-> 填写格式：描述问题 + 涉及区域/模块
-
-- （无）

package/templates/openspec/procedures/design-clarification-flow.md

@@ -1,57 +0,0 @@
-# 设计澄清完整流程
-
-## 触发条件
-
-在**创建 design.md 之后、创建 tasks 之前**，当以下任一条件成立时执行本流程：
-- `spec/design-issues.md` 不存在
-- `spec/design-issues.md` 存在但状态不在 `{clarified, resolved}`
-
-> **与需求澄清的关键区别**：无论是否发现 High/Medium 问题，设计澄清都**强制**执行用户确认步骤（步骤 4）。
-
-## 执行步骤
-
-### 步骤 1：读取设计问题分类学
-
-读取 `openspec/templates/taxonomy/design-issue-taxonomy.md`，了解 7 个检查维度：
-架构决策、技术选型、接口设计、数据状态、安全合规、性能可靠性、部署运维
-
-### 步骤 2：分析 design.md 的不确定性
-
-按 7 个维度检查 `design.md`，识别：
-- 技术决策中的模糊之处（选了什么但没说为什么）
-- 未明确的备选方案对比
-- 潜在风险点和未处理的约束条件
-
-标记每个发现问题的严重程度（High / Medium / Low）。
-
-### 步骤 3：创建 spec/design-issues.md
-
-使用 `openspec/templates/issues/design-issues.md` 模板，填充发现的问题列表，
-初始状态设为 `analyzing`。
-
-### 步骤 4：强制用户确认（无论是否发现问题，必须执行）
-
-按照 `openspec/templates/procedures/interactive-clarification-protocol.md` 的规范执行：
-- 发现 High/Medium 问题 → 批量提问，一次性展示所有问题，等待统一回答
-- 未发现 High/Medium 问题 → 展示设计分析摘要（主要决策列表），请求用户确认或提出顾虑
-
-收到回答后，将用户意见同步到 `design-issues.md`，更新状态为 `clarifying`。
-
-### 步骤 5：根据澄清结果更新 design.md
-
-将用户答案中涉及的设计调整反映到 `design.md` 中（更新技术决策、补充约束条件、明确备选方案等）。
-
-### 步骤 6：确认澄清完成，更新状态
-
-确认所有 🔴 High 问题已获得明确答案，将 `design-issues.md` 状态更新为 `clarified`。
-
-## 产出物
-
-- `spec/design-issues.md`（状态：`clarified`）
-- `design.md`（已根据澄清结果更新）
-
-## 状态流转
-
-```
-analyzing → clarifying → clarified → resolved
-```

package/templates/openspec/procedures/evolution-system.md

@@ -1,128 +0,0 @@
-# 进化体系 v5
-
-aspec (ace-spec) 的知识积累分为三层，在 `archive` 时自动推进——**使用越久，整个 spec coding 流程越精准**。
-
-## 三层架构
-
-**Layer A（每次 archive 立即更新）— 项目事实积累**
-- `openspec/decisions/adr.md`：技术决策账本，防止反复讨论已决定的事
-- `openspec/glossary.md`：领域词汇表，统一业务术语命名
-- `openspec/risk-map.md`：风险图谱，记录已知高风险区和 bug 模式
-- `openspec/specs/CHANGELOG.md`：规格演化历史（有 delta spec sync 时更新）
-- `openspec/metrics.md`：工作流效率信号
-
-**Layer B（积累 3+ 复盘后自动触发）— 流程模式学习**
-- `openspec/templates/taxonomy/`：基于跨 change 漏检/噪音模式优化问题分类学
-- `openspec/task-patterns/`：按 change 类型积累的任务分解模板库
-- `openspec/config.yaml` user_preferences：记录用户的稳定决策偏好
-
-**Layer C（长期积累，元信号）— 系统性洞察**
-- `openspec/specs/CHANGELOG.md`：规格演化历史，揭示业务边界稳定性
-- `openspec/metrics.md`：工作流效率信号，支持系统性优化
-
----
-
-## archive 操作步骤
-
-### Step 1：生成复盘报告（BEFORE archiving，必须执行）
-
-1. 读取以下文件：
-   - `spec/requirement-issues.md`
-   - `spec/design-issues.md`
-   - `spec/retrospective-notes.md`（如存在）
-   - 本次 `design.md`（提取技术决策）
-   - 本次 `proposal.md`（提取新术语）
-
-2. 在 `openspec/retrospectives/` 目录下创建复盘报告：
-   文件名：`{YYYY-MM-DD}-{change-name}.md`（目录不存在时先创建）
-
-3. 按 `openspec/templates/retrospective-template.md` 的格式填写九章内容
-
-4. 向用户展示复盘摘要（5-8 行），然后继续执行归档
-
----
-
-### Step 2：Layer A 立即更新（AFTER archiving，每次必须执行）
-
-**A1. 技术决策账本（ADR）**
-- 读取复盘报告"四、技术决策"章节
-- 如有新决策，追加到 `openspec/decisions/adr.md`：
-  ```
-  ## {决策标题} | 来源: {change-name} | 日期: {date}
-  **选择**: {选了什么}
-  **理由**: {为什么}
-  **备选**: {考虑过哪些}
-  **状态**: active
-  ```
-- 文件不存在时先创建（参考 `openspec/templates/evolution/adr.md` 格式）
-
-**A2. 领域词汇表**
-- 读取复盘报告"五、领域词汇"章节
-- 如有新术语，追加到 `openspec/glossary.md`
-- 文件不存在时先创建（参考 `openspec/templates/evolution/glossary.md` 格式）
-
-**A3. 风险图谱**
-- 读取复盘报告"六、风险事件"章节
-- 如有新风险事件，追加到 `openspec/risk-map.md` 的对应分区（"代码热点"或"问题模式"）
-- 文件不存在时先创建（参考 `openspec/templates/evolution/risk-map.md` 格式）
-
-**C1. 规格演化日志**（如本次有 delta spec sync）
-- 将 delta spec 的变更（改了什么 + 为什么）追加到 `openspec/specs/CHANGELOG.md`
-- 文件不存在时先创建并写入标题行
-
-**C2. 效率指标**
-- 将复盘报告"八、效率信号"的数据追加到 `openspec/metrics.md`：
-  `| {date} | {change-name} | {change-type} | {需求澄清轮次} | {设计澄清轮次} | {暂停次数} | {任务数} |`
-- 文件不存在时先创建并写入表头
-
----
-
-### Step 3：Layer B 进化分析（条件触发，N ≥ 3 时自动执行）
-
-**触发判断**：统计 `openspec/retrospectives/` 下 `pending-review` 状态的复盘文件数 N（不含 `accumulated-insights.md`）
-
-**N < 3 时**：
-提示用户：「✅ 归档完成，知识库已更新。复盘已保存（第 N 个），还需 {3-N} 个复盘后将自动触发进化分析。」然后结束。
-
-**N ≥ 3 时，执行以下分析**：
-
-1. 读取所有 `pending-review` 状态的复盘文件
-
-2. 分析以下模式（仅当出现 2+ 次视为显著）：
-   - 【B1: 问题分类学】哪些"漏检问题"反复出现？哪些"无效问题"反复出现？
-   - 【B2: 任务模式】同类型 change 的任务结构是否有共性？哪些步骤总被遗漏？
-   - 【B3: 用户偏好】是否发现稳定的决策/交互偏好值得记录到 config.yaml？
-
-3. 生成/更新 `openspec/retrospectives/accumulated-insights.md`，记录发现和具体优化建议
-
-4. 使用 AskUserQuestion 工具展示进化提案：
-   ```
-   🧬 进化分析完成！基于 N 个复盘，发现以下优化机会：
-
-   📚 问题分类学优化（X 条）：
-   1. [新增到需求分类学/边界与异常] "XX" 问题（N 个复盘漏检）
-   2. [从设计分类学删除] "YY" 问题（N 个复盘均标记为噪音）
-
-   📋 任务模板优化（Y 条）：
-   1. [新建 feature-add 任务模板]（基于 3 次 feature change 的共性结构）
-   2. [在 bug-fix 模板中增加"回归验证"步骤]（2 次被遗漏）
-
-   ⚙️ 偏好/规则优化（Z 条）：
-   1. [建议记录用户偏好] 观察到你通常选择保守技术方案...
-
-   是否现在应用以上优化？
-   A) 全部应用
-   B) 部分应用（请说明保留/跳过哪些）
-   C) 暂不应用（下次归档时再次提醒）
-   ```
-
-5. 根据用户选择执行：
-   - **A（全部应用）**：
-     - 更新 `openspec/templates/taxonomy/requirement-issue-taxonomy.md`（B1）
-     - 更新 `openspec/templates/taxonomy/design-issue-taxonomy.md`（B1）
-     - 更新/创建 `openspec/task-patterns/` 下对应文件（B2）
-     - 如有偏好建议：更新 `openspec/config.yaml` 的 `user_preferences`（B3）
-     - 将已分析复盘文件状态改为 `incorporated`
-     - 提示：「✅ 进化完成！知识库已更新，下次流程将更精准。」
-   - **B（部分应用）**：仅应用用户确认的条目，未应用条目记入 `accumulated-insights.md` 的"待定区"
-   - **C（暂不应用）**：保持 `pending-review`，下次归档时重新评估