@shirayner/ace 0.1.3 → 0.1.4-snapshot.20260423234641

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@shirayner/ace",
-  "version": "0.1.3",
+  "version": "0.1.4-snapshot.20260423234641",
   "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,140 @@
 schema: spec-driven
-
-# =============================================================================
-# aspec (ace-spec) 增强配置 v5 — 寄生模式
-# =============================================================================
-# aspec 通过 context 和 rules 注入 OpenSpec 工作流，不改变 OpenSpec schema。
-# 核心目标：捕获需求/设计中的不确定性，避免基于假设实施带来的返工。
-# =============================================================================
-
-version: "5.0.3"
+version: 8.0.0
 language: zh
 
 context: |
   ## 工作模式
+  aspec 寄生于 OpenSpec 工作流，通过 context 和 rules 注入增强能力，不修改 OpenSpec 本身。
+  核心理念：对齐优先于效率。准确完成用户真正想要的，胜过高效完成 AI 以为的。
 
-  aspec (ace-spec) 采用"寄生模式"增强 OpenSpec 核心流程：在关键阶段注入前置/后置检查，
-  不改变 OpenSpec schema。跳过澄清 = AI 基于假设实施 = 大概率返工。
+  ## 流程概览
+  explore → [需求澄清 → 对齐确认] → 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：可选
+
+  ## 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，分四类：需求意外 / 设计意外 / 好的实践 / 风险事件
 
-  需求澄清：discovering → clarifying → clarified → superseded
-  设计澄清：analyzing → clarifying → clarified → resolved
+  ## 澄清与对齐协议
 
-  ## 问题严重程度
+  需求澄清（proposal 前）和设计澄清（design.md 前）共用此协议，分两个独立步骤：
 
-  - 🔴 High：阻塞性，必须澄清后才能继续
-  - 🟡 Medium：重要，建议澄清
-  - 🟢 Low：建议性，可后续补充
+  ### 步骤一：澄清
+  通过 AskUserQuestion 工具批量提问所有 High/Medium 问题，标注总数和严重度分布。
+  用户可中途退出（q），进度保存到问题清单。收到完整回答后统一更新问题清单。
+  差异：需求澄清无问题时可跳过；设计澄清即使无问题也须展示决策摘要。
 
-  ## 知识库索引
+  ### 步骤二：对齐确认
+  澄清完成后，AI 用 markdown 文本向用户呈现 4 要素：
+  1. 我的理解 — 复述核心需求/设计意图
+  2. 计划方向 — 接下来文档将包含什么
+  3. 关键假设 — 不确定的假设
+  4. 完成标准 — 产出合格条件
+  呈现完毕后，调用 AskUserQuestion 让用户确认或调整。
+  注意：对齐内容用普通 markdown 文本输出，不放在 AskUserQuestion 中（大段内容显示异常）。
 
-  - 需求问题分类学（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）
+  ### 设计额外要求
+  design.md 创建后、tasks 前，须展示设计核心摘要，通过 AskUserQuestion 获得审批。
 
-  ## 进化体系（v5）
+  ## 知识进化
 
-  aspec 在 archive 时自动积累项目知识，**使用越久，流程越精准**：
-  - Layer A（每次立即）：ADR 技术决策 / 词汇表 / 风险图谱
-  - Layer B（积累 3+ 复盘后触发）：问题分类学优化 / 任务模板 / 用户偏好
-  - Layer C（长期）：规格演化历史 / 效率指标
+  ### 生命周期：提取 → 存储 → 主动应用 → 验证 → 收敛
 
-  完整说明及 archive 操作步骤：openspec/templates/procedures/evolution-system.md
+  ### 提取（每次 apply 完成后）
 
-  ## AI 知识库消费速查
+  | 复盘章节 | 目标 | 更新内容 |
+  |----------|------|----------|
+  | 技术决策 | experience.md 技术决策段 | 选择 + 理由 + 备选 + 状态 |
+  | 新术语 | experience.md 领域词汇段 | 定义 + 首次出现 |
+  | 风险事件 | experience.md 风险图谱段 | 描述 + 区域 + 类型 |
+  | 澄清漏检 | dimensions.md 盲区段 | 新盲区 |
+  | 复盘记录 | experience.md 复盘记录段 | 变更概述·澄清质量·过程经验·效率信号 |
 
