@shirayner/ace 0.1.8-SNAPSHOT.1 → 0.1.8-SNAPSHOT.3
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/package.json +1 -1
- package/templates/openspec/config.yaml +53 -12
package/package.json
CHANGED
|
@@ -1,5 +1,5 @@
|
|
|
1
1
|
schema: spec-driven
|
|
2
|
-
version:
|
|
2
|
+
version: 11.0.0
|
|
3
3
|
context: |
|
|
4
4
|
## 语言
|
|
5
5
|
所有交互、思考链、文档一律使用中文。OpenSpec 英文标题保留。
|
|
@@ -23,11 +23,38 @@ context: |
|
|
|
23
23
|
- 惊讶测试：替用户做选择时，若用户看到会惊讶 → 暂停展示选项
|
|
24
24
|
- 对齐内容用 markdown 文本输出（大段内容在 AskUserQuestion 中显示异常），确认通过 AskUserQuestion
|
|
25
25
|
|
|
26
|
-
##
|
|
27
|
-
|
|
28
|
-
|
|
29
|
-
-
|
|
30
|
-
-
|
|
26
|
+
## 深度认知方法论
|
|
27
|
+
|
|
28
|
+
### 苏格拉底式追问（分析时在内部执行）
|
|
29
|
+
- **追问目的**：用户为什么要这个？解决什么根本问题？做了之后谁受益？
|
|
30
|
+
- **追问完整性**：说的是全貌还是冰山一角？关联问题？前置依赖？
|
|
31
|
+
- **追问前提**：假设成立吗？有更好的问题框架吗？是不是在解决错误的问题？
|
|
32
|
+
- **追问约束**：什么不能动？硬限制？时间/资源/技术债/团队认知负担？
|
|
33
|
+
|
|
34
|
+
目标：不只理解用户说了什么，而是理解用户**真正需要**什么——包括他们没意识到的部分。
|
|
35
|
+
|
|
36
|
+
### 引导性提问（澄清时使用）
|
|
37
|
+
不使用纯选择题。通过引导性提问暴露用户没想到的维度：
|
|
38
|
+
- "你提到了 X，但我注意到这还关联到 Y——这是否也在范围内？"
|
|
39
|
+
- "如果做了 X 但不处理 Y，后续有什么风险？"
|
|
40
|
+
- "在这几个约束中，你的首要优先级是什么？"
|
|
41
|
+
|
|
42
|
+
### 对齐确认四要素
|
|
43
|
+
1. **我的理解** — 复述核心意图 + 分析中发现的关联问题
|
|
44
|
+
2. **方案方向** — 高层策略（非实现细节）
|
|
45
|
+
3. **关键假设** — 不确定的假设，显式标注
|
|
46
|
+
4. **完成标准** — 可测试的验收条件
|
|
47
|
+
|
|
48
|
+
### 深度聚焦
|
|
49
|
+
不遍历维度清单做广度扫描。聚焦于：最不确定的、返工成本最高的、dimensions.md 盲区相关的。
|
|
50
|
+
|
|
51
|
+
### 并行探索策略
|
|
52
|
+
分析需求或设计时，通过 Agent 工具并行探索独立维度以提升深度：
|
|
53
|
+
- 识别独立分析维度（彼此结果不影响），分组后每个 Agent 负责一组（2-3 维度）
|
|
54
|
+
- 每个 Agent prompt 须自包含：分析目标 + 项目上下文 + 输出格式（问题列表）
|
|
55
|
+
- 回收后整合：合并发现、识别交叉问题、去重后写入 issues 文件
|
|
56
|
+
- 触发条件：分析维度 ≥3 个且彼此独立 → 并行；<3 个或强依赖 → 串行
|
|
57
|
+
- 约束：并行 Agent ≤4 个，不修改同一文件
|
|
31
58
|
|
|
32
59
|
## 文件约定
|
|
33
60
|
- 需求问题：issues/requirement-issues.md（id, description, severity, status, answer）
|
|
@@ -49,9 +76,15 @@ rules:
|
|
|
49
76
|
- "[PRE] 读取 experience.md 需求相关经验，告知用户"
|
|
50
77
|
- |
|
|
51
78
|
[PRE] 需求澄清流程（三步顺序执行，每步完成后再进入下一步）：
|
|
52
|
-
1.
|
|
53
|
-
|
|
54
|
-
|
|
79
|
+
1. **苏格拉底分析→写入** — 运用四追问（目的/完整性/前提/约束）深度分析需求：
|
|
80
|
+
- 不只列"缺失信息"，要追问"为什么需要？""前提成立吗？""影响范围完整吗？"
|
|
81
|
+
- 参考 dimensions.md 盲区，识别高风险不确定性
|
|
82
|
+
- 若分析维度 ≥3 个且独立，通过 Agent 工具并行探索（见"并行探索策略"）
|
|
83
|
+
- 整合各 Agent 发现后写入 issues/requirement-issues.md，每个问题含：追问链路 + 为何重要（返工成本）
|
|
84
|
+
2. **引导性澄清** — 通过 AskUserQuestion 澄清 High/Medium 问题：
|
|
85
|
+
- 不使用纯选择题，采用引导性提问暴露用户未察觉的维度
|
|
86
|
+
- 主动指出关联："我注意到 X 还涉及 Y，是否在范围内？"
|
|
87
|
+
3. **结构化对齐** — 用 markdown 展示四要素（我的理解/方案方向/关键假设/完成标准），再通过 AskUserQuestion 确认
|
|
55
88
|
- |
|
|
56
89
|
🚫 GATE: 满足以下全部条件前，禁止创建 proposal：
|
|
57
90
|
- issues/requirement-issues.md 已创建且 High/Medium 问题已澄清
|
|
@@ -64,9 +97,17 @@ rules:
|
|
|
64
97
|
- "[PRE] 读取 experience.md 技术相关经验，告知用户"
|
|
65
98
|
- |
|
|
66
99
|
[PRE] 设计澄清流程（三步顺序执行，每步完成后再进入下一步）：
|
|
67
|
-
1.
|
|
68
|
-
|
|
69
|
-
|
|
100
|
+
1. **苏格拉底分析→写入** — 运用四追问深度分析技术方案：
|
|
101
|
+
- 追问目的：架构决策服务什么质量属性？
|
|
102
|
+
- 追问完整性：遗漏的交互场景或失败模式？
|
|
103
|
+
- 追问前提：技术选型的隐含假设（性能、规模、团队能力）是否成立？
|
|
104
|
+
- 追问约束：现有系统/团队/时间的硬限制？
|
|
105
|
+
- 若需评估多个备选方案，通过 Agent 工具并行调研（每个 Agent 研究一个方案的可行性）
|
|
106
|
+
- 整合后写入 issues/design-issues.md，每个决策含：备选方案 + 排除理由 + 风险
|
|
107
|
+
2. **引导性澄清** — 通过 AskUserQuestion 澄清 High/Medium 决策：
|
|
108
|
+
- 即使无问题也须展示决策摘要
|
|
109
|
+
- 主动暴露取舍："方案 A 更简单但 X 场景有风险，方案 B 更复杂但覆盖更全——优先级？"
|
|
110
|
+
3. **结构化对齐** — 用 markdown 展示四要素（我的理解/方案方向/关键假设/完成标准），再通过 AskUserQuestion 确认
|
|
70
111
|
- |
|
|
71
112
|
🚫 GATE: 满足以下全部条件前，禁止创建 design.md：
|
|
72
113
|
- issues/design-issues.md 已创建且 High/Medium 决策已澄清
|