@shirayner/ace 0.1.4 → 0.1.5

package/templates/openspec/procedures/interactive-clarification-protocol.md

@@ -1,54 +0,0 @@
-# 交互式澄清通用协议
-
-本协议定义 aspec (ace-spec) 与用户进行批量问答澄清的交互规范。
-**需求澄清**和**设计澄清**均使用此协议，不在各自流程中重复定义。
-
-## 调用方式
-
-由澄清流程文档在需要用户回答问题时调用：
-- 需求澄清调用入口：`openspec/templates/procedures/requirement-clarification-flow.md` 步骤 5
-- 设计澄清调用入口：`openspec/templates/procedures/design-clarification-flow.md` 步骤 4
-
-## 有 High/Medium 问题时：批量提问
-
-使用 AskUserQuestion 工具，将所有 High/Medium 问题组织为编号列表，**一次性**展示给用户：
-
-```
-需要确认 N 个问题（X High，Y Medium），请一并回答：
-
-1. [问题描述]
-   选项：A) ... B) ... C) ...
-
-2. [问题描述]
-   选项：A) ... B) ...
-
-...
-```
-
-## 无 High/Medium 问题时：确认摘要（仅设计澄清强制执行）
-
-即使未发现高优先级问题，设计澄清仍**强制**展示分析摘要并请求确认：
-
-```
-设计分析完成，未发现高优先级问题。主要设计决策摘要如下：
-- [关键决策 1]
-- [关键决策 2]
-...
-
-请确认以上设计，或提出任何顾虑/补充：
-```
-
-> 需求澄清若无 High/Medium 问题，可直接将状态标记为 clarified，无需强制确认。
-
-## 核心规则
-
-- **批量提问**：所有问题一次性展示，不逐题单独提交
-- **统一同步**：收到用户完整回答后，统一同步到问题清单（不在每题之后单独同步）
-- **进度显示**：标题中显示总题数，如 "需要确认 5 个问题（2 High，3 Medium）"
-- **选项格式**：每题附带 2-4 个备选选项，帮助用户快速决策
-- **断点续传**：用户可输入 `q` 随时退出，进度自动保存；下次从断点恢复
-
-## 收到回答后
-
-将用户答案同步到对应的问题清单文件（`requirement-issues.md` 或 `design-issues.md`），
-更新各问题的 `answer` 字段，并将整体状态更新为 `clarifying`。

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

@@ -1,55 +0,0 @@
-# 需求澄清完整流程
-
-## 触发条件
-
-在**创建 proposal 之前**，当以下任一条件成立时执行本流程：
-- `spec/requirement-issues.md` 不存在
-- `spec/requirement-issues.md` 存在但状态不是 `clarified`
-
-## 执行步骤
-
-### 步骤 1：读取需求问题分类学
-
-读取 `openspec/templates/taxonomy/requirement-issue-taxonomy.md`，了解 6 个检查维度：
-功能完整性、数据相关、用户体验、边界异常、集成依赖、优先级
-
-### 步骤 2：分析需求，识别功能点（Capabilities）
-
-读取当前需求描述，拆解出所有独立功能点，每个功能点分配唯一 ID（如 `CAP-001`）。
-
-### 步骤 3：按 6 个维度检查每个功能点
-
-对每个功能点，逐一检查 6 个维度是否存在不确定性或缺失信息，识别问题并标记严重程度：
-- 🔴 High：阻塞性，必须澄清后才能继续
-- 🟡 Medium：重要，建议澄清
-- 🟢 Low：建议性，可后续补充
-
-### 步骤 4：创建 spec/requirement-issues.md
-
-使用 `openspec/templates/issues/requirement-issues.md` 模板，填充发现的问题列表，
-初始状态设为 `discovering`。
-
-### 步骤 5：启动交互式澄清
-
-按照 `openspec/templates/procedures/interactive-clarification-protocol.md` 的规范执行：
-- 将所有 High/Medium 问题组织为批量提问，一次性展示给用户
-- 等待用户统一回答
-- 收到回答后，将答案同步到 `requirement-issues.md`，更新状态为 `clarifying`
-
-若无 High/Medium 问题，可跳过交互直接进入步骤 6。
-
-### 步骤 6：确认澄清完成，更新状态
-
-确认所有 🔴 High 问题已获得明确答案，将 `requirement-issues.md` 状态更新为 `clarified`。
-
-> 🟢 Low 问题可保留为 open 状态，不阻塞流程继续。
-
-## 产出物
-
-- `spec/requirement-issues.md`（状态：`clarified`）
-
-## 状态流转
-
-```
-discovering → clarifying → clarified → superseded
-```

