@aipper/aiws-spec 0.0.34 → 0.0.36
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/docs/ws-goal-contract.md
CHANGED
|
@@ -32,9 +32,18 @@ aiws 当前没有等价协议。OpenCode + oh-my-opencode 已经提供了 3 层
|
|
|
32
32
|
|
|
33
33
|
### 方案:ws-goal 作为协议层
|
|
34
34
|
|
|
35
|
-
ws-goal 定义为**协议层**(prompt-template + artifact spec
|
|
35
|
+
ws-goal 定义为**协议层**(prompt-template + artifact spec),不是运行时引擎。**它做四件事:录入目标、依赖链预检、管道委托、完成审计。**
|
|
36
36
|
|
|
37
|
-
|
|
37
|
+
| 步骤 | 做什么 | 不做什么 |
|
|
38
|
+
|---|---|---|
|
|
39
|
+
| 录入目标 | 按模板写 `.aiws/goals/<id>.md` | 不创建 change/plan |
|
|
40
|
+
| 依赖链预检 | 追溯上游 change 健康度 + target_base_branch 一致性 | 不修改上游工件 |
|
|
41
|
+
| 管道委托 | 预检通过后,将 goal 委托给子 agent 执行完整 pipeline(ws-plan → ws-dev → ws-review → ws-commit → ws-finish → 审计) | ws-goal 自己不执行任何实现步骤 |
|
|
42
|
+
| 完成审计 | Verification 对照 outcome 逐条验证 | 不替代 review 门禁 |
|
|
43
|
+
|
|
44
|
+
第四步(管道委托)是 ws-goal 的**编排出口**:依赖链预检通过后,ws-goal 构造一个包含 goal 文件完整内容 + 真值文件路径 + 强制 pipeline 步骤的委托 prompt,交由平台支持的子 agent 执行。子 agent 执行完成后,ws-goal 执行最终的完成审计并更新 goal status。
|
|
45
|
+
|
|
46
|
+
这样做的好处是:ws-goal 保持轻量协议层,不重复造 runtime,但通过委托机制提供了从 goal 到 complete 的自动化路径。
|
|
38
47
|
|
|
39
48
|
---
|
|
40
49
|
|
|
@@ -51,7 +60,8 @@ ws-goal 定义为**协议层**(prompt-template + artifact spec),不是运
|
|
|
51
60
|
| **constraints** | object | 预算限制:token_budget(token 上限)、time_budget(wall clock 上限)、max_iterations(turn 次数上限) |
|
|
52
61
|
| **boundaries** | string[] | 显式的非目标、范围限制。什么不在本次 goal 内 |
|
|
53
62
|
| **iteration_policy** | object | max_attempts(重试次数)、reaudit_frequency(每几次迭代重新审计一次) |
|
|
54
|
-
| **blocked_stop** | boolean | 遇到 blocker 时是否暂停并报告。true =
|
|
63
|
+
| **blocked_stop** | boolean/object | 遇到 blocker 时是否暂停并报告。true = 报告并等待,不能静默失败。可扩展为 `{ enabled: true, extends_to_upstream: true }`,将阻断语义延伸到上游依赖链不健康的情况(见 2.4) |
|
|
64
|
+
| **target_base_branch** | string | 目标交付的目标分支(如 `main`、`release/v2`)。agent 在 ws-plan 创建 change 时必须以此为 base_branch,不得自由选择。默认 `main`。若使用的 base_branch 与 `target_base_branch` 不一致,阻断并提示。 |
|
|
55
65
|
|
|
56
66
|
### 2.2 Goal State Machine
|
|
57
67
|
|
|
@@ -78,6 +88,98 @@ active → paused (optional) → complete | budget_limited → archived
|
|
|
78
88
|
7. **Uncertain = NOT achieved**:不确定的、间接的、推论性的证据不能作为完成依据。audit 需要确定的证明
|
|
79
89
|
8. **Prove, not disprove**:audit 必须正面证明完成,而不是反面证明"没找到未完成的工作"。找不出 bug 不等于代码正确
|
|
80
90
|
|
|
91
|
+
### 2.4 Dependency Chain Validation
|
|
92
|
+
|
|
93
|
+
引入 change 流水线之前(由 ws-plan/ws-dev 负责),必须先对其上游依赖链做健康检查——这是 ws-goal 作为预检门的职责。防止"死 change 阻塞下游"或"base_branch 选错导致 chaining 混乱"。
|
|
94
|
+
|
|
95
|
+
#### 2.4.1 依赖链定义
|
|
96
|
+
|
|
97
|
+
依赖链是从当前 goal 的目标分支追溯到 main 的完整 change 列表:
|
|
98
|
+
|
|
99
|
+
```
|
|
100
|
+
main → change/A → change/B → change/C (当前)
|
|
101
|
+
```
|
|
102
|
+
|
|
103
|
+
每个环节称为一个 **link**。每个 link 有独立健康状态。
|
|
104
|
+
|
|
105
|
+
#### 2.4.2 Link 健康判定
|
|
106
|
+
|
|
107
|
+
| 维度 | 健康 (HEALTHY) | 不健康 (UNHEALTHY) | 过时 (STALE) |
|
|
108
|
+
|---|---|---|---|
|
|
109
|
+
| **Artifacts 完整性** | proposal/tasks/design 都存在 | 缺失任意一项 | — |
|
|
110
|
+
| **Task 完成率** | ≤30% WS:TODO,有实际进展 | >50% WS:TODO,无进展迹象 | — |
|
|
111
|
+
| **Review** | review 已通过或无 blocking 项 | review 存在 HIGH blocker | — |
|
|
112
|
+
| **活跃度** | 最近 14 天内有更新 | — | >14 天无任何更新 |
|
|
113
|
+
| **Truth drift** | `aiws validate .` 通过 | `aiws validate .` 失败 | — |
|
|
114
|
+
|
|
115
|
+
整体判定规则:
|
|
116
|
+
- 任意维度 UNHEALTHY → link 标记 **UNHEALTHY**
|
|
117
|
+
- 所有维度 HEALTHY 但任一维度 STALE → link 标记 **STALE**
|
|
118
|
+
- 全部 HEALTHY 且无 STALE → link 标记 **HEALTHY**
|
|
119
|
+
|
|
120
|
+
#### 2.4.3 阻断与确认规则
|
|
121
|
+
|
|
122
|
+
| 上游状态 | 当前 goal 行为 |
|
|
123
|
+
|---|---|
|
|
124
|
+
| 全部 HEALTHY | 放行,无需确认 |
|
|
125
|
+
| 存在 STALE | 输出警告,允许继续 |
|
|
126
|
+
| 存在 UNHEALTHY | 输出完整 chain 拓扑 + 健康报告,**必须用户显式确认**才能继续 |
|
|
127
|
+
| 父 change 不存在(孤儿分支)| 阻断,提示选择已知 base |
|
|
128
|
+
| **实际 base_branch ≠ goal target_base_branch** | **阻断**。输出 "goal 声明 target_base_branch = X,但当前 base_branch = Y",必须用户修正或显式确认才能继续。此检查优先于链健康检查——如果 base_branch 本身就选错了,不需要继续追溯 |
|
|
129
|
+
|
|
130
|
+
#### 2.4.4 Dependency Chain 证据记录
|
|
131
|
+
|
|
132
|
+
验证结果必须写入 goal artifact 的 `Dependency Chain` 字段(见 3.1 模板),包括:
|
|
133
|
+
- 完整 chain 拓扑(从 main 到当前)
|
|
134
|
+
- 每个 link 的健康状态与判定理由
|
|
135
|
+
- 用户确认记录(若 UNHEALTHY 被显式放行)
|
|
136
|
+
|
|
137
|
+
### 2.5 Workspace State Analysis
|
|
138
|
+
|
|
139
|
+
ws-goal 在执行 pipeline delegation(管道委托,见 1.§ 第四步)之前,必须先对当前工作区做全面的状态分析。目的是防止委托子 agent 时因为 workspace 的 dirty 状态、子模块未提交、旧 change 残留等问题导致执行失败或产生意外副作用。
|
|
140
|
+
|
|
141
|
+
#### 2.5.1 分析维度
|
|
142
|
+
|
|
143
|
+
| 维度 | 检查项 | 工具 |
|
|
144
|
+
|---|---|---|
|
|
145
|
+
| **Dirty 状态** | staged changes、unstaged changes、untracked files | `git diff --cached --stat` / `git diff --stat` / `git status --porcelain` |
|
|
146
|
+
| **Submodule 状态** | dirty submodules、detached HEAD、unpushed commits | `git submodule status` / `git -C <path> symbolic-ref HEAD` / `git -C <path> log @{u}..HEAD --oneline` |
|
|
147
|
+
| **Change artifacts** | 已有 change 分支、未完成的 change、旧残留 | `git branch --list 'change/*'` / 检查 WS:TODO 比例 |
|
|
148
|
+
| **Git 状态** | unpushed commits、stash | `git log @{u}..HEAD --oneline` / `git stash list` |
|
|
149
|
+
| **Goal 冲突** | 同名 goal、相同 scope 的 active goal | 扫描 `.aiws/goals/*.md` 的 status 与 outcome |
|
|
150
|
+
|
|
151
|
+
#### 2.5.2 影响评估
|
|
152
|
+
|
|
153
|
+
每个发现项必须归属影响等级:
|
|
154
|
+
|
|
155
|
+
| 等级 | 含义 | 示例 |
|
|
156
|
+
|---|---|---|
|
|
157
|
+
| **HIGH** | 阻碍 goal 执行,必须处理 | 子模块 dirty 且与 goal 同一目录 |
|
|
158
|
+
| **MED** | 可能干扰或产生误报 | 旧 change 残留导致依赖链误判 |
|
|
159
|
+
| **LOW** | 无影响,仅提示 | untracked 日志文件 |
|
|
160
|
+
| **NONE** | 完全无关 | `.DS_Store` 之类的系统文件 |
|
|
161
|
+
|
|
162
|
+
#### 2.5.3 报告格式
|
|
163
|
+
|
|
164
|
+
分析结果必须用结构化文本块输出,便于用户快速扫描:
|
|
165
|
+
|
|
166
|
+
```text
|
|
167
|
+
═══ 工作区状态报告 ═══
|
|
168
|
+
[HIGH] <发现项描述> — <影响说明>
|
|
169
|
+
[MED] <发现项描述> — <影响说明>
|
|
170
|
+
[LOW] <发现项描述> — <影响说明>
|
|
171
|
+
═══════════════════════
|
|
172
|
+
```
|
|
173
|
+
|
|
174
|
+
#### 2.5.4 确认门禁
|
|
175
|
+
|
|
176
|
+
报告输出后,必须等待用户确认:
|
|
177
|
+
- **继续** → 进入 pipeline delegation
|
|
178
|
+
- **暂停** → goal status=paused,报告写入 Audit Trail
|
|
179
|
+
- **先清理** → goal status=paused,输出清理建议步骤
|
|
180
|
+
|
|
181
|
+
用户未确认,不得进入 delegation。
|
|
182
|
+
|
|
81
183
|
---
|
|
82
184
|
|
|
83
185
|
## 3. Protocol Specification
|
|
@@ -87,8 +189,8 @@ active → paused (optional) → complete | budget_limited → archived
|
|
|
87
189
|
```markdown
|
|
88
190
|
---
|
|
89
191
|
ws_goal:
|
|
90
|
-
version:
|
|
91
|
-
state: active
|
|
192
|
+
version: 2 # ↑ bumped to 2 for dependency chain support
|
|
193
|
+
state: active # active | paused | complete | budget_limited | archived
|
|
92
194
|
created_at: <ISO 8601>
|
|
93
195
|
updated_at: <ISO 8601>
|
|
94
196
|
iteration: 1
|
|
@@ -123,10 +225,24 @@ ws_goal:
|
|
|
123
225
|
- max_attempts: <number>
|
|
124
226
|
- reaudit_frequency: <number> # 每 N 次 iteration 重新做一次完成审计
|
|
125
227
|
|
|
126
|
-
##
|
|
228
|
+
## Target Base Branch
|
|
229
|
+
|
|
230
|
+
- target_base_branch: main | change/<id> | release/<name> # 强制。agent 创建 change 时必须以此为 base
|
|
231
|
+
- base_branch_mismatch_action: block | warn # base_branch 不匹配时的行为。默认 block
|
|
232
|
+
|
|
233
|
+
## Dependency Chain
|
|
127
234
|
|
|
128
|
-
-
|
|
129
|
-
-
|
|
235
|
+
- base_branch: main | change/<id>
|
|
236
|
+
- chain:
|
|
237
|
+
- <link-1>: HEALTHY
|
|
238
|
+
- <link-2>: HEALTHY
|
|
239
|
+
- <link-3>: UNHEALTHY (reason: ...)
|
|
240
|
+
- chain_verified_at: <ISO 8601>
|
|
241
|
+
- user_confirmed_unhealthy: true | false | null # UNHEALTHY 时是否显式确认放行
|
|
242
|
+
|
|
243
|
+
## Audit Trail
|
|
244
|
+
|
|
245
|
+
<确认记录、约束传递记录、关键变更等>
|
|
130
246
|
|
|
131
247
|
## Progress Notes
|
|
132
248
|
|
|
@@ -164,6 +280,7 @@ token_budget 依赖平台的 token 计数器。aiws 不提供独立的 token 监
|
|
|
164
280
|
| `changes/<id>/tasks.md` | tasks.md 中的每个 item 可携带 `ws_goal_id: <id>` 引用,表示该 task 通过 goal 自动执行。`update_plan` 的 progress tracking 反映 goal iteration 进度 |
|
|
165
281
|
| `.aiws/plan/...` proposal | proposal 中的 `Plan_File` 可以指向 goal objective markdown,表示该 change 使用 goal-driven 执行模式 |
|
|
166
282
|
| `aiws validate` + evidence | validate 的门禁检查可以包含对 goal 的完成审计证据的校验。goal 的 evidence 应落盘到 `changes/<id>/evidence/`,与其他 change 工件统一 |
|
|
283
|
+
| `changes/<id>/.ws-change.json` | `base_branch` 字段作为 dependency chain 验证的起点。ws-goal 在依赖链预检中读取 `.ws-change.json` 的 `base_branch` 追溯上游链 |
|
|
167
284
|
|
|
168
285
|
---
|
|
169
286
|
|
|
@@ -221,7 +338,19 @@ aiws 只定义"预算耗尽时应该做什么"的协议,不提供跨平台的
|
|
|
221
338
|
|
|
222
339
|
aiws 协议层定义了完整的语义状态,但各平台只能实现其中一部分。goal 创建时应注意平台的能力边界。
|
|
223
340
|
|
|
224
|
-
### 5.5
|
|
341
|
+
### 5.5 Dependency Chain Validation 依赖仓库上下文
|
|
342
|
+
|
|
343
|
+
Dependency chain 验证(2.4)需要:
|
|
344
|
+
- 当前仓库的 git 历史完整(能追溯到 main)
|
|
345
|
+
- `.ws-change.json` 或 proposal.md 记录了 `base_branch`
|
|
346
|
+
- 对链上每个 change 的 artifacts 有读权限(同一工作区)
|
|
347
|
+
|
|
348
|
+
如果当前不在 git 仓库、或无法访问上游 change 的工件(例如跨仓库依赖),则 chain 验证降级为:
|
|
349
|
+
- 报 UNKNOWN 状态
|
|
350
|
+
- 输出警告"无法验证上游依赖链"
|
|
351
|
+
- 不阻断,但要求用户确认已知风险
|
|
352
|
+
|
|
353
|
+
### 5.6 Completion Audit 的执行成本
|
|
225
354
|
|
|
226
355
|
8 步完成审计方法在完整执行时需要独立审计者(在 OpenCode L3 中需要额外模型调用)。对于小目标(比如"修复一个 lint 错误"),完整审计的 overhead 可能超过实际工作的成本。建议根据目标复杂度选择审计级别:
|
|
227
356
|
|
package/package.json
CHANGED
|
@@ -1,44 +1,151 @@
|
|
|
1
1
|
---
|
|
2
|
-
description: 目标协议:设定可审计的 goal
|
|
2
|
+
description: 目标协议:设定可审计的 goal 目标;依赖链预检;完成审计
|
|
3
3
|
---
|
|
4
4
|
<!-- AIWS_MANAGED_BEGIN:opencode:ws-goal -->
|
|
5
5
|
# ws goal
|
|
6
6
|
|
|
7
7
|
用中文输出(命令/路径/代码标识符保持原样不翻译)。
|
|
8
8
|
|
|
9
|
-
|
|
10
|
-
|
|
9
|
+
## 职责边界
|
|
10
|
+
|
|
11
|
+
ws-goal 只做三件事,不做更多:
|
|
12
|
+
|
|
13
|
+
| 做 | 不做 |
|
|
14
|
+
|---|---|
|
|
15
|
+
| 录入目标(写 `.aiws/goals/<id>.md`) | 创建/驱动 change(那是 ws-plan/ws-dev) |
|
|
16
|
+
| 依赖链预检(上游死 change → 阻断) | 评估复杂度、路由执行路径 |
|
|
17
|
+
| 完成审计(claim done 时验证 outcome) | git add/commit/push、finish |
|
|
18
|
+
| 记录 target_base_branch 约束 | auto-chain 到下一个 goal |
|
|
19
|
+
|
|
20
|
+
超出以上范围的需求,路由到对应 ws-* 技能,ws-goal 不碰。
|
|
21
|
+
|
|
22
|
+
## 前置条件
|
|
11
23
|
|
|
12
|
-
前置条件:
|
|
13
24
|
1) 先运行 `/ws-preflight`(对齐 `AI_PROJECT.md` / `REQUIREMENTS.md` / `AI_WORKSPACE.md`)。
|
|
14
25
|
|
|
15
|
-
|
|
26
|
+
## 执行流程
|
|
27
|
+
|
|
16
28
|
0) 检查 `.aiws/goals/` 目录:
|
|
17
29
|
a) 若用户仅查询状态(无明确目标),列出所有 goal 文件及其 status 字段,然后结束。
|
|
18
30
|
b) 若存在 status=active 或 status=paused 的 goal 文件,优先读取并恢复执行,不再新建 goal。
|
|
31
|
+
|
|
19
32
|
1) 读取真值文件(`AI_PROJECT.md`、`REQUIREMENTS.md`、`AI_WORKSPACE.md`),确认项目规则与边界。
|
|
33
|
+
|
|
20
34
|
2) 接受用户输入的 goal objective,明确目标范围与验收标准。
|
|
35
|
+
|
|
21
36
|
3) 按 ws-goal-contract.md 的目标模板生成目标文件,写入 `.aiws/goals/<goal-id>.md`。
|
|
22
|
-
|
|
23
|
-
|
|
24
|
-
|
|
25
|
-
b)
|
|
26
|
-
|
|
27
|
-
|
|
28
|
-
|
|
29
|
-
|
|
30
|
-
|
|
31
|
-
|
|
32
|
-
|
|
33
|
-
-
|
|
34
|
-
|
|
35
|
-
|
|
36
|
-
|
|
37
|
-
|
|
38
|
-
|
|
39
|
-
|
|
40
|
-
|
|
41
|
-
|
|
37
|
+
a) 生成时填入 `Target Base Branch` 字段:
|
|
38
|
+
- `target_base_branch`:从当前分支追踪或用户声明确定。默认 `main`
|
|
39
|
+
- `base_branch_mismatch_action`:默认 `block`
|
|
40
|
+
b) 生成时填入初始 `Dependency Chain` 字段:
|
|
41
|
+
- `base_branch`:当前检出分支或用户指定的基分支
|
|
42
|
+
- `chain`:追溯完整的 change 链到 main
|
|
43
|
+
- `chain_verified_at`:当前时间
|
|
44
|
+
- `user_confirmed_unhealthy`:初始为 null
|
|
45
|
+
|
|
46
|
+
4) **Dependency Chain Validation**:上游依赖链健康检查(不创建任何 change/plan/commit)。
|
|
47
|
+
a) 确定 base_branch:
|
|
48
|
+
- 若当前已存在 change 分支,读取 `.ws-change.json` 或 proposal.md 的 `base_branch`
|
|
49
|
+
- 若用户显式指定 base_branch,以用户指定为准
|
|
50
|
+
- 否则默认 main
|
|
51
|
+
a1) **target_base_branch 一致性检查**(Rule C):
|
|
52
|
+
- 读取 goal 文件的 `Target Base Branch.target_base_branch`
|
|
53
|
+
- 若 `base_branch != target_base_branch`:
|
|
54
|
+
- 输出 "goal 声明 target_base_branch = X,但当前 base_branch = Y"
|
|
55
|
+
- 若 `base_branch_mismatch_action` 为 `block`(默认):**强制 blocker**,必须用户修正 base_branch 或显式确认 mismatch 才能继续
|
|
56
|
+
- 若为 `warn`:输出警告并允许继续
|
|
57
|
+
- 将 mismatch 记录到 goal 文件的 Audit Trail
|
|
58
|
+
- 若一致:继续 step b
|
|
59
|
+
b) 追溯 chain:从 base_branch 逐级向上追溯到 main
|
|
60
|
+
- 每级检查 `.ws-change.json` 的 `base_branch` 或 git 分支关系
|
|
61
|
+
- 若无法追溯(孤儿分支),标记 UNKNOWN 并输出警告
|
|
62
|
+
c) 对 chain 中每个 link 做健康检查(按 ws-goal-contract.md 2.4.2 标准):
|
|
63
|
+
- artifacts 完整性:proposal/tasks/design 是否存在
|
|
64
|
+
- task 完成率:WS:TODO 占比
|
|
65
|
+
- review 状态:是否有 HIGH blocker
|
|
66
|
+
- 活跃度:最后更新时间
|
|
67
|
+
- truth drift:`aiws validate .` 是否通过
|
|
68
|
+
d) 结果:
|
|
69
|
+
- ALL HEALTHY → 输出 "依赖链健康" 并继续
|
|
70
|
+
- 存在 STALE → 输出链拓扑 + 警告,允许继续
|
|
71
|
+
- 存在 UNHEALTHY → 输出完整 chain 拓扑 + 每级健康报告,**强制 blocker**,必须用户显式确认才能继续
|
|
72
|
+
- UNKNOWN(无法追溯)→ 输出警告"无法验证上游依赖链",不阻断但要求用户确认
|
|
73
|
+
e) 将验证结果写入 goal 文件的 `Dependency Chain` 字段:
|
|
74
|
+
- 更新 `chain` 中每个 link 的健康状态与判定理由
|
|
75
|
+
- 若用户放行 UNHEALTHY:设置 `user_confirmed_unhealthy: true` 并记录到 `Audit Trail`
|
|
76
|
+
- 若用户未放行:设置 goal status=paused 并结束
|
|
77
|
+
|
|
78
|
+
4.5) **Workspace State Analysis**:依赖链预检通过后、delegation 前,分析工作区状态并输出报告。
|
|
79
|
+
必须用户确认后才能进入 step 5。
|
|
80
|
+
a) 检查 dirty 状态:
|
|
81
|
+
- staged changes(`git diff --cached --stat`)
|
|
82
|
+
- unstaged changes(`git diff --stat`)
|
|
83
|
+
- untracked files(`git status --porcelain` 中 `??` 开头项)
|
|
84
|
+
b) 检查 submodule 状态:
|
|
85
|
+
- 每个 submodule 的 dirty 状态(`git submodule status`)
|
|
86
|
+
- detached HEAD(`git -C <path> symbolic-ref HEAD` 失败)
|
|
87
|
+
- unpushed 提交(`git -C <path> log @{u}..HEAD --oneline`)
|
|
88
|
+
c) 检查 change artifacts:
|
|
89
|
+
- 存在哪些 change 分支(`git branch --list 'change/*'`)
|
|
90
|
+
- 是否有未完成的 change(proposal/tasks 仍含 WS:TODO)
|
|
91
|
+
- 是否与当前 goal 冲突(同名、同域)
|
|
92
|
+
d) 检查 git 状态:
|
|
93
|
+
- 是否有 unpushed 提交(`git log @{u}..HEAD --oneline`)
|
|
94
|
+
- 是否有 stash(`git stash list`)
|
|
95
|
+
e) 评估影响:逐项判断与当前 goal 的关联度:
|
|
96
|
+
- HIGH:阻碍 goal 执行,必须处理
|
|
97
|
+
- MED:可能干扰或产生误报
|
|
98
|
+
- LOW:无影响,仅提示
|
|
99
|
+
- NONE:完全无关,忽略
|
|
100
|
+
f) 输出结构化分析报告:
|
|
101
|
+
用格式化的文本块输出,每行标注影响等级:
|
|
102
|
+
```
|
|
103
|
+
═══ 工作区状态报告 ═══
|
|
104
|
+
[HIGH] 子模块 web/ dirty(7 文件)— 与 goal 同一目录,可能干扰
|
|
105
|
+
[MED] 旧 change contract-ai-rag 残留 — 可能干扰依赖链判断
|
|
106
|
+
[LOW] .aiws/journal/ 日志文件 — 无影响
|
|
107
|
+
════════════════════════
|
|
108
|
+
```
|
|
109
|
+
g) 展示报告后要求用户选择:
|
|
110
|
+
- **继续** → 进入 step 5
|
|
111
|
+
- **暂停** → goal status=paused,报告写入 Audit Trail,结束
|
|
112
|
+
- **先清理** → goal status=paused,输出清理建议步骤,结束
|
|
113
|
+
用户未确认前,不得进入 step 5。
|
|
114
|
+
|
|
115
|
+
5) **Pipeline Delegation**:依赖链预检 + workspace 分析通过后,将 goal 完整执行委托给管道 agent。
|
|
116
|
+
前置条件:step 4 必须通过(ALL HEALTHY 或 UNHEALTHY 已显式放行)。若 step 4 阻断,则不允许 delegation。
|
|
117
|
+
a) 读取 goal 文件,评估复杂度:
|
|
118
|
+
- 简单(配置/doc/规范,≤5 文件,低风险)→ delegate 到 ws-dev-lite
|
|
119
|
+
- 复杂(代码改动 >5 文件,多模块,架构/迁移风险)→ delegate 到完整 pipeline
|
|
120
|
+
b) 构造 delegation prompt,包含:
|
|
121
|
+
- goal 文件完整路径与内容(含 target_base_branch、dependency chain 验证结果)
|
|
122
|
+
- 真值文件路径(AI_PROJECT.md / REQUIREMENTS.md / AI_WORKSPACE.md)
|
|
123
|
+
- 强制 pipeline 步骤(见下方 c)
|
|
124
|
+
- 完成条件:goal 文件的 Verification 字段全部通过
|
|
125
|
+
c) 强制 pipeline 步骤(子 agent 必须依次执行,不得跳过):
|
|
126
|
+
1. 如果 change 不存在:`aiws change start <goal-id> --allow-dirty`,base_branch 必须用 goal 的 target_base_branch
|
|
127
|
+
2. 写 proposal.md:绑定 goal 的 outcome 到 Req_ID,plan_file 指向即将生成的 plan
|
|
128
|
+
3. 写 plan 文件:`plan/<timestamp>-<goal-id>.md`,含验证命令与预期
|
|
129
|
+
4. 运行 plan-verify:`aiws plan-verify <plan-file>` 或等效检查
|
|
130
|
+
5. 实现代码改动(ws-dev):按 plan 实施,边改边验证
|
|
131
|
+
6. review 检查:lint/typecheck/code review 按 ws-review 标准
|
|
132
|
+
7. 提交:`ws-commit`(或等效 git add + commit)
|
|
133
|
+
8. 收尾:`ws-finish`(fast-forward 合并 + 推送)
|
|
134
|
+
9. 更新 goal status=complete:修改 goal 文件中的 state 字段
|
|
135
|
+
「not applicable」步骤可跳过,但必须说明理由
|
|
136
|
+
d) 使用 task 委托:
|
|
137
|
+
- 简单 → `task(category="quick", load_skills=[], ...)`
|
|
138
|
+
- 复杂 → `task(category="deep", load_skills=[], ...)` 或 `task(subagent_type="general", ...)`
|
|
139
|
+
e) 委托任务执行完成后:
|
|
140
|
+
- 收集子 agent 的输出,逐项对照 goal 文件的 Verification 字段做完成审计
|
|
141
|
+
- 全部通过 → 更新 goal state=complete,输出 "Goal <goal-id> complete"
|
|
142
|
+
- 有未通过 → 更新 goal state=paused,记录 blocker 到 Audit Trail,输出 "Goal <goal-id> paused: <reason>"
|
|
143
|
+
- 若子 agent 返回了未完成的 pipeline 状态(只有部分步骤完成),在 goal 文件的 Progress Notes 中记录进展,标记 goal state=paused 并输出当前进度
|
|
144
|
+
f) 判断平台是否支持 task 委托:
|
|
145
|
+
- 调用 `task(category="quick", load_skills=[], description="probe", prompt="probe", run_in_background=true)`
|
|
146
|
+
- 若返回有效的 task_id/session_id → 支持委托,走 e)
|
|
147
|
+
- 若返回错误或无 session_id → 不支持委托
|
|
148
|
+
- 不支持时:在本会话中亲自执行 c) 的 pipeline 步骤,全部完成后更新 goal status=complete
|
|
42
149
|
<!-- AIWS_MANAGED_END:opencode:ws-goal -->
|
|
43
150
|
|
|
44
151
|
可在下方追加本项目对 OpenCode 的额外说明(托管块外内容会被保留)。
|
|
@@ -1,13 +1,21 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: ws-goal
|
|
3
|
-
description: 目标协议:设定可审计的 goal
|
|
3
|
+
description: 目标协议:设定可审计的 goal 目标;依赖链预检;管道委托;完成审计
|
|
4
4
|
---
|
|
5
5
|
# ws-goal
|
|
6
6
|
|
|
7
7
|
用中文输出(命令/路径/代码标识符保持原样不翻译)。
|
|
8
8
|
|
|
9
9
|
目标:
|
|
10
|
-
- 将用户需求转化为可审计的 goal 目标,按 ws-goal-contract.md
|
|
10
|
+
- 将用户需求转化为可审计的 goal 目标,按 ws-goal-contract.md 的目标模板写入目标文件。
|
|
11
|
+
- 依赖链预检:阻断"死 change 阻塞下游"这类 chain 问题。
|
|
12
|
+
- 管道委托:预检通过后将完整 pipeline 委托给子 agent(从 ws-plan 一路走到 ws-finish)。
|
|
13
|
+
- 完成审计:claim done 时验证 outcome 真伪。
|
|
14
|
+
|
|
15
|
+
ws-goal 不做的事:
|
|
16
|
+
- 不直接创建 change、不直接写 code
|
|
17
|
+
- 不替换 review/commit/finish 门禁
|
|
18
|
+
- 不 auto-chain 到下一个 goal
|
|
11
19
|
|
|
12
20
|
前置条件:
|
|
13
21
|
1) 先运行 `/ws-preflight`(对齐 `AI_PROJECT.md` / `REQUIREMENTS.md` / `AI_WORKSPACE.md`)。
|
|
@@ -20,22 +28,5 @@ description: 目标协议:设定可审计的 goal 目标并执行完成闭环
|
|
|
20
28
|
2) 接受用户输入的 goal objective,明确目标范围与验收标准。
|
|
21
29
|
3) 按 ws-goal-contract.md 的目标模板生成目标文件,写入 `.aiws/goals/<goal-id>.md`。
|
|
22
30
|
4) 输出 completion audit checklist,列出每个 goal 的完成标准与验证方式。
|
|
23
|
-
5) **
|
|
24
|
-
|
|
25
|
-
b) 复杂(多模块、代码改动 >5 文件、架构/安全/迁移风险)→ 自动触发 `ws-plan` 启动 change 流水线(ws-plan → ws-dev → review → ws-commit → ws-finish),完成后更新 goal status=complete
|
|
26
|
-
c) 将路由决策写入 goal 文件 Audit Trail
|
|
27
|
-
6) 建议续跑方式:简单路径直行 auto-finish;复杂路径进入 change 流水线后建议 `ws-dev`
|
|
28
|
-
7) 每轮 execution 结束后执行 completion audit,比对 checklist 判断 goal 是否达成;未达成则继续下一轮。
|
|
29
|
-
8) 若 completion audit 确认 goal 达成,自动执行闭环 pipeline:
|
|
30
|
-
a) Review 检查(按改动类型):
|
|
31
|
-
- 配置/文档/规范类(markdown):内容一致性、引用完整性、内容正确性、无 secrets、格式统一
|
|
32
|
-
- 代码类(ts/js/py 等):lint/typecheck 通过、符合现有代码模式、无 secrets、测试通过或覆盖缺口已记录
|
|
33
|
-
- 混合类:以上两种合并
|
|
34
|
-
b) 简单路径:`git add` 目标产出文件 → `git commit -m "goal(<goal-id>): <objective 摘要>"` → `git push` → 更新 goal status=complete
|
|
35
|
-
c) 复杂路径:走 `ws-commit` → `ws-finish` → archive change → 更新 goal status=complete
|
|
36
|
-
d) 不通过:记录 blocker → 继续 fix 循环
|
|
37
|
-
9) **Auto-chain to next goal**:当前 goal pipeline 完成后:
|
|
38
|
-
a) 扫描 `.aiws/goals/*.md`,按文件名排序找出第一个 status=pending 的 goal
|
|
39
|
-
b) 若找到:读取其 objective,输出 "→ Auto-continuing to <goal-id>",回到步骤 5 创建新 pipeline 自动继续
|
|
40
|
-
c) 若未找到:输出 "All goals completed" 并结束
|
|
41
|
-
d) 若找到的 pending goal 缺少 Success Criteria:输出 blocker 并停止(不自动跳过)
|
|
31
|
+
5) **Workspace State Analysis**:分析 dirty/submodule/change artifacts/git 状态,输出影响等级报告,用户确认后才能继续。参考 `/ws-goal` command 的 step 4.5 完整流程。
|
|
32
|
+
6) **Pipeline Delegation**:预检 + 分析通过后,将 goal 完整执行委托给管道 agent。参考 `/ws-goal` command 的 step 5 完整流程。
|
|
@@ -48,6 +48,18 @@
|
|
|
48
48
|
".opencode/command/ws-plan-verify.md",
|
|
49
49
|
".opencode/command/ws-spec-review.md",
|
|
50
50
|
".opencode/command/ws-quality-review.md",
|
|
51
|
+
".opencode/command/ws-migrate.md",
|
|
52
|
+
".opencode/command/ws-preflight.md",
|
|
53
|
+
".opencode/command/ws-pull.md",
|
|
54
|
+
".opencode/command/ws-push.md",
|
|
55
|
+
".opencode/command/ws-req-change.md",
|
|
56
|
+
".opencode/command/ws-req-contract-sync.md",
|
|
57
|
+
".opencode/command/ws-req-contract-validate.md",
|
|
58
|
+
".opencode/command/ws-req-flow-sync.md",
|
|
59
|
+
".opencode/command/ws-req-review.md",
|
|
60
|
+
".opencode/command/ws-review.md",
|
|
61
|
+
".opencode/command/ws-rule.md",
|
|
62
|
+
".opencode/command/ws-submodule-setup.md",
|
|
51
63
|
".opencode/command/ws-verify-before-complete.md",
|
|
52
64
|
".opencode/plugins/aiws-inject-context.js",
|
|
53
65
|
".opencode/plugins/aiws-session-start.js",
|
|
@@ -325,7 +337,19 @@
|
|
|
325
337
|
".opencode/skills/ws-quality-review/SKILL.md",
|
|
326
338
|
".opencode/skills/ws-verify-before-complete/SKILL.md",
|
|
327
339
|
".opencode/skills/ws-rule/SKILL.md",
|
|
328
|
-
".opencode/skills/ws-submodule-setup/SKILL.md"
|
|
340
|
+
".opencode/skills/ws-submodule-setup/SKILL.md",
|
|
341
|
+
".opencode/command/ws-migrate.md",
|
|
342
|
+
".opencode/command/ws-preflight.md",
|
|
343
|
+
".opencode/command/ws-pull.md",
|
|
344
|
+
".opencode/command/ws-push.md",
|
|
345
|
+
".opencode/command/ws-req-change.md",
|
|
346
|
+
".opencode/command/ws-req-contract-sync.md",
|
|
347
|
+
".opencode/command/ws-req-contract-validate.md",
|
|
348
|
+
".opencode/command/ws-req-flow-sync.md",
|
|
349
|
+
".opencode/command/ws-req-review.md",
|
|
350
|
+
".opencode/command/ws-review.md",
|
|
351
|
+
".opencode/command/ws-rule.md",
|
|
352
|
+
".opencode/command/ws-submodule-setup.md"
|
|
329
353
|
],
|
|
330
354
|
"managed_blocks": {
|
|
331
355
|
"AGENTS.md": ["agents"],
|