@namewta/speculo 0.7.2 → 0.7.4
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/dist/src/migrations.js +755 -23
- package/dist/src/migrations.js.map +1 -1
- package/package.json +1 -1
- package/template/canonical/canonical-specdev-engineering-cognitive-mentor.md +200 -448
- package/template/canonical/canonical-specdev-goal-plan.md +744 -1108
- package/template/canonical/canonical-specdev-grill-with-docs.md +201 -449
- package/template/canonical/canonical-specdev-spec.md +232 -486
- package/template/canonical/canonical-specdev-tickets.md +411 -590
- package/template/canonical/canonical-specdev-wayfinder.md +199 -447
- package/template/skills/migrate-runtime-state/SKILL.md +6 -6
- package/template/skills/migrate-runtime-state/references/migration-contract.md +9 -3
- package/template/skills/migrate-runtime-state/scripts/migrate-runtime-state.mjs +404 -33
- package/template/workflows/specdev/I-implement/I-implement.md +98 -143
- package/template/workflows/specdev/I-implement/evidence-template.md +66 -48
- package/template/workflows/specdev/I-implement/execution-preflight.md +31 -21
- package/template/workflows/specdev/I-implement/merge-conflict-protocol.md +12 -12
- package/template/workflows/specdev/I-init-setup/I-init-setup.md +4 -5
- package/template/workflows/specdev/I-init-setup/change-status-template.json +14 -1
- package/template/workflows/specdev/I-init-setup/config-template.json +7 -6
- package/template/workflows/specdev/I-init-setup/status-template.json +1 -1
- package/template/workflows/specdev/INDEX.md +11 -8
- package/template/workflows/specdev/P-goal-plan/P-goal-plan.md +76 -102
- package/template/workflows/specdev/P-goal-plan/completion-control.md +26 -44
- package/template/workflows/specdev/P-goal-plan/goal-plan-template.md +46 -37
- package/template/workflows/specdev/P-goal-plan/lead-orchestration.md +34 -0
- package/template/workflows/specdev/P-goal-plan/orchestration-protocol.md +31 -46
- package/template/workflows/specdev/P-goal-plan/planning-modes.md +67 -89
- package/template/workflows/specdev/P-prototype/ui-prototype.md +1 -1
- package/template/workflows/specdev/T-tickets/T-tickets.md +6 -3
- package/template/workflows/specdev/T-tickets/ticket-readiness.md +5 -3
- package/template/workflows/specdev/T-tickets/ticket-template.md +8 -1
- package/template/workflows/specdev/T-tickets/tickets-map-template.md +5 -4
- package/template/workflows/specdev/_state/status.json +1 -1
- package/template/workflows/specdev/common/README.md +2 -2
- package/template/workflows/specdev/common/rules/change-completion.md +17 -20
- package/template/workflows/specdev/common/rules/deviation-control.md +1 -1
- package/template/workflows/specdev/common/rules/evidence-and-verification.md +31 -37
- package/template/workflows/specdev/common/rules/path-ownership.md +21 -23
- package/template/workflows/specdev/common/rules/readiness-and-depth.md +1 -1
- package/template/workflows/specdev/common/schemas/change-status.schema.json +153 -363
- package/template/workflows/specdev/common/schemas/config.schema.json +17 -13
- package/template/workflows/specdev/common/schemas/goal-plan.schema.json +33 -16
- package/template/workflows/specdev/common/schemas/status.schema.json +7 -63
- package/template/workflows/specdev/common/skills/dev-worktree/SKILL.md +42 -21
- package/template/workflows/specdev/common/skills/dev-worktree/references/create.md +36 -21
- package/template/workflows/specdev/common/skills/dev-worktree/references/finalize.md +46 -18
- package/template/workflows/specdev/common/skills/subagent-delivery/SKILL.md +34 -31
- package/template/workflows/specdev/common/skills/subagent-delivery/references/external-web-subagent.md +10 -23
- package/template/workflows/specdev/common/skills/subagent-delivery/references/native-subagent.md +15 -25
- package/template/workflows/specdev/common/tools/README.md +2 -1
- package/template/workflows/specdev/common/tools/validate-specdev.mjs +591 -219
- package/template/workflows/specdev/I-implement/delegated-evidence-template.md +0 -12
- package/template/workflows/specdev/P-goal-plan/delegated-execution-template.md +0 -35
- package/template/workflows/specdev/P-goal-plan/delegated-execution.md +0 -59
- package/template/workflows/specdev/P-goal-plan/workspace-execution-template.md +0 -24
|
@@ -1,11 +1,15 @@
|
|
|
1
1
|
---
|
|
2
|
-
schema_version:
|
|
2
|
+
schema_version: 6
|
|
3
3
|
artifact: goal-plan
|
|
4
4
|
change: <YYYY-MM-DD-topic>
|
|
5
5
|
status: draft
|
|
6
|
-
modes: [
|
|
7
|
-
|
|
8
|
-
|
|
6
|
+
modes: []
|
|
7
|
+
orchestration: lead-directed
|
|
8
|
+
lead: <owner-or-session-locator>
|
|
9
|
+
implementation_agent_limit: 3
|
|
10
|
+
integration_attempt_limit: 3
|
|
11
|
+
ticket_workspace_policy: current
|
|
12
|
+
integration_gate: direct-parent
|
|
9
13
|
ready_for_execution: false
|
|
10
14
|
---
|
|
11
15
|
|
|
@@ -30,10 +34,11 @@ ready_for_execution: false
|
|
|
30
34
|
| 优先级 | 来源 | 负责内容 | 冲突处理 |
|
|
31
35
|
|---|---|---|---|
|
|
32
36
|
| 1 | 用户最新明确决定 | 产品取舍与批准 | 更新真正拥有该决策的工件 |
|
|
33
|
-
| 2 | `<Path>{roots.state}/specdev/changes/{change}/ADR.md</Path>` | 当前 change
|
|
34
|
-
| 3 | `<Path>{roots.state}/specdev/changes/{change}/
|
|
35
|
-
| 4 | `<Path>{roots.state}/specdev/changes/{change}/
|
|
36
|
-
| 5 |
|
|
37
|
+
| 2 | `<Path>{roots.state}/specdev/changes/{change}/ADR.md</Path>` 与 `<Path>{roots.state}/specdev/changes/{change}/CONTEXT.md</Path>` | 当前 change 架构决定与领域语义 | 返回 `<Path>{roots.workflows}/specdev/G-grill-with-docs/G-grill-with-docs.md</Path>` 更新真正 owner |
|
|
38
|
+
| 3 | `<Path>{roots.state}/specdev/adr/</Path>` 与 `<Path>{roots.state}/specdev/context/</Path>` | 已毕业的永久决定与领域知识 | 当前 change 替代时在 `<Path>{roots.state}/specdev/changes/{change}/ADR.md</Path>` 与 `<Path>{roots.state}/specdev/changes/{change}/LOG.md</Path>` 明示 |
|
|
39
|
+
| 4 | `<Path>{roots.state}/specdev/changes/{change}/spec.md</Path>` | 外部行为、范围与验收 | 下游不得改写 |
|
|
40
|
+
| 5 | `<Path>{roots.state}/specdev/changes/{change}/ticket/</Path>` | 单 Ticket 契约 | Goal Plan 只编排 |
|
|
41
|
+
| 6 | `<Path>{roots.state}/specdev/changes/{change}/diagnosis.md</Path>` 与当前代码/运行事实 | 已验证根因、现状与可行性 | 冲突时触发偏差并返回真正 owner |
|
|
37
42
|
|
|
38
43
|
## 2. Execution Graph
|
|
39
44
|
|
|
@@ -45,14 +50,14 @@ ready_for_execution: false
|
|
|
45
50
|
|
|
46
51
|
### Waves and Ownership
|
|
47
52
|
|
|
48
|
-
| Wave | Ticket | 前置条件 | 项目写路径 | Shared owner |
|
|
53
|
+
| Wave | Ticket | 前置条件 | 项目写路径 | Shared owner | Gate/集成序号 |
|
|
49
54
|
|---|---|---|---|---|---|
|
|
50
55
|
|
|
51
56
|
### Ticket Quick Reference
|
|
52
57
|
|
|
53
|
-
| ID |
|
|
54
|
-
|
|
55
|
-
| T-01 |
|
|
58
|
+
| ID | 可观察产出 | Dependencies | Workspace | Implementation owner | E2E disposition | Evidence |
|
|
59
|
+
|---|---|---|---|---|---|---|
|
|
60
|
+
| T-01 | ... | — | `current`(required 模式为 `specdev-worktree/<change>/T-01`) | Lead / dynamic dispatch | required / not-required: reason | `<Path>{roots.state}/specdev/changes/{change}/evidence/T-01.md</Path>` |
|
|
56
61
|
|
|
57
62
|
## 3. Gates and Completion Evidence
|
|
58
63
|
|
|
@@ -60,7 +65,7 @@ ready_for_execution: false
|
|
|
60
65
|
|
|
61
66
|
### Gates
|
|
62
67
|
|
|
63
|
-
| Gate | 开启条件 | 关闭证据 | 阻塞范围 |
|
|
68
|
+
| Gate | 开启条件 | 关闭证据 | 阻塞范围 | Lead/批准人 | 失败恢复 |
|
|
64
69
|
|---|---|---|---|---|---|
|
|
65
70
|
|
|
66
71
|
### Contract and Reference Coverage
|
|
@@ -70,41 +75,49 @@ ready_for_execution: false
|
|
|
70
75
|
|
|
71
76
|
## 4. Execution and Integration Protocol
|
|
72
77
|
|
|
73
|
-
###
|
|
78
|
+
### Lead Orchestration
|
|
74
79
|
|
|
75
|
-
|
|
|
80
|
+
| 项目 | 决定 | 事实依据 |
|
|
76
81
|
|---|---|---|
|
|
77
|
-
|
|
|
78
|
-
|
|
|
82
|
+
| Lead | `<owner-or-session-locator>` | 唯一 SpecDev 状态、Evidence 与父分支 owner |
|
|
83
|
+
| Implementation subagents | `<implementation_agent_limit>`,Lead 不计入 | Goal Plan 快照、依赖和平台能力的最小值 |
|
|
84
|
+
| Integration attempts | `<integration_attempt_limit>` | Goal Plan 创建时从 config 快照 |
|
|
85
|
+
| Read-only agents | 无 SpecDev 数字上限 | review/research/test-observation,不写状态 |
|
|
86
|
+
| Dispatch | execution-time dynamic | provider/模型/派单按 Ticket 事实选择 |
|
|
79
87
|
|
|
80
|
-
### Ticket
|
|
88
|
+
### Ticket Workspace and Integration
|
|
81
89
|
|
|
82
|
-
| Ticket |
|
|
83
|
-
|
|
90
|
+
| Ticket | Parent/base | Workspace/branch | Source checks | Implementation commit | Integration checks/E2E | Parent result |
|
|
91
|
+
|---|---|---|---|---|---|---|
|
|
92
|
+
|
|
93
|
+
当 `ticket_workspace_policy: current` 时,Ticket 必须严格串行。Lead 每次只允许一个 implementation owner 写入当前 workspace;完成非 E2E 检查并形成 commit 后,Lead 在同一父分支/current workspace 运行适用集成检查和 E2E,验证通过后将该 Ticket 的 `result_sha` 记录为其 implementation commit,再开始下一个 Ticket。不得创建 source/candidate worktree。
|
|
94
|
+
|
|
95
|
+
当 `ticket_workspace_policy: required` 时,Ticket 使用独立 source worktree;source worktree 不运行 E2E,Lead 在最新父分支的 candidate 状态运行集成检查和适用 E2E,通过且父 HEAD 未漂移后才推进父分支。
|
|
84
96
|
|
|
85
97
|
### Authorization Matrix
|
|
86
98
|
|
|
87
99
|
| 动作 | 状态 | 目标与条件 |
|
|
88
100
|
|---|---|---|
|
|
89
|
-
|
|
|
90
|
-
|
|
|
91
|
-
|
|
|
92
|
-
|
|
|
93
|
-
|
|
|
101
|
+
| Current workspace Ticket changes | allowed / not-authorized | 仅 current 模式;严格串行,单一 implementation writer |
|
|
102
|
+
| Ticket worktree local changes | allowed / not-authorized | 仅 required 模式;限 writable/shared owner 合同 |
|
|
103
|
+
| Implementation commit | allowed / not-authorized | 每 Ticket 必需;缺失则 Plan blocked |
|
|
104
|
+
| Local direct-parent verification and parent update | allowed / not-authorized | 仅 current 模式;Lead 核对 Ticket commit 后继续 |
|
|
105
|
+
| Local candidate integration and parent update | allowed / not-authorized | 仅 required 模式;Lead-only;缺失则 Plan blocked |
|
|
106
|
+
| Push / PR / remote merge | allowed / not-authorized | 不从本计划本地授权继承 |
|
|
107
|
+
| Branch/worktree cleanup | allowed / not-authorized | 成功集成不自动继承 |
|
|
108
|
+
| Deploy / migration / production actions | allowed / not-authorized | 逐动作、目标和条件 |
|
|
94
109
|
|
|
95
|
-
### Evidence Return
|
|
110
|
+
### Evidence Return
|
|
96
111
|
|
|
97
|
-
|
|
112
|
+
subagent 只返回候选事实与 commit;Lead 独立核对并写 Evidence、状态和最终验收。
|
|
98
113
|
|
|
99
114
|
## 5. Constraints, Risk and Recovery
|
|
100
115
|
|
|
101
116
|
### Non-negotiable Constraints
|
|
102
117
|
|
|
103
|
-
每条包含来源和违反后果;局部实现自由进入 Guidance。
|
|
104
|
-
|
|
105
118
|
### Verification Integrity
|
|
106
119
|
|
|
107
|
-
|
|
120
|
+
记录判卷接缝、基线、禁止的伪绿色方式,以及 current/direct-parent 或 source/candidate 两层验证边界。
|
|
108
121
|
|
|
109
122
|
### Migration or Release Sequence
|
|
110
123
|
|
|
@@ -118,18 +131,14 @@ ready_for_execution: false
|
|
|
118
131
|
|
|
119
132
|
### Current Status
|
|
120
133
|
|
|
121
|
-
记录 Wave/Gate、Ticket
|
|
134
|
+
记录 Wave/Gate、Ticket、implementation/source、适用 candidate 和 result SHA、最近验证和未验证项;不使用主观百分比。
|
|
122
135
|
|
|
123
136
|
### Pending Decisions and Blockers
|
|
124
137
|
|
|
125
|
-
记录失败命令、已通过行为、owner 和恢复条件。
|
|
126
|
-
|
|
127
138
|
### Resume Protocol
|
|
128
139
|
|
|
129
|
-
|
|
130
|
-
|
|
131
|
-
### Reporting Format
|
|
140
|
+
恢复时读取 Goal Plan、当前 Ticket、change workspace 状态和最新 Evidence;从最后通过的父分支 result 或待修正 implementation/source checkpoint 继续。
|
|
132
141
|
|
|
133
142
|
## Assumptions
|
|
134
143
|
|
|
135
|
-
|
|
144
|
+
只记录低影响且可验证的假设。存在高影响假设时 `ready_for_execution` 必须为 `false`。
|
|
@@ -0,0 +1,34 @@
|
|
|
1
|
+
# Lead 编排与动态派单协议
|
|
2
|
+
|
|
3
|
+
## 1. 唯一 Lead
|
|
4
|
+
|
|
5
|
+
Lead 是主会话中的唯一编排 owner,保留需求解释、DAG/Wave/Gate、路径分配、权限、SpecDev 状态、Evidence、候选验收、父分支集成和最终回复责任。恢复时以 Goal Plan 的 `lead` locator 和权威工件继续;更换会话只转移 Lead 身份,不产生第二写入者。
|
|
6
|
+
|
|
7
|
+
## 2. 派单类型
|
|
8
|
+
|
|
9
|
+
- **implementation**:写入 Goal Plan 选择的 current workspace 或 Ticket worktree 的授权项目路径,运行非 E2E 检查并返回 implementation/source commit;
|
|
10
|
+
- **review**:只读审查固定 checkpoint,返回 findings;
|
|
11
|
+
- **research**:只读收集代码或外部事实,返回来源与结论;
|
|
12
|
+
- **test-observation**:只读运行或观察已授权检查,返回命令与结果,不拥有 E2E Gate。
|
|
13
|
+
|
|
14
|
+
Lead 在 Ticket 可以独立执行、写路径不冲突、上下文足够且平台支持时派单。派单是执行期决定,不写回 Goal Plan 作为固定拓扑。
|
|
15
|
+
|
|
16
|
+
## 3. 并发
|
|
17
|
+
|
|
18
|
+
required 模式 implementation subagent 上限取 Goal Plan、config 与平台能力的最小值;current 模式保持单 writer 串行安全不变量;Lead 不计入。review/research/test-observation agent 不设置 SpecDev 数字上限,但 Lead 必须避免测试资源冲突、重复工作和上下文失控。
|
|
19
|
+
|
|
20
|
+
## 4. 写入边界
|
|
21
|
+
|
|
22
|
+
implementation subagent 只写分配的 current workspace 或 worktree 中的项目路径和其 Git commit,不写 Ticket、Map、Goal Plan、Evidence、change status 或父分支。current 模式 commit 直接落在 parent branch;required 模式 commit 落在 source branch。其他 subagent 全部只读。Lead 接收返回后独立核对,再写所有 SpecDev 状态。
|
|
23
|
+
|
|
24
|
+
## 5. 动态 Dispatch Packet
|
|
25
|
+
|
|
26
|
+
每次派单必须绑定 Ticket、Goal Plan、依赖 Evidence、不可变 `base_sha`、branch/workspace locator、workspace strategy、writable/read-only/shared paths、provider、允许动作、非 E2E 验证、停止条件和返回格式。provider 或模型按当次能力与授权选择;外部 provider 需要独立的数据发送授权。
|
|
27
|
+
|
|
28
|
+
implementation 返回至少包含:Ticket ID、workspace locator、最终 commit、dirty 状态、修改路径、检查命令/结果、未验证项、冲突与阻塞。review/research 返回固定输入、findings、来源和未验证声明。
|
|
29
|
+
|
|
30
|
+
## 6. Lead 验收
|
|
31
|
+
|
|
32
|
+
Lead 核对基线、路径、commit、dirty 状态、项目事实与非 E2E 结果;不接受 subagent 自报的 Evidence 或 E2E pass。required implementation 候选进入 dev-worktree candidate-merge;current implementation 由 Lead 在同一 parent branch/current workspace 做 direct-parent 验证。read-only 结果由 Lead 复核后写入对应权威工件。失败返回同一 workspace/worktree 修正或标记 blocked。
|
|
33
|
+
|
|
34
|
+
**完成标准**:每次写入只有一个 Ticket/owner/worktree;所有 SpecDev 状态由 Lead 落盘;派单和返回可从 Evidence 恢复。
|
|
@@ -1,71 +1,56 @@
|
|
|
1
1
|
# Goal Plan 核心编排协议
|
|
2
2
|
|
|
3
|
-
|
|
3
|
+
本文件定义 DAG、Wave、Gate、路径所有权、Ticket workspace 策略、Evidence 返回和父分支集成队列。
|
|
4
4
|
|
|
5
5
|
## 1. DAG 与关键路径
|
|
6
6
|
|
|
7
|
-
- 依赖权威来自
|
|
8
|
-
- `<Path>{roots.state}/specdev/changes/{change}/tickets-map.md</Path>` 是投影,不是第二套依赖真相;
|
|
7
|
+
- 依赖权威来自 Ticket frontmatter 的 `blocked_by`;Tickets Map 是投影;
|
|
9
8
|
- 计算根节点、扇出、汇合点、关键路径、共享合同 owner 和最终收缩点;
|
|
10
|
-
-
|
|
11
|
-
-
|
|
9
|
+
- 依赖只表示真实开始条件,不表达偏好、Agent 交接或“最好先做”;
|
|
10
|
+
- 无法独立保持可验证状态的迁移批次必须有明确 Gate 和恢复策略。
|
|
12
11
|
|
|
13
|
-
## 2. Wave
|
|
12
|
+
## 2. Wave 与实现并发
|
|
14
13
|
|
|
15
|
-
Wave 内 Ticket
|
|
14
|
+
required 模式的 Wave 内 Ticket 必须 Ready、依赖 Evidence 完整、项目写路径不相交、shared owner 已稳定、适用 Gate 已打开且基线一致。current 模式即使 DAG 存在可并行节点,也强制一次只执行一个 Ticket。
|
|
16
15
|
|
|
17
|
-
-
|
|
18
|
-
- 所有依赖已完成并有 Evidence;
|
|
19
|
-
- 项目写路径不相交;
|
|
20
|
-
- shared path 已由 owner 稳定;
|
|
21
|
-
- 适用 Gate 已打开;
|
|
22
|
-
- 源码基线和外部合同版本一致。
|
|
23
|
-
|
|
24
|
-
最大并发从 `<Path>{roots.state}/specdev/config.json</Path>` 读取。并发上限是资源约束,不是必须填满的目标;Wave 也不意味着必须使用多个 Agent。
|
|
25
|
-
|
|
26
|
-
Wave、Agent Team 和 worktree 是三个不同概念。Wave 只表达依赖上可并发;是否委派由 coordination mode 决定,是否隔离写入由 workspace strategy 决定。只读并行不需要 worktree;同一 current workspace 只能有一个项目与状态写入 owner。
|
|
16
|
+
Lead 根据当前事实决定自行实现或派单。required 模式同时活跃的 implementation subagent 不得超过 Goal Plan、config 与平台能力的共同上限;current 模式保持单 writer 串行安全不变量。Lead 不计入。Wave 是可并发性,不是必须填满的目标。只读 review/research/test-observation agent 不写固定数字上限,但不得写项目或 SpecDev 状态,也不得争用同一可变测试环境。
|
|
27
17
|
|
|
28
18
|
## 3. Gate
|
|
29
19
|
|
|
30
|
-
Gate
|
|
31
|
-
|
|
32
|
-
常见 Gate 包括共享合同稳定、首条垂直路径通过、迁移完成、旧调用点归零、发布就绪和观察期结束。名称按项目语义自定义。
|
|
33
|
-
|
|
34
|
-
## 4. Shared path 与共享合同
|
|
20
|
+
Gate 用可验证状态定义,必须写明:工程/业务状态、开启条件、关闭证据、阻塞范围、Lead/批准人和失败恢复。常见 Gate 包括共享合同稳定、首条垂直路径、迁移完成、旧调用点归零、候选合并通过、发布就绪和观察期结束。
|
|
35
21
|
|
|
36
|
-
|
|
22
|
+
## 4. Shared path 与合同
|
|
37
23
|
|
|
38
|
-
|
|
39
|
-
2. 形成可验证稳定基线;
|
|
40
|
-
3. 下游消费者在新基线上重新运行 preflight;
|
|
41
|
-
4. 才允许扇出或继续后续 Ticket;
|
|
42
|
-
5. 共享契约需要变化时暂停消费者并修订上游,不通过多个执行者同时修改解决。
|
|
24
|
+
遵循 `<Path>{roots.workflows}/specdev/common/rules/path-ownership.md</Path>`:
|
|
43
25
|
|
|
44
|
-
|
|
26
|
+
1. 专用 owner Ticket 修改共享路径;
|
|
27
|
+
2. required 模式在其 source worktree 形成 commit 与非 E2E 证据;current 模式在当前 workspace 形成 commit 与证据;
|
|
28
|
+
3. required 模式通过 Lead candidate-merge 进入父分支;current 模式由 Lead 在父分支 direct-parent 验证并推进;
|
|
29
|
+
4. required 模式下游 Ticket 基于新的父分支 checkpoint 创建或刷新 worktree;current 模式仅在前一 Ticket 完成后开始下一个;
|
|
30
|
+
5. 共享合同变化时暂停消费者并修订上游,不让多个执行者竞争写入。
|
|
45
31
|
|
|
46
|
-
|
|
32
|
+
## 5. 每 Ticket workspace 记录
|
|
47
33
|
|
|
48
|
-
|
|
49
|
-
2. **migrate**:按可独立验证的影响范围分批迁移;
|
|
50
|
-
3. **observe**:扫描旧调用点、旧数据或旧协议使用量;
|
|
51
|
-
4. **contract**:收缩条件有证据后删除旧形式;
|
|
52
|
-
5. **verify**:运行兼容、数据、回归、监控和回滚检查。
|
|
34
|
+
每个进入 I-implement 的 Ticket 建立唯一记录。current 模式使用 `workspace_ref=current`、`branch=parent_branch`,记录 implementation/source/result SHA 与 direct-parent 验证;required 模式使用唯一 `specdev-worktree/<ticket-id>`,记录 source/candidate/result SHA 与验证状态。Lead 自行实现或派 subagent 不改变所选策略。
|
|
53
35
|
|
|
54
|
-
|
|
36
|
+
required 模式同一 Ticket 在 candidate 验证失败后保留来源 worktree 并继续修正。新的 source commit 替换当前 `source_checkpoint`,旧 commit 继续由 Git/Evidence 可追溯。成功集成不自动清理 branch/worktree。
|
|
55
37
|
|
|
56
|
-
## 6.
|
|
38
|
+
## 6. 父分支集成队列
|
|
57
39
|
|
|
58
|
-
|
|
40
|
+
required 模式 Lead 串行集成 Ready 候选:
|
|
59
41
|
|
|
60
|
-
|
|
42
|
+
1. 冻结最新 `parent_before_sha`;
|
|
43
|
+
2. 在 Lead-owned parent integration checkout 组合父分支与 `source_checkpoint`;
|
|
44
|
+
3. 生成可定位的 `candidate_sha`;
|
|
45
|
+
4. 在 candidate 状态运行集成检查和适用 E2E;
|
|
46
|
+
5. 重读父 HEAD;若变化,将候选标记 `stale` 并重建;
|
|
47
|
+
6. 检查通过且父 HEAD 未变时,父分支 fast-forward 到 candidate;
|
|
48
|
+
7. 重读父 HEAD/tree,写入 `result_sha` 后才允许 Ticket Done。
|
|
61
49
|
|
|
62
|
-
|
|
50
|
+
父分支是 source checkpoint 的祖先时 candidate/result 可等于 source SHA,方法为 `fast-forward`;否则 candidate 必须是独立 merge commit。候选失败时父分支保持不变,Ticket 回到 `in_progress` 或 `blocked`。current 模式跳过候选 checkout,Lead 在 current workspace 核对 implementation commit、运行集成检查并记录 `method=direct-parent`;失败时父 HEAD 不推进。
|
|
63
51
|
|
|
64
|
-
|
|
65
|
-
2. 同步 Ticket、Tickets Map、Goal Plan 和 change 状态;
|
|
66
|
-
3. 检查依赖、路径所有权、合同覆盖和适用 Gate;
|
|
67
|
-
4. 返回 Ticket 状态、Evidence 路径、代码引用、未验证项和恢复条件。
|
|
52
|
+
## 7. Expand-contract
|
|
68
53
|
|
|
69
|
-
|
|
54
|
+
标准顺序为 expand → migrate → observe → contract → verify。每批迁移独立 commit、按所选策略验证和父分支集成;收缩依据旧调用/数据/协议归零证据,不依据 Ticket 数量推断。
|
|
70
55
|
|
|
71
|
-
|
|
56
|
+
**完成标准**:每个 Ticket 从父基线、implementation/source commit、对应 integration 到 result 都可恢复;父分支只包含已通过所选门禁的 Ticket。
|
|
@@ -1,91 +1,69 @@
|
|
|
1
1
|
# Goal Plan 规划模式与输入门禁
|
|
2
2
|
|
|
3
|
-
|
|
4
|
-
|
|
5
|
-
## 1.
|
|
6
|
-
|
|
7
|
-
|
|
8
|
-
|
|
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
|
-
## 5. 规划摘要
|
|
72
|
-
|
|
73
|
-
写入前形成核心摘要:
|
|
74
|
-
|
|
75
|
-
```text
|
|
76
|
-
modes=<mode-list>
|
|
77
|
-
coordination_mode=single-session|lead-team
|
|
78
|
-
workspace_strategy=current|worktree|mixed
|
|
79
|
-
tickets=<count>
|
|
80
|
-
critical_path=<ticket-list>
|
|
81
|
-
parallel_capacity=<n>
|
|
82
|
-
shared_owners=<owner-map>
|
|
83
|
-
gates=<gate-list>
|
|
84
|
-
authorization=<action-summary>
|
|
85
|
-
hard_stops=<none-or-list>
|
|
86
|
-
adopted_assumptions=<low-impact-only>
|
|
87
|
-
```
|
|
88
|
-
|
|
89
|
-
Lead Team 额外形成 `execution_model`、`lead`、`provider`、`checkpoint`、`source_delivery`、`max_correction_rounds` 和 locator;worktree/mixed 额外形成逐 Ticket workspace allocation。两类字段分别只进入各自附录。
|
|
90
|
-
|
|
91
|
-
**完成标准**:规划 modes、coordination mode 与 workspace strategy 互不代替;single-session 没有委派痕迹;current 没有隔离安排;所有条件分支的源码、交付、权限和恢复字段都有可验证值。
|
|
3
|
+
规划模式描述 Goal Plan 需要额外解决的工程问题。Goal Plan 创建时单独询问 Ticket 是否开启 worktree,默认使用当前 workspace;worktree 与 direct-parent/candidate-merge 由该次 Goal Plan 固定。
|
|
4
|
+
|
|
5
|
+
## 1. 输入门禁
|
|
6
|
+
|
|
7
|
+
开始规划前穷尽检查:
|
|
8
|
+
|
|
9
|
+
- Spec `ready_for_tickets: true`,或上游工件已等价覆盖范围、合同与验收;
|
|
10
|
+
- Tickets Map 与全部 Ticket 存在、Ready、DAG 无环;
|
|
11
|
+
- 每个验收合同被 Ticket 覆盖;
|
|
12
|
+
- writable/shared path 有唯一 owner,Wave 候选无写冲突;
|
|
13
|
+
- config schema v5,`max_implementation_agents` 与 `max_integration_attempts` 为正整数;原型变体范围读取 planning 配置;
|
|
14
|
+
- 父分支可定位,implementation commit 与本地 integration 已获授权;
|
|
15
|
+
- Deep Ticket 的迁移、兼容、监控、恢复和不可逆批准点完整。
|
|
16
|
+
- Ticket 与 `<Path>{roots.state}/specdev/changes/{change}/spec.md</Path>`、`<Path>{roots.state}/specdev/changes/{change}/ADR.md</Path>`、`<Path>{roots.state}/specdev/adr/</Path>`、`<Path>{roots.state}/specdev/context/</Path>` 和当前代码事实不存在未处理冲突;
|
|
17
|
+
- 项目声明的验证命令真实存在,并能观察目标行为;不可运行项有替代证据或明确 blocker;
|
|
18
|
+
- 当前源码基线、父分支、工作区状态和现有用户改动已经实测;
|
|
19
|
+
- 外部合同、标准、参考实现或依赖版本已经固定,不使用浮动的“最新”描述。
|
|
20
|
+
|
|
21
|
+
缺失上游事实返回其 owner;非 v5 Goal Plan 必须按当前合同重新规划,不能只修改版本号。
|
|
22
|
+
|
|
23
|
+
## 2. 可组合模式
|
|
24
|
+
|
|
25
|
+
- `migration`:存在 expand-contract、数据/协议迁移、兼容窗口或收缩条件;
|
|
26
|
+
- `high-assurance`:涉及安全、隐私、资金、数据完整性、法规、关键基础设施、不可逆操作或高事故半径;
|
|
27
|
+
- `reference-conformance`:必须逐项符合外部标准、协议、设计或参考实现;
|
|
28
|
+
- `release-coordination`:存在发布窗口、跨团队依赖、外部批准、阶段部署、观察期、运营交接或远程 reconcile。
|
|
29
|
+
|
|
30
|
+
没有适用模式时 `modes: []`。模式只增加对应 Gate、证据和恢复,不改变 Lead、worktree 或集成基本合同。
|
|
31
|
+
|
|
32
|
+
## 3. Goal Plan 工作区选择
|
|
33
|
+
|
|
34
|
+
- 创建 Goal Plan 时询问“是否开启 worktree 开发?”,默认 `否`;
|
|
35
|
+
- 用户选择 `否` 时写入 `ticket_workspace_policy: current` 与 `integration_gate: direct-parent`;
|
|
36
|
+
- 用户选择 `是` 时写入 `ticket_workspace_policy: required` 与 `integration_gate: candidate-merge`;
|
|
37
|
+
- 该选择只作用于当前 Goal Plan,不读取或修改全局配置;
|
|
38
|
+
- `current` 模式下所有 Ticket 必须串行,并持有唯一 implementation writer 锁;
|
|
39
|
+
- `required` 模式继续使用每 Ticket source worktree 和 Lead-owned candidate integration;
|
|
40
|
+
- `orchestration` 固定为 `lead-directed`;implementation agent 与 integration attempt 上限读取 config,并可在本计划中进一步降低。
|
|
41
|
+
|
|
42
|
+
## 4. Ready 停止条件
|
|
43
|
+
|
|
44
|
+
存在以下任一情况时 `ready_for_execution: false`:
|
|
45
|
+
|
|
46
|
+
- Goal Plan 工作区选择未记录;
|
|
47
|
+
- `current` 模式下 Ticket 无法串行排序或当前 workspace 不是唯一项目写入 owner;
|
|
48
|
+
- `required` 模式下 Ticket 无法建立独立 worktree 或父分支不明确;
|
|
49
|
+
- 当前模式所需的 implementation commit 或 direct-parent/candidate integration 授权缺失;
|
|
50
|
+
- shared path 没有唯一 owner;
|
|
51
|
+
- E2E 是否需要会改变验收结论但尚未确定;
|
|
52
|
+
- 项目验证命令不能执行或无法观察目标行为,且没有批准的替代证据;
|
|
53
|
+
- 当前源码/工作区基线未实测,或外部合同版本仍然浮动;
|
|
54
|
+
- Ticket 与 Spec、ADR、`<Path>{roots.state}/specdev/adr/</Path>`、`<Path>{roots.state}/specdev/context/</Path>` 或代码事实存在未处理冲突;
|
|
55
|
+
- 迁移、发布、不可逆动作或恢复存在高影响未知项;
|
|
56
|
+
- 实现 agent 或 integration attempt 上限超过 config 或平台能力。
|
|
57
|
+
|
|
58
|
+
## 5. 固定执行拓扑
|
|
59
|
+
|
|
60
|
+
- `orchestration: lead-directed`;
|
|
61
|
+
- `ticket_workspace_policy: current | required`;
|
|
62
|
+
- `integration_gate: direct-parent | candidate-merge`;
|
|
63
|
+
- `current` 与 `direct-parent` 必须成对;`required` 与 `candidate-merge` 必须成对;
|
|
64
|
+
- `implementation_agent_limit` 不大于 config 与平台能力;`integration_attempt_limit` 不大于 config;current 模式保持单 writer 串行安全不变量;
|
|
65
|
+
- Lead 不计入 implementation subagent 数量;
|
|
66
|
+
- review/research/test-observation agent 无 SpecDev 固定数字上限,但必须保持只读且不竞争同一可变环境;
|
|
67
|
+
- provider 与派单在执行期决定,不成为 Goal Plan 的静态枚举。
|
|
68
|
+
|
|
69
|
+
**完成标准**:所有固定字段、适用模式、授权、Lead、父分支和阻塞均可验证;没有替代编排模型或空占位。
|
|
@@ -8,7 +8,7 @@
|
|
|
8
8
|
|
|
9
9
|
## 变体
|
|
10
10
|
|
|
11
|
-
|
|
11
|
+
变体数量读取 `<Path>{roots.state}/specdev/config.json</Path>` 的 `planning.ui_prototype_default_variants` 与 `planning.ui_prototype_max_variants`。每个变体必须在布局、信息层级或主要操作入口上结构不同,不能只换颜色或文案。使用项目现有组件和样式系统,但不要共享会限制结构探索的布局抽象。
|
|
12
12
|
|
|
13
13
|
## 切换器
|
|
14
14
|
|
|
@@ -94,7 +94,7 @@ Ticket 是**决策完备的微型执行计划**:它消除执行者在目标、
|
|
|
94
94
|
|
|
95
95
|
- `lite`:局部、可逆、沿用既有模式、无公共契约或迁移影响;
|
|
96
96
|
- `standard`:大多数多文件或跨层垂直切片;
|
|
97
|
-
- `deep`:公共 API/schema、数据迁移、安全/隐私/资金、不可逆操作、expand-contract
|
|
97
|
+
- `deep`:公共 API/schema、数据迁移、安全/隐私/资金、不可逆操作、expand-contract、共享核心路径、多个 implementation owner 的跨 Ticket 写入协调或高事故半径。
|
|
98
98
|
|
|
99
99
|
规划深度不是优先级,也不是 Gate。每个 Ticket 必须记录触发该深度的原因。
|
|
100
100
|
|
|
@@ -111,7 +111,8 @@ Ticket 是**决策完备的微型执行计划**:它消除执行者在目标、
|
|
|
111
111
|
- 有序执行路线和安全落点;
|
|
112
112
|
- expected、writable、read-only、shared 路径;
|
|
113
113
|
- 正常、失败和回归验证矩阵;
|
|
114
|
-
-
|
|
114
|
+
- 每个 Ticket 按 Goal Plan 的 workspace 策略定义 current-workspace/direct-parent 或 source-worktree/parent-candidate 检查,以及按实际跨边界风险判定的 E2E disposition;
|
|
115
|
+
- 每个实现 Ticket 的 implementation commit 与对应父分支完成条件;仅 required 模式创建独立 worktree;
|
|
115
116
|
- Deep 的迁移、兼容窗口、监控、回滚和不可逆批准点;
|
|
116
117
|
- 可判定验收标准。
|
|
117
118
|
|
|
@@ -139,6 +140,8 @@ Ticket 是**决策完备的微型执行计划**:它消除执行者在目标、
|
|
|
139
140
|
- 依赖缺失或 DAG 有环;
|
|
140
141
|
- 可写路径不明确或并行所有权冲突;
|
|
141
142
|
- 验证方法不能执行且没有批准的替代证据;
|
|
143
|
+
- Ticket 未声明 E2E required/not-required 及理由,或在 required 模式把 E2E 安排到 source worktree;
|
|
144
|
+
- 无法形成实现 commit 与 Goal Plan 所选 direct-parent/candidate-merge 父分支出口;
|
|
142
145
|
- 单个新上下文无法完成;
|
|
143
146
|
- Standard/Deep 缺少有序执行路线;
|
|
144
147
|
- Deep 缺少迁移、兼容、监控、回滚或批准点。
|
|
@@ -219,4 +222,4 @@ node <Path>{roots.workflows}/specdev/common/tools/validate-specdev.mjs</Path> \
|
|
|
219
222
|
|
|
220
223
|
## 下一步
|
|
221
224
|
|
|
222
|
-
满足任一情况时建议运行 `<Path>{roots.workflows}/specdev/P-goal-plan/P-goal-plan.md</Path>`:Ticket 数量达到或超过 10
|
|
225
|
+
满足任一情况时建议运行 `<Path>{roots.workflows}/specdev/P-goal-plan/P-goal-plan.md</Path>`:Ticket 数量达到或超过 10、存在多个 implementation owner 的并行写入协调、Deep Ticket、迁移、共享契约、多个 Gate 或高风险发布。只读 review/research 并行本身不触发 Goal Plan;少量线性 Ready Ticket 可直接进入 `<Path>{roots.workflows}/specdev/I-implement/I-implement.md</Path>`。
|
|
@@ -11,10 +11,12 @@
|
|
|
11
11
|
- [ ] 高影响未决问题为零。
|
|
12
12
|
- [ ] `blocked_by` 指向存在的 Ticket,DAG 无环。
|
|
13
13
|
- [ ] `expected_changes`、`writable_paths`、`read_only_paths` 和 `shared_paths` 中的项目路径都使用项目相对 Path 标签。
|
|
14
|
-
- [ ] `writable_paths`
|
|
14
|
+
- [ ] `writable_paths` 非空;纯 review/research 不伪装成 I-implement Ticket。
|
|
15
15
|
- [ ] 每个 shared path 在 `shared_path_owners` 中有唯一 owner。
|
|
16
16
|
- [ ] 正常、失败和回归至少各有一条验证,或有可信的不适用原因。
|
|
17
|
-
- [ ]
|
|
17
|
+
- [ ] 明确 `E2E disposition: required | not-required: reason`;required 场景、预期和接缝可执行。
|
|
18
|
+
- [ ] 按 Goal Plan 策略定义 current-workspace 或 source-worktree 的非 E2E 检查;E2E owner 固定为 Lead,运行环境分别为 current-workspace 或 parent-candidate。
|
|
19
|
+
- [ ] Ticket 完成合同包含 implementation commit、direct-parent 或 candidate-merge、父分支 result SHA 和 Lead Evidence;仅 required 模式需要独立 worktree。
|
|
18
20
|
- [ ] Evidence 位置明确为 `<Path>{roots.state}/specdev/changes/{change}/evidence/{ticket-id}.md</Path>`。
|
|
19
21
|
- [ ] 单个全新上下文能够完成;否则已拆分。
|
|
20
22
|
- [ ] 所有内部文件与目录引用使用完整根变量 Path 标签。
|
|
@@ -30,7 +32,7 @@
|
|
|
30
32
|
|
|
31
33
|
- [ ] 迁移顺序、兼容窗口、监控、回滚或前向恢复、收缩条件和批准点完整。
|
|
32
34
|
- [ ] 安全、隐私、资金或数据完整性风险有缓解与验证。
|
|
33
|
-
- [ ] 跨
|
|
35
|
+
- [ ] 跨 implementation owner 的路径所有权和所选 direct-parent/parent-candidate 集成 Gate 明确。
|
|
34
36
|
- [ ] expand-contract 的收缩条件可通过扫描、指标、查询或测试证明。
|
|
35
37
|
|
|
36
38
|
## Ready 状态
|
|
@@ -102,7 +102,12 @@ shared_path_owners: []
|
|
|
102
102
|
|
|
103
103
|
不适用的关键风险类别必须写“不适用:原因”。
|
|
104
104
|
|
|
105
|
-
|
|
105
|
+
- **Workspace checks:** 按 Goal Plan 在 current workspace 或 source worktree 运行单元、组件、静态、类型、lint/build 等适用非 E2E 检查。
|
|
106
|
+
- **E2E disposition:** required / not-required:原因。
|
|
107
|
+
- **E2E owner/environment:** Lead / current-workspace 或 parent-candidate;required 时写明场景、接缝与预期。
|
|
108
|
+
- **Integration evidence:** implementation/source commit、parent before、适用 candidate/result SHA 和父分支包含关系。
|
|
109
|
+
|
|
110
|
+
E2E 由实际跨边界行为与风险决定,不限于 UI;required 模式不得在 Ticket source worktree 运行或声明通过。
|
|
106
111
|
|
|
107
112
|
## 9. 发布、迁移与恢复
|
|
108
113
|
|
|
@@ -120,5 +125,7 @@ shared_path_owners: []
|
|
|
120
125
|
- [ ] `AC-001`:<可判定结果>。
|
|
121
126
|
- [ ] 验证矩阵全部执行并记录到 `<Path>{roots.state}/specdev/changes/{change}/evidence/T-01.md</Path>`。
|
|
122
127
|
- [ ] 实际项目修改未超出 `writable_paths`,shared path 由指定 owner 修改。
|
|
128
|
+
- [ ] Ticket 已按 Goal Plan 策略形成非空 implementation/source commit,direct-parent 或 candidate 验证通过且父分支 result 已记录。
|
|
129
|
+
- [ ] E2E disposition 已执行;required 模式 E2E 在 parent-candidate、current 模式在 current workspace 由 Lead 完成。
|
|
123
130
|
- [ ] 未发生未批准的范围、契约或发布偏差。
|
|
124
131
|
- [ ] Ticket、Tickets Map 和 Evidence 状态一致。
|
|
@@ -46,10 +46,11 @@ T-01 [READY]
|
|
|
46
46
|
|
|
47
47
|
## 5. 并行与路径所有权
|
|
48
48
|
|
|
49
|
-
-
|
|
50
|
-
-
|
|
49
|
+
- implementation subagent 上限来自 `<Path>{roots.state}/specdev/config.json</Path>`,Goal Plan 可进一步降低且不含 Lead。
|
|
50
|
+
- review/research/test-observation agent 不设 SpecDev 数字上限,但保持只读。
|
|
51
|
+
- shared owner 为专用 Ticket;Lead 是 SpecDev 状态与父分支 integration owner。
|
|
51
52
|
- 项目路径契约以 Ticket frontmatter 为准。
|
|
52
|
-
-
|
|
53
|
+
- 每个实现 Ticket 的 workspace 由 Goal Plan 选择;current 模式串行使用当前 workspace,required 模式使用独立 worktree;只读调查不进入 I-implement Ticket。
|
|
53
54
|
|
|
54
55
|
| Ticket A | Ticket B | Writable 交集 | 真实依赖 | 处理 |
|
|
55
56
|
|---|---|---|---|---|
|
|
@@ -57,7 +58,7 @@ T-01 [READY]
|
|
|
57
58
|
|
|
58
59
|
## 6. Gate、Wave 与集成点
|
|
59
60
|
|
|
60
|
-
T-tickets 可以标注候选 Wave 和行为里程碑。需要正式跨 Ticket 编排时,由 `<Path>{roots.workflows}/specdev/P-goal-plan/P-goal-plan.md</Path>` 完成 Gate、Wave、
|
|
61
|
+
T-tickets 可以标注候选 Wave、E2E disposition 和行为里程碑。需要正式跨 Ticket 编排时,由 `<Path>{roots.workflows}/specdev/P-goal-plan/P-goal-plan.md</Path>` 完成 Gate、Wave、Lead、动态派单边界、candidate 集成顺序、发布与恢复,并把结果投影回本 Map。
|
|
61
62
|
|
|
62
63
|
## 7. 横切契约与风险
|
|
63
64
|
|
|
@@ -44,8 +44,8 @@
|
|
|
44
44
|
- 包与 change 校验器:`<Path>{roots.workflows}/specdev/common/tools/validate-specdev.mjs</Path>`
|
|
45
45
|
- 校验器说明:`<Path>{roots.workflows}/specdev/common/tools/README.md</Path>`
|
|
46
46
|
- 外部技术研究 Skill:`<Path>{roots.workflows}/specdev/common/skills/research/SKILL.md</Path>`
|
|
47
|
-
-
|
|
48
|
-
-
|
|
47
|
+
- Ticket/原型 worktree Skill:`<Path>{roots.workflows}/specdev/common/skills/dev-worktree/SKILL.md</Path>`;仅 required Ticket 使用 source → parent-candidate → parent 状态机,current Ticket 使用 current workspace/direct-parent,原型保持临时生命周期
|
|
48
|
+
- 动态 Agent 交付合同 Skill:`<Path>{roots.workflows}/specdev/common/skills/subagent-delivery/SKILL.md</Path>`;P-goal-plan 建立 Lead 合同,I-implement 在执行期派单与验收
|
|
49
49
|
- 双轴代码审查 Skill:`<Path>{roots.workflows}/specdev/common/skills/code-review/SKILL.md</Path>`
|
|
50
50
|
|
|
51
51
|
## 加载原则
|