@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.
Files changed (55) hide show
  1. package/dist/src/migrations.js +755 -23
  2. package/dist/src/migrations.js.map +1 -1
  3. package/package.json +1 -1
  4. package/template/canonical/canonical-specdev-engineering-cognitive-mentor.md +200 -448
  5. package/template/canonical/canonical-specdev-goal-plan.md +744 -1108
  6. package/template/canonical/canonical-specdev-grill-with-docs.md +201 -449
  7. package/template/canonical/canonical-specdev-spec.md +232 -486
  8. package/template/canonical/canonical-specdev-tickets.md +411 -590
  9. package/template/canonical/canonical-specdev-wayfinder.md +199 -447
  10. package/template/skills/migrate-runtime-state/SKILL.md +6 -6
  11. package/template/skills/migrate-runtime-state/references/migration-contract.md +9 -3
  12. package/template/skills/migrate-runtime-state/scripts/migrate-runtime-state.mjs +404 -33
  13. package/template/workflows/specdev/I-implement/I-implement.md +98 -143
  14. package/template/workflows/specdev/I-implement/evidence-template.md +66 -48
  15. package/template/workflows/specdev/I-implement/execution-preflight.md +31 -21
  16. package/template/workflows/specdev/I-implement/merge-conflict-protocol.md +12 -12
  17. package/template/workflows/specdev/I-init-setup/I-init-setup.md +4 -5
  18. package/template/workflows/specdev/I-init-setup/change-status-template.json +14 -1
  19. package/template/workflows/specdev/I-init-setup/config-template.json +7 -6
  20. package/template/workflows/specdev/I-init-setup/status-template.json +1 -1
  21. package/template/workflows/specdev/INDEX.md +11 -8
  22. package/template/workflows/specdev/P-goal-plan/P-goal-plan.md +76 -102
  23. package/template/workflows/specdev/P-goal-plan/completion-control.md +26 -44
  24. package/template/workflows/specdev/P-goal-plan/goal-plan-template.md +46 -37
  25. package/template/workflows/specdev/P-goal-plan/lead-orchestration.md +34 -0
  26. package/template/workflows/specdev/P-goal-plan/orchestration-protocol.md +31 -46
  27. package/template/workflows/specdev/P-goal-plan/planning-modes.md +67 -89
  28. package/template/workflows/specdev/P-prototype/ui-prototype.md +1 -1
  29. package/template/workflows/specdev/T-tickets/T-tickets.md +6 -3
  30. package/template/workflows/specdev/T-tickets/ticket-readiness.md +5 -3
  31. package/template/workflows/specdev/T-tickets/ticket-template.md +8 -1
  32. package/template/workflows/specdev/T-tickets/tickets-map-template.md +5 -4
  33. package/template/workflows/specdev/_state/status.json +1 -1
  34. package/template/workflows/specdev/common/README.md +2 -2
  35. package/template/workflows/specdev/common/rules/change-completion.md +17 -20
  36. package/template/workflows/specdev/common/rules/deviation-control.md +1 -1
  37. package/template/workflows/specdev/common/rules/evidence-and-verification.md +31 -37
  38. package/template/workflows/specdev/common/rules/path-ownership.md +21 -23
  39. package/template/workflows/specdev/common/rules/readiness-and-depth.md +1 -1
  40. package/template/workflows/specdev/common/schemas/change-status.schema.json +153 -363
  41. package/template/workflows/specdev/common/schemas/config.schema.json +17 -13
  42. package/template/workflows/specdev/common/schemas/goal-plan.schema.json +33 -16
  43. package/template/workflows/specdev/common/schemas/status.schema.json +7 -63
  44. package/template/workflows/specdev/common/skills/dev-worktree/SKILL.md +42 -21
  45. package/template/workflows/specdev/common/skills/dev-worktree/references/create.md +36 -21
  46. package/template/workflows/specdev/common/skills/dev-worktree/references/finalize.md +46 -18
  47. package/template/workflows/specdev/common/skills/subagent-delivery/SKILL.md +34 -31
  48. package/template/workflows/specdev/common/skills/subagent-delivery/references/external-web-subagent.md +10 -23
  49. package/template/workflows/specdev/common/skills/subagent-delivery/references/native-subagent.md +15 -25
  50. package/template/workflows/specdev/common/tools/README.md +2 -1
  51. package/template/workflows/specdev/common/tools/validate-specdev.mjs +591 -219
  52. package/template/workflows/specdev/I-implement/delegated-evidence-template.md +0 -12
  53. package/template/workflows/specdev/P-goal-plan/delegated-execution-template.md +0 -35
  54. package/template/workflows/specdev/P-goal-plan/delegated-execution.md +0 -59
  55. package/template/workflows/specdev/P-goal-plan/workspace-execution-template.md +0 -24
