@haaaiawd/anws 2.2.6 → 2.3.0
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/README.md +1 -1
- package/lib/manifest.js +213 -213
- package/package.json +1 -1
- package/templates/.agents/skills/code-reviewer/SKILL.md +17 -5
- package/templates/.agents/skills/craft-authoring/SKILL.md +183 -123
- package/templates/.agents/skills/craft-authoring/references/PROMPT_QUALITY_RUBRIC.md +99 -0
- package/templates/.agents/skills/craft-authoring/references/SCORECARD_TEMPLATE.md +64 -0
- package/templates/.agents/skills/e2e-testing-guide/SKILL.md +3 -3
- package/templates/.agents/workflows/blueprint.md +56 -21
- package/templates/.agents/workflows/change.md +1 -1
- package/templates/.agents/workflows/craft.md +121 -160
- package/templates/.agents/workflows/forge.md +134 -75
|
@@ -1,123 +1,183 @@
|
|
|
1
|
-
---
|
|
2
|
-
|
|
3
|
-
|
|
4
|
-
|
|
5
|
-
|
|
6
|
-
# Craft Authoring
|
|
7
|
-
|
|
8
|
-
本 skill 承接
|
|
9
|
-
|
|
10
|
-
|
|
11
|
-
|
|
12
|
-
|
|
13
|
-
|
|
14
|
-
|
|
15
|
-
|
|
16
|
-
|
|
17
|
-
|
|
18
|
-
|
|
19
|
-
|
|
20
|
-
|
|
21
|
-
|
|
22
|
-
|
|
23
|
-
|
|
24
|
-
|
|
25
|
-
|
|
26
|
-
|
|
27
|
-
|
|
28
|
-
|
|
29
|
-
---
|
|
30
|
-
|
|
31
|
-
|
|
32
|
-
|
|
33
|
-
|
|
34
|
-
|
|
35
|
-
>
|
|
36
|
-
|
|
37
|
-
|
|
38
|
-
|
|
39
|
-
|
|
40
|
-
|
|
41
|
-
|
|
42
|
-
|
|
43
|
-
|
|
44
|
-
|
|
45
|
-
|
|
46
|
-
|
|
47
|
-
|
|
48
|
-
|
|
49
|
-
|
|
50
|
-
|
|
51
|
-
---
|
|
52
|
-
|
|
53
|
-
|
|
54
|
-
|
|
55
|
-
|
|
56
|
-
|
|
57
|
-
|
|
58
|
-
|
|
59
|
-
|
|
60
|
-
|
|
61
|
-
|
|
62
|
-
|
|
63
|
-
|
|
64
|
-
|
|
65
|
-
|
|
66
|
-
|
|
67
|
-
|
|
68
|
-
|
|
69
|
-
|
|
70
|
-
|
|
71
|
-
|
|
72
|
-
|
|
73
|
-
|
|
74
|
-
|
|
75
|
-
|
|
76
|
-
|
|
77
|
-
|
|
78
|
-
|
|
79
|
-
|
|
80
|
-
# 标题
|
|
81
|
-
|
|
82
|
-
##
|
|
83
|
-
|
|
84
|
-
|
|
85
|
-
##
|
|
86
|
-
|
|
87
|
-
|
|
88
|
-
##
|
|
89
|
-
|
|
90
|
-
|
|
91
|
-
|
|
92
|
-
|
|
93
|
-
|
|
94
|
-
|
|
95
|
-
|
|
96
|
-
|
|
97
|
-
|
|
98
|
-
|
|
99
|
-
|
|
100
|
-
|
|
101
|
-
|
|
102
|
-
|
|
103
|
-
|
|
104
|
-
|
|
105
|
-
|
|
106
|
-
|
|
107
|
-
|
|
108
|
-
|
|
109
|
-
|
|
110
|
-
|
|
111
|
-
|
|
112
|
-
|
|
113
|
-
|
|
114
|
-
|
|
115
|
-
|
|
116
|
-
|
|
117
|
-
|
|
118
|
-
|
|
119
|
-
|
|
120
|
-
|
|
121
|
-
|
|
122
|
-
|
|
123
|
-
|
|
1
|
+
---
|
|
2
|
+
|
|
3
|
+
## name: craft-authoring
|
|
4
|
+
description: 执行 /craft 时必读。提供 Workflow / Skill / Prompt 骨架与质量护栏。以判断准绳替代堆砌步骤。
|
|
5
|
+
|
|
6
|
+
# Craft Authoring - 脚手架与自检
|
|
7
|
+
|
|
8
|
+
本 skill 承接 `/craft` 中“如何写成”的细节。
|
|
9
|
+
`/craft` 给方向，这里给落地。方向如果没有落地，会变成口号；落地如果没有方向，会变成机械动作。
|
|
10
|
+
|
|
11
|
+
## 全局写作协议
|
|
12
|
+
|
|
13
|
+
1. 禁止使用 emoji。
|
|
14
|
+
2. 允许拟人叙事，但语气必须克制、理性、专业。
|
|
15
|
+
3. 使用短句，每句表达单一语义。
|
|
16
|
+
4. 每个 Step 固定回答：做什么 / 为什么 / 怎么验收。
|
|
17
|
+
5. 先给意义，再给规则，再给验证。禁止只写漂亮话。
|
|
18
|
+
|
|
19
|
+
**判断准绳**：
|
|
20
|
+
|
|
21
|
+
- 好文档让执行者更清醒、更稳定、更可复现。
|
|
22
|
+
- 坏文档让执行者更兴奋，却更依赖临场发挥。
|
|
23
|
+
|
|
24
|
+
---
|
|
25
|
+
|
|
26
|
+
## Workflow 骨架（最小可用）
|
|
27
|
+
|
|
28
|
+
```markdown
|
|
29
|
+
---
|
|
30
|
+
description: [一句话说明用途]
|
|
31
|
+
---
|
|
32
|
+
|
|
33
|
+
# /name
|
|
34
|
+
|
|
35
|
+
<phase_context>
|
|
36
|
+
你是 **[角色]**。
|
|
37
|
+
**使命**：...
|
|
38
|
+
**能力**：...
|
|
39
|
+
**限制**：...
|
|
40
|
+
**与用户的关系**：...
|
|
41
|
+
**Output Goal**: `路径`
|
|
42
|
+
</phase_context>
|
|
43
|
+
|
|
44
|
+
---
|
|
45
|
+
|
|
46
|
+
## CRITICAL 写作约束
|
|
47
|
+
|
|
48
|
+
> [!IMPORTANT]
|
|
49
|
+
> 写作约束由 `/craft` 主 workflow 统一定义，此处不重复展开。
|
|
50
|
+
|
|
51
|
+
---
|
|
52
|
+
|
|
53
|
+
## Step 1: [标题]
|
|
54
|
+
|
|
55
|
+
### 做什么
|
|
56
|
+
...
|
|
57
|
+
|
|
58
|
+
### 为什么
|
|
59
|
+
...
|
|
60
|
+
|
|
61
|
+
### 怎么验收
|
|
62
|
+
- ...
|
|
63
|
+
- ...
|
|
64
|
+
|
|
65
|
+
---
|
|
66
|
+
|
|
67
|
+
<completion_criteria>
|
|
68
|
+
- [可验证完成标准]
|
|
69
|
+
</completion_criteria>
|
|
70
|
+
```
|
|
71
|
+
|
|
72
|
+
## Skill 骨架（description 必须是触发条件）
|
|
73
|
+
|
|
74
|
+
```markdown
|
|
75
|
+
---
|
|
76
|
+
name: kebab-name
|
|
77
|
+
description: 当 [具体触发场景] 时加载。[能力概括]
|
|
78
|
+
---
|
|
79
|
+
|
|
80
|
+
# 标题
|
|
81
|
+
|
|
82
|
+
## 做什么
|
|
83
|
+
...
|
|
84
|
+
|
|
85
|
+
## 为什么
|
|
86
|
+
...
|
|
87
|
+
|
|
88
|
+
## 怎么验收
|
|
89
|
+
- 输入契约：...
|
|
90
|
+
- 输出契约：...
|
|
91
|
+
```
|
|
92
|
+
|
|
93
|
+
**description 忌**：泛化能力标签。
|
|
94
|
+
**description 宜**：明确触发场景与边界。
|
|
95
|
+
|
|
96
|
+
**判断准绳**：
|
|
97
|
+
一个好的 description 像门禁，不像标语。
|
|
98
|
+
它要决定“何时进入”，也要决定“何时不进入”。
|
|
99
|
+
|
|
100
|
+
## Prompt 骨架
|
|
101
|
+
|
|
102
|
+
```markdown
|
|
103
|
+
# 标题
|
|
104
|
+
|
|
105
|
+
## 做什么
|
|
106
|
+
...
|
|
107
|
+
|
|
108
|
+
## 为什么
|
|
109
|
+
...
|
|
110
|
+
|
|
111
|
+
## 怎么验收
|
|
112
|
+
- 约束：...
|
|
113
|
+
- 输出格式：...
|
|
114
|
+
```
|
|
115
|
+
|
|
116
|
+
## 防护语法速查
|
|
117
|
+
|
|
118
|
+
|
|
119
|
+
| 机制 | 用途 |
|
|
120
|
+
| ----------------------- | ------ |
|
|
121
|
+
| `[!IMPORTANT]` | 不可跳过节点 |
|
|
122
|
+
| `## CRITICAL` | 边界醒目 |
|
|
123
|
+
| `你**必须**` | 强制动作 |
|
|
124
|
+
| `<completion_criteria>` | 完成定义 |
|
|
125
|
+
|
|
126
|
+
|
|
127
|
+
重要约束至少写清：做什么、为什么、偏航信号。
|
|
128
|
+
|
|
129
|
+
## 填充内容（Step 5 等价）
|
|
130
|
+
|
|
131
|
+
用 `sequential-thinking` 组织 3-5 个 thought，覆盖目标、易错点、每步 I/O、调研结论落点。
|
|
132
|
+
|
|
133
|
+
质量快检：
|
|
134
|
+
|
|
135
|
+
- 章节是否单问题回答
|
|
136
|
+
- 约束是否写明为什么
|
|
137
|
+
- 输出是否可验证
|
|
138
|
+
|
|
139
|
+
**判断准绳**：
|
|
140
|
+
如果一个段落不能告诉执行者“该做什么”，它就是噪声。
|
|
141
|
+
如果一个段落不能告诉执行者“为何如此”，它就是命令。
|
|
142
|
+
如果一个段落不能告诉执行者“如何验证”，它就是祈祷。
|
|
143
|
+
|
|
144
|
+
## 验证清单（输出前）
|
|
145
|
+
|
|
146
|
+
结构：
|
|
147
|
+
|
|
148
|
+
- frontmatter
|
|
149
|
+
- `phase_context`（workflow 场景）
|
|
150
|
+
- `CRITICAL` 块
|
|
151
|
+
- `<completion_criteria>`
|
|
152
|
+
|
|
153
|
+
内容：
|
|
154
|
+
|
|
155
|
+
- 路径与命名正确
|
|
156
|
+
- 触发条件清晰
|
|
157
|
+
- 输入输出契约完整
|
|
158
|
+
- 失败信号可被外部观察
|
|
159
|
+
|
|
160
|
+
## 评分闸门（发布前）
|
|
161
|
+
|
|
162
|
+
发布前必须执行静态评分：
|
|
163
|
+
|
|
164
|
+
- 读取 `references/PROMPT_QUALITY_RUBRIC.md`
|
|
165
|
+
- 生成 `references/SCORECARD_TEMPLATE.md` 对应的评分卡
|
|
166
|
+
- 输出 Tier（T0/T1/T2/T3）与七维加权得分
|
|
167
|
+
|
|
168
|
+
硬门规则：
|
|
169
|
+
|
|
170
|
+
- 若触发 Hard Fail Gate，结论必须为 `Infeasible`
|
|
171
|
+
- 若未触发 Hard Fail 且总分 < 4.0，必须回炉一次再评分
|
|
172
|
+
|
|
173
|
+
## 自我批评（输出前最后一道）
|
|
174
|
+
|
|
175
|
+
用 `sequential-thinking` 做 3-5 个 thought：
|
|
176
|
+
|
|
177
|
+
- 用户会卡在哪一步
|
|
178
|
+
- AI 可能跳过哪条约束
|
|
179
|
+
- 哪一节仍存在多问题混写
|
|
180
|
+
- 修复后再交付
|
|
181
|
+
|
|
182
|
+
最后问自己一句：
|
|
183
|
+
如果这份文档真的会被反复执行，你敢不敢为它的后果负责？
|
|
@@ -0,0 +1,99 @@
|
|
|
1
|
+
## Prompt Quality Rubric v1.0 (Static)
|
|
2
|
+
|
|
3
|
+
用途：对 Workflow / Skill / Prompt 进行静态评分，不依赖运行时采样。
|
|
4
|
+
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
## 0. 评估前置：静态消融
|
|
8
|
+
|
|
9
|
+
评估前先做文本消融，剥离以下外部挂载：
|
|
10
|
+
|
|
11
|
+
- 情绪祈使句
|
|
12
|
+
- 格式强迫词
|
|
13
|
+
- 防幻觉补丁句
|
|
14
|
+
|
|
15
|
+
保留骨架：
|
|
16
|
+
|
|
17
|
+
- Role
|
|
18
|
+
- Context / Worldview
|
|
19
|
+
- Core Concepts
|
|
20
|
+
- Reasoning Path
|
|
21
|
+
|
|
22
|
+
若消融后骨架崩塌，优先判定为 T2 或 T3。
|
|
23
|
+
|
|
24
|
+
---
|
|
25
|
+
|
|
26
|
+
## 1. 段位判定（Tier）
|
|
27
|
+
|
|
28
|
+
- `T0` 原生共振：消融后仍具备稳定语义风格与闭环约束
|
|
29
|
+
- `T1` 结构锚定：主要依靠结构网格稳定执行
|
|
30
|
+
- `T2` 外部挂载：高度依赖祈使与补丁句
|
|
31
|
+
- `T3` 认知崩塌：存在事实或逻辑前提错误
|
|
32
|
+
|
|
33
|
+
> 规则：若命中 T3，直接判定不可行，不进入高分档比较。
|
|
34
|
+
|
|
35
|
+
---
|
|
36
|
+
|
|
37
|
+
## 2. 七维评分矩阵（0-5）
|
|
38
|
+
|
|
39
|
+
每个维度必须输出：`score` + `evidence` + `fix` + `confidence`。
|
|
40
|
+
|
|
41
|
+
### D1 Structure（权重 20%）
|
|
42
|
+
|
|
43
|
+
- 看结构是否清晰、分段是否承担稳定语义职责
|
|
44
|
+
|
|
45
|
+
### D2 Alignment（权重 20%）
|
|
46
|
+
|
|
47
|
+
- 看目标、步骤、验收是否一致
|
|
48
|
+
|
|
49
|
+
### D3 Robustness（权重 15%）
|
|
50
|
+
|
|
51
|
+
- 看是否存在异常输入下的阻断与降级机制
|
|
52
|
+
|
|
53
|
+
### D4 Efficiency（权重 10%）
|
|
54
|
+
|
|
55
|
+
- 看 token 成本与约束收益是否平衡
|
|
56
|
+
|
|
57
|
+
### D5 Meta-Isomorphism（权重 15%）
|
|
58
|
+
|
|
59
|
+
- 看“要求的品质”与“文本自身品质”是否同构
|
|
60
|
+
|
|
61
|
+
### D6 Groundability（权重 10%）
|
|
62
|
+
|
|
63
|
+
- 看抽象叙事是否能回落到可执行动作
|
|
64
|
+
|
|
65
|
+
### D7 Ablation Survivability（权重 10%）
|
|
66
|
+
|
|
67
|
+
- 看消融后骨架是否仍能独立支撑行为
|
|
68
|
+
|
|
69
|
+
---
|
|
70
|
+
|
|
71
|
+
## 3. 硬失败门（Hard Fail Gate）
|
|
72
|
+
|
|
73
|
+
满足任一条件，直接触发硬失败：
|
|
74
|
+
|
|
75
|
+
1. 检索验证发现核心前提虚构（T3）
|
|
76
|
+
2. 关键步骤无法验证完成状态
|
|
77
|
+
3. 关键依赖路径不可解析且无阻断出口
|
|
78
|
+
|
|
79
|
+
硬失败输出：`Infeasible` + 证据 + 最小修复清单。
|
|
80
|
+
|
|
81
|
+
---
|
|
82
|
+
|
|
83
|
+
## 4. 评分一致性协议
|
|
84
|
+
|
|
85
|
+
- 建议双评审独立打分
|
|
86
|
+
- 单维分差 > 1.0 进入仲裁
|
|
87
|
+
- 仲裁必须引用证据句，不允许“印象打分”
|
|
88
|
+
|
|
89
|
+
---
|
|
90
|
+
|
|
91
|
+
## 5. 总分与档位
|
|
92
|
+
|
|
93
|
+
- 加权总分范围：0-5
|
|
94
|
+
- `A`: >= 4.5
|
|
95
|
+
- `B`: 4.0-4.49
|
|
96
|
+
- `C`: 3.0-3.99
|
|
97
|
+
- `D`: < 3.0
|
|
98
|
+
|
|
99
|
+
若触发硬失败门，最终结论强制为 `Infeasible`，覆盖总分档位。
|
|
@@ -0,0 +1,64 @@
|
|
|
1
|
+
# Prompt Scorecard
|
|
2
|
+
|
|
3
|
+
## Target
|
|
4
|
+
|
|
5
|
+
- Artifact:
|
|
6
|
+
- Path:
|
|
7
|
+
- Date:
|
|
8
|
+
- Reviewer:
|
|
9
|
+
|
|
10
|
+
## Ablation Result
|
|
11
|
+
|
|
12
|
+
- Removed layers:
|
|
13
|
+
- Remaining skeleton summary:
|
|
14
|
+
- Ablation survivability note:
|
|
15
|
+
|
|
16
|
+
## Tier
|
|
17
|
+
|
|
18
|
+
- Tier: T0 / T1 / T2 / T3
|
|
19
|
+
- Tier rationale:
|
|
20
|
+
|
|
21
|
+
## Dimension Scores
|
|
22
|
+
|
|
23
|
+
|
|
24
|
+
| Dimension | Weight | Score (0-5) | Confidence | Evidence | Fix |
|
|
25
|
+
| ---------------------- | ------ | ----------- | --------------- | -------- | --- |
|
|
26
|
+
| Structure | 20% | | high/medium/low | | |
|
|
27
|
+
| Alignment | 20% | | high/medium/low | | |
|
|
28
|
+
| Robustness | 15% | | high/medium/low | | |
|
|
29
|
+
| Efficiency | 10% | | high/medium/low | | |
|
|
30
|
+
| Meta-Isomorphism | 15% | | high/medium/low | | |
|
|
31
|
+
| Groundability | 10% | | high/medium/low | | |
|
|
32
|
+
| Ablation Survivability | 10% | | high/medium/low | | |
|
|
33
|
+
|
|
34
|
+
|
|
35
|
+
## Hard Fail Gate Check
|
|
36
|
+
|
|
37
|
+
- Triggered: Yes / No
|
|
38
|
+
- Condition:
|
|
39
|
+
- Evidence:
|
|
40
|
+
- Minimal repair actions:
|
|
41
|
+
|
|
42
|
+
## Weighted Score
|
|
43
|
+
|
|
44
|
+
- Score:
|
|
45
|
+
- Grade: A / B / C / D
|
|
46
|
+
- Final verdict: Pass / Needs Iteration / Infeasible
|
|
47
|
+
|
|
48
|
+
## Top Risks
|
|
49
|
+
|
|
50
|
+
|
|
51
|
+
|
|
52
|
+
|
|
53
|
+
|
|
54
|
+
## Top Fixes
|
|
55
|
+
|
|
56
|
+
|
|
57
|
+
|
|
58
|
+
|
|
59
|
+
|
|
60
|
+
## Re-score Expectation
|
|
61
|
+
|
|
62
|
+
- Expected tier after fixes:
|
|
63
|
+
- Expected score delta:
|
|
64
|
+
|
|
@@ -2,11 +2,11 @@
|
|
|
2
2
|
|
|
3
3
|
## name: e2e-testing-guide
|
|
4
4
|
|
|
5
|
-
description: 规定如何撰写面向真人的 E2E / 手动验证《测试指南》及《E2E Verification》报告格式（PRD 对照、功能面、旅程与步骤）；不含实机浏览器编排——实机顺序由 `/forge` §3.
|
|
5
|
+
description: 规定如何撰写面向真人的 E2E / 手动验证《测试指南》及《E2E Verification》报告格式（PRD 对照、功能面、旅程与步骤）；不含实机浏览器编排——实机顺序由 `/forge` §3.7 写死。
|
|
6
6
|
|
|
7
7
|
# E2E Testing Guide
|
|
8
8
|
|
|
9
|
-
本 skill **只解决两件事**：（1）**怎么写**可执行的 E2E / 手动验证**测试指南**；（2）**报告长什么样**（含评测列）。**是否在浏览器里按指南操作**，由 `**/forge` §3.
|
|
9
|
+
本 skill **只解决两件事**：（1）**怎么写**可执行的 E2E / 手动验证**测试指南**；（2）**报告长什么样**（含评测列）。**是否在浏览器里按指南操作**，由 `**/forge` §3.7** 统一编排：先按本 skill 产出报告，再在用户授权下使用宿主浏览器工具回填证据。
|
|
10
10
|
|
|
11
11
|
> 原则：像真人逛产品一样写清「从哪进、点哪、期望看到什么」；每一项应对得上 **PRD / 验收** 里的可追溯条目。
|
|
12
12
|
|
|
@@ -72,7 +72,7 @@ description: 规定如何撰写面向真人的 E2E / 手动验证《测试指南
|
|
|
72
72
|
|
|
73
73
|
### 5. 执行计划（可选短文）
|
|
74
74
|
|
|
75
|
-
`Target` / `Environment` / `Role` / `Data setup` / `Side effects` / `Blockers` 一段即可。**不写**浏览器点击协议——实机见 `**/forge` §3.
|
|
75
|
+
`Target` / `Environment` / `Role` / `Data setup` / `Side effects` / `Blockers` 一段即可。**不写**浏览器点击协议——实机见 `**/forge` §3.7**。
|
|
76
76
|
|
|
77
77
|
---
|
|
78
78
|
|
|
@@ -4,23 +4,35 @@ description: "编排 /blueprint：基于设计输入生成 05A_TASKS.md 与 05B_
|
|
|
4
4
|
|
|
5
5
|
# /blueprint
|
|
6
6
|
|
|
7
|
+
<phase_context>
|
|
7
8
|
你是 **TASK ARCHITECT (任务规划师)**。
|
|
8
|
-
|
|
9
|
-
|
|
10
|
-
|
|
11
|
-
|
|
12
|
-
|
|
9
|
+
**使命**：把已批准设计输入编排为可执行的 05A/05B 双文档，并完成收口质量门禁。
|
|
10
|
+
**能力**：版本定位、输入校验、契约映射、调用 `task-planner`、收口检查与状态更新。
|
|
11
|
+
**限制**：只做编排与关卡校验；详细字段、示例与版式由 `task-planner` 与 references 维护。
|
|
12
|
+
**与用户的关系**：你负责交付可执行计划骨架，不替用户越权执行实现与实测。
|
|
13
|
+
**Output Goal**: `.anws/v{N}/05A_TASKS.md` + `.anws/v{N}/05B_VERIFICATION_PLAN.md`
|
|
14
|
+
</phase_context>
|
|
13
15
|
|
|
14
16
|
---
|
|
15
17
|
|
|
16
|
-
##
|
|
18
|
+
## CRITICAL 编排约束
|
|
17
19
|
|
|
18
|
-
|
|
19
|
-
|
|
20
|
+
> [!IMPORTANT]
|
|
21
|
+
> `blueprint` 只定义流程与门禁，不复写模板细节。
|
|
22
|
+
>
|
|
23
|
+
> - 任务/验证字段、示例格式的唯一事实源是：
|
|
24
|
+
> - `task-planner/SKILL.md`
|
|
25
|
+
> - `task-planner/references/TASK_TEMPLATE_05A.md`
|
|
26
|
+
> - `task-planner/references/TASK_TEMPLATE_05B.md`
|
|
27
|
+
> - 禁止在 `blueprint` 重复粘贴字段级规范，避免双源漂移
|
|
28
|
+
> - 若发现上游规范冲突，优先修正事实源，不在本文件打补丁
|
|
20
29
|
|
|
21
|
-
|
|
30
|
+
## 目标
|
|
31
|
+
|
|
32
|
+
- 产出 `.anws/v{N}/05A_TASKS.md`（执行主清单）
|
|
33
|
+
- 产出 `.anws/v{N}/05B_VERIFICATION_PLAN.md`（验证计划）
|
|
22
34
|
|
|
23
|
-
## Step 0: 定位版本与前置检查
|
|
35
|
+
## Step 0: 定位版本与前置检查 (Locate Version & Preconditions)
|
|
24
36
|
|
|
25
37
|
1. 扫描 `.anws/` 找到最新 `v{N}`，设定 `TARGET_DIR = .anws/v{N}`。
|
|
26
38
|
2. 必需文件：
|
|
@@ -32,7 +44,7 @@ description: "编排 /blueprint：基于设计输入生成 05A_TASKS.md 与 05B_
|
|
|
32
44
|
|
|
33
45
|
---
|
|
34
46
|
|
|
35
|
-
## Step 1: 加载输入并建立契约映射
|
|
47
|
+
## Step 1: 加载输入并建立契约映射 (Load Inputs & Contract Mapping)
|
|
36
48
|
|
|
37
49
|
1. 读取 `01_PRD.md`、`02_ARCHITECTURE_OVERVIEW.md`、`03_ADR/`（以及存在时的 `04_SYSTEM_DESIGN/`）。
|
|
38
50
|
2. 从输入中提取公共契约与风险点。
|
|
@@ -43,20 +55,34 @@ description: "编排 /blueprint：基于设计输入生成 05A_TASKS.md 与 05B_
|
|
|
43
55
|
|
|
44
56
|
---
|
|
45
57
|
|
|
46
|
-
## Step
|
|
58
|
+
## Step 1.5: 编排思考准绳（中等强度）
|
|
59
|
+
|
|
60
|
+
在进入任务拆解前，先完成三项快速判断：
|
|
47
61
|
|
|
48
|
-
|
|
62
|
+
1. **真实性判断**：当前任务树是否真实承接了设计中的外部可观察契约，而不是只承接“代码实现动作”。
|
|
63
|
+
2. **风险闭合判断**：高风险契约是否至少有一个明确验证落点，且验证类型不过度上推到 E2E。
|
|
64
|
+
3. **执行可落地判断**：Sprint/INT 关口是否可被客观证据验证（日志/报告/截图），避免“写了计划但无法验收”。
|
|
49
65
|
|
|
50
|
-
|
|
51
|
-
|
|
52
|
-
- 验证类型按“最轻但足够”选择，避免 E2E 滥用
|
|
53
|
-
- 单元测试与 API接口功能测试必须同时规划
|
|
54
|
-
- 冒烟测试优先绑定 `INT-S{N}` 里程碑任务
|
|
55
|
-
- 仅在 `05A/05B` 中记录 E2E 触发条件、范围与证据预期；**不得在 `/blueprint` 阶段执行 `e2e-testing-guide`**
|
|
66
|
+
> [!IMPORTANT]
|
|
67
|
+
> 若任一判断失败，应先修正契约映射约束，再调用 `task-planner`。禁止带着已知缺口继续拆解。
|
|
56
68
|
|
|
57
69
|
---
|
|
58
70
|
|
|
59
|
-
## Step
|
|
71
|
+
## Step 2: 调用 task-planner 生成 A/B 双文档 (Decompose via task-planner)
|
|
72
|
+
|
|
73
|
+
> [!IMPORTANT]
|
|
74
|
+
> 调用 `task-planner` 时必须显式传递以下约束：
|
|
75
|
+
>
|
|
76
|
+
> - 输入文档是唯一事实来源
|
|
77
|
+
> - 若 ADR 存在测试策略与质量门禁，必须优先遵循
|
|
78
|
+
> - 验证类型按“最轻但足够”选择，避免 E2E 滥用
|
|
79
|
+
> - 单元测试与 API接口功能测试必须同时规划
|
|
80
|
+
> - 冒烟测试优先绑定 `INT-S{N}` 里程碑任务
|
|
81
|
+
> - 仅在 `05A/05B` 中记录 E2E 触发条件、范围与证据预期；**不得在 `/blueprint` 阶段执行 `e2e-testing-guide`**
|
|
82
|
+
|
|
83
|
+
---
|
|
84
|
+
|
|
85
|
+
## Step 3: 收口写入 (Write Outputs)
|
|
60
86
|
|
|
61
87
|
1. 保存：
|
|
62
88
|
- `.anws/v{N}/05A_TASKS.md`
|
|
@@ -67,7 +93,7 @@ description: "编排 /blueprint：基于设计输入生成 05A_TASKS.md 与 05B_
|
|
|
67
93
|
|
|
68
94
|
---
|
|
69
95
|
|
|
70
|
-
## Step 4: 必过检查清单
|
|
96
|
+
## Step 4: 必过检查清单 (Mandatory Exit Checklist)
|
|
71
97
|
|
|
72
98
|
- [ ] `05A_TASKS.md` 与 `05B_VERIFICATION_PLAN.md` 均已生成
|
|
73
99
|
- [ ] 每个 05A 任务都含 `验证引用` 且可在 05B 定位到对应条目
|
|
@@ -75,3 +101,12 @@ description: "编排 /blueprint：基于设计输入生成 05A_TASKS.md 与 05B_
|
|
|
75
101
|
- [ ] 单元测试与 API接口功能测试职责均已规划
|
|
76
102
|
- [ ] 测试覆盖按风险类别闭合，且未出现测试膨胀
|
|
77
103
|
- [ ] `AGENTS.md` 已更新为 A/B 双文档入口
|
|
104
|
+
|
|
105
|
+
---
|
|
106
|
+
|
|
107
|
+
<completion_criteria>
|
|
108
|
+
- 已完成版本定位与前置校验，且阻断条件被正确执行
|
|
109
|
+
- 已将契约映射约束传递给 `task-planner` 并产出 05A/05B 双文档
|
|
110
|
+
- 05A/05B 通过收口检查清单，关键追溯链完整
|
|
111
|
+
- 文档入口状态已回写到 `AGENTS.md`
|
|
112
|
+
</completion_criteria>
|
|
@@ -280,7 +280,7 @@
|
|
|
280
280
|
- (注意: 局部修订不改变待办任务数)
|
|
281
281
|
4. **报告**: 告知用户变更已完成。
|
|
282
282
|
5. **回到 `/forge` 前的衔接说明（非静态代码审查）**:
|
|
283
|
-
- `**/change` 不运行、不替代 `code-reviewer`。** 静态忠实度审查只属于 `**/forge` 3.
|
|
283
|
+
- `**/change` 不运行、不替代 `code-reviewer`。** 静态忠实度审查只属于 `**/forge` §3.6** 与 `**/challenge`（CODE/FULL）**；不得在本次变更报告中声称「代码已完成静态审查」。
|
|
284
284
|
- 若本次变更触及 `契约承接`、`验证类型` / `验证说明`、`04_SYSTEM_DESIGN/` 或公共接口语义：在报告中 **列表说明触达项**，便于 `/forge` 规划门禁与任务执行。
|
|
285
285
|
- **可选（文档侧）**：若任务表或设计措辞需要可读性复核，可 **建议** 用户使用 `task-reviewer` 或 `design-reviewer`；**不得**将 `/change` 写成与 `**/forge` Step 0**（含 `07_CHALLENGE_REPORT.md`）同等效力的「Critical/High 阻塞回到编码」门禁。
|
|
286
286
|
|