@shirayner/ace 0.1.4 → 0.1.5

package/README.en-US.md

@@ -16,7 +16,7 @@
 
 ```
 $ ace init
-◇  ace v0.1.2
+◇  ace v0.1.5
 │
 ◇  Installed to ~/.claude/
 │
@@ -42,13 +42,13 @@ $ cd my-project
 # 执行 aspec 初始化
 $ ace spec init
 ✔ openspec config installed
-✔ spec templates installed (taxonomy, issues, procedures, evolution)
+✔ spec templates installed (config.yaml, dimensions.md, experience-template.md)
 Done! Spec workflow is ready.
 
 # 三命令 spec coding 流程：
 /opsx:proposal   → 需求澄清 + 创建提案 + 技术澄清 + 确定方案
 /opsx:apply      → 按方案逐项实现，每步验证
-/opsx:archive    → spec 归档，复盘总结，知识库三层进化
+/opsx:archive    → spec 归档，收敛检查
 ```
 
 Claude Code 开箱即用已经很强大——但手动配置规则、技能、安全守卫和记忆模板既繁琐又容易出错。

package/README.md

@@ -45,7 +45,7 @@ ace init
 
 ```bash
 $ ace init
-◇  ace v0.1.2
+◇  ace v0.1.5
 │
 ◇  Installed to ~/.claude/
 │
@@ -104,9 +104,8 @@ Claude:
 > /opsx:archive
 
 Claude:
-spec 归档
-复盘总结，知识库三层进化
-✓ ADR/术语表/风险图谱 已更新
+spec 归档，收敛检查
+✓ 归档完成
 ```
 
 ### 健康检查
@@ -151,10 +150,10 @@ All systems operational.
 │  │ (角色脚本)   │  │  (记忆系统)  │  │ (规范驱动)   │         │
 │  ├─────────────┤  ├─────────────┤  ├─────────────┤         │
 │  │ • Java 编译 │  │ • MEMORY.md │  │ • config    │         │