package/templates/openspec/retrospective-template.md

@@ -1,81 +0,0 @@
-# 复盘报告模板
-
-> 使用说明：在 `openspec/retrospectives/{YYYY-MM-DD}-{change-name}.md` 中按此格式填写。
-
----
-
-# 复盘报告 - {change-name}
-
-**变更日期**: {YYYY-MM-DD}
-**变更类型**: bug-fix / feature-add / refactor / config-update / 其他
-**复盘状态**: `pending-review`
-
-## 一、变更概述
-
-- **做了什么**: 简述需求
-- **实际结果**: 实施了什么，与预期是否一致
-
-## 二、需求澄清质量（→ Layer B1 原料）
-
-### 命中的关键问题（避免了返工）
-| # | 问题 | 维度 | 为什么重要 |
-|---|------|------|-----------|
-
-### 无效问题（问了但实际不重要）
-| # | 问题 | 维度 | 实际影响 |
-|---|------|------|---------|
-
-### 漏检问题（实施中才暴露）
-| # | 问题 | 建议归入哪个维度 | 重要性 |
-|---|------|----------------|-------|
-
-## 三、设计澄清质量（→ Layer B1 原料）
-
-### 命中的关键决策
-| # | 问题 | 维度 | 为什么重要 |
-|---|------|------|-----------|
-
-### 过度担心的问题（实际无关紧要）
-| # | 问题 | 维度 | 实际影响 |
-|---|------|------|---------|
-
-### 漏检的设计盲点（实施中才发现）
-| # | 问题 | 建议归入哪个维度 | 涉及代码区域 |
-|---|------|----------------|------------|
-
-## 四、技术决策（→ Layer A1：ADR 更新原料）
-
-| 决策 | 选择了什么 | 为什么 | 考虑过哪些备选 |
-|------|-----------|-------|--------------|
-
-## 五、领域词汇（→ Layer A2：词汇表更新原料）
-
-| 术语 | 定义 | 首次出现场景 |
-|------|------|------------|
-
-## 六、风险事件（→ Layer A3：风险图谱更新原料）
-
-| 事件描述 | 涉及代码区域/模块 | 问题类型 | 是否已在风险图谱中 |
-|---------|----------------|---------|-----------------|
-
-## 七、实施观察（来自 retrospective-notes.md）
-
-{如有，复制 retrospective-notes.md 内容；无则填"无"}
-
-## 八、效率信号（→ Layer C2：指标原料）
-
-| 项目 | 值 |
-|------|---|
-| 需求澄清轮次 | |
-| 设计澄清轮次 | |
-| apply 暂停次数 | |
-| 最终任务总数 | |
-
-## 九、综合评分
-
-| 维度 | 评分（1-5） |
-|------|-----------|
-| 需求识别准确率 | |
-| 设计识别准确率 | |
-| 澄清效率 | |
-| 实施中意外问题数（越少越好） | |

package/templates/openspec/taxonomy/design-issue-taxonomy.md

