@aipper/aiws-spec 0.0.30 → 0.0.32
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/workspace/.agents/skills/p-aiws-change-archive/SKILL.md +1 -1
- package/templates/workspace/.agents/skills/p-aiws-change-finish/SKILL.md +1 -1
- package/templates/workspace/.agents/skills/p-aiws-change-new/SKILL.md +2 -2
- package/templates/workspace/.agents/skills/p-aiws-change-start/SKILL.md +1 -1
- package/templates/workspace/.agents/skills/p-aiws-change-sync/SKILL.md +2 -2
- package/templates/workspace/.agents/skills/p-aiws-change-validate/SKILL.md +1 -1
- package/templates/workspace/.agents/skills/p-aiws-validate/SKILL.md +1 -1
- package/templates/workspace/.agents/skills/p-tasks-plan/SKILL.md +7 -7
- package/templates/workspace/.agents/skills/using-aiws/SKILL.md +2 -2
- package/templates/workspace/.agents/skills/ws-analyze/SKILL.md +3 -3
- package/templates/workspace/.agents/skills/ws-bugfix/SKILL.md +8 -8
- package/templates/workspace/.agents/skills/ws-delegate/SKILL.md +4 -4
- package/templates/workspace/.agents/skills/ws-dev/SKILL.md +4 -4
- package/templates/workspace/.agents/skills/ws-dev-lite/SKILL.md +2 -2
- package/templates/workspace/.agents/skills/ws-frontend-design/SKILL.md +1 -1
- package/templates/workspace/.agents/skills/ws-plan/SKILL.md +5 -5
- package/templates/workspace/.agents/skills/ws-preflight/SKILL.md +4 -3
- package/templates/workspace/.agents/skills/ws-quality-review/SKILL.md +5 -5
- package/templates/workspace/.agents/skills/ws-req-review/SKILL.md +1 -1
- package/templates/workspace/.agents/skills/ws-review/SKILL.md +9 -9
- package/templates/workspace/.agents/skills/ws-spec-review/SKILL.md +5 -5
- package/templates/workspace/.opencode/command/ws-preflight.md +4 -3
- package/templates/workspace/.opencode/command/ws-req-review.md +1 -1
- package/templates/workspace/.opencode/commands/ws-preflight.md +4 -3
- package/templates/workspace/.opencode/commands/ws-req-review.md +1 -1
- package/templates/workspace/.opencode/skills/p-aiws-change-archive/SKILL.md +1 -1
- package/templates/workspace/.opencode/skills/p-aiws-change-finish/SKILL.md +1 -1
- package/templates/workspace/.opencode/skills/p-aiws-change-new/SKILL.md +2 -2
- package/templates/workspace/.opencode/skills/p-aiws-change-start/SKILL.md +1 -1
- package/templates/workspace/.opencode/skills/p-aiws-change-sync/SKILL.md +2 -2
- package/templates/workspace/.opencode/skills/p-aiws-change-validate/SKILL.md +1 -1
- package/templates/workspace/.opencode/skills/p-aiws-validate/SKILL.md +1 -1
- package/templates/workspace/.opencode/skills/p-tasks-plan/SKILL.md +7 -7
- package/templates/workspace/.opencode/skills/using-aiws/SKILL.md +3 -3
- package/templates/workspace/.opencode/skills/ws-analyze/SKILL.md +2 -2
- package/templates/workspace/.opencode/skills/ws-autonomy/SKILL.md +1 -1
- package/templates/workspace/.opencode/skills/ws-bugfix/SKILL.md +7 -7
- package/templates/workspace/.opencode/skills/ws-delegate/SKILL.md +7 -7
- package/templates/workspace/.opencode/skills/ws-dev/SKILL.md +4 -4
- package/templates/workspace/.opencode/skills/ws-dev-lite/SKILL.md +2 -2
- package/templates/workspace/.opencode/skills/ws-frontend-design/SKILL.md +1 -1
- package/templates/workspace/.opencode/skills/ws-plan/SKILL.md +5 -5
- package/templates/workspace/.opencode/skills/ws-preflight/SKILL.md +4 -3
- package/templates/workspace/.opencode/skills/ws-quality-review/SKILL.md +5 -5
- package/templates/workspace/.opencode/skills/ws-req-review/SKILL.md +1 -1
- package/templates/workspace/.opencode/skills/ws-review/SKILL.md +8 -8
- package/templates/workspace/.opencode/skills/ws-spec-review/SKILL.md +5 -5
- package/templates/workspace/.opencode/skills/ws-verify-before-complete/SKILL.md +5 -5
package/package.json
CHANGED
|
@@ -20,5 +20,5 @@ fi
|
|
|
20
20
|
|
|
21
21
|
说明:
|
|
22
22
|
- 默认等价于:`git merge --ff-only change/<change-id>`
|
|
23
|
-
- 若你当前就在 `change/<change-id>` 分支上,`finish` 会尝试读取
|
|
23
|
+
- 若你当前就在 `change/<change-id>` 分支上,`finish` 会尝试读取 `.aiws/changes/<change-id>/.ws-change.json` 的 `base_branch` 作为目标分支
|
|
24
24
|
- 若无法 fast-forward:先在 change 分支(或对应 worktree)里 `git rebase <target-branch>`,再重试 `aiws change finish`
|
|
@@ -1,10 +1,10 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: p-aiws-change-new
|
|
3
|
-
description: 私有:创建 changes/<change-id> 工件
|
|
3
|
+
description: 私有:创建 .aiws/changes/<change-id> 工件
|
|
4
4
|
---
|
|
5
5
|
|
|
6
6
|
目标:
|
|
7
|
-
- 创建
|
|
7
|
+
- 创建 `.aiws/changes/<change-id>/` 工件目录与基础文件(proposal/tasks/可选 design)
|
|
8
8
|
|
|
9
9
|
要求:
|
|
10
10
|
- `change-id` 必须是 kebab-case:`^[a-z0-9]+(-[a-z0-9]+)*$`
|
|
@@ -4,7 +4,7 @@ description: 私有:切分支并初始化变更工件(可选安装 hooks)
|
|
|
4
4
|
---
|
|
5
5
|
|
|
6
6
|
目标:
|
|
7
|
-
- 切到分支 `change/<change-id>` 并初始化
|
|
7
|
+
- 切到分支 `change/<change-id>` 并初始化 `.aiws/changes/<change-id>/` 工件
|
|
8
8
|
- 若检测到 `.gitmodules`(git submodules),默认优先使用 `--worktree`(失败则回退为 `--no-switch`),避免切走 superproject 分支导致 submodule 状态混乱
|
|
9
9
|
|
|
10
10
|
要求:
|
|
@@ -1,10 +1,10 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: p-aiws-change-sync
|
|
3
|
-
description: 私有:同步真值基线到 changes/<change-id>(写入 .ws-change.json)
|
|
3
|
+
description: 私有:同步真值基线到 .aiws/changes/<change-id>(写入 .ws-change.json)
|
|
4
4
|
---
|
|
5
5
|
|
|
6
6
|
目标:
|
|
7
|
-
- 将当前真值文件(`AI_PROJECT.md` / `AI_WORKSPACE.md` / `REQUIREMENTS.md`)的 hash 快照同步到
|
|
7
|
+
- 将当前真值文件(`AI_PROJECT.md` / `AI_WORKSPACE.md` / `REQUIREMENTS.md`)的 hash 快照同步到 `.aiws/changes/<change-id>/.ws-change.json`
|
|
8
8
|
|
|
9
9
|
执行(在仓库根目录):
|
|
10
10
|
```bash
|
|
@@ -1,18 +1,18 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: p-tasks-plan
|
|
3
|
-
description: 原子:tasks 同步(从 changes/<id>/tasks.md 生成 update_plan payload)
|
|
3
|
+
description: 原子:tasks 同步(从 .aiws/changes/<id>/tasks.md 生成 update_plan payload)
|
|
4
4
|
---
|
|
5
5
|
|
|
6
6
|
用中文输出(命令/路径/代码标识符保持原样不翻译)。
|
|
7
7
|
|
|
8
8
|
目标:
|
|
9
|
-
- 用
|
|
9
|
+
- 用 `.aiws/changes/<change-id>/tasks.md` 的 checkbox 任务作为“步骤真值”
|
|
10
10
|
- 生成可直接用于 `update_plan` 的 JSON payload(`pending/in_progress/completed`)
|
|
11
11
|
- 输出当前进度摘要(done/total + 当前 in_progress)
|
|
12
12
|
|
|
13
13
|
约束:
|
|
14
14
|
- 不写入任何 secrets(token、账号、内网端点等不得进入 git)
|
|
15
|
-
- 只读
|
|
15
|
+
- 只读 `.aiws/changes/<id>/tasks.md`(不自动改写 tasks 文件)
|
|
16
16
|
- 未运行不声称已运行
|
|
17
17
|
|
|
18
18
|
执行步骤(建议):
|
|
@@ -20,18 +20,18 @@ description: 原子:tasks 同步(从 changes/<id>/tasks.md 生成 update_pla
|
|
|
20
20
|
2) 推断 `change-id`:
|
|
21
21
|
- 优先从当前分支名读取:`git rev-parse --abbrev-ref HEAD`(期望形如 `change/<change-id>`)
|
|
22
22
|
- 若无法推断:让用户明确本次要同步的 `<change-id>`
|
|
23
|
-
3) 检查 tasks 文件存在:`test -f changes/<change-id>/tasks.md`
|
|
23
|
+
3) 检查 tasks 文件存在:`test -f .aiws/changes/<change-id>/tasks.md`
|
|
24
24
|
4) 输出进度摘要:
|
|
25
25
|
```bash
|
|
26
|
-
python3 tools/ws_tasks_plan.py status --file changes/<change-id>/tasks.md
|
|
26
|
+
python3 tools/ws_tasks_plan.py status --file .aiws/changes/<change-id>/tasks.md
|
|
27
27
|
```
|
|
28
28
|
5) 生成 `update_plan` payload(JSON 输出到 stdout):
|
|
29
29
|
```bash
|
|
30
|
-
python3 tools/ws_tasks_plan.py plan --file changes/<change-id>/tasks.md --explanation "sync tasks.md -> update_plan"
|
|
30
|
+
python3 tools/ws_tasks_plan.py plan --file .aiws/changes/<change-id>/tasks.md --explanation "sync tasks.md -> update_plan"
|
|
31
31
|
```
|
|
32
32
|
6) 调用 `update_plan`,将上一步 JSON 原样作为入参(确保任意时刻最多 1 条 `in_progress`)。
|
|
33
33
|
|
|
34
34
|
输出要求:
|
|
35
35
|
- `Change_ID:` <change-id>
|
|
36
|
-
- `Tasks:`
|
|
36
|
+
- `Tasks:` `.aiws/changes/<change-id>/tasks.md`
|
|
37
37
|
- `Next:` 推荐下一步(通常为继续完善 tasks 或进入 `$ws-dev`)
|
|
@@ -19,7 +19,7 @@ description: 默认 workflow bootstrap/router:先读真值,再路由到正
|
|
|
19
19
|
- `AI_PROJECT.md`
|
|
20
20
|
- `REQUIREMENTS.md`
|
|
21
21
|
- `AI_WORKSPACE.md`
|
|
22
|
-
- 若已存在:当前 `change/<change-id>` 上下文、`plan
|
|
22
|
+
- 若已存在:当前 `change/<change-id>` 上下文、`plan/...`、`.aiws/changes/<change-id>/...`
|
|
23
23
|
|
|
24
24
|
必需输出:
|
|
25
25
|
- `Root:` 当前项目根
|
|
@@ -41,7 +41,7 @@ description: 默认 workflow bootstrap/router:先读真值,再路由到正
|
|
|
41
41
|
- 已经明确给出单一路由结果,并进入对应 `ws-*` skill;或已提出关键澄清问题并停止。
|
|
42
42
|
|
|
43
43
|
执行步骤(强制):
|
|
44
|
-
1) 先遵守 `$ws-preflight`
|
|
44
|
+
1) 先遵守 `$ws-preflight` 的真值读取要求(含 submodule 感知的项目根定位——若在 submodule 内自动上溯到 superproject 根):
|
|
45
45
|
- 定位项目根目录
|
|
46
46
|
- 读取 `AI_PROJECT.md` / `REQUIREMENTS.md` / `AI_WORKSPACE.md`
|
|
47
47
|
- 输出 `Root:` / `Found:` / `Missing:`
|
|
@@ -5,20 +5,20 @@ description: 分析(定位问题与收集上下文)
|
|
|
5
5
|
|
|
6
6
|
用中文输出(命令/路径/代码标识符保持原样不翻译)。
|
|
7
7
|
|
|
8
|
-
目标:在开始实现/修复前做一次技术分析,产出可执行的最小行动清单,并把证据落盘到 `.
|
|
8
|
+
目标:在开始实现/修复前做一次技术分析,产出可执行的最小行动清单,并把证据落盘到 `.aiws/tmp/analyze/`。
|
|
9
9
|
|
|
10
10
|
输入:
|
|
11
11
|
- 主题/需求:用户在本次消息中提供的主题(若不明确,先问一句“本次分析主题是什么?”)
|
|
12
12
|
|
|
13
13
|
步骤(建议):
|
|
14
|
-
1) 先做 preflight
|
|
14
|
+
1) 先做 preflight:定位项目根目录(submodule 感知:若在 submodule 内自动上溯到 superproject 根),读取 `AI_PROJECT.md` / `REQUIREMENTS.md` / `AI_WORKSPACE.md`,输出约束摘要。
|
|
15
15
|
2) 基于真值文件与当前代码现状,输出:
|
|
16
16
|
- 目标 / 非目标
|
|
17
17
|
- 现状证据(文件路径/接口路径)
|
|
18
18
|
- 推荐方案(1 个)+ 备选(可选)
|
|
19
19
|
- 风险与回滚(3–8 条)
|
|
20
20
|
- 最小验证命令(可复现)
|
|
21
|
-
3) 将分析落盘到:`.
|
|
21
|
+
3) 将分析落盘到:`.aiws/tmp/analyze/codex-analysis.md`(目录不存在则创建)。
|
|
22
22
|
4) 回复中必须包含:`Evidence:` 证据文件路径。
|
|
23
23
|
|
|
24
24
|
安全:
|
|
@@ -1,13 +1,13 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: ws-bugfix
|
|
3
|
-
description: 缺陷修复(通过禅道 MCP 拉取 bug 与附件,下载图片证据,汇总到 issues/fix_bus_issues.csv,并绑定到 changes/<change-id>/)
|
|
3
|
+
description: 缺陷修复(通过禅道 MCP 拉取 bug 与附件,下载图片证据,汇总到 issues/fix_bus_issues.csv,并绑定到 .aiws/changes/<change-id>/)
|
|
4
4
|
---
|
|
5
5
|
|
|
6
6
|
用中文输出(命令/路径/代码标识符保持原样不翻译)。
|
|
7
7
|
|
|
8
8
|
目标:
|
|
9
9
|
- 用禅道 MCP 拉取 bug 详情与附件(尤其图片)
|
|
10
|
-
- 把证据落盘到
|
|
10
|
+
- 把证据落盘到 `.aiws/changes/<change-id>/bug/`(避免只停留在对话)
|
|
11
11
|
- 把修复任务汇总/更新到 `issues/fix_bus_issues.csv`
|
|
12
12
|
- 与 `ws-dev` / `aiws change` 流程绑定,确保可追溯、可验证
|
|
13
13
|
|
|
@@ -21,7 +21,7 @@ description: 缺陷修复(通过禅道 MCP 拉取 bug 与附件,下载图片
|
|
|
21
21
|
2) 准备 `change-id`(建议:`bug-<bug-id>` 或 `bugfix-<bug-id>-<slug>`)。
|
|
22
22
|
3) 建立 change 上下文(推荐先于任何落盘):
|
|
23
23
|
- 若当前还不在 `change/<change-id>` 分支 / worktree,先调用 `aiws change start`
|
|
24
|
-
- 工作区必须先干净;否则不要先写
|
|
24
|
+
- 工作区必须先干净;否则不要先写 `.aiws/changes/<change-id>/bug/` 或 `issues/fix_bus_issues.csv`,避免后续切 worktree 时工件留在原工作区
|
|
25
25
|
- 仓库已有提交:优先 `--worktree`
|
|
26
26
|
- superproject + submodule:优先 `--worktree --submodules`
|
|
27
27
|
- 仓库尚无提交 / 不满足 worktree 前置条件:回退 `--no-switch`
|
|
@@ -46,7 +46,7 @@ fi
|
|
|
46
46
|
- 优先复用 `$ws-dev` 的 `submodules.targets` 生成/确认流程
|
|
47
47
|
- detached HEAD 时默认建议取 `.gitmodules` 声明的分支
|
|
48
48
|
- 已附着在某个本地分支时默认建议取当前分支
|
|
49
|
-
- 以上都只是建议值,最终必须显式写入
|
|
49
|
+
- 以上都只是建议值,最终必须显式写入 `.aiws/changes/<change-id>/submodules.targets`
|
|
50
50
|
|
|
51
51
|
建议流程(按顺序):
|
|
52
52
|
|
|
@@ -58,14 +58,14 @@ fi
|
|
|
58
58
|
- 若当前环境没有 zentao MCP 工具:立即停止并提示用户先配置,不要猜数据。
|
|
59
59
|
|
|
60
60
|
## 2) 证据落盘(强制)
|
|
61
|
-
在当前 active change 上下文的
|
|
61
|
+
在当前 active change 上下文的 `.aiws/changes/<change-id>/bug/` 下落盘:
|
|
62
62
|
- `zentao-bug-<bug-id>.json`:原始字段快照(避免信息丢失)
|
|
63
63
|
- `zentao-bug-<bug-id>.md`:人类可读摘要(复现步骤/期望/实际/风险)
|
|
64
64
|
- `images/<bug-id>/...`:下载的图片附件(保留原扩展名)
|
|
65
65
|
|
|
66
66
|
建议目录:
|
|
67
67
|
```text
|
|
68
|
-
changes/<change-id>/bug/
|
|
68
|
+
.aiws/changes/<change-id>/bug/
|
|
69
69
|
zentao-bug-<bug-id>.json
|
|
70
70
|
zentao-bug-<bug-id>.md
|
|
71
71
|
images/<bug-id>/
|
|
@@ -83,7 +83,7 @@ Bug_ID,Title,Severity,Module,Status,Assigned_To,Change_ID,Image_Count,Image_Path
|
|
|
83
83
|
|
|
84
84
|
字段约束:
|
|
85
85
|
- `Change_ID`:必须等于当前 `change-id`
|
|
86
|
-
- `Evidence_Path`:指向
|
|
86
|
+
- `Evidence_Path`:指向 `.aiws/changes/<change-id>/bug/zentao-bug-<bug-id>.md`
|
|
87
87
|
- `Image_Paths`:多个路径用 `;` 分隔
|
|
88
88
|
- `Fix_Status`:`TODO|DOING|DONE|BLOCKED`
|
|
89
89
|
|
|
@@ -107,5 +107,5 @@ aiws validate . --stamp
|
|
|
107
107
|
- `Change_ID:` `<change-id>`
|
|
108
108
|
- `Change context:` `<当前分支或 worktree 路径>`
|
|
109
109
|
- `CSV:` `issues/fix_bus_issues.csv` 中对应 `Bug_ID` 行的关键字段
|
|
110
|
-
- `Evidence:`
|
|
110
|
+
- `Evidence:` `.aiws/changes/<change-id>/bug/zentao-bug-<bug-id>.md` + 图片目录
|
|
111
111
|
- `Verify:` 实际运行命令与结果(未运行不声称已运行)
|
|
@@ -55,10 +55,10 @@ description: 原生多 agent 委托入口(Codex 优先;先定义角色/边
|
|
|
55
55
|
5) 若当前环境不支持,或无法稳定约束 scope:
|
|
56
56
|
- 明确输出 `Execution Mode: fallback single-agent`
|
|
57
57
|
- 仍按 AIWS 协同工件约定执行:
|
|
58
|
-
-
|
|
59
|
-
-
|
|
60
|
-
-
|
|
61
|
-
-
|
|
58
|
+
- `.aiws/changes/<id>/analysis/`
|
|
59
|
+
- `.aiws/changes/<id>/patches/`
|
|
60
|
+
- `.aiws/changes/<id>/review/`
|
|
61
|
+
- `.aiws/changes/<id>/evidence/`
|
|
62
62
|
6) 不论是否启用原生多 agent,都不要跳过:
|
|
63
63
|
- 需求归因
|
|
64
64
|
- 验证命令
|
|
@@ -20,7 +20,7 @@ description: 开发(按需求实现并验证;适用于任何需要修改代
|
|
|
20
20
|
|
|
21
21
|
- `变更文件(Changed):` 实际改动清单
|
|
22
22
|
- `验证(Verify):` 实际运行的命令与结果说明
|
|
23
|
-
- `证据(Evidence):` `plan
|
|
23
|
+
- `证据(Evidence):` `plan/...`、`.aiws/changes/<change-id>/...`、`.aiws/tmp/...` 等证据路径
|
|
24
24
|
- `Next:` 若准备提交,建议 `$ws-review` 或 `$ws-commit`
|
|
25
25
|
|
|
26
26
|
## 阻断条件
|
|
@@ -37,7 +37,7 @@ description: 开发(按需求实现并验证;适用于任何需要修改代
|
|
|
37
37
|
|
|
38
38
|
### 1. Preflight
|
|
39
39
|
|
|
40
|
-
|
|
40
|
+
定位项目根目录(submodule 感知:若在 submodule 内自动上溯到 superproject 根),读取 `AI_PROJECT.md` / `REQUIREMENTS.md` / `AI_WORKSPACE.md`,输出约束摘要。
|
|
41
41
|
|
|
42
42
|
- 中大型任务:建议先用 `$ws-plan` 生成 `plan/` 工件。
|
|
43
43
|
- 已有计划:先 `$ws-plan-verify`,通过后进入实现。
|
|
@@ -47,7 +47,7 @@ description: 开发(按需求实现并验证;适用于任何需要修改代
|
|
|
47
47
|
|
|
48
48
|
在进入实现前,先验证绑定工件是否完整:
|
|
49
49
|
|
|
50
|
-
- 若计划或实际改动超过 2 个文件:**必须**检查
|
|
50
|
+
- 若计划或实际改动超过 2 个文件:**必须**检查 `.aiws/changes/<change-id>/` 下是否存在 `proposal.md` 和 `tasks.md`
|
|
51
51
|
- 若缺失:**阻断**并输出信息 `Design Gate: proposal.md and tasks.md required for multi-file implementations. Run $ws-plan first.`
|
|
52
52
|
- 若为单文件/小改动(≤2 文件):此检查为 advisory 级别,缺失仅在输出中提示但不阻断
|
|
53
53
|
- Design Gate 检查结果需记录在输出中,作为实现入口证据
|
|
@@ -59,7 +59,7 @@ Design Gate 通过后,继续进入变更归因与实现。
|
|
|
59
59
|
- 若 `git status --porcelain` 仅有计划/工件文件,属于预期行为,继续即可。
|
|
60
60
|
- 若需创建新 change:`aiws change start <change-id> --hooks --no-switch`
|
|
61
61
|
- 若需切换分支:先确认无额外未提交改动,再 `git switch change/<change-id>`
|
|
62
|
-
- 若存在 submodule(`.gitmodules`):进入编码前必须准备好
|
|
62
|
+
- 若存在 submodule(`.gitmodules`):进入编码前必须准备好 `.aiws/changes/<change-id>/submodules.targets`。`aiws change start` 的 `--submodules` 标志会自动处理。参考 `changes/README.md` 和 `.aiws/changes/<change-id>/submodules.targets` 格式。
|
|
63
63
|
|
|
64
64
|
### 3. 实现策略:默认 dispatch aiws-worker(Subagent-First)
|
|
65
65
|
|
|
@@ -44,8 +44,8 @@ description: 轻量开发(simple/local 单点修复;最小改动 + 最小验
|
|
|
44
44
|
- 若只需局部回归,允许运行更窄的验证,但要说明为什么足够
|
|
45
45
|
5) 留下至少一个可追溯证据:
|
|
46
46
|
- 实际改动文件
|
|
47
|
-
- 或 `.
|
|
48
|
-
- 或
|
|
47
|
+
- 或 `.aiws/tmp/...`
|
|
48
|
+
- 或 `.aiws/changes/<change-id>/...`
|
|
49
49
|
6) 输出:
|
|
50
50
|
- `变更文件(Changed):`
|
|
51
51
|
- `验证(Verify):`
|
|
@@ -16,7 +16,7 @@ description: 规划(生成可落盘 plan/ 工件;供 ws-dev 执行)
|
|
|
16
16
|
- 不写入任何 secrets(token、账号、内网端点等不得进入 git)
|
|
17
17
|
- 本 skill 只负责“想清楚怎么做 + 落盘计划”,不要直接大规模改动代码
|
|
18
18
|
- 未运行不声称已运行;验证命令要写清“预期结果”
|
|
19
|
-
- 若存在
|
|
19
|
+
- 若存在 `.aiws/changes/<change-id>/proposal.md`,计划与 proposal 的绑定字段必须保持一致(不一致时先修正再继续)
|
|
20
20
|
|
|
21
21
|
阶段定位:
|
|
22
22
|
- planning 阶段;负责把用户目标收敛为 change 绑定、计划文件和验证入口。
|
|
@@ -25,7 +25,7 @@ description: 规划(生成可落盘 plan/ 工件;供 ws-dev 执行)
|
|
|
25
25
|
- 当前任务描述
|
|
26
26
|
- 真值文件:`AI_PROJECT.md` / `REQUIREMENTS.md` / `AI_WORKSPACE.md`
|
|
27
27
|
- 若已存在:最新 `plan/*.intake.md`
|
|
28
|
-
-
|
|
28
|
+
- 若已存在:`.aiws/changes/<change-id>/proposal.md`
|
|
29
29
|
- 若已有计划:当前 `plan/...` 文件
|
|
30
30
|
|
|
31
31
|
必需输出:
|
|
@@ -52,7 +52,7 @@ description: 规划(生成可落盘 plan/ 工件;供 ws-dev 执行)
|
|
|
52
52
|
3) 若用户任务描述不清,且也没有可消费的 intake 草案:先问 1-3 个关键澄清问题(不要猜);若问题较多则回退到 `$ws-intake`
|
|
53
53
|
4) 判断复杂度:`simple / medium / complex`(给出一句理由),并估算步骤数。
|
|
54
54
|
5) 识别或建立主索引 / change 上下文:
|
|
55
|
-
- 若存在
|
|
55
|
+
- 若存在 `.aiws/changes/<change-id>/proposal.md`:读取其中 `Change_ID` / `Req_ID` / `Problem_ID` / `Contract_Row` / `Evidence_Path`
|
|
56
56
|
- 若缺失关键绑定:先补齐 proposal(至少 `Change_ID`、`Req_ID|Problem_ID`、`Contract_Row`)再继续生成计划
|
|
57
57
|
- 若当前不在 `change/<change-id>` 分支 / worktree,且本次任务需要新建 change:先调用 `aiws change start` 建立上下文,再继续写 plan
|
|
58
58
|
- 推荐顺序:
|
|
@@ -101,7 +101,7 @@ fi
|
|
|
101
101
|
- `Submodules`(当存在 `.gitmodules` 且声明了 submodule 条目时,强制):声明“本次 change 的 submodule 目标分支真值”(用于同一 superproject 分支内的多渠道交付;也避免仅靠 `.gitmodules` 默认分支导致交付推送到错误分支)
|
|
102
102
|
- `Verify`:可复现命令 + 期望结果(优先引用 `AI_WORKSPACE.md` 的入口;必要时补充 e2e)
|
|
103
103
|
- `Risks & Rollback`:风险点 + 回滚方案(例如 git 回滚、`aiws rollback`、恢复备份等)
|
|
104
|
-
- `Evidence`:计划文件路径;若创建了变更工件则附
|
|
104
|
+
- `Evidence`:计划文件路径;若创建了变更工件则附 `.aiws/changes/<change-id>/...`
|
|
105
105
|
8) 若存在 change proposal:回填并对齐 `proposal.md` 的 `Plan_File`(必要时同步 `Contract_Row` / `Evidence_Path`),保证 plan/proposal 一致。
|
|
106
106
|
9) 运行 `$ws-plan-verify` 作为执行前质量门(计划不过长、不跑偏、验证可复现)。
|
|
107
107
|
10) 若计划涉及“需求/验收”变更:先用 `$ws-req-review` 评审 → 用户确认后再 `$ws-req-change` 落盘(避免需求漂移)。
|
|
@@ -111,7 +111,7 @@ fi
|
|
|
111
111
|
- 背景:`.gitmodules submodule.<name>.branch` 适合作为“团队默认分支真值”,但当同一 superproject 分支需要在不同交付中选择不同 submodule 目标分支(多渠道)时,仅靠 `.gitmodules` 不足。
|
|
112
112
|
- 强约束:当 `.gitmodules` 声明了 submodule 条目时,门禁会要求本次 change 存在该文件且覆盖所有 submodule path(否则 `aiws validate .` / `aiws change validate --strict` 阻断)。
|
|
113
113
|
- 约定:为本次 change 落盘一个“交付目标分支映射”文件,并在后续 `$ws-dev`/`$ws-deliver`/`$ws-finish` 优先使用它:
|
|
114
|
-
-
|
|
114
|
+
- 文件:`.aiws/changes/<change-id>/submodules.targets`
|
|
115
115
|
- 格式:每行一个 submodule(忽略空行与 `#` 注释),字段用空白分隔(推荐 `TAB`):
|
|
116
116
|
- 第 1 列:submodule path(例如 `vendor/foo`)
|
|
117
117
|
- 第 2 列:target branch(例如 `release/channel-a`)
|
|
@@ -31,9 +31,10 @@ description: 预检(提交前快速检查与建议)
|
|
|
31
31
|
- 使用者已经知道当前仓库能否继续进入后续阶段,以及必须遵守的约束与下一步入口。
|
|
32
32
|
|
|
33
33
|
执行步骤(强制):
|
|
34
|
-
1)
|
|
35
|
-
- 优先:`git rev-parse --show-
|
|
36
|
-
-
|
|
34
|
+
1) 定位项目根目录(submodule 感知):
|
|
35
|
+
- 优先:`git rev-parse --show-superproject-working-tree`(若当前在 submodule 内则返回 superproject 根)
|
|
36
|
+
- 若为空(不在 submodule 内):`git rev-parse --show-toplevel`
|
|
37
|
+
- 若两者都失败:停止并让用户确认当前目录是否为项目根(不要猜测)。
|
|
37
38
|
2) 在项目根目录读取以下文件(存在则必须读取;缺失则明确报告缺失项,不要臆测内容):
|
|
38
39
|
- `AI_PROJECT.md`
|
|
39
40
|
- `REQUIREMENTS.md`
|
|
@@ -7,7 +7,7 @@ description: 质量审查(行为回归 / 测试覆盖 / 实现质量)
|
|
|
7
7
|
|
|
8
8
|
目标:
|
|
9
9
|
- 审查当前改动的行为正确性、边界条件、测试覆盖和实现质量
|
|
10
|
-
- 把“代码/行为层 findings”优先落盘到
|
|
10
|
+
- 把“代码/行为层 findings”优先落盘到 `.aiws/changes/<change-id>/review/quality-review.md`
|
|
11
11
|
|
|
12
12
|
阶段定位:
|
|
13
13
|
- review 子 gate;负责实现质量、行为回归与验证覆盖审查。
|
|
@@ -16,10 +16,10 @@ description: 质量审查(行为回归 / 测试覆盖 / 实现质量)
|
|
|
16
16
|
- 当前 `git diff`
|
|
17
17
|
- 已执行的验证结果
|
|
18
18
|
- 相关代码 / 配置 / 测试文件
|
|
19
|
-
-
|
|
19
|
+
- 若存在:`.aiws/changes/<change-id>/analysis/`、`patches/`、已有 review 文件
|
|
20
20
|
|
|
21
21
|
必需输出:
|
|
22
|
-
- `证据(Evidence):`
|
|
22
|
+
- `证据(Evidence):` `.aiws/changes/<change-id>/review/quality-review.md` 或回退 `.aiws/tmp/review/quality-review.md`
|
|
23
23
|
- `主要发现(Findings):` 高到低排序的问题 / 风险 / 缺失测试
|
|
24
24
|
- `下一步(Next):` 最小修复项与回归命令
|
|
25
25
|
|
|
@@ -39,8 +39,8 @@ description: 质量审查(行为回归 / 测试覆盖 / 实现质量)
|
|
|
39
39
|
- 测试是否足以支撑改动
|
|
40
40
|
- 是否存在明显复杂度、耦合、可维护性或性能问题
|
|
41
41
|
3) 将结论落盘到:
|
|
42
|
-
-
|
|
43
|
-
- 回退:`.
|
|
42
|
+
- 默认:`.aiws/changes/<change-id>/review/quality-review.md`
|
|
43
|
+
- 回退:`.aiws/tmp/review/quality-review.md`
|
|
44
44
|
4) 输出:
|
|
45
45
|
- `证据(Evidence):`
|
|
46
46
|
- `主要发现(Findings):`
|
|
@@ -8,7 +8,7 @@ description: 需求评审(对齐真值与验收)
|
|
|
8
8
|
目标:在不修改任何文件的前提下,对 `REQUIREMENTS.md` 做一次整体 QA,输出缺口/冲突/风险,减少实现漂移。
|
|
9
9
|
|
|
10
10
|
执行步骤(强制):
|
|
11
|
-
1)
|
|
11
|
+
1) 定位项目根目录:先尝试 `git rev-parse --show-superproject-working-tree`(submodule 感知上溯到 superproject 根);若为空再用 `git rev-parse --show-toplevel`。都失败则停止并让用户确认根目录。
|
|
12
12
|
2) 读取(存在则必须读取;缺失则明确列出,不要臆测):
|
|
13
13
|
- `AI_PROJECT.md`
|
|
14
14
|
- `REQUIREMENTS.md`
|
|
@@ -5,7 +5,7 @@ description: 评审(提交前审计与证据落盘)
|
|
|
5
5
|
|
|
6
6
|
用中文输出(命令/路径/代码标识符保持原样不翻译)。
|
|
7
7
|
|
|
8
|
-
目标:在提交/交付前审计当前改动,对照真值文件检查是否越界,并把审计证据优先落盘到
|
|
8
|
+
目标:在提交/交付前审计当前改动,对照真值文件检查是否越界,并把审计证据优先落盘到 `.aiws/changes/<change-id>/review/`(若无法确定 `change-id` 再回退 `.aiws/tmp/review/`)。
|
|
9
9
|
若当前语境已经明确是“准备交付/finish”,则本入口不应只停留在通用 review:应继续同时补齐 `$ws-spec-review` 与 `$ws-quality-review`,把 dual review gate 一次性收敛完。
|
|
10
10
|
|
|
11
11
|
阶段定位:
|
|
@@ -16,10 +16,10 @@ description: 评审(提交前审计与证据落盘)
|
|
|
16
16
|
- 已执行的验证结果
|
|
17
17
|
- 真值文件:`AI_PROJECT.md` / `REQUIREMENTS.md` / `AI_WORKSPACE.md`
|
|
18
18
|
- 当前 `change/<change-id>` 上下文(若能识别)
|
|
19
|
-
-
|
|
19
|
+
- 若存在:`.aiws/changes/<change-id>/analysis/`、`patches/`、已有 `review/` 文件
|
|
20
20
|
|
|
21
21
|
必需输出:
|
|
22
|
-
-
|
|
22
|
+
- 审计文件:`.aiws/changes/<change-id>/review/codex-review.md` 或回退 `.aiws/tmp/review/codex-review.md`
|
|
23
23
|
- `主要风险(Top risks):` 3-8 条
|
|
24
24
|
- `下一步(Next):` 最小修复清单 + 最小验证命令
|
|
25
25
|
|
|
@@ -31,19 +31,19 @@ description: 评审(提交前审计与证据落盘)
|
|
|
31
31
|
- 审计证据已落盘,主要风险和下一步已明确,可作为 commit/deliver 前置输入。
|
|
32
32
|
|
|
33
33
|
步骤(建议):
|
|
34
|
-
1) 先做 preflight
|
|
34
|
+
1) 先做 preflight:定位项目根目录(submodule 感知:若在 submodule 内自动上溯到 superproject 根),读取 `AI_PROJECT.md` / `REQUIREMENTS.md` / `AI_WORKSPACE.md`,输出约束摘要。
|
|
35
35
|
2) 基于 `git status` / `git diff`(以及你实际运行过的测试结果),对照 `AI_PROJECT.md` 与 `REQUIREMENTS.md` 检查:
|
|
36
36
|
- 是否存在越界目录改动/危险操作
|
|
37
37
|
- 是否有可复现验证命令与证据
|
|
38
|
-
- 是否维护了
|
|
38
|
+
- 是否维护了 `.aiws/changes/<change-id>/` 或相关 `issues/*.csv`
|
|
39
39
|
- 若存在 `analysis/` / `patches/`:审查这些委托工件是否已被主 agent 理解、是否需要采用/拒绝,并把结论写入 review 文件
|
|
40
40
|
3) 将审计落盘到(目录不存在则创建):
|
|
41
|
-
-
|
|
42
|
-
- 回退:`.
|
|
41
|
+
- 默认:`.aiws/changes/<change-id>/review/codex-review.md`
|
|
42
|
+
- 回退:`.aiws/tmp/review/codex-review.md`(仅在无法确定 `change-id` 时使用)
|
|
43
43
|
- 若已有其它 reviewer 文件:不要覆盖它们;当前 reviewer 应写自己的文件或更新自己的汇总文件
|
|
44
44
|
4) 若当前任务已进入“准备提交/交付/finish”的语境,继续补齐 dual review gate:
|
|
45
|
-
- 运行/收敛 `$ws-spec-review`,落盘
|
|
46
|
-
- 运行/收敛 `$ws-quality-review`,落盘
|
|
45
|
+
- 运行/收敛 `$ws-spec-review`,落盘 `.aiws/changes/<change-id>/review/spec-review.md`(或回退 `.aiws/tmp/review/spec-review.md`)
|
|
46
|
+
- 运行/收敛 `$ws-quality-review`,落盘 `.aiws/changes/<change-id>/review/quality-review.md`(或回退 `.aiws/tmp/review/quality-review.md`)
|
|
47
47
|
- 不要把单个 `codex-review.md` 误当成 finish gate 已完成
|
|
48
48
|
5) 回复中输出:
|
|
49
49
|
- `证据(Evidence):` 证据文件路径
|
|
@@ -7,7 +7,7 @@ description: 规范审查(requirements / plan / evidence / gate 完整性)
|
|
|
7
7
|
|
|
8
8
|
目标:
|
|
9
9
|
- 审查当前改动是否满足真值文件、change 绑定、证据路径和 gate 完整性要求
|
|
10
|
-
- 把“流程/规范层 blocker”与“代码层问题”区分开,优先落盘到
|
|
10
|
+
- 把“流程/规范层 blocker”与“代码层问题”区分开,优先落盘到 `.aiws/changes/<change-id>/review/spec-review.md`
|
|
11
11
|
|
|
12
12
|
阶段定位:
|
|
13
13
|
- review 子 gate;负责 requirements / plan / evidence / workflow gate 完整性审查。
|
|
@@ -17,10 +17,10 @@ description: 规范审查(requirements / plan / evidence / gate 完整性)
|
|
|
17
17
|
- `REQUIREMENTS.md`
|
|
18
18
|
- `AI_WORKSPACE.md`
|
|
19
19
|
- 当前 `git diff`
|
|
20
|
-
- 若存在:`plan
|
|
20
|
+
- 若存在:`plan/...`、`.aiws/changes/<change-id>/proposal.md`、`tasks.md`、`review/`、`evidence/`
|
|
21
21
|
|
|
22
22
|
必需输出:
|
|
23
|
-
- `证据(Evidence):`
|
|
23
|
+
- `证据(Evidence):` `.aiws/changes/<change-id>/review/spec-review.md` 或回退 `.aiws/tmp/review/spec-review.md`
|
|
24
24
|
- `阻断项(Blockers):` requirements 归因 / gate / evidence 缺口
|
|
25
25
|
- `下一步(Next):` 修复项与最小验证命令
|
|
26
26
|
|
|
@@ -40,8 +40,8 @@ description: 规范审查(requirements / plan / evidence / gate 完整性)
|
|
|
40
40
|
- 是否存在越界目录改动、危险操作、未声明的非目标扩张
|
|
41
41
|
- 是否已经准备好可复现验证入口
|
|
42
42
|
3) 把结论落盘到:
|
|
43
|
-
-
|
|
44
|
-
- 回退:`.
|
|
43
|
+
- 默认:`.aiws/changes/<change-id>/review/spec-review.md`
|
|
44
|
+
- 回退:`.aiws/tmp/review/spec-review.md`
|
|
45
45
|
4) 输出:
|
|
46
46
|
- `证据(Evidence):`
|
|
47
47
|
- `阻断项(Blockers):`
|
|
@@ -9,9 +9,10 @@ description: 预检:读取真值文件并输出约束摘要
|
|
|
9
9
|
目标:在开始任何“写代码/改配置/落盘文件”之前,对齐工作区真值文件,避免规则漂移。
|
|
10
10
|
|
|
11
11
|
执行步骤(强制):
|
|
12
|
-
1)
|
|
13
|
-
- 优先:`git rev-parse --show-
|
|
14
|
-
-
|
|
12
|
+
1) 定位项目根目录(submodule 感知):
|
|
13
|
+
- 优先:`git rev-parse --show-superproject-working-tree`(submodule 内上溯到 superproject 根)
|
|
14
|
+
- 若为空:`git rev-parse --show-toplevel`
|
|
15
|
+
- 若两者都失败:停止并让用户确认当前目录是否为项目根(不要猜测)。
|
|
15
16
|
2) 在项目根目录读取以下文件(存在则必须读取;缺失则明确报告缺失项,不要臆测内容):
|
|
16
17
|
- `AI_PROJECT.md`
|
|
17
18
|
- `REQUIREMENTS.md`
|
|
@@ -9,7 +9,7 @@ description: 需求评审:对 REQUIREMENTS 做整体 QA(不改文件)
|
|
|
9
9
|
目标:在不修改任何文件的前提下,对 `REQUIREMENTS.md` 做一次整体 QA,输出缺口/冲突/风险,减少实现漂移。
|
|
10
10
|
|
|
11
11
|
执行步骤(强制):
|
|
12
|
-
1)
|
|
12
|
+
1) 定位项目根目录:先尝试 `git rev-parse --show-superproject-working-tree`(submodule 感知上溯);若为空再用 `git rev-parse --show-toplevel`。都失败则停止并让用户确认根目录。
|
|
13
13
|
2) 读取(存在则必须读取;缺失则明确列出,不要臆测):
|
|
14
14
|
- `AI_PROJECT.md`
|
|
15
15
|
- `REQUIREMENTS.md`
|
|
@@ -9,9 +9,10 @@ description: 预检:读取真值文件并输出约束摘要
|
|
|
9
9
|
目标:在开始任何“写代码/改配置/落盘文件”之前,对齐工作区真值文件,避免规则漂移。
|
|
10
10
|
|
|
11
11
|
执行步骤(强制):
|
|
12
|
-
1)
|
|
13
|
-
- 优先:`git rev-parse --show-
|
|
14
|
-
-
|
|
12
|
+
1) 定位项目根目录(submodule 感知):
|
|
13
|
+
- 优先:`git rev-parse --show-superproject-working-tree`(submodule 内上溯到 superproject 根)
|
|
14
|
+
- 若为空:`git rev-parse --show-toplevel`
|
|
15
|
+
- 若两者都失败:停止并让用户确认当前目录是否为项目根(不要猜测)。
|
|
15
16
|
2) 在项目根目录读取以下文件(存在则必须读取;缺失则明确报告缺失项,不要臆测内容):
|
|
16
17
|
- `AI_PROJECT.md`
|
|
17
18
|
- `REQUIREMENTS.md`
|
|
@@ -9,7 +9,7 @@ description: 需求评审:对 REQUIREMENTS 做整体 QA(不改文件)
|
|
|
9
9
|
目标:在不修改任何文件的前提下,对 `REQUIREMENTS.md` 做一次整体 QA,输出缺口/冲突/风险,减少实现漂移。
|
|
10
10
|
|
|
11
11
|
执行步骤(强制):
|
|
12
|
-
1)
|
|
12
|
+
1) 定位项目根目录:先尝试 `git rev-parse --show-superproject-working-tree`(submodule 感知上溯);若为空再用 `git rev-parse --show-toplevel`。都失败则停止并让用户确认根目录。
|
|
13
13
|
2) 读取(存在则必须读取;缺失则明确列出,不要臆测):
|
|
14
14
|
- `AI_PROJECT.md`
|
|
15
15
|
- `REQUIREMENTS.md`
|
|
@@ -20,5 +20,5 @@ fi
|
|
|
20
20
|
|
|
21
21
|
说明:
|
|
22
22
|
- 默认等价于:`git merge --ff-only change/<change-id>`
|
|
23
|
-
- 若你当前就在 `change/<change-id>` 分支上,`finish` 会尝试读取
|
|
23
|
+
- 若你当前就在 `change/<change-id>` 分支上,`finish` 会尝试读取 `.aiws/changes/<change-id>/.ws-change.json` 的 `base_branch` 作为目标分支
|
|
24
24
|
- 若无法 fast-forward:先在 change 分支(或对应 worktree)里 `git rebase <target-branch>`,再重试 `aiws change finish`
|
|
@@ -1,10 +1,10 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: p-aiws-change-new
|
|
3
|
-
description: 私有:创建 changes/<change-id> 工件
|
|
3
|
+
description: 私有:创建 .aiws/changes/<change-id> 工件
|
|
4
4
|
---
|
|
5
5
|
|
|
6
6
|
目标:
|
|
7
|
-
- 创建
|
|
7
|
+
- 创建 `.aiws/changes/<change-id>/` 工件目录与基础文件(proposal/tasks/可选 design)
|
|
8
8
|
|
|
9
9
|
要求:
|
|
10
10
|
- `change-id` 必须是 kebab-case:`^[a-z0-9]+(-[a-z0-9]+)*$`
|
|
@@ -4,7 +4,7 @@ description: 私有:切分支并初始化变更工件(可选安装 hooks)
|
|
|
4
4
|
---
|
|
5
5
|
|
|
6
6
|
目标:
|
|
7
|
-
- 切到分支 `change/<change-id>` 并初始化
|
|
7
|
+
- 切到分支 `change/<change-id>` 并初始化 `.aiws/changes/<change-id>/` 工件
|
|
8
8
|
- 若检测到 `.gitmodules`(git submodules),默认优先使用 `--worktree`(失败则回退为 `--no-switch`),避免切走 superproject 分支导致 submodule 状态混乱
|
|
9
9
|
|
|
10
10
|
要求:
|
|
@@ -1,10 +1,10 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: p-aiws-change-sync
|
|
3
|
-
description: 私有:同步真值基线到 changes/<change-id>(写入 .ws-change.json)
|
|
3
|
+
description: 私有:同步真值基线到 .aiws/changes/<change-id>(写入 .ws-change.json)
|
|
4
4
|
---
|
|
5
5
|
|
|
6
6
|
目标:
|
|
7
|
-
- 将当前真值文件(`AI_PROJECT.md` / `AI_WORKSPACE.md` / `REQUIREMENTS.md`)的 hash 快照同步到
|
|
7
|
+
- 将当前真值文件(`AI_PROJECT.md` / `AI_WORKSPACE.md` / `REQUIREMENTS.md`)的 hash 快照同步到 `.aiws/changes/<change-id>/.ws-change.json`
|
|
8
8
|
|
|
9
9
|
执行(在仓库根目录):
|
|
10
10
|
```bash
|
|
@@ -1,18 +1,18 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: p-tasks-plan
|
|
3
|
-
description: 原子:tasks 同步(从 changes/<id>/tasks.md 生成 update_plan payload)
|
|
3
|
+
description: 原子:tasks 同步(从 .aiws/changes/<id>/tasks.md 生成 update_plan payload)
|
|
4
4
|
---
|
|
5
5
|
|
|
6
6
|
用中文输出(命令/路径/代码标识符保持原样不翻译)。
|
|
7
7
|
|
|
8
8
|
目标:
|
|
9
|
-
- 用
|
|
9
|
+
- 用 `.aiws/changes/<change-id>/tasks.md` 的 checkbox 任务作为“步骤真值”
|
|
10
10
|
- 生成可直接用于 `update_plan` 的 JSON payload(`pending/in_progress/completed`)
|
|
11
11
|
- 输出当前进度摘要(done/total + 当前 in_progress)
|
|
12
12
|
|
|
13
13
|
约束:
|
|
14
14
|
- 不写入任何 secrets(token、账号、内网端点等不得进入 git)
|
|
15
|
-
- 只读
|
|
15
|
+
- 只读 `.aiws/changes/<id>/tasks.md`(不自动改写 tasks 文件)
|
|
16
16
|
- 未运行不声称已运行
|
|
17
17
|
|
|
18
18
|
执行步骤(建议):
|
|
@@ -20,18 +20,18 @@ description: 原子:tasks 同步(从 changes/<id>/tasks.md 生成 update_pla
|
|
|
20
20
|
2) 推断 `change-id`:
|
|
21
21
|
- 优先从当前分支名读取:`git rev-parse --abbrev-ref HEAD`(期望形如 `change/<change-id>`)
|
|
22
22
|
- 若无法推断:让用户明确本次要同步的 `<change-id>`
|
|
23
|
-
3) 检查 tasks 文件存在:`test -f changes/<change-id>/tasks.md`
|
|
23
|
+
3) 检查 tasks 文件存在:`test -f .aiws/changes/<change-id>/tasks.md`
|
|
24
24
|
4) 输出进度摘要:
|
|
25
25
|
```bash
|
|
26
|
-
python3 tools/ws_tasks_plan.py status --file changes/<change-id>/tasks.md
|
|
26
|
+
python3 tools/ws_tasks_plan.py status --file .aiws/changes/<change-id>/tasks.md
|
|
27
27
|
```
|
|
28
28
|
5) 生成 `update_plan` payload(JSON 输出到 stdout):
|
|
29
29
|
```bash
|
|
30
|
-
python3 tools/ws_tasks_plan.py plan --file changes/<change-id>/tasks.md --explanation "sync tasks.md -> update_plan"
|
|
30
|
+
python3 tools/ws_tasks_plan.py plan --file .aiws/changes/<change-id>/tasks.md --explanation "sync tasks.md -> update_plan"
|
|
31
31
|
```
|
|
32
32
|
6) 调用 `update_plan`,将上一步 JSON 原样作为入参(确保任意时刻最多 1 条 `in_progress`)。
|
|
33
33
|
|
|
34
34
|
输出要求:
|
|
35
35
|
- `Change_ID:` <change-id>
|
|
36
|
-
- `Tasks:`
|
|
36
|
+
- `Tasks:` `.aiws/changes/<change-id>/tasks.md`
|
|
37
37
|
- `Next:` 推荐下一步(通常为继续完善 tasks 或进入 `$ws-dev`)
|
|
@@ -19,7 +19,7 @@ description: 使用时机:新会话开始、不确定下一步做什么时。
|
|
|
19
19
|
|
|
20
20
|
- 当前任务描述
|
|
21
21
|
- `AI_PROJECT.md` / `REQUIREMENTS.md` / `AI_WORKSPACE.md`
|
|
22
|
-
- 若已存在:`change/<change-id>` 上下文、`plan
|
|
22
|
+
- 若已存在:`change/<change-id>` 上下文、`plan/...`、`.aiws/changes/<change-id>/...`
|
|
23
23
|
|
|
24
24
|
## 必需输出
|
|
25
25
|
|
|
@@ -44,7 +44,7 @@ description: 使用时机:新会话开始、不确定下一步做什么时。
|
|
|
44
44
|
|
|
45
45
|
### 1.5 Per-turn Breadcrumb(必做)
|
|
46
46
|
|
|
47
|
-
每轮对话开始时强制读取当前 change
|
|
47
|
+
每轮对话开始时强制读取当前 change 状态(`.aiws/changes/<change-id>/.ws-change.json` 或 phase 状态文件),输出 `[workflow-state:PHASE/N]` breadcrumb 标记。
|
|
48
48
|
|
|
49
49
|
目的:即使 context 被压缩,breadcrumb 也能让 AI 知道当前处于哪个阶段、上次做到哪一步。
|
|
50
50
|
|
|
@@ -121,7 +121,7 @@ Subagent 不可用时的降级路径:
|
|
|
121
121
|
- 上次 delegation 返回 `NEEDS_CONTEXT` → 补 context JSONL 后重新派发
|
|
122
122
|
- Subagent-first 默认:`ready-for-dev` / `in-progress` 默认派发 worker/reviewer
|
|
123
123
|
- Subagent 不可用时:降级为当前 agent 直接执行,但必须在 evidence 中记录降级原因
|
|
124
|
-
- Subagent 不可用时回退:单 agent 模式 + 显式维护
|
|
124
|
+
- Subagent 不可用时回退:单 agent 模式 + 显式维护 `.aiws/changes/<id>/` 工件(handoff-evidence.md, analysis/, patches/);不阻断流程,但须标注 `mode: single-agent`
|
|
125
125
|
|
|
126
126
|
### 5. 输出路由
|
|
127
127
|
|
|
@@ -5,7 +5,7 @@ description: 使用时机:需要分析问题、定位根因、收集上下文
|
|
|
5
5
|
|
|
6
6
|
用中文输出(命令/路径/代码标识符保持原样不翻译)。
|
|
7
7
|
|
|
8
|
-
目标:在开始实现/修复前做一次技术分析,产出可执行的最小行动清单,并把证据落盘到 `.
|
|
8
|
+
目标:在开始实现/修复前做一次技术分析,产出可执行的最小行动清单,并把证据落盘到 `.aiws/tmp/analyze/`。
|
|
9
9
|
|
|
10
10
|
输入:
|
|
11
11
|
- 主题/需求:用户在本次消息中提供的主题(若不明确,先问一句“本次分析主题是什么?”)
|
|
@@ -18,7 +18,7 @@ description: 使用时机:需要分析问题、定位根因、收集上下文
|
|
|
18
18
|
- 推荐方案(1 个)+ 备选(可选)
|
|
19
19
|
- 风险与回滚(3–8 条)
|
|
20
20
|
- 最小验证命令(可复现)
|
|
21
|
-
3) 将分析落盘到:`.
|
|
21
|
+
3) 将分析落盘到:`.aiws/tmp/analyze/codex-analysis.md`(目录不存在则创建)。
|
|
22
22
|
4) 回复中必须包含:`Evidence:` 证据文件路径。
|
|
23
23
|
|
|
24
24
|
安全:
|
|
@@ -59,4 +59,4 @@ description: 使用时机:需要自主协作、无人值守执行时。触发
|
|
|
59
59
|
|
|
60
60
|
安全:
|
|
61
61
|
- `ws-autonomy` 不是 runtime controller。
|
|
62
|
-
- 任何 tmux helper 的结果都必须回收到 `.
|
|
62
|
+
- 任何 tmux helper 的结果都必须回收到 `.aiws/tmp/opencode-autonomy/`,最终再由主 agent 收敛到 `.aiws/changes/<id>/...`。
|
|
@@ -7,7 +7,7 @@ description: 使用时机:从禅道/外部系统拉取 bug 进行修复时。
|
|
|
7
7
|
|
|
8
8
|
目标:
|
|
9
9
|
- 用禅道 MCP 拉取 bug 详情与附件(尤其图片)
|
|
10
|
-
- 把证据落盘到
|
|
10
|
+
- 把证据落盘到 `.aiws/changes/<change-id>/bug/`(避免只停留在对话)
|
|
11
11
|
- 把修复任务汇总/更新到 `issues/fix_bus_issues.csv`
|
|
12
12
|
- 与 `ws-dev` / `aiws change` 流程绑定,确保可追溯、可验证
|
|
13
13
|
|
|
@@ -21,7 +21,7 @@ description: 使用时机:从禅道/外部系统拉取 bug 进行修复时。
|
|
|
21
21
|
2) 准备 `change-id`(建议:`bug-<bug-id>` 或 `bugfix-<bug-id>-<slug>`)。
|
|
22
22
|
3) 建立 change 上下文(推荐先于任何落盘):
|
|
23
23
|
- 若当前还不在 `change/<change-id>` 分支 / worktree,先调用 `aiws change start`
|
|
24
|
-
- 工作区必须先干净;否则不要先写
|
|
24
|
+
- 工作区必须先干净;否则不要先写 `.aiws/changes/<change-id>/bug/` 或 `issues/fix_bus_issues.csv`,避免后续切 worktree 时工件留在原工作区
|
|
25
25
|
- 仓库已有提交:优先 `--worktree`
|
|
26
26
|
- superproject + submodule:优先 `--worktree --submodules`
|
|
27
27
|
- 仓库尚无提交 / 不满足 worktree 前置条件:回退 `--no-switch`
|
|
@@ -46,7 +46,7 @@ fi
|
|
|
46
46
|
- 优先复用 `$ws-dev` 的 `submodules.targets` 生成/确认流程
|
|
47
47
|
- detached HEAD 时默认建议取 `.gitmodules` 声明的分支
|
|
48
48
|
- 已附着在某个本地分支时默认建议取当前分支
|
|
49
|
-
- 以上都只是建议值,最终必须显式写入
|
|
49
|
+
- 以上都只是建议值,最终必须显式写入 `.aiws/changes/<change-id>/submodules.targets`
|
|
50
50
|
|
|
51
51
|
建议流程(按顺序):
|
|
52
52
|
|
|
@@ -58,14 +58,14 @@ fi
|
|
|
58
58
|
- 若当前环境没有 zentao MCP 工具:立即停止并提示用户先配置,不要猜数据。
|
|
59
59
|
|
|
60
60
|
## 2) 证据落盘(强制)
|
|
61
|
-
在当前 active change 上下文的
|
|
61
|
+
在当前 active change 上下文的 `.aiws/changes/<change-id>/bug/` 下落盘:
|
|
62
62
|
- `zentao-bug-<bug-id>.json`:原始字段快照(避免信息丢失)
|
|
63
63
|
- `zentao-bug-<bug-id>.md`:人类可读摘要(复现步骤/期望/实际/风险)
|
|
64
64
|
- `images/<bug-id>/...`:下载的图片附件(保留原扩展名)
|
|
65
65
|
|
|
66
66
|
建议目录:
|
|
67
67
|
```text
|
|
68
|
-
changes/<change-id>/bug/
|
|
68
|
+
.aiws/changes/<change-id>/bug/
|
|
69
69
|
zentao-bug-<bug-id>.json
|
|
70
70
|
zentao-bug-<bug-id>.md
|
|
71
71
|
images/<bug-id>/
|
|
@@ -83,7 +83,7 @@ Bug_ID,Title,Severity,Module,Status,Assigned_To,Change_ID,Image_Count,Image_Path
|
|
|
83
83
|
|
|
84
84
|
字段约束:
|
|
85
85
|
- `Change_ID`:必须等于当前 `change-id`
|
|
86
|
-
- `Evidence_Path`:指向
|
|
86
|
+
- `Evidence_Path`:指向 `.aiws/changes/<change-id>/bug/zentao-bug-<bug-id>.md`
|
|
87
87
|
- `Image_Paths`:多个路径用 `;` 分隔
|
|
88
88
|
- `Fix_Status`:`TODO|DOING|DONE|BLOCKED`
|
|
89
89
|
|
|
@@ -107,5 +107,5 @@ aiws validate . --stamp
|
|
|
107
107
|
- `Change_ID:` `<change-id>`
|
|
108
108
|
- `Change context:` `<当前分支或 worktree 路径>`
|
|
109
109
|
- `CSV:` `issues/fix_bus_issues.csv` 中对应 `Bug_ID` 行的关键字段
|
|
110
|
-
- `Evidence:`
|
|
110
|
+
- `Evidence:` `.aiws/changes/<change-id>/bug/zentao-bug-<bug-id>.md` + 图片目录
|
|
111
111
|
- `Verify:` 实际运行命令与结果(未运行不声称已运行)
|
|
@@ -10,7 +10,7 @@ description: 使用时机:需要拆分子任务、委托给子 agent 时。触
|
|
|
10
10
|
## 核心约束
|
|
11
11
|
|
|
12
12
|
- **Subagent-First**:主 session 只做编排与收敛,不直接写实现代码。所有产出必须由 subagent 完成并可追溯到具体 worker。
|
|
13
|
-
- **Handoff 证据**:每轮委托完成后,worker 必须产出结构化 handoff 到
|
|
13
|
+
- **Handoff 证据**:每轮委托完成后,worker 必须产出结构化 handoff 到 `.aiws/changes/<id>/handoff-evidence.md`(完成项、未完成项、残余风险),供主 session 收敛判断。handoff 文件缺失等同于委托未完成。
|
|
14
14
|
|
|
15
15
|
## 必需输入
|
|
16
16
|
|
|
@@ -40,7 +40,7 @@ description: 使用时机:需要拆分子任务、委托给子 agent 时。触
|
|
|
40
40
|
- 没有写清委托边界
|
|
41
41
|
- 上下文策展未执行(未生成 JSONL 或未在 prompt 中引用)
|
|
42
42
|
- 无法判断当前是否可用 oMo,又不能接受回退
|
|
43
|
-
- handoff 文件
|
|
43
|
+
- handoff 文件 `.aiws/changes/<id>/handoff-evidence.md` 缺失或为空(委托返回后必须检查)
|
|
44
44
|
|
|
45
45
|
## 角色映射
|
|
46
46
|
|
|
@@ -82,7 +82,7 @@ description: 使用时机:需要拆分子任务、委托给子 agent 时。触
|
|
|
82
82
|
2. 展开 glob 为实际路径(替换 `<id>`)
|
|
83
83
|
3. 委托者调整:添加/删除/调整 priority/sections
|
|
84
84
|
4. 预算检查:high+medium ≤ 5 文件,总行数 ≤ 4000
|
|
85
|
-
5. 写入
|
|
85
|
+
5. 写入 `.aiws/changes/<id>/analysis/<role>-context.jsonl`
|
|
86
86
|
|
|
87
87
|
OpenCode 插件 `aiws-inject-context` 会自动注入 JSONL 上下文——只需在 `task()` 中指定 `role: <role>`。
|
|
88
88
|
|
|
@@ -113,16 +113,16 @@ OpenCode 插件 `aiws-inject-context` 会自动注入 JSONL 上下文——只
|
|
|
113
113
|
- task: <描述>
|
|
114
114
|
- readScope: <文件/目录>
|
|
115
115
|
- writeScope: <文件/目录>
|
|
116
|
-
- artifactTargets: changes/<id>/patches/, changes/<id>/evidence/
|
|
116
|
+
- artifactTargets: .aiws/changes/<id>/patches/, .aiws/changes/<id>/evidence/
|
|
117
117
|
- fallback: single-agent
|
|
118
|
-
Context Curation: changes/<id>/analysis/worker-context.jsonl
|
|
118
|
+
Context Curation: .aiws/changes/<id>/analysis/worker-context.jsonl
|
|
119
119
|
```
|
|
120
120
|
|
|
121
121
|
## 委托者检查清单
|
|
122
122
|
|
|
123
123
|
派遣前:
|
|
124
124
|
- [ ] 子 agent prompt 包含上下文引用
|
|
125
|
-
- [ ] JSONL 已写入
|
|
125
|
+
- [ ] JSONL 已写入 `.aiws/changes/<id>/analysis/<role>-context.jsonl`
|
|
126
126
|
- [ ] 预算检查通过
|
|
127
127
|
- [ ] readScope / writeScope / artifactTargets 已声明
|
|
128
128
|
|
|
@@ -130,7 +130,7 @@ Context Curation: changes/<id>/analysis/worker-context.jsonl
|
|
|
130
130
|
- [ ] 解析 Status 行
|
|
131
131
|
- [ ] 非 DONE → 按状态处理规则行动
|
|
132
132
|
- [ ] 非 DONE → 记录决策到 `delegation-decisions.md`
|
|
133
|
-
- [ ] handoff 文件
|
|
133
|
+
- [ ] handoff 文件 `.aiws/changes/<id>/handoff-evidence.md` 已存在且非空
|
|
134
134
|
|
|
135
135
|
安全:
|
|
136
136
|
- 不让 `ws-delegate` 变成第二套 orchestrator
|
|
@@ -20,17 +20,17 @@ description: 使用时机:需要修改代码、配置、测试时。触发词
|
|
|
20
20
|
|
|
21
21
|
- `变更文件(Changed):` 实际改动清单
|
|
22
22
|
- `验证(Verify):` 实际运行的命令与结果说明
|
|
23
|
-
- `证据(Evidence):` `plan
|
|
23
|
+
- `证据(Evidence):` `plan/...`、`.aiws/changes/<change-id>/...`、`.aiws/tmp/...` 等证据路径
|
|
24
24
|
- `Next:` 若准备提交,建议 `$ws-review` 或 `$ws-commit`
|
|
25
25
|
|
|
26
26
|
## 前置条件(硬阻断 — 必须最先检查)
|
|
27
27
|
|
|
28
28
|
在开始任何代码改动之前,必须完成以下检查:
|
|
29
29
|
|
|
30
|
-
1. **Design Gate**:若
|
|
30
|
+
1. **Design Gate**:若 `.aiws/changes/<change-id>/proposal.md` 不存在:
|
|
31
31
|
- 立即停止,不要写代码
|
|
32
32
|
- 输出:`BLOCKED: 缺少 proposal。请先执行 $ws-plan 创建变更计划与任务分解。`
|
|
33
|
-
2. **Task Gate**:若
|
|
33
|
+
2. **Task Gate**:若 `.aiws/changes/<change-id>/tasks.md` 不存在:
|
|
34
34
|
- 立即停止,不要写代码
|
|
35
35
|
- 输出:`BLOCKED: 缺少 tasks。请先执行 $ws-plan 创建任务分解。`
|
|
36
36
|
|
|
@@ -78,7 +78,7 @@ description: 使用时机:需要修改代码、配置、测试时。触发词
|
|
|
78
78
|
- 若 `git status --porcelain` 仅有计划/工件文件,属于预期行为,继续即可。
|
|
79
79
|
- 若需创建新 change:`aiws change start <change-id> --hooks --no-switch`
|
|
80
80
|
- 若需切换分支:先确认无额外未提交改动,再 `git switch change/<change-id>`
|
|
81
|
-
- 若存在 submodule(`.gitmodules`):进入编码前必须准备好
|
|
81
|
+
- 若存在 submodule(`.gitmodules`):进入编码前必须准备好 `.aiws/changes/<change-id>/submodules.targets`。`aiws change start` 的 `--submodules` 标志会自动处理。参考 `changes/README.md` 和 `.aiws/changes/<change-id>/submodules.targets` 格式。
|
|
82
82
|
|
|
83
83
|
### 3. 实现策略:默认 dispatch aiws-worker(Subagent-First)
|
|
84
84
|
|
|
@@ -54,8 +54,8 @@ description: 使用时机:单文件/小范围快速修复时。触发词:轻
|
|
|
54
54
|
- 若只需局部回归,允许运行更窄的验证,但要说明为什么足够
|
|
55
55
|
6) 留下至少一个可追溯证据:
|
|
56
56
|
- 实际改动文件
|
|
57
|
-
- 或 `.
|
|
58
|
-
- 或
|
|
57
|
+
- 或 `.aiws/tmp/...`
|
|
58
|
+
- 或 `.aiws/changes/<change-id>/...`
|
|
59
59
|
7) 输出:
|
|
60
60
|
- `变更文件(Changed):`
|
|
61
61
|
- `验证(Verify):`
|
|
@@ -21,7 +21,7 @@ OpenCode + oMo 优先策略:
|
|
|
21
21
|
- 不写入任何 secrets(token、账号、内网端点等不得进入 git)
|
|
22
22
|
- 本 skill 只负责“想清楚怎么做 + 落盘计划”,不要直接大规模改动代码
|
|
23
23
|
- 未运行不声称已运行;验证命令要写清“预期结果”
|
|
24
|
-
- 若存在
|
|
24
|
+
- 若存在 `.aiws/changes/<change-id>/proposal.md`,计划与 proposal 的绑定字段必须保持一致(不一致时先修正再继续)
|
|
25
25
|
|
|
26
26
|
阶段定位:
|
|
27
27
|
- planning 阶段;负责把用户目标收敛为 change 绑定、计划文件和验证入口。
|
|
@@ -29,7 +29,7 @@ OpenCode + oMo 优先策略:
|
|
|
29
29
|
必需输入:
|
|
30
30
|
- 当前任务描述
|
|
31
31
|
- 真值文件:`AI_PROJECT.md` / `REQUIREMENTS.md` / `AI_WORKSPACE.md`
|
|
32
|
-
-
|
|
32
|
+
- 若已存在:`.aiws/changes/<change-id>/proposal.md`
|
|
33
33
|
- 若已有计划:当前 `plan/...` 文件
|
|
34
34
|
|
|
35
35
|
必需输出:
|
|
@@ -53,7 +53,7 @@ OpenCode + oMo 优先策略:
|
|
|
53
53
|
2) 若用户任务描述不清:先问 1-3 个关键澄清问题(不要猜)。
|
|
54
54
|
3) 判断复杂度:`simple / medium / complex`(给出一句理由),并估算步骤数。
|
|
55
55
|
4) 识别或建立主索引 / change 上下文:
|
|
56
|
-
- 若存在
|
|
56
|
+
- 若存在 `.aiws/changes/<change-id>/proposal.md`:读取其中 `Change_ID` / `Req_ID` / `Problem_ID` / `Contract_Row` / `Evidence_Path`
|
|
57
57
|
- 若缺失关键绑定:先补齐 proposal(至少 `Change_ID`、`Req_ID|Problem_ID`、`Contract_Row`)再继续生成计划
|
|
58
58
|
- 若当前不在 `change/<change-id>` 分支 / worktree,且本次任务需要新建 change:
|
|
59
59
|
```bash
|
|
@@ -76,7 +76,7 @@ OpenCode + oMo 优先策略:
|
|
|
76
76
|
- `Verify`:可复现命令 + 期望结果(优先引用 `AI_WORKSPACE.md` 的入口;必要时补充 e2e)
|
|
77
77
|
- `Risks & Rollback`:风险点 + 回滚方案(例如 git 回滚、`aiws rollback`、恢复备份等)
|
|
78
78
|
- 若 intake 草案包含 `Error States` 或 `Rollback Plan`:必须显式引用并纳入本计划的 `Risks & Rollback` 中,不能丢弃 intake 已识别的问题
|
|
79
|
-
- `Evidence`:计划文件路径;若创建了变更工件则附
|
|
79
|
+
- `Evidence`:计划文件路径;若创建了变更工件则附 `.aiws/changes/<change-id>/...`
|
|
80
80
|
7) 若存在 change proposal:回填并对齐 `proposal.md` 的 `Plan_File`(必要时同步 `Contract_Row` / `Evidence_Path`),保证 plan/proposal 一致。
|
|
81
81
|
8) 运行 `$ws-plan-verify` 作为执行前质量门(计划不过长、不跑偏、验证可复现)。
|
|
82
82
|
- 通过后:标记 `[workflow-state:plan:DONE]` 或 `[workflow-state:gate:plan_passed]`,表示 plan 阶段已收敛。
|
|
@@ -91,7 +91,7 @@ oMo 回退:
|
|
|
91
91
|
- 背景:`.gitmodules submodule.<name>.branch` 适合作为“团队默认分支真值”,但当同一 superproject 分支需要在不同交付中选择不同 submodule 目标分支(多渠道)时,仅靠 `.gitmodules` 不足。
|
|
92
92
|
- 强约束:当 `.gitmodules` 声明了 submodule 条目时,门禁会要求本次 change 存在该文件且覆盖所有 submodule path(否则 `aiws validate .` / `aiws change validate --strict` 阻断)。
|
|
93
93
|
- 约定:为本次 change 落盘一个“交付目标分支映射”文件,并在后续 `$ws-dev`/`$ws-deliver`/`$ws-finish` 优先使用它:
|
|
94
|
-
-
|
|
94
|
+
- 文件:`.aiws/changes/<change-id>/submodules.targets`
|
|
95
95
|
- 格式:每行一个 submodule(忽略空行与 `#` 注释),字段用空白分隔(推荐 `TAB`):
|
|
96
96
|
- 第 1 列:submodule path(例如 `vendor/foo`)
|
|
97
97
|
- 第 2 列:target branch(例如 `release/channel-a`)
|
|
@@ -32,9 +32,10 @@ description: 使用时机:新会话开始、仓库首次操作时。触发词
|
|
|
32
32
|
- 使用者已经知道当前仓库能否继续进入后续阶段,以及必须遵守的约束与下一步入口。
|
|
33
33
|
|
|
34
34
|
执行步骤(强制):
|
|
35
|
-
1)
|
|
36
|
-
- 优先:`git rev-parse --show-
|
|
37
|
-
-
|
|
35
|
+
1) 定位项目根目录(submodule 感知):
|
|
36
|
+
- 优先:`git rev-parse --show-superproject-working-tree`(submodule 内上溯到 superproject 根)
|
|
37
|
+
- 若为空:`git rev-parse --show-toplevel`
|
|
38
|
+
- 若两者都失败:停止并让用户确认当前目录是否为项目根(不要猜测)。
|
|
38
39
|
2) 在项目根目录读取以下文件(存在则必须读取;缺失则明确报告缺失项,不要臆测内容):
|
|
39
40
|
- `AI_PROJECT.md`
|
|
40
41
|
- `REQUIREMENTS.md`
|
|
@@ -7,7 +7,7 @@ description: 使用时机:需要审查实现质量、测试覆盖时。触发
|
|
|
7
7
|
|
|
8
8
|
目标:
|
|
9
9
|
- 审查当前改动的行为正确性、边界条件、测试覆盖和实现质量
|
|
10
|
-
- 把“代码/行为层 findings”优先落盘到
|
|
10
|
+
- 把“代码/行为层 findings”优先落盘到 `.aiws/changes/<change-id>/review/quality-review.md`
|
|
11
11
|
|
|
12
12
|
OpenCode + oMo 优先策略:
|
|
13
13
|
- 若检测到 `.opencode/oh-my-opencode.json`,或当前会话明确可用 `oracle` / `explore`,优先借用这些 agent 做质量审查。
|
|
@@ -21,10 +21,10 @@ OpenCode + oMo 优先策略:
|
|
|
21
21
|
- 当前 `git diff`
|
|
22
22
|
- 已执行的验证结果
|
|
23
23
|
- 相关代码 / 配置 / 测试文件
|
|
24
|
-
-
|
|
24
|
+
- 若存在:`.aiws/changes/<change-id>/analysis/`、`patches/`、已有 review 文件
|
|
25
25
|
|
|
26
26
|
必需输出:
|
|
27
|
-
- `证据(Evidence):`
|
|
27
|
+
- `证据(Evidence):` `.aiws/changes/<change-id>/review/quality-review.md` 或回退 `.aiws/tmp/review/quality-review.md`
|
|
28
28
|
- `主要发现(Findings):` 高到低排序的问题 / 风险 / 缺失测试
|
|
29
29
|
- `下一步(Next):` 最小修复项与回归命令
|
|
30
30
|
|
|
@@ -50,8 +50,8 @@ OpenCode + oMo 优先策略:
|
|
|
50
50
|
- over_defensive:过度防御(不必要的安全检查、对不可能情况的处理)
|
|
51
51
|
- cargo_cult:货舱崇拜(照搬模式但不理解原因,如不必要的 observer/strategy)
|
|
52
52
|
3) 将结论落盘到:
|
|
53
|
-
-
|
|
54
|
-
- 回退:`.
|
|
53
|
+
- 默认:`.aiws/changes/<change-id>/review/quality-review.md`
|
|
54
|
+
- 回退:`.aiws/tmp/review/quality-review.md`
|
|
55
55
|
4) 输出:
|
|
56
56
|
- `证据(Evidence):`
|
|
57
57
|
- `主要发现(Findings):`
|
|
@@ -8,7 +8,7 @@ description: 使用时机:需要评审需求、验收条件、合同时。触
|
|
|
8
8
|
目标:在不修改任何文件的前提下,对 `REQUIREMENTS.md` 做一次整体 QA,输出缺口/冲突/风险,减少实现漂移。
|
|
9
9
|
|
|
10
10
|
执行步骤(强制):
|
|
11
|
-
1)
|
|
11
|
+
1) 定位项目根目录:先尝试 `git rev-parse --show-superproject-working-tree`(submodule 感知上溯);若为空再用 `git rev-parse --show-toplevel`。都失败则停止并让用户确认根目录。
|
|
12
12
|
2) 读取(存在则必须读取;缺失则明确列出,不要臆测):
|
|
13
13
|
- `AI_PROJECT.md`
|
|
14
14
|
- `REQUIREMENTS.md`
|
|
@@ -11,7 +11,7 @@ description: 使用时机:需要审计当前改动、查找风险时。触发
|
|
|
11
11
|
|
|
12
12
|
用中文输出(命令/路径/代码标识符保持原样不翻译)。
|
|
13
13
|
|
|
14
|
-
目标:在提交/交付前审计当前改动,对照真值文件检查是否越界,并把审计证据优先落盘到
|
|
14
|
+
目标:在提交/交付前审计当前改动,对照真值文件检查是否越界,并把审计证据优先落盘到 `.aiws/changes/<change-id>/review/`(若无法确定 `change-id` 再回退 `.aiws/tmp/review/`)。
|
|
15
15
|
若当前语境已经明确是“准备交付/finish”,则本入口不应只停留在通用 review:应继续同时补齐 `$ws-spec-review` 与 `$ws-quality-review`,把 dual review gate 一次性收敛完。
|
|
16
16
|
|
|
17
17
|
OpenCode + oMo 优先策略:
|
|
@@ -28,10 +28,10 @@ OpenCode + oMo 优先策略:
|
|
|
28
28
|
- 已执行的验证结果
|
|
29
29
|
- 真值文件:`AI_PROJECT.md` / `REQUIREMENTS.md` / `AI_WORKSPACE.md`
|
|
30
30
|
- 当前 `change/<change-id>` 上下文(若能识别)
|
|
31
|
-
-
|
|
31
|
+
- 若存在:`.aiws/changes/<change-id>/analysis/`、`patches/`、已有 `review/` 文件
|
|
32
32
|
|
|
33
33
|
必需输出:
|
|
34
|
-
-
|
|
34
|
+
- 审计文件:`.aiws/changes/<change-id>/review/codex-review.md` 或回退 `.aiws/tmp/review/codex-review.md`
|
|
35
35
|
- `主要风险(Top risks):` 3-8 条
|
|
36
36
|
- `下一步(Next):` 最小修复清单 + 最小验证命令
|
|
37
37
|
|
|
@@ -61,7 +61,7 @@ OpenCode + oMo 优先策略:
|
|
|
61
61
|
3) 基于 `git status` / `git diff`(以及你实际运行过的测试结果),对照 `AI_PROJECT.md` 与 `REQUIREMENTS.md` 检查:
|
|
62
62
|
- 是否存在越界目录改动/危险操作
|
|
63
63
|
- 是否有可复现验证命令与证据
|
|
64
|
-
- 是否维护了
|
|
64
|
+
- 是否维护了 `.aiws/changes/<change-id>/` 或相关 `issues/*.csv`
|
|
65
65
|
- 若存在 `analysis/` / `patches/`:审查这些委托工件是否已被主 agent 理解、是否需要采用/拒绝,并把结论写入 review 文件
|
|
66
66
|
4) Workflow State Suffix 审计(检查 4 种后缀使用是否一致):
|
|
67
67
|
- `session` 后缀:只由 ws-dev-lite / ws-intake 写入,标记会话级进度(如 `[workflow-state:session:in_progress]`)
|
|
@@ -70,12 +70,12 @@ OpenCode + oMo 优先策略:
|
|
|
70
70
|
- `gateway` 后缀:由 ws-finish / ws-deliver 写入,标记交付门禁结果(如 `[workflow-state:gateway:finish_gate_ok]`)
|
|
71
71
|
- 检查当前 change 中使用的后缀类型是否正确对应所在阶段;若出现混用(如 session 与 gate 在同一文件),在审计报告中标记异常并说明应该修正的方向。
|
|
72
72
|
5) 将审计落盘到(目录不存在则创建):
|
|
73
|
-
-
|
|
74
|
-
- 回退:`.
|
|
73
|
+
- 默认:`.aiws/changes/<change-id>/review/codex-review.md`
|
|
74
|
+
- 回退:`.aiws/tmp/review/codex-review.md`(仅在无法确定 `change-id` 时使用)
|
|
75
75
|
- 若已有其它 reviewer 文件:不要覆盖它们;当前 reviewer 应写自己的文件或更新自己的汇总文件
|
|
76
76
|
6) 若 triage 标记为 `dual_review_required`,继续补齐 dual review gate:
|
|
77
|
-
- 运行/收敛 `$ws-spec-review`,落盘
|
|
78
|
-
- 运行/收敛 `$ws-quality-review`,落盘
|
|
77
|
+
- 运行/收敛 `$ws-spec-review`,落盘 `.aiws/changes/<change-id>/review/spec-review.md`(或回退 `.aiws/tmp/review/spec-review.md`)
|
|
78
|
+
- 运行/收敛 `$ws-quality-review`,落盘 `.aiws/changes/<change-id>/review/quality-review.md`(或回退 `.aiws/tmp/review/quality-review.md`)
|
|
79
79
|
- 不要把单个 `codex-review.md` 误当成 finish gate 已完成
|
|
80
80
|
7) 回复中输出:
|
|
81
81
|
- `证据(Evidence):` 证据文件路径
|
|
@@ -7,7 +7,7 @@ description: 使用时机:需要审查流程完整性、requirements 归因时
|
|
|
7
7
|
|
|
8
8
|
目标:
|
|
9
9
|
- 审查当前改动是否满足真值文件、change 绑定、证据路径和 gate 完整性要求
|
|
10
|
-
- 把“流程/规范层 blocker”与“代码层问题”区分开,优先落盘到
|
|
10
|
+
- 把“流程/规范层 blocker”与“代码层问题”区分开,优先落盘到 `.aiws/changes/<change-id>/review/spec-review.md`
|
|
11
11
|
|
|
12
12
|
OpenCode + oMo 优先策略:
|
|
13
13
|
- 若检测到 `.opencode/oh-my-opencode.json`,或当前会话明确可用 `oracle` / `librarian`,优先借用它们做 spec / gate 审查。
|
|
@@ -22,10 +22,10 @@ OpenCode + oMo 优先策略:
|
|
|
22
22
|
- `REQUIREMENTS.md`
|
|
23
23
|
- `AI_WORKSPACE.md`
|
|
24
24
|
- 当前 `git diff`
|
|
25
|
-
- 若存在:`plan
|
|
25
|
+
- 若存在:`plan/...`、`.aiws/changes/<change-id>/proposal.md`、`tasks.md`、`review/`、`evidence/`
|
|
26
26
|
|
|
27
27
|
必需输出:
|
|
28
|
-
- `证据(Evidence):`
|
|
28
|
+
- `证据(Evidence):` `.aiws/changes/<change-id>/review/spec-review.md` 或回退 `.aiws/tmp/review/spec-review.md`
|
|
29
29
|
- `阻断项(Blockers):` requirements 归因 / gate / evidence 缺口
|
|
30
30
|
- `下一步(Next):` 修复项与最小验证命令
|
|
31
31
|
|
|
@@ -46,8 +46,8 @@ OpenCode + oMo 优先策略:
|
|
|
46
46
|
- 是否存在越界目录改动、危险操作、未声明的非目标扩张
|
|
47
47
|
- 是否已经准备好可复现验证入口
|
|
48
48
|
3) 把结论落盘到:
|
|
49
|
-
-
|
|
50
|
-
- 回退:`.
|
|
49
|
+
- 默认:`.aiws/changes/<change-id>/review/spec-review.md`
|
|
50
|
+
- 回退:`.aiws/tmp/review/spec-review.md`
|
|
51
51
|
4) 输出:
|
|
52
52
|
- `证据(Evidence):`
|
|
53
53
|
- `阻断项(Blockers):`
|
|
@@ -9,11 +9,11 @@ description: Thin wrapper for `aiws verify-bc`
|
|
|
9
9
|
|
|
10
10
|
进入 `ws-finish` / `ws-handoff` 前必须确认:
|
|
11
11
|
|
|
12
|
-
- [ ] `ws-spec-review` 已完成:`test -f changes/<id>/review/spec-review.md` (→ PASS/FAIL)
|
|
13
|
-
- [ ] `ws-quality-review` 已完成:`test -f changes/<id>/review/quality-review.md` (→ PASS/FAIL)
|
|
14
|
-
- [ ] `aiws validate .` stamp 存在:`ls .
|
|
15
|
-
- [ ] 无未关闭 Critical blocker:`grep -c 'Critical' changes/<id>/review/*.md` = 0 或已标记 resolved (→ PASS/FAIL)
|
|
16
|
-
- [ ] 评审-返工循环 handoff 记录:`test -f changes/<id>/handoff-evidence.md` 且含 rework round 记录 (→ PASS/FAIL)
|
|
12
|
+
- [ ] `ws-spec-review` 已完成:`test -f .aiws/changes/<id>/review/spec-review.md` (→ PASS/FAIL)
|
|
13
|
+
- [ ] `ws-quality-review` 已完成:`test -f .aiws/changes/<id>/review/quality-review.md` (→ PASS/FAIL)
|
|
14
|
+
- [ ] `aiws validate .` stamp 存在:`ls .aiws/tmp/aiws-validate/*.json 2>/dev/null` (→ PASS/FAIL)
|
|
15
|
+
- [ ] 无未关闭 Critical blocker:`grep -c 'Critical' .aiws/changes/<id>/review/*.md` = 0 或已标记 resolved (→ PASS/FAIL)
|
|
16
|
+
- [ ] 评审-返工循环 handoff 记录:`test -f .aiws/changes/<id>/handoff-evidence.md` 且含 rework round 记录 (→ PASS/FAIL)
|
|
17
17
|
|
|
18
18
|
## Gate Result(结构化输出)
|
|
19
19
|
|