@@ -1,11 +1,15 @@
1
1
  ---
2
- schema_version: 3
2
+ schema_version: 6
3
3
  artifact: goal-plan
4
4
  change: <YYYY-MM-DD-topic>
5
5
  status: draft
6
- modes: [coordination]
7
- coordination_mode: single-session
8
- workspace_strategy: current
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}/spec.md</Path>` | 外部行为、范围与验收 | 下游不得改写 |
35
- | 4 | `<Path>{roots.state}/specdev/changes/{change}/ticket/{ticket-file}.md</Path>` | Ticket 契约 | Goal Plan 只编排 |
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 | Ticket | 行为产出 | Depth/Risk | Dependencies | Wave/Gate | Owner | Evidence |
54
- |---|---|---|---|---|---|---|---|
55
- | T-01 | `<Path>{roots.state}/specdev/changes/{change}/ticket/01-<name>.md</Path>` | ... | standard/medium | | W0/G0 | `<owner>` | `<Path>{roots.state}/specdev/changes/{change}/evidence/T-01.md</Path>` |
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 | 开启条件 | 关闭证据 | 阻塞范围 | Owner/批准人 | 失败恢复 |
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
- ### Execution Topology
78
+ ### Lead Orchestration
74
79
 
75
- | 维度 | 决定 | 事实依据 |
80
+ | 项目 | 决定 | 事实依据 |
76
81
  |---|---|---|
77
- | Coordination | single-session | 未启用严格角色分派;辅助调查只能返回只读结论 |
78
- | Workspace | current | 没有并行写入或其他隔离触发条件 |
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 Execution Order
88
+ ### Ticket Workspace and Integration
81
89
 
82
- | Ticket | 开始条件 | 执行 owner | 必跑验证 | Evidence | 集成条件 |
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
- | Local changes | allowed / not-authorized | ... |
90
- | Implementation commit | allowed / not-authorized | ... |
91
- | Remote repository actions | allowed / not-authorized | ... |
92
- | Deploy / Migration | allowed / not-authorized | ... |
93
- | Production configuration / feature / real user data | allowed / not-authorized | ... |
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 and Integration
110
+ ### Evidence Return
96
111
 
97
- 每个实现者按 I-implement 与对应 Ticket 执行,写入 Evidence 并同步 Ticket/Map/Goal Plan。最后一个计划内 Implement 汇总 Gate、运行适用集成验证,并按完成合同关闭 change。
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
- 恢复时读取本 Goal Plan、当前 Ticket、最新 Evidence change 状态,从最后已验证事实继续。
130
-
131
- ### Reporting Format
140
+ 恢复时读取 Goal Plan、当前 Ticket、change workspace 状态和最新 Evidence;从最后通过的父分支 result 或待修正 implementation/source checkpoint 继续。
132
141
 
133
142
  ## Assumptions
134
143
 
135
- 仅记录低影响、可逆且有验证方式的假设。高影响假设存在时,`ready_for_execution` 必须为 `false`。
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
- 本文件定义所有 Goal Plan 都需要的 DAG、Wave、Gate、路径所有权、Evidence 返回和集成规则。它不建立 Lead/subagent 角色或 Agent 交付合同。
3
+ 本文件定义 DAG、Wave、Gate、路径所有权、Ticket workspace 策略、Evidence 返回和父分支集成队列。
4
4
 
5
5
  ## 1. DAG 与关键路径
6
6
 
7
- - 依赖权威来自 `<Path>{roots.state}/specdev/changes/{change}/ticket/{ticket-file}.md</Path>` frontmatter 的 `blocked_by`;
8
- - `<Path>{roots.state}/specdev/changes/{change}/tickets-map.md</Path>` 是投影,不是第二套依赖真相;
7
+ - 依赖权威来自 Ticket frontmatter 的 `blocked_by`;Tickets Map 是投影;
9
8
  - 计算根节点、扇出、汇合点、关键路径、共享合同 owner 和最终收缩点;
10
- - 依赖只表示真实开始条件,不表示偏好、人员交接或“最好先做”;
11
- - 无法独立保持可验证状态的迁移批次必须有隔离集成策略和最终集成 Gate
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
- - `ready: true`;
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 由可验证状态定义,不用“完成若干 Ticket”作为唯一条件。每个 Gate 必须写明业务或工程状态、开启条件、关闭证据、阻塞范围、owner/批准人和失败恢复。
31
-
32
- 常见 Gate 包括共享合同稳定、首条垂直路径通过、迁移完成、旧调用点归零、发布就绪和观察期结束。名称按项目语义自定义。
33
-
34
- ## 4. Shared path 与共享合同
20
+ Gate 用可验证状态定义,必须写明:工程/业务状态、开启条件、关闭证据、阻塞范围、Lead/批准人和失败恢复。常见 Gate 包括共享合同稳定、首条垂直路径、迁移完成、旧调用点归零、候选合并通过、发布就绪和观察期结束。
35
21
 
36
- 规则遵循 `<Path>{roots.workflows}/specdev/common/rules/path-ownership.md</Path>`:
22
+ ## 4. Shared path 与合同
37
23
 
38
- 1. 由专用 owner Ticket 或计划指定的唯一 owner 修改共享路径;
39
- 2. 形成可验证稳定基线;
40
- 3. 下游消费者在新基线上重新运行 preflight;
41
- 4. 才允许扇出或继续后续 Ticket;
42
- 5. 共享契约需要变化时暂停消费者并修订上游,不通过多个执行者同时修改解决。
24
+ 遵循 `<Path>{roots.workflows}/specdev/common/rules/path-ownership.md</Path>`:
43
25
 
44
- ## 5. Expand-contract
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
- 1. **expand**:新旧形式并存,既有调用者继续工作;
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
- 收缩不得仅以“所有迁移 Ticket 已完成”为依据。
36
+ required 模式同一 Ticket 在 candidate 验证失败后保留来源 worktree 并继续修正。新的 source commit 替换当前 `source_checkpoint`,旧 commit 继续由 Git/Evidence 可追溯。成功集成不自动清理 branch/worktree。
55
37
 
56
- ## 6. Ticket 执行、Evidence 与集成
38
+ ## 6. 父分支集成队列
57
39
 
58
- 每个计划 Ticket 必须写明开始条件、依赖 Evidence、项目路径合同、workspace 分配、适用 Gate、必跑验证、Evidence 目标和失败恢复。实际执行仍由 `<Path>{roots.workflows}/specdev/I-implement/I-implement.md</Path>` 与 Ticket 拥有,不在 Goal Plan 复制局部施工步骤。
40
+ required 模式 Lead 串行集成 Ready 候选:
59
41
 
60
- Current workspace Ticket 由该 workspace 的唯一写入 owner 顺序执行。隔离 Ticket 的创建、恢复和本地集成由 workspace addendum 与 dev-worktree Skill 管理;integration owner 是核心编排角色,不预设为 Lead。`single-session` 时通常映射为主会话,`lead-team` 时通常映射为 Lead。
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
- 1. 写入 `<Path>{roots.state}/specdev/changes/{change}/evidence/{ticket-id}.md</Path>`;
65
- 2. 同步 Ticket、Tickets Map、Goal Plan 和 change 状态;
66
- 3. 检查依赖、路径所有权、合同覆盖和适用 Gate;
67
- 4. 返回 Ticket 状态、Evidence 路径、代码引用、未验证项和恢复条件。
52
+ ## 7. Expand-contract
68
53
 
69
- 最后一个计划内 Implement `<Path>{roots.workflows}/specdev/P-goal-plan/completion-control.md</Path>` 汇总核心计划的 Gate Evidence。Lead Team 的候选交付验收由独立委派协议拥有;worktree Git 集成由角色中立的 workspace 协议拥有。
54
+ 标准顺序为 expand migrate observe contract verify。每批迁移独立 commit、按所选策略验证和父分支集成;收缩依据旧调用/数据/协议归零证据,不依据 Ticket 数量推断。
70
55
 
71
- **完成标准**:每个执行结果可追溯到代码状态和 Evidence;single-session Goal Plan 可以在不建立角色交付合同的情况下完整恢复和完成。
56
+ **完成标准**:每个 Ticket 从父基线、implementation/source commit、对应 integration 到 result 都可恢复;父分支只包含已通过所选门禁的 Ticket。
@@ -1,91 +1,69 @@
1
1
  # Goal Plan 规划模式与输入门禁
2
2
 
3
- 本文件由 `<Path>{roots.workflows}/specdev/P-goal-plan/P-goal-plan.md</Path>` 在上游验证和角色分支确认时加载。
4
-
5
- ## 1. 必需输入门禁
6
-
7
- - [ ] `<Path>{roots.state}/specdev/changes/{change}/spec.md</Path>` 设置 `ready_for_tickets: true`,或存在用户明确批准的等价权威目标。
8
- - [ ] `<Path>{roots.state}/specdev/changes/{change}/tickets-map.md</Path>` 与全部 Ticket 一致。
9
- - [ ] 所有计划执行的 Ticket 设置 `ready: true`。
10
- - [ ] Ticket ID、具体 `<Path>{roots.state}/specdev/changes/{change}/ticket/{ticket-file}.md</Path>` 和 Map 行一致。
11
- - [ ] `blocked_by` 引用存在,DAG 无环。
12
- - [ ] Spec 验收合同全部 covered,或 deferred 项有批准、原因和后续归属。
13
- - [ ] 可能并行的 Ticket 项目写路径不相交,或已有 shared owner 与排序方案。
14
- - [ ] Deep Ticket 具备迁移、兼容、监控、回滚、收缩条件和批准点。
15
- - [ ] Ticket 与 Spec、ADR、代码事实不存在未处理冲突。
16
- - [ ] 项目声明的验证命令真实存在且能观察目标行为;不可运行项有替代证据或明确 blocker。
17
- - [ ] 当前源码基线、工作区状态和外部合同版本已实测,而非使用浮动的“最新”描述。
18
-
19
- ## 2. 硬停止
20
-
21
- 出现以下任一情况时停止:
22
-
23
- - 任一计划内 Ticket 未 Ready;
24
- - DAG 有环、缺失引用或依赖仅代表偏好;
25
- - 合同 uncovered 且未批准 deferred;
26
- - 并行候选写路径相交且无 owner 或顺序;
27
- - Ticket 改写了 Spec 的外部行为、范围或验收;
28
- - Ticket 与 `<Path>{roots.state}/specdev/changes/{change}/ADR.md</Path>` 的已接受决定冲突;
29
- - Deep Ticket 缺少关键迁移或恢复信息;
30
- - 当前代码事实使 Ticket 的核心行为、接口或验证不可执行;
31
- - 必需外部合同或参考权威不可获得;
32
- - 已选择委派,但 Lead、checkpoint、可恢复 locator 或交付通道无法建立;
33
- - workspace strategy 为 worktree/mixed,但任一隔离 Ticket 缺少允许的 trigger、父分支、integration owner、可恢复 locator 或结束动作;
34
- - `lead-team + current` 中存在 `worker-write`,或 current workspace 出现多个项目/状态写入 owner;
35
- - 用户要求的远程或生产动作没有逐动作授权。
36
-
37
- 按 `<Path>{roots.workflows}/specdev/common/rules/artifact-contract.md</Path>` `<Path>{roots.workflows}/specdev/common/rules/deviation-control.md</Path>` 返回真正拥有该决策的工件。
38
-
39
- ## 3. 可组合规划模式
40
-
41
- - **coordination**:多 Wave、扇出/汇合或 shared path;重点是 DAG、owner、Evidence 返回、集成和状态同步。
42
- - **migration**:expand-contract、数据或协议迁移;重点是扩展、分批迁移、收缩条件、数据核对、监控和回滚。
43
- - **high-assurance**:安全、隐私、资金、数据完整性、法规或不可逆操作;重点是独立审查、人工批准、Evidence 完整性和失败恢复。
44
- - **reference-conformance**:外部合同、标准、官方实现或指定兼容行为;重点是来源版本、符合性矩阵和冲突裁决。
45
- - **release-coordination**:发布窗口、跨团队依赖、部署顺序或运营交接;重点是环境前置条件、Gate、观察期和回退。
46
-
47
- 模式可以组合。仅有线性低风险 Ticket 时不应为了形式生成重型 Goal Plan。
48
-
49
- ## 4. 锁定正交执行维度
50
-
51
- 规划模式描述为什么需要跨 Ticket 治理,不决定协作或工作区方式。每份新 Goal Plan 都必须分别记录:
52
-
53
- - `coordination_mode: single-session | lead-team`;
54
- - `workspace_strategy: current | worktree | mixed`。
55
-
56
- `single-session` 是默认协作方式:主会话拥有全部项目和 SpecDev 状态写入,只读探索、日志分析、测试观察和审查 Agent 可以返回结论,但不得成为第二写入者。只有用户明确要求或确认严格角色分派时才能使用 `lead-team`;不得根据 Ticket 数量、并行机会或平台能力静默启用。
57
-
58
- Workspace Ticket 判断,允许触发只有:`parallel-write`、`protect-local-state`、`disposable-experiment`、`background-resume`、`provider-requirement`、`user-requested`。每个触发必须引用实测事实;Agent Team、Ticket 数量、只读并行、顺序写入或泛化的“更安全”都不是触发条件。全部 Ticket 使用当前工作区时为 `current`;全部项目写入位于隔离 workspace 时为 `worktree`;两者并存时为 `mixed`。
59
-
60
- 四种组合均合法,但约束不同:
61
-
62
- | Coordination | Workspace | 写入约束 |
63
- |---|---|---|
64
- | single-session | current | 主会话唯一写入 |
65
- | single-session | worktree/mixed | 主会话管理并集成隔离写入 |
66
- | lead-team | current | Lead 唯一写入,Worker 只读 |
67
- | lead-team | worktree/mixed | `worker-write` 每项绑定独立 workspace,Lead 默认承担 integration owner |
68
-
69
- 选择 Lead Team 后固定 Lead、provider、repository、不可变 `base_sha` 或等价基线、源码交付方式、`max_correction_rounds` 和逐动作授权。选择 worktree/mixed 后固定每项的 trigger、workspace owner、integration owner、父分支、locator、来源 checkpoint 策略和结束动作。认证秘密和机器绝对路径不得进入 Goal Plan。
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
- 默认 3 个,最多 5 个。每个变体必须在布局、信息层级或主要操作入口上结构不同,不能只换颜色或文案。使用项目现有组件和样式系统,但不要共享会限制结构探索的布局抽象。
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、共享核心路径、多 Agent 或高事故半径。
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
- - 用户界面交互受影响时的 E2E Gate 与执行 owner;后续委派 Goal Plan 可以显式把该 Gate 转交 Lead
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、存在多 Agent 并行、Deep Ticket、迁移、共享契约、多个 Gate 或高风险发布。少量线性 Ready Ticket 可直接进入 `<Path>{roots.workflows}/specdev/I-implement/I-implement.md</Path>`。
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
- - [ ] 仅当用户界面交互受影响时定义 E2E 与当前执行 owner;Ticket 不预设 Lead/Worker,委派 Goal Plan 可以显式改由 Lead 集成。
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
- - [ ] 跨 Agent 路径所有权和集成 Gate 明确。
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
- 仅当用户界面交互受影响时增加 E2E 行并指定当前执行 owner。若后续 Goal Plan 含委派附录,再由该计划显式转交 Lead;Ticket 不预设 Lead/Worker 角色。
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
- - 最大并发来自 `<Path>{roots.state}/specdev/config.json</Path>`。
50
- - shared owner 为专用 Ticket 或明确的集成 owner;只有委派 Goal Plan 才使用 Lead 角色。
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
- - 并行写代码的 Ticket 使用独立 worktree;只读调查不需要。
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、owner、发布与恢复,并把结果投影回本 Map。
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
 
@@ -1,5 +1,5 @@
1
1
  {
2
- "schema_version": 4,
2
+ "schema_version": 5,
3
3
  "workflow": "specdev",
4
4
  "active": [],
5
5
  "archived": []
@@ -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
- - 隔离 Ticket/原型 worktree Skill:`<Path>{roots.workflows}/specdev/common/skills/dev-worktree/SKILL.md</Path>`,角色中立;由 change 的隔离事实触发,Agent Team 只影响 owner 映射
48
- - 委派 Agent 交付合同 Skill:`<Path>{roots.workflows}/specdev/common/skills/subagent-delivery/SKILL.md</Path>`,仅用户明确选择 lead-team 时调用
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
  ## 加载原则