@@ -1,180 +0,0 @@
-# 设计问题分类学
-
-## 如何使用
-
-AI 在分析技术设计时，应按以下分类维度检查设计方案中的不确定性和风险。
-
----
-
-## 1. 架构决策问题 (Architecture Decisions)
-
-### 1.1 架构方案不确定
-- **症状**: 缺少架构选型理由
-- **检查点**:
-  - 采用的架构模式是什么？（单体/微服务/Serverless）
-  - 为什么选择这种架构？
-  - 其他备选方案及放弃原因？
-
-### 1.2 服务边界模糊
-- **症状**: 服务职责划分不清
-- **检查点**:
-  - 各服务的职责范围？
-  - 服务间通信方式？（同步/异步）
-  - 数据归属哪个服务？
-
-### 1.3 扩展性考量缺失
-- **症状**: 未考虑未来扩展
-- **检查点**:
-  - 未来可能的增长点？
-  - 扩展的瓶颈在哪里？
-  - 横向扩展方案？
-
----
-
-## 2. 技术选型问题 (Technology Choices)
-
-### 2.1 核心框架/库未确定
-- **症状**: "使用主流框架"过于笼统
-- **检查点**:
-  - 具体的框架/库版本？
-  - 选型理由（性能/生态/团队熟悉度）？
-  - 替代方案比较？
-
-### 2.2 数据库选型不确定
-- **症状**: 数据存储方案不明确
-- **检查点**:
-  - 使用哪种数据库？（SQL/NoSQL/混合）
-  - 数据模型如何映射到存储？
-  - 读写分离/分库分表策略？
-
-### 2.3 中间件依赖
-- **症状**: 消息队列/缓存等未明确
-- **检查点**:
-  - 使用哪些中间件？
-  - 中间件的高可用方案？
-  - 中间件的运维成本？
-
----
-
-## 3. 接口设计问题 (Interface Design)
-
-### 3.1 API 契约未定
-- **症状**: 接口只描述了功能，未定义契约
-- **检查点**:
-  - 接口的请求/响应格式？
-  - 错误码定义？
-  - 版本管理策略？
-
-### 3.2 数据流不清晰
-- **症状**: 数据如何在系统中流转不明
-- **检查点**:
-  - 数据的入口和出口？
-  - 数据转换逻辑在哪里？
-  - 数据验证的时机和方式？
-
-### 3.3 异步处理机制
-- **症状**: 异步场景未明确
-- **检查点**:
-  - 哪些操作需要异步？
-  - 消息可靠性保证？
-  - 幂等性如何处理？
-
----
-
-## 4. 数据与状态问题 (Data & State)
-
-### 4.1 数据模型未定
-- **症状**: ER 图或 Schema 未确定
-- **检查点**:
-  - 实体关系是否已明确？
-  - 字段类型和约束？
-  - 索引设计？
-
-### 4.2 状态机未定义
-- **症状**: 业务状态流转不明
-- **检查点**:
-  - 有哪些业务状态？
-  - 状态间的流转规则？
-  - 状态变更的触发条件？
-
-### 4.3 数据迁移方案
-- **症状**: 存量数据处理未考虑
-- **检查点**:
-  - 是否需要数据迁移？
-  - 迁移策略（在线/离线）？
-  - 回滚方案？
-
----
-
-## 5. 安全与合规 (Security & Compliance)
-
-### 5.1 认证授权未设计
-- **症状**: 安全方案缺失
-- **检查点**:
-  - 认证方式？（OAuth/JWT/Session）
-  - 权限模型？（RBAC/ABAC）
-  - Token 过期和刷新策略？
-
-### 5.2 数据安全
-- **症状**: 敏感数据处理未明确
-- **检查点**:
-  - 哪些数据需要加密？
-  - 加密策略？（传输/存储）
-  - 密钥管理方案？
-
-### 5.3 审计与日志
-- **症状**: 操作审计未考虑
-- **检查点**:
-  - 需要审计哪些操作？
-  - 日志保留策略？
-  - 审计查询需求？
-
----
-
-## 6. 性能与可靠性 (Performance & Reliability)
-
-### 6.1 性能瓶颈未识别
-- **症状**: 缺少性能分析
-- **检查点**:
-  - 预期的 QPS/TPS？
-  - 可能的性能瓶颈？
-  - 性能优化策略？
-
-### 6.2 缓存策略未定
-- **症状**: 缓存方案缺失
-- **检查点**:
-  - 哪些数据需要缓存？
-  - 缓存更新策略？（主动/被动）
-  - 缓存一致性保证？
-
-### 6.3 降级与熔断
-- **症状**: 故障处理未设计
-- **检查点**:
-  - 依赖服务失败如何处理？
-  - 是否需要熔断机制？
-  - 降级方案？
-
----
-
-## 7. 部署与运维 (Deployment & Operations)
-
-### 7.1 部署方案未定
-- **症状**: 如何上线未明确
-- **检查点**:
-  - 部署环境要求？
-  - 部署流程？（蓝绿/金丝雀）
-  - 回滚策略？
-
-### 7.2 监控告警
-- **症状**: 可观测性未设计
-- **检查点**:
-  - 需要监控哪些指标？
-  - 告警阈值和策略？
-  - 日志收集方案？
-
-### 7.3 配置管理
-- **症状**: 配置项未梳理
-- **检查点**:
-  - 哪些配置需要外部化？
-  - 配置变更如何生效？
-  - 环境间配置差异？

package/templates/openspec/taxonomy/requirement-issue-taxonomy.md