-│  │   检查      │  │ • user_     │  │ • taxonomy/ │         │
-│  │ • TypeScript│  │   profile   │  │ • issues/   │         │
-│  │   检查      │  │ • roles/    │  │ • procedures│         │
-│  │ • 更多...   │  │             │  │ • evolution │         │
+│  │   检查      │  │ • user_     │  │   .yaml     │         │
+│  │ • TypeScript│  │   profile   │  │ • dimensions│         │
+│  │   检查      │  │ • roles/    │  │   .md       │         │
+│  │ • 更多...   │  │             │  │ • experience│         │
 │  └─────────────┘  └─────────────┘  └─────────────┘         │
 │                                                             │
 └─────────────────────────────────────────────────────────────┘

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@shirayner/ace",
-  "version": "0.1.4",
+  "version": "0.1.5",
   "description": "AI Coding Environment - One command to set up your Claude Code harness",
   "bin": {
     "ace": "./bin/ace.js"

package/src/core/constants.js

@@ -52,19 +52,8 @@ export const ROLES = {
 // Spec (project-level) constants
 export const OPENSPEC_TEMPLATES_DIR = path.join(__dirname, '..', '..', 'templates', 'openspec');
 export const SPEC_TEMPLATE_FILES = [
-  'taxonomy/requirement-issue-taxonomy.md',
-  'taxonomy/design-issue-taxonomy.md',
-  'issues/requirement-issues.md',
-  'issues/design-issues.md',
-  'issues/retrospective-notes.md',
-  'evolution/adr.md',
-  'evolution/glossary.md',
-  'evolution/risk-map.md',
-  'procedures/requirement-clarification-flow.md',
-  'procedures/design-clarification-flow.md',
-  'procedures/interactive-clarification-protocol.md',
-  'procedures/evolution-system.md',
-  'retrospective-template.md',
+  'dimensions.md',
+  'experience-template.md',
 ];
 
 /**

package/templates/openspec/config.yaml

@@ -1,150 +1,152 @@
 schema: spec-driven
-
-# =============================================================================
-# aspec (ace-spec) 增强配置 v5 — 寄生模式
-# =============================================================================
-# aspec 通过 context 和 rules 注入 OpenSpec 工作流，不改变 OpenSpec schema。
-# 核心目标：捕获需求/设计中的不确定性，避免基于假设实施带来的返工。
-# =============================================================================
-
-version: "5.0.3"
-language: zh
-
+version: 9.0.0
 context: |
+  ## 语言
+  所有交互、思考链、文档内容一律使用中文。OpenSpec 模板的英文标题保留（结构标记），标题下的内容用中文填充。
+
   ## 工作模式
+  aspec 寄生于 OpenSpec 工作流，通过 context 和 rules 注入增强能力，不修改 OpenSpec 本身。
+  核心理念：对齐优先于效率。准确完成用户真正想要的，胜过高效完成 AI 以为的。
 
-  aspec (ace-spec) 采用"寄生模式"增强 OpenSpec 核心流程：在关键阶段注入前置/后置检查，
-  不改变 OpenSpec schema。跳过澄清 = AI 基于假设实施 = 大概率返工。
+  ## 流程概览
+  [需求澄清 → 对齐] → proposal → specs
+  → [设计澄清 → 对齐] → design.md → [设计审批] → tasks
+  → [确认实施?] → apply → [经验提取] → [确认归档?] → archive
 
-  ## 门禁条件（强制，不满足时禁止继续）
+  ## 通用原则：惊讶测试
+  替用户做选择时，如果用户此刻看到该决策会惊讶 → 暂停，展示选项等待确认。
 
-  | 阶段 | 前置条件 | 触发动作 |
-  |------|----------|----------|
-  | proposal 前 | spec/requirement-issues.md 状态为 `clarified` | 执行需求澄清流程 |
-  | tasks 前 | spec/design-issues.md 状态为 `clarified` 或 `resolved` | 执行设计澄清流程 |
+  ## 门禁条件
 
-  澄清流程文档（含详细执行步骤）：
-  - 需求澄清：openspec/templates/procedures/requirement-clarification-flow.md
-  - 设计澄清：openspec/templates/procedures/design-clarification-flow.md
-  - 交互式提问通用协议：openspec/templates/procedures/interactive-clarification-protocol.md
+  | 阶段 | 前置条件 |
+  |------|----------|
+  | proposal | 需求澄清完成 + 对齐确认通过 |
+  | design.md | 设计澄清完成 + 对齐确认通过 |
+  | tasks | 用户审批 design.md |
 
   ## 澄清状态机
-
-  需求澄清：discovering → clarifying → clarified → superseded
-  设计澄清：analyzing → clarifying → clarified → resolved
-
-  ## 问题严重程度
-
-  - 🔴 High：阻塞性，必须澄清后才能继续
-  - 🟡 Medium：重要，建议澄清
-  - 🟢 Low：建议性，可后续补充
-
-  ## 知识库索引
-
-  - 需求问题分类学（6维度）：openspec/templates/taxonomy/requirement-issue-taxonomy.md
-  - 设计问题分类学（7维度）：openspec/templates/taxonomy/design-issue-taxonomy.md
-  - 问题清单模板：openspec/templates/issues/（requirement-issues.md / design-issues.md）
-
-  ## 进化体系（v5）
-
-  aspec 在 archive 时自动积累项目知识，**使用越久，流程越精准**：
-  - Layer A（每次立即）：ADR 技术决策 / 词汇表 / 风险图谱
-  - Layer B（积累 3+ 复盘后触发）：问题分类学优化 / 任务模板 / 用户偏好
-  - Layer C（长期）：规格演化历史 / 效率指标
-
-  完整说明及 archive 操作步骤：openspec/templates/procedures/evolution-system.md
-
-  ## AI 知识库消费速查
-
-  每个阶段开始前读取对应知识库，避免重复已有决策：
-  - explore / propose：ADR + Glossary + Task Patterns
-  - specs：Glossary + Spec CHANGELOG
-  - design：ADR + Risk Map + 问题分类学
-  - tasks：Task Patterns + Risk Map
-  - apply：ADR + Risk Map
-  - archive：全部 → 更新全部 → 触发进化分析
-
-# =============================================================================
-# 阶段规则
-# =============================================================================
-
+  - 需求：discovering → clarifying → clarified → superseded
+  - 设计：analyzing → clarifying → clarified → resolved
+
+  ## 严重度
+  - High：阻塞性，必须澄清 / Medium：建议澄清 / Low：可选
+
+  ## Spec 质量标准
+  - proposal：每个 Capability 有明确边界和验收条件
+  - specs：场景覆盖核心路径 + 已知边界条件
+  - design：每个 High 决策有选择、理由、备选方案
+  - tasks：可独立验证，粒度适合单次实现
+
+  ## Issue Schema
+  - 需求问题：id (R{功能序号}-{编号}), description, severity, status, answer
+  - 设计问题：id (D{维度序号}-{编号}), description, severity, status, decision, rationale
+  - 按功能点或维度分组，含统计汇总。格式自行组织。
+
+  ## 实施观察笔记
+  apply 阶段记录到 spec/notes.md，分四类：需求意外 / 设计意外 / 好的实践 / 风险事件
+
+  ## 澄清与对齐协议
+
+  需求澄清（proposal 前）和设计澄清（design.md 前）共用此协议，分两个独立步骤：
+
+  ### 步骤一：澄清
+  通过 AskUserQuestion 工具批量提问所有 High/Medium 问题，标注总数和严重度分布。
+  用户可中途退出（q），进度保存到问题清单。收到完整回答后统一更新问题清单。
+  差异：需求澄清无问题时可跳过；设计澄清即使无问题也须展示决策摘要。
+
+  ### 步骤二：对齐确认
+  澄清完成后，AI 用 markdown 文本向用户呈现 4 要素：
+  1. 我的理解 — 复述核心需求/设计意图
+  2. 计划方向 — 接下来文档将包含什么
+  3. 关键假设 — 不确定的假设
+  4. 完成标准 — 产出合格条件
+  呈现完毕后，调用 AskUserQuestion 让用户确认或调整。
+  注意：对齐内容用普通 markdown 文本输出，不放在 AskUserQuestion 中（大段内容显示异常）。
+
+  ### 设计额外要求
+  design.md 创建后、tasks 前，须展示设计核心摘要，通过 AskUserQuestion 获得审批。
+
+  ## 知识进化
+
+  ### 生命周期：提取 → 存储 → 主动应用 → 验证 → 收敛
+
+  ### 提取（每次 apply 完成后）
+
+  | 复盘章节 | 目标 | 更新内容 |
+  |----------|------|----------|
+  | 技术决策 | experience.md 技术决策段 | 选择 + 理由 + 备选 + 状态 |
+  | 新术语 | experience.md 领域词汇段 | 定义 + 首次出现 |
+  | 风险事件 | experience.md 风险图谱段 | 描述 + 区域 + 类型 |
+  | 澄清漏检 | dimensions.md 盲区段 | 新盲区 |
+  | 复盘记录 | experience.md 复盘记录段 | 变更概述·澄清质量·过程经验·效率信号 |
+
+  ### 主动应用（每次新 change 开始）
+  读取 openspec/experience.md 和 dimensions.md 盲区段，主动告知用户相关知识。
+
+  ### 收敛
+  条目超阈值时合并/淘汰（需用户确认）。
+
+  ## 阶段规则（非 schema artifact）
+
+  ### explore 阶段
+  [PRE] **知识主动应用**
+  读取 openspec/experience.md 和 dimensions.md 盲区段，告知用户与当前 change 相关的已有知识。
+
+  ### apply 阶段
+  [CONSTRAINT] 实施前读取所有澄清决策。新问题暂停评估，记录到 spec/notes.md。
+  [CONSTRAINT] Spec-Code 一致性：偏差须记录理由。
+  [POST] **复盘与知识进化**
+  1. 回顾本次实施过程，按 experience-template.md 复盘记录段的结构追加复盘
+  2. 提取知识更新 openspec/experience.md（技术决策/术语/风险）
+  3. 漏检问题更新 dimensions.md 盲区段
+  4. 展示 5-8 行摘要供用户确认
+  [POST] **流程衔接 → 归档**
+  经验提取完成后，通过 AskUserQuestion 询问用户："是否立即归档？"
+  选项：立即归档（推荐）/ 稍后手动归档
+  用户确认后，调用 Skill 工具执行 opsx:archive。
+
+  ### archive 阶段
+  [POST] **收敛检查**
+  experience.md 条目超阈值时提议合并/淘汰（需用户确认）。
 rules:
-  # ===========================================================================
-  # proposal — 需求澄清门禁
-  # ===========================================================================
   proposal:
     - |
-      BEFORE creating proposal：
-      1. 检查 spec/requirement-issues.md 是否存在且状态为 clarified
-      2. 不满足 → 执行 openspec/templates/procedures/requirement-clarification-flow.md 中的完整流程
-      3. 通过后创建 proposal，在 Why / Capabilities / Impact 中引用澄清决策
-    - "🚫 禁止跳过：requirement-issues.md 不存在或状态非 clarified 时，禁止创建 proposal"
-
-  # ===========================================================================
-  # specs — 与澄清结果保持一致
-  # ===========================================================================
+      [PRE] **需求澄清 + 对齐确认**
+      1. 读取 dimensions.md 作为参考维度和已知盲区，同时自主探索需求中的新不确定性
+      2. 创建/更新 spec/requirement-issues.md
+      3. 步骤一（澄清）：AskUserQuestion 批量提问
+      4. 步骤二（对齐确认）：markdown 展示 4 要素 → AskUserQuestion 确认
+      5. 确认后标记 clarified，创建 proposal
+
   specs:
     - |
-      创建 specs 时：
-      - 参考 requirement-issues.md 中的功能点定义，确保规格与澄清结果一致
-      - 需求有变更（MODIFIED/REMOVED/RENAMED）时，在问题清单中记录变更原因
+      [CONSTRAINT] specs 必须与已澄清的需求一致。
+      需求有变更时，在问题清单中记录变更原因。
 
-  # ===========================================================================
-  # design — 技术决策四要素 + 设计澄清门禁
-  # ===========================================================================
   design:
     - |
-      创建 design.md 时，每个技术决策必须包含：
-      - 选择了什么方案
-      - 为什么选择（决策理由）
-      - 考虑过哪些备选方案
-      - 为什么放弃备选方案
-      注意体现 requirement-issues.md 中澄清的约束条件。
+      [PRE] **设计澄清 + 对齐确认**
+      1. 自主探索设计中的不确定性，结合 proposal 和 specs 分析技术决策点
+      2. 创建/更新 spec/design-issues.md
+      3. 步骤一（澄清）：AskUserQuestion 批量提问（设计阶段即使无问题也须展示决策摘要）
+      4. 步骤二（对齐确认）：markdown 展示 4 要素 → AskUserQuestion 确认
+      5. 确认后创建 design.md
     - |
-      AFTER creating design.md：
-      1. 检查 spec/design-issues.md 是否存在且状态为 clarified 或 resolved
-      2. 不满足 → 执行 openspec/templates/procedures/design-clarification-flow.md 中的完整流程
-      3. 根据澄清结果更新 design.md，通过后创建 tasks
-    - "🚫 禁止跳过：design-issues.md 不存在或状态不在 {clarified, resolved} 时，禁止创建 tasks"
-
-  # ===========================================================================
-  # tasks — 基于最终方案创建任务
-  # ===========================================================================
+      [CONSTRAINT] 技术决策四要素：
+      - 决策内容（选择了什么方案）
+      - 选择理由（为什么选择）
+      - 备选方案（考虑过哪些）
+      - 排除原因（为什么放弃备选）
+
   tasks:
     - |
-      创建 tasks 时：
-      - 基于最终确定的技术方案（已经过设计澄清）
-      - 确保任务覆盖 design-issues.md 中所有 🔴 High 决策
-      - 设计澄清导致 design.md 重大变更时，相应调整任务列表
-      - 任务描述中引用相关设计决策（方便追溯）
-
-  # ===========================================================================
-  # apply — 严格遵循澄清决策
-  # ===========================================================================
-  apply:
-    - |
-      实施前：读取 spec/requirement-issues.md 和 spec/design-issues.md，了解所有澄清决策。
-    - |
-      实施中：严格遵循澄清决策。发现新问题时：
-      暂停 → 评估问题类型（需求/设计）→ 更新对应问题清单 → 可选启动澄清补充 → 继续
-      完成每个任务后立即用 "- [x]" 标记完成。
-    - |
-      轻量观察（选做，记录到 spec/retrospective-notes.md，供归档时汇入复盘报告）：
-      - 澄清未覆盖但实际重要的问题 → 【需求层面的意外】
-      - 设计不明确需临时决策的问题 → 【设计层面的意外】
-      - 澄清有效避免返工的案例 → 【好的实践】
-      - 高风险代码区域或意外技术问题 → 【风险事件】
-
-  # ===========================================================================
-  # archive — 复盘 + 知识库更新 + 进化分析
-  # ===========================================================================
-  archive:
+      [PRE] **设计文档审批**
+      展示 design.md 核心摘要（关键决策、目标/非目标、风险），通过 AskUserQuestion 获得审批后创建任务。
     - |
-      BEFORE archiving — 生成复盘报告：
-      1. 读取 spec/requirement-issues.md、design-issues.md、retrospective-notes.md（如存在）、design.md、proposal.md
-      2. 在 openspec/retrospectives/{YYYY-MM-DD}-{change-name}.md 创建复盘报告
-         格式参见 openspec/templates/retrospective-template.md
-      3. 向用户展示复盘摘要（5-8 行），然后继续归档
+      [CONSTRAINT] 任务必须基于已审批的设计。
+      所有 High 决策须在任务中体现。
     - |
-      AFTER archiving — 执行进化体系更新（Layer A 立即 + Layer B 条件触发）：
-      完整操作步骤参见 openspec/templates/procedures/evolution-system.md
+      [POST] **流程衔接 → 实施**
+      Tasks 创建完成后，通过 AskUserQuestion 询问用户："是否立即开始实施？"
+      选项：立即执行（推荐）/ 稍后手动执行
+      用户确认后，调用 Skill 工具执行 opsx:apply。

package/templates/openspec/dimensions.md

@@ -0,0 +1,11 @@
+# 澄清维度
+
+**需求**：功能完整性 | 数据关切 | 用户体验 | 边界异常 | 集成依赖 | 优先级范围
+**设计**：架构决策 | 技术选型 | 接口设计 | 数据状态 | 安全合规 | 性能可靠性 | 部署运维
+
+分析不确定性时参考以上维度，聚焦实际不确定的部分，不逐条遍历。
+
+## 项目已知盲区（优先检查）
+
+<!-- 由进化体系自动维护。格式：维度 | 盲区描述 | 来源 change -->
+*首次 archive 后自动填充。*

package/templates/openspec/experience-template.md

@@ -0,0 +1,25 @@
+# 项目经验库
+
+## 技术决策 (ADR)
+<!-- 每次 apply 完成后自动从复盘提取。格式自行组织。 -->
+*暂无记录。首次 apply 完成后自动填充。*
+
+## 领域词汇
+<!-- 每次 apply 完成后自动提取新术语。 -->
+*暂无记录。*
+
+## 风险图谱
+
+### 代码热点
+<!-- 频繁变更或容易出问题的代码区域。 -->
+*暂无记录。*
+
+### 问题模式
+<!-- 多个 change 中反复出现的问题类型。 -->
+*暂无记录。*
+
+---
+
+## 复盘记录
+<!-- 每次 apply 完成后追加一条。结构提示：变更概述 / 澄清质量(命中·漏检·噪音) / 技术决策 / 过程经验 / 效率信号 -->
+*暂无记录。*

package/templates/openspec/evolution/adr.md

@@ -1,23 +0,0 @@
-# 技术决策账本（Architecture Decision Records）
-
-> **用途**: 记录项目中已做出的架构和技术决策，避免重复讨论已决定的事项。
-> **更新时机**: 每次 archive 时，自动从复盘报告提取新决策追加。
->
-> **如何消费**:
-> - design 阶段：先查询此文件，已有决策不重复讨论
-> - explore 阶段：比较技术方案时直接引用
-> - propose 阶段：评估 Impact 时与已有决策对齐
-
----
-
-<!-- 格式：
-## {决策标题} | 来源: {change-name} | 日期: {YYYY-MM-DD}
-
-**选择**: 选了什么方案
-**理由**: 为什么选择这个方案
-**备选**: 考虑过哪些其他方案
-**放弃原因**: 为什么放弃备选方案
-**状态**: active / superseded / deprecated
--->
-
-*暂无决策记录。第一次 archive 后将自动填充。*

package/templates/openspec/evolution/glossary.md

@@ -1,24 +0,0 @@
-# 领域词汇表（Domain Glossary）
-
-> **用途**: 项目中稳定使用的业务术语、技术概念的标准定义，以及 Capability 命名规范。
-> **更新时机**: 每次 archive 时，自动从 proposal 的 Capabilities 章节提取新术语追加。
->
-> **如何消费**:
-> - propose 阶段：Capabilities 命名时复用标准术语保持一致
-> - specs 阶段：Scenario 中使用标准术语，减少歧义
-> - 新成员加入时：快速建立项目语言认知
-
----
-
-<!-- 格式：
-## {术语}
-
-**定义**: 一句话定义
-**首次出现**: {change-name}（{date}）
-**相关术语**: 与哪些其他术语有关联
-**备注**: 如有歧义或特殊用法说明
-
----
--->
-
-*暂无词汇记录。第一次 archive 后将自动填充。*

package/templates/openspec/evolution/risk-map.md

@@ -1,43 +0,0 @@
-# 风险图谱（Risk Map）
-
-> **用途**: 记录项目中已知的高风险代码区域、高频 bug 模式，以及历史上实际发生的实施问题。
-> **更新时机**: 每次 archive 时，从复盘报告"六、风险事件"章节提取新发现追加。
->
-> **如何消费**:
-> - design 阶段：优先检查已知风险区域
-> - tasks 阶段：高风险区任务自动细化粒度、增加验证步骤
-> - apply 阶段：进入高风险区时主动预警
-
----
-
-## 代码热点
-
-> 历史上频繁变更或容易出问题的代码区域。
-
-<!-- 格式：
-### {模块/文件路径}
-
-**风险类型**: 频繁变更 / 并发问题 / 边界复杂 / 依赖脆弱 / 其他
-**历史问题**: 具体描述
-**首次记录**: {change-name}（{date}）
-**注意事项**: 处理时需要特别关注的点
--->
-
-*暂无记录。第一次 archive 后将自动填充。*
-
----
-
-## 问题模式
-
-> 在多个 change 中反复出现的问题类型。
-
-<!-- 格式：
-### {问题模式名称}
-
-**描述**: 什么情况下会触发
-**影响范围**: 影响哪些功能/模块
-**出现次数**: N 次（最近一次: {change-name}）
-**预防措施**: 如何在下次避免
--->
-
-*暂无记录。第一次 archive 后将自动填充。*