-  每个阶段开始前读取对应知识库，避免重复已有决策：
-  - explore / propose：ADR + Glossary + Task Patterns
-  - specs：Glossary + Spec CHANGELOG
-  - design：ADR + Risk Map + 问题分类学
-  - tasks：Task Patterns + Risk Map
-  - apply：ADR + Risk Map
-  - archive：全部 → 更新全部 → 触发进化分析
+  ### 主动应用（每次新 change 开始）
+  读取 openspec/experience.md 和 dimensions.md 盲区段，主动告知用户相关知识。
 
-# =============================================================================
-# 阶段规则
-# =============================================================================
+  ### 收敛
+  条目超阈值时合并/淘汰（需用户确认）。
 
 rules:
-  # ===========================================================================
-  # proposal — 需求澄清门禁
-  # ===========================================================================
+  explore:
+    pre: |
+      **知识主动应用**
+      读取 openspec/experience.md 和 dimensions.md 盲区段，
+      告知用户与当前 change 相关的已有知识。
+
   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）时，在问题清单中记录变更原因
-
-  # ===========================================================================
-  # design — 技术决策四要素 + 设计澄清门禁
-  # ===========================================================================
+    constraint: |
+      specs 必须与已澄清的需求一致。
+
   design:
-    - |
-      创建 design.md 时，每个技术决策必须包含：
-      - 选择了什么方案
-      - 为什么选择（决策理由）
-      - 考虑过哪些备选方案
-      - 为什么放弃备选方案
-      注意体现 requirement-issues.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: |
+      技术决策四要素：决策内容、选择理由、备选方案、排除原因。
+    post: |
+      **设计澄清 + 对齐确认**
+      1. 读取 dimensions.md 获取设计维度和盲区
+      2. 扫描设计不确定性，创建/更新 spec/design-issues.md
+      3. 步骤一（澄清）：AskUserQuestion 批量提问（设计阶段即使无问题也须展示摘要）
+      4. 步骤二（对齐确认）：markdown 展示 4 要素 → AskUserQuestion 确认
+      5. 确认后标记 clarified，创建 design.md
+
   tasks:
-    - |
-      创建 tasks 时：
-      - 基于最终确定的技术方案（已经过设计澄清）
-      - 确保任务覆盖 design-issues.md 中所有 🔴 High 决策
-      - 设计澄清导致 design.md 重大变更时，相应调整任务列表
-      - 任务描述中引用相关设计决策（方便追溯）
-
-  # ===========================================================================
-  # apply — 严格遵循澄清决策
-  # ===========================================================================
+    pre: |
+      **设计文档审批**
+      展示 design.md 核心摘要，通过 AskUserQuestion 获得审批后创建任务。
+    constraint: |
+      任务必须基于已审批的设计。所有 High 决策须在任务中体现。
+
   apply:
-    - |
-      实施前：读取 spec/requirement-issues.md 和 spec/design-issues.md，了解所有澄清决策。
-    - |
-      实施中：严格遵循澄清决策。发现新问题时：
-      暂停 → 评估问题类型（需求/设计）→ 更新对应问题清单 → 可选启动澄清补充 → 继续
-      完成每个任务后立即用 "- [x]" 标记完成。
-    - |
-      轻量观察（选做，记录到 spec/retrospective-notes.md，供归档时汇入复盘报告）：
-      - 澄清未覆盖但实际重要的问题 → 【需求层面的意外】
-      - 设计不明确需临时决策的问题 → 【设计层面的意外】
-      - 澄清有效避免返工的案例 → 【好的实践】
-      - 高风险代码区域或意外技术问题 → 【风险事件】
-
-  # ===========================================================================
-  # archive — 复盘 + 知识库更新 + 进化分析
-  # ===========================================================================
+    constraint: |
+      实施前读取所有澄清决策。新问题暂停评估，记录到 spec/notes.md。
+      Spec-Code 一致性：偏差须记录理由。
+    post: |
+      **复盘与知识进化**
+      1. 回顾本次实施过程，按 experience-template.md 复盘记录段的结构追加复盘
+      2. 提取知识更新 openspec/experience.md（技术决策/术语/风险）
+      3. 漏检问题更新 dimensions.md 盲区段
+      4. 展示 5-8 行摘要供用户确认
+
   archive:
-    - |
-      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 行），然后继续归档
-    - |
-      AFTER archiving — 执行进化体系更新（Layer A 立即 + Layer B 条件触发）：
-      完整操作步骤参见 openspec/templates/procedures/evolution-system.md
+    post: |
+      **收敛检查**
+      experience.md 条目超阈值时提议合并/淘汰（需用户确认）。

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 后将自动填充。*

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`
-
----
-
-## 备注
-
-<!-- 任何补充说明 -->