@@ -1,155 +0,0 @@
-# 需求问题分类学
-
-## 如何使用
-
-AI 在分析需求时，应按以下分类维度逐一检查，确保不遗漏关键问题。
-
----
-
-## 1. 功能完整性问题 (Functional Completeness)
-
-### 1.1 功能边界模糊
-- **症状**: "支持用户管理" — 具体包括哪些操作？
-- **检查点**:
-  - 功能的包含范围是否明确？
-  - 功能的排除范围是否明确？
-  - 与相邻功能的边界是否清晰？
-
-### 1.2 功能流程缺失
-- **症状**: 只描述了结果，没描述过程
-- **检查点**:
-  - 用户如何触发这个功能？
-  - 功能的完整流程是什么？
-  - 异常情况如何处理？
-
-### 1.3 功能依赖未说明
-- **症状**: 假设其他功能已存在
-- **检查点**:
-  - 该功能依赖哪些前置功能？
-  - 依赖的功能是否已实现？
-  - 依赖的接口是否已定义？
-
----
-
-## 2. 数据相关问题 (Data Concerns)
-
-### 2.1 数据定义模糊
-- **症状**: "用户资料" — 包含哪些字段？
-- **检查点**:
-  - 核心数据实体有哪些？
-  - 每个实体的字段和类型是什么？
-  - 字段的约束条件（必填、唯一、格式）？
-
-### 2.2 数据量级未明确
-- **症状**: 没有考虑数据规模
-- **检查点**:
-  - 预计的数据量级？（条数/日增长）
-  - 是否有大数据量特殊处理需求？
-  - 数据保留策略？
-
-### 2.3 数据一致性问题
-- **症状**: 多系统数据同步场景
-- **检查点**:
-  - 数据是否需要跨系统一致？
-  - 一致性要求（强一致/最终一致）？
-  - 冲突解决策略？
-
----
-
-## 3. 用户体验问题 (User Experience)
-
-### 3.1 用户场景缺失
-- **症状**: 没有具体的使用场景
-- **检查点**:
-  - 目标用户是谁？
-  - 用户在什么场景下使用？
-  - 用户的核心痛点是什么？
-
-### 3.2 交互方式未确定
-- **症状**: 界面交互细节缺失
-- **检查点**:
-  - 界面布局有要求吗？
-  - 关键操作的交互流程？
-  - 错误提示方式？
-
-### 3.3 性能体验要求
-- **症状**: 没有性能指标
-- **检查点**:
-  - 响应时间要求？
-  - 并发用户数？
-  - 可用性要求（SLA）？
-
----
-
-## 4. 边界与异常 (Edge Cases & Exceptions)
-
-### 4.1 边界条件未定义
-- **症状**: 只考虑正常流程
-- **检查点**:
-  - 输入的边界值（最大/最小/空值）？
-  - 数量的边界（批量操作的最大值）？
-  - 时间的边界（超时、有效期）？
-
-### 4.2 异常场景缺失
-- **症状**: "用户会正确操作"
-- **检查点**:
-  - 网络异常如何处理？
-  - 第三方服务失败如何处理？
-  - 数据校验失败如何反馈？
-
-### 4.3 权限与安全
-- **症状**: 没有权限控制描述
-- **检查点**:
-  - 哪些角色可以使用？
-  - 数据权限如何控制？
-  - 敏感操作是否需要审计？
-
----
-
-## 5. 集成与依赖 (Integration & Dependencies)
-
-### 5.1 外部系统集成
-- **症状**: 需要对接但未说明细节
-- **检查点**:
-  - 需要对接哪些外部系统？
-  - 对接的接口是否已确定？
-  - 外部系统的稳定性/可用性？
-
-### 5.2 内部模块依赖
-- **症状**: 与现有功能的关系不明
-- **检查点**:
-  - 需要修改哪些现有模块？
-  - 是否影响现有功能？
-  - 是否需要数据迁移？
-
-### 5.3 环境依赖
-- **症状**: 部署环境未明确
-- **检查点**:
-  - 目标部署环境？（开发/测试/生产）
-  - 环境配置要求？
-  - 基础设施依赖？
-
----
-
-## 6. 优先级与范围 (Priority & Scope)
-
-### 6.1 必需 vs 可选
-- **症状**: 所有功能都"必须有"
-- **检查点**:
-  - MVP 必须包含哪些功能？
-  - 哪些是后续迭代功能？
-  - 功能优先级排序？
-
-### 6.2 时间约束
-- **症状**: 没有时间线
-- **检查点**:
-  - 期望的交付时间？
-  - 是否有硬性 deadline？
-  - 阶段性里程碑？
-
-### 6.3 资源约束
-- **症状**: 资源无限假设
-- **检查点**:
-  - 预算限制？
-  - 人力约束？
-  - 技术栈限制？