@house365/comate 0.9.12 → 0.9.14
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/bin/cli.mjs
CHANGED
|
@@ -5,11 +5,18 @@
|
|
|
5
5
|
// handles agent detection, symlinking, update/remove for 70+ agents.
|
|
6
6
|
import { fileURLToPath } from 'node:url';
|
|
7
7
|
import { dirname } from 'node:path';
|
|
8
|
+
import { readFileSync } from 'node:fs';
|
|
8
9
|
|
|
9
10
|
import { run, skillsInvocation, SKILLS_TIMEOUT_MS } from './init.mjs';
|
|
10
11
|
|
|
11
12
|
const pkgRoot = dirname(dirname(fileURLToPath(import.meta.url)));
|
|
12
13
|
const args = process.argv.slice(2);
|
|
14
|
+
const packageVersion = JSON.parse(readFileSync(`${pkgRoot}/package.json`, 'utf8')).version;
|
|
15
|
+
|
|
16
|
+
if (args[0] === '--version' || args[0] === '-v') {
|
|
17
|
+
console.log(packageVersion);
|
|
18
|
+
process.exit(0);
|
|
19
|
+
}
|
|
13
20
|
|
|
14
21
|
if (args[0] === 'init') {
|
|
15
22
|
const { init } = await import('./init-run.mjs');
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "@house365/comate",
|
|
3
|
-
"version": "0.9.
|
|
3
|
+
"version": "0.9.14",
|
|
4
4
|
"description": "comate —— SDD (规约驱动开发) 的 AI 开发编排器(Agent Skills)",
|
|
5
5
|
"type": "module",
|
|
6
6
|
"license": "MIT",
|
|
@@ -46,7 +46,7 @@
|
|
|
46
46
|
},
|
|
47
47
|
"scripts": {
|
|
48
48
|
"postinstall": "node bin/postinstall.mjs",
|
|
49
|
-
"test": "node bin/init.test.mjs && node bin/usage.test.mjs && bash skills/comate/tests/run.sh",
|
|
49
|
+
"test": "node bin/cli.test.mjs && node bin/init.test.mjs && node bin/usage.test.mjs && bash skills/comate/tests/run.sh",
|
|
50
50
|
"doctor": "cd skills && bash comate/scripts/comate.sh doctor",
|
|
51
51
|
"prepublish-check": "node scripts/prepublish-check.mjs",
|
|
52
52
|
"pack-check": "node scripts/pack-check.mjs",
|
package/skills/comate/SKILL.md
CHANGED
|
@@ -53,8 +53,9 @@ agent 做决策只需读本节,其余参见末尾「参考附录」。决策
|
|
|
53
53
|
|
|
54
54
|
普通进度(如 `design.brainstorm-complete`)、已确认状态和依赖阻塞状态都**不是**待决策,不得抢占用户的新请求。用户明确说“新建 change”时也优先按新建意图处理。
|
|
55
55
|
|
|
56
|
-
**立即路由到对应子 skill**(根据 `phase` 字段):
|
|
57
|
-
- `phase: open`
|
|
56
|
+
**立即路由到对应子 skill**(根据 `phase` 字段):
|
|
57
|
+
- `phase_step: fix.upgrade-awaiting` → 无论当前是 `phase: open` 还是 `phase: build`,调用 `/comate-fix`
|
|
58
|
+
- `phase: open` → 调用 `/comate-open`
|
|
58
59
|
- `phase: design` → 调用 `/comate-design`
|
|
59
60
|
- `phase: build` → 调用 `/comate-build`
|
|
60
61
|
- `phase: verify` → 调用 `/comate-verify`
|
|
@@ -173,7 +174,7 @@ agent 做决策只需读本节,其余参见末尾「参考附录」。决策
|
|
|
173
174
|
- 有活跃 change 且工作树有未提交改动时,按 `comate/reference/dirty-worktree.md` 协议处理。
|
|
174
175
|
- 若 `phase: build`,先检查 `build_mode`、`isolation`、`tdd_mode` 是否已设;任一未设则回 `/comate-build` 对应步骤补充;都已设则读 tasks.md 下一个未勾选任务继续。
|
|
175
176
|
- 若 `phase: verify` 且 `verify_result: fail`,按决策点 4 分级处理:CRITICAL 失败直接 `state transition <name> verify-fail` 回 `/comate-build`(不询问,回退前报告失败项);仅 WARNING/SUGGESTION 或 Spec 漂移时才 AskUserQuestion 暂停。
|
|
176
|
-
- 若 `phase: open` 但 proposal/design/tasks
|
|
177
|
+
- 若 `phase: open` 但 proposal/design/tasks 已完成,按 `workflow` 恢复:`fix` 调 `/comate-fix`,`full` 调 `/comate-open`;对应 skill 立即运行 `bash "$COMATE" guard <name> open --apply` 修复状态,并在 guard 成功后同轮继续下一阶段。
|
|
177
178
|
- 若 `phase: archive`,只调用 `/comate-archive`;归档成功后 change 移入 archive 目录,不要再对旧活跃目录跑 guard。
|
|
178
179
|
|
|
179
180
|
**phase_step 生命周期**:
|
|
@@ -188,7 +189,7 @@ agent 做决策只需读本节,其余参见末尾「参考附录」。决策
|
|
|
188
189
|
4. `phase: verify` → 调用 `/comate-verify`。`tasks.md` 全勾不能单独触发 verify;验证失败回退到 build 后,必须继续按 build 路由修复。
|
|
189
190
|
5. `phase: build` 或有 Design Doc 但 plan/执行未完成 → 按 workflow 路由:`fix`→`/comate-fix`,`full`→`/comate-build`
|
|
190
191
|
6. `phase: design` 或有 change 但无 Design Doc → 调用 `/comate-design`
|
|
191
|
-
7. `phase: open`
|
|
192
|
+
7. `phase: open` → 按 workflow 路由:`fix`→`/comate-fix`,`full`→`/comate-open`;有活跃 change 但 `.comate.yaml` 缺失 → 调用 `/comate-open`
|
|
192
193
|
8. 无活跃 change → 调用 `/comate-open`
|
|
193
194
|
|
|
194
195
|
元数据与文件状态冲突时,以可验证的文件状态为准,先用 `state set` 修正 `.comate.yaml` 再继续。
|
|
@@ -214,7 +215,9 @@ agent 做决策只需读本节,其余参见末尾「参考附录」。决策
|
|
|
214
215
|
|
|
215
216
|
流转链:open → design → build → verify → archive
|
|
216
217
|
|
|
217
|
-
**连续执行要求**:从探测到的阶段开始,agent 自动连续走完后续阶段。但**自动推进仅适用于无用户决策的流转点**。遇到决策阻塞点时,**必须用 AskUserQuestion 工具暂停等待用户明确回应**,不得用推荐规则、默认值或历史偏好替代用户确认,也不得只输出文字提示后继续执行。
|
|
218
|
+
**连续执行要求**:从探测到的阶段开始,agent 自动连续走完后续阶段。但**自动推进仅适用于无用户决策的流转点**。遇到决策阻塞点时,**必须用 AskUserQuestion 工具暂停等待用户明确回应**,不得用推荐规则、默认值或历史偏好替代用户确认,也不得只输出文字提示后继续执行。
|
|
219
|
+
|
|
220
|
+
guard 成功、代码提交成功以及用户已经完成某个决策后的操作都不是新的暂停点。状态已满足下一阶段入口时,必须在当前调用内重新探测并继续;尤其是 fix 流程不得停在 `phase: open` 实现代码,也不得停在 build 提交之后等待用户发送“继续”。
|
|
218
221
|
|
|
219
222
|
7 个决策点(部分含自动处理分支)+ Red Flags 表见 `comate/reference/decision-points.md`。**每个决策点先按三类行动分类**(用户决策 / 自动处理 / 停止条件):判定属用户决策才用 AskUserQuestion 阻塞等待用户选择;属自动处理则直接执行并如实报告;其他无歧义流转自动进行,不得中途退出。
|
|
220
223
|
</IMPORTANT>
|
|
@@ -275,6 +275,21 @@ seed_open() {
|
|
|
275
275
|
[ "$(comate state demo get phase)" = "design" ]
|
|
276
276
|
}
|
|
277
277
|
|
|
278
|
+
@test "fix guards continuously advance open to build to verify" {
|
|
279
|
+
comate state demo init fix
|
|
280
|
+
local d="openspec/changes/demo"
|
|
281
|
+
printf '# p\n' > "$d/proposal.md"
|
|
282
|
+
printf '# d\n' > "$d/design.md"
|
|
283
|
+
printf -- '- [x] t1\n' > "$d/tasks.md"
|
|
284
|
+
|
|
285
|
+
comate guard demo open --apply >/dev/null 2>&1
|
|
286
|
+
[ "$(comate state demo get phase)" = "build" ]
|
|
287
|
+
|
|
288
|
+
comate handoff demo build --write >/dev/null 2>&1
|
|
289
|
+
comate guard demo build --apply >/dev/null 2>&1
|
|
290
|
+
[ "$(comate state demo get phase)" = "verify" ]
|
|
291
|
+
}
|
|
292
|
+
|
|
278
293
|
@test "guard open json emits block false" {
|
|
279
294
|
seed_open
|
|
280
295
|
run comate guard demo open --json
|
|
@@ -39,6 +39,25 @@ if [ -z "$COMATE" ]; then
|
|
|
39
39
|
fi
|
|
40
40
|
```
|
|
41
41
|
|
|
42
|
+
### 0. 入口状态与断点恢复
|
|
43
|
+
|
|
44
|
+
`comate-fix` 必须以 `.comate.yaml` 为进度真相源,并且可以从任一已完成步骤继续。已有 fix change 时,**禁止重新创建 change**;先读取:
|
|
45
|
+
|
|
46
|
+
```bash
|
|
47
|
+
bash "$COMATE" state <name> get workflow
|
|
48
|
+
bash "$COMATE" state <name> get phase
|
|
49
|
+
bash "$COMATE" state <name> get phase_step
|
|
50
|
+
```
|
|
51
|
+
|
|
52
|
+
- `workflow` 不是 `fix` → 退出本预设,交回 `/comate` 按完整流程路由
|
|
53
|
+
- `phase: open` → 恢复 Step 1;产物齐全时立即执行 open guard,不重新创建产物
|
|
54
|
+
- `phase: build` → 恢复 Step 2,从 tasks.md 第一个未完成任务继续;全部完成时直接执行 build 交接与 guard
|
|
55
|
+
- `phase: verify` → 立即加载 `comate-verify`,不得回跑 open/build
|
|
56
|
+
- `phase: archive` → 立即加载 `comate-archive`
|
|
57
|
+
- `phase_step: fix.upgrade-awaiting` → 恢复升级决策,不执行普通 open/build
|
|
58
|
+
|
|
59
|
+
每次 guard 使用 `--apply` 成功后,**在同一次调用内**重新读取 `phase`,并立即执行新阶段;除明确的用户决策、guard 失败或停止条件外,不得把“请用户再说继续”作为阶段边界。
|
|
60
|
+
|
|
42
61
|
### 1. 快速开启(preset open)
|
|
43
62
|
|
|
44
63
|
复用 open 能力但用 fix 默认值:不执行 `openspec-explore` 长探索,直接精简创建。
|
|
@@ -55,6 +74,14 @@ bash "$COMATE" state <name> check open
|
|
|
55
74
|
bash "$COMATE" guard <name> open --apply
|
|
56
75
|
```
|
|
57
76
|
|
|
77
|
+
**Step 1 硬出口**:open guard 成功后必须立即确认状态已经进入 build:
|
|
78
|
+
|
|
79
|
+
```bash
|
|
80
|
+
test "$(bash "$COMATE" state <name> get phase)" = "build"
|
|
81
|
+
```
|
|
82
|
+
|
|
83
|
+
只有该检查通过才能开始 Step 2 的源码修改。不得在 `phase: open` 时实现或提交代码;guard 失败则修复 open 产物并重跑,不能绕过状态流转。
|
|
84
|
+
|
|
58
85
|
### 2. 直接构建(preset build)
|
|
59
86
|
|
|
60
87
|
用 fix 默认值 `build_mode: direct`。跳过 `superpowers:brainstorming` 和 `superpowers:writing-plans`(除非任务 > 3,则转入 `/comate-build` 的计划与执行方式选择)。
|
|
@@ -63,6 +90,8 @@ bash "$COMATE" guard <name> open --apply
|
|
|
63
90
|
|
|
64
91
|
**立即执行:** 按 tasks.md 逐个执行:读未完成任务 → 改代码 → 运行格式化命令 → 运行测试 → 勾选 `- [x]` → 提交。全部完成后显式运行测试和构建命令。
|
|
65
92
|
|
|
93
|
+
提交代码不是 Step 2 的结束点。最后一次提交完成后,当前调用必须继续生成 build 交接包、运行 build guard,并确认进入 verify;不得在提交成功处停下或只向用户报告“代码已提交”。
|
|
94
|
+
|
|
66
95
|
**commit 前缀**:
|
|
67
96
|
- **bug 模式** — `fix: <简述>`
|
|
68
97
|
- **调整模式** — `chore: <简述>`
|
|
@@ -82,9 +111,12 @@ bash "$COMATE" guard <name> open --apply
|
|
|
82
111
|
```bash
|
|
83
112
|
bash "$COMATE" handoff <name> build --write
|
|
84
113
|
bash "$COMATE" guard <name> build --apply
|
|
114
|
+
test "$(bash "$COMATE" state <name> get phase)" = "verify"
|
|
85
115
|
```
|
|
86
116
|
|
|
87
|
-
|
|
117
|
+
**调整模式跳过根因检查,但不跳过交接与流转**;tasks 完成后同样连续运行上述三个命令。
|
|
118
|
+
|
|
119
|
+
build guard 成功后,必须在**同一次 `/comate-fix` 调用**中立即进入 Step 4。只有 guard 返回非 0 时才停留在 build,并报告具体失败检查。
|
|
88
120
|
|
|
89
121
|
### 4. 验证(preset verify)
|
|
90
122
|
|
|
@@ -94,6 +126,8 @@ bash "$COMATE" guard <name> build --apply
|
|
|
94
126
|
|
|
95
127
|
验证通过后按其规则记录 `verify_result: pass`。
|
|
96
128
|
|
|
129
|
+
`comate-verify` 的分支处理属于合法用户决策点;等待用户选择是暂停。用户完成分支处理后,必须立即继续 verify guard,并在 guard 流转到 archive 后同轮加载 `comate-archive`,不得再要求用户发送“继续”。
|
|
130
|
+
|
|
97
131
|
### 5. 归档(preset archive)
|
|
98
132
|
|
|
99
133
|
**立即执行:** 使用 Skill 工具加载 `comate-archive`。归档前必须 `verify_result: pass`。有 delta spec(仅 bug 模式可能)则同步到 main spec。
|
|
@@ -109,6 +143,8 @@ Fix 为**一次性连续执行**。调用后在自有步骤间自动推进,但
|
|
|
109
143
|
3. comate-verify 的验证失败决策(决策点 4)和分支处理决策(决策点 5)
|
|
110
144
|
|
|
111
145
|
执行顺序:快速开启 → 直接构建 → [bug 模式:根因消除检查] → 验证 → 归档 → 完成。
|
|
146
|
+
|
|
147
|
+
其中“提交代码”“guard 成功”“用户已完成分支处理”都不是可停点;它们分别触发交接、下一阶段和 verify 收尾。每次恢复也必须按 Step 0 从持久化状态继续,而不是依赖对话中的上一条说明。
|
|
112
148
|
</IMPORTANT>
|
|
113
149
|
|
|
114
150
|
---
|
|
@@ -140,6 +140,15 @@ bash "$COMATE" state <name> set branch_status handled
|
|
|
140
140
|
bash "$COMATE" state <name> set phase_step verify.branch-handled
|
|
141
141
|
```
|
|
142
142
|
|
|
143
|
+
写入 `branch_status: handled` 后不是退出点。当前 `/comate-verify` 调用必须立即运行:
|
|
144
|
+
|
|
145
|
+
```bash
|
|
146
|
+
bash "$COMATE" guard <name> verify --apply
|
|
147
|
+
test "$(bash "$COMATE" state <name> get phase)" = "archive"
|
|
148
|
+
```
|
|
149
|
+
|
|
150
|
+
guard 成功流转到 `archive` 后,立即加载 `comate-archive` skill;只有 guard 失败或新的用户决策才允许暂停。
|
|
151
|
+
|
|
143
152
|
选择**丢弃工作**时必须写 `branch_status: discarded` 和 `phase_step: verify.discarded`,随后立即停止;不得运行 verify guard、不得设置 `verify_result: pass`、不得归档。若之后要继续该 change,先执行 `state transition <name> verify-fail` 回到 build,再重新实现并生成新的 build handoff。
|
|
144
153
|
|
|
145
154
|
## 退出条件
|