@namewta/speculo 0.8.6 → 0.8.8

package/template/canonical/canonical-specdev-spec.md

@@ -365,15 +365,20 @@ SpecDev 通过分层工件避免同一决策被多个模型反复重做。每个
 | Ticket | `specdev/changes/{change}/ticket/NN-<ticket-name>.md` | 单一垂直切片的行为、决策、范围、路径所有权、执行路线和验证证据 | 跨 Ticket 里程碑治理 |
 | Tickets Map | `specdev/changes/{change}/tickets-map.md` | 依赖 DAG、合同覆盖、Ready 投影、并行候选和路径冲突 | 单 Ticket 的完整实现契约 |
 | Goal Plan | `specdev/changes/{change}/goal-plan.md` | 跨 Ticket 调度、Gate、共享所有权、迁移顺序、集成和偏差治理 | 复制 Ticket 全文 |
+| Implementation Map | `specdev/changes/{change}/implementation-map.md` | Ready 成员、组合 Ticket inventory、跨 change dependency/serialization 与 revision | 创建或改写子 Spec、Ticket 或实现细节 |
+| Implementation Plan | `specdev/changes/{change}/implementation-plan.md` | 父 Lead、全局 workspace/实现上限、frontier/Wave/locks/integration queue 和可恢复进度投影 | 改写子 change 权威或伪造完成 |
+| Implementation Orchestration Evidence | `specdev/changes/{change}/evidence/implementation-orchestration.md` | 成员完成、组合 Ticket 顺序/锁、repository integration、整体验证、漂移和残余风险 | 新产品/架构决定或单 Ticket Evidence 替代品 |
 | Evidence | `specdev/changes/{change}/evidence/T-NN.md` | 实际修改、命令、结果、验收映射、偏差、风险和提交引用 | 新的产品或架构决策 |
 | 代码审查 | `specdev/changes/{change}/reviews/CR-###.md` | 固定点、标准轴和规范轴 finding | 实施修复或合并两轴排名 |
-| 原型记录 | `specdev/changes/{change}/prototypes/{prototype-id}/record.md` | 一个问题、分支、资产、答案、promotion 和清理 | 生产实现或多个问题的计划 |
+| UI 设计包 | `specdev/changes/{change}/prototypes/{design-id}/design-system.md`、`specdev/changes/{change}/prototypes/{design-id}/comparison/` 与 `specdev/changes/{change}/prototypes/{design-id}/final/` | 项目 UI 证据、功能风格候选、逐层用户决定、设计 token、交互合同和可运行 HTML/CSS/JS 投影 | 生产 UI 实现或替用户确认高影响偏好 |
 | Stakeholder 问卷 | `specdev/changes/{change}/questionnaires/{slug}.md` | 第三方原始回答和恢复条件 | 未经转录确认的产品/架构决定 |
 | Wayfinder 地图 | `specdev/changes/{change}/wayfinder-map.md` | 目的地、说明、已关闭决策索引、战争迷雾和范围之外 | 开放 Ticket 正文或答案详情 |
 | Wayfinder Ticket | `specdev/changes/{change}/investigation/{investigation-id}.md` | 一个可精确陈述的问题、类型、阻塞和关闭状态 | 解决方案评论或交付目标 |
 | Wayfinder solution comment | `specdev/changes/{change}/investigation/comments/{investigation-id}/NN-solution.md` | Ticket 的答案、结果事实和资产指针 | 地图索引或产品实现 |
 | 架构审查 | `specdev/changes/{change}/architecture-review.md` 与 `specdev/changes/{change}/architecture-review.html` | 深化候选、证据、可视化、选择和访谈状态 | 未经用户选择的执行契约 |
 
+UI 设计包中的 `{design-id}` 由 P-prototype 分配为当前 change 内最小未占用的 `UI-NNN`；设计系统文档是唯一设计权威，comparison 与 final 不建立第二套规则。
+
 Change CONTEXT/ADR 是 active change 内的执行权威，不是 workflow 级永久知识。G 和其他设计/执行 Works 只读 `specdev/context/` 与 `specdev/adr/`；只有 A 在 change 完成、实现证据验证、毕业评估和用户确认后才能写入永久 namespace。未毕业内容随归档 change 保留，不能从 change 工件消失。
 
 ## 2. 权威顺序
@@ -386,8 +391,9 @@ Change CONTEXT/ADR 是 active change 内的执行权威，不是 workflow 级永
 4. 当前外部行为权威：`specdev/changes/{change}/spec.md`；
 5. 当前 Ticket 契约：`specdev/changes/{change}/ticket/NN-<ticket-name>.md`；
 6. 当前跨 Ticket 编排：`specdev/changes/{change}/goal-plan.md`；
-7. 当前代码与运行事实；
-8. 旧计划、旧日志和未经确认的推断。
+7. 若当前 change 属于父实现 change，父 Implementation Map 对组合 Ticket dependency/serialization 具有权威，父 Implementation Plan 拥有全局 workspace、frontier 与 integration queue；
+8. 当前代码与运行事实；
+9. 旧计划、旧日志和未经确认的推断。
 
 当前 change 决定与永久知识冲突时，必须在 LOG/ADR 中显式说明替代关系；它只约束当前 change，直到 A 决定是否提升并更新永久版本。
 
@@ -532,6 +538,8 @@ required Ticket Done 必须有 source commit、通过 candidate、父分支 resu
 
 Direct Spec Evidence 至少包含：用户批准与轻量合同、Lead、实施前/最终 checkpoint、实际路径、定向/回归/E2E 命令及环境、验收映射、未运行项、偏差、残余风险和提交授权状态。
 
+父实现 change 的 Implementation Orchestration Evidence 不能替代子 Evidence。它至少记录最终 Map revision、全部成员最终状态和子证据指针、dependency/serialization 实际顺序、跨 change 合同检查、aggregate 命令/环境/结果、stale candidate 处理、偏差和残余风险。任何成员未 completed 或整体验证未通过时不得形成父完成证据。
+
 </evidence-and-verification>
 
 <deviation-control>
@@ -559,6 +567,7 @@ Direct Spec Evidence 至少包含：用户批准与轻量合同、Lead、实施
 - 发现新的安全、数据、兼容、性能或迁移风险；
 - 依赖、合同或外部参考权威已变化；
 - 实际行为将与 Spec 或 ADR 不一致。
+- 父 Implementation Map 的成员、组合 Ticket、dependency、serialization 或 revision 已与子状态、路径或 Git 事实不一致。
 
 ## 3. 偏差记录
 
@@ -579,6 +588,7 @@ Direct Spec Evidence 至少包含：用户批准与轻量合同、Lead、实施
 - 未批准的 ticket、spec、architecture 或 release 偏差不得继续实现。
 - 不得通过扩大 `writable_paths`、删除测试、降低断言或把风险改写成“已知限制”来绕过停止。
 - 偏差影响并行执行、source checkpoint 或 candidate 集成时，Lead 必须暂停受影响 Wave，重新计算路径所有权、依赖、Gate 与父分支顺序；任何 subagent 都不能自行改写上层合同。
+- 偏差跨越多个成员时，父 Lead 先递增 Implementation Map revision，再重算 Implementation Plan；旧派单和 candidate 全部标记 stale。
 
 </deviation-control>
 
@@ -663,8 +673,8 @@ Direct Spec Evidence 至少包含：用户批准与轻量合同、Lead、实施
     "default_depth": "standard",
     "require_ready_gate": true,
     "require_evidence": true,
-    "ui_prototype_default_variants": 3,
-    "ui_prototype_max_variants": 5
+    "ui_design_default_candidates": 3,
+    "ui_design_max_candidates": 4
   }
 }
 ```
@@ -716,19 +726,19 @@ Direct Spec Evidence 至少包含：用户批准与轻量合同、Lead、实施
     },
     "planning": {
       "type": "object",
-      "required": ["default_depth", "require_ready_gate", "require_evidence", "ui_prototype_default_variants", "ui_prototype_max_variants"],
+      "required": ["default_depth", "require_ready_gate", "require_evidence", "ui_design_default_candidates", "ui_design_max_candidates"],
       "properties": {
         "default_depth": {"enum": ["lite", "standard", "deep"]},
         "require_ready_gate": {"type": "boolean"},
         "require_evidence": {"type": "boolean"},
-        "ui_prototype_default_variants": {"type": "integer", "minimum": 1},
-        "ui_prototype_max_variants": {"type": "integer", "minimum": 1}
+        "ui_design_default_candidates": {"type": "integer", "minimum": 2, "maximum": 4},
+        "ui_design_max_candidates": {"type": "integer", "minimum": 2, "maximum": 4}
       },
       "additionalProperties": true
     }
   },
   "allOf": [{
-    "$comment": "ui_prototype_default_variants <= ui_prototype_max_variants is enforced by validate-specdev.mjs because JSON Schema cannot compare sibling numeric values."
+    "$comment": "ui_design_default_candidates <= ui_design_max_candidates is enforced by validate-specdev.mjs because JSON Schema cannot compare sibling numeric values."
   }],
   "additionalProperties": false
 }

package/template/canonical/canonical-specdev-tickets.md

@@ -652,15 +652,20 @@ SpecDev 通过分层工件避免同一决策被多个模型反复重做。每个
 | Ticket | `specdev/changes/{change}/ticket/NN-<ticket-name>.md` | 单一垂直切片的行为、决策、范围、路径所有权、执行路线和验证证据 | 跨 Ticket 里程碑治理 |
 | Tickets Map | `specdev/changes/{change}/tickets-map.md` | 依赖 DAG、合同覆盖、Ready 投影、并行候选和路径冲突 | 单 Ticket 的完整实现契约 |
 | Goal Plan | `specdev/changes/{change}/goal-plan.md` | 跨 Ticket 调度、Gate、共享所有权、迁移顺序、集成和偏差治理 | 复制 Ticket 全文 |
+| Implementation Map | `specdev/changes/{change}/implementation-map.md` | Ready 成员、组合 Ticket inventory、跨 change dependency/serialization 与 revision | 创建或改写子 Spec、Ticket 或实现细节 |
+| Implementation Plan | `specdev/changes/{change}/implementation-plan.md` | 父 Lead、全局 workspace/实现上限、frontier/Wave/locks/integration queue 和可恢复进度投影 | 改写子 change 权威或伪造完成 |
+| Implementation Orchestration Evidence | `specdev/changes/{change}/evidence/implementation-orchestration.md` | 成员完成、组合 Ticket 顺序/锁、repository integration、整体验证、漂移和残余风险 | 新产品/架构决定或单 Ticket Evidence 替代品 |
 | Evidence | `specdev/changes/{change}/evidence/T-NN.md` | 实际修改、命令、结果、验收映射、偏差、风险和提交引用 | 新的产品或架构决策 |
 | 代码审查 | `specdev/changes/{change}/reviews/CR-###.md` | 固定点、标准轴和规范轴 finding | 实施修复或合并两轴排名 |
-| 原型记录 | `specdev/changes/{change}/prototypes/{prototype-id}/record.md` | 一个问题、分支、资产、答案、promotion 和清理 | 生产实现或多个问题的计划 |
+| UI 设计包 | `specdev/changes/{change}/prototypes/{design-id}/design-system.md`、`specdev/changes/{change}/prototypes/{design-id}/comparison/` 与 `specdev/changes/{change}/prototypes/{design-id}/final/` | 项目 UI 证据、功能风格候选、逐层用户决定、设计 token、交互合同和可运行 HTML/CSS/JS 投影 | 生产 UI 实现或替用户确认高影响偏好 |
 | Stakeholder 问卷 | `specdev/changes/{change}/questionnaires/{slug}.md` | 第三方原始回答和恢复条件 | 未经转录确认的产品/架构决定 |
 | Wayfinder 地图 | `specdev/changes/{change}/wayfinder-map.md` | 目的地、说明、已关闭决策索引、战争迷雾和范围之外 | 开放 Ticket 正文或答案详情 |
 | Wayfinder Ticket | `specdev/changes/{change}/investigation/{investigation-id}.md` | 一个可精确陈述的问题、类型、阻塞和关闭状态 | 解决方案评论或交付目标 |
 | Wayfinder solution comment | `specdev/changes/{change}/investigation/comments/{investigation-id}/NN-solution.md` | Ticket 的答案、结果事实和资产指针 | 地图索引或产品实现 |
 | 架构审查 | `specdev/changes/{change}/architecture-review.md` 与 `specdev/changes/{change}/architecture-review.html` | 深化候选、证据、可视化、选择和访谈状态 | 未经用户选择的执行契约 |
 
+UI 设计包中的 `{design-id}` 由 P-prototype 分配为当前 change 内最小未占用的 `UI-NNN`；设计系统文档是唯一设计权威，comparison 与 final 不建立第二套规则。
+
 Change CONTEXT/ADR 是 active change 内的执行权威，不是 workflow 级永久知识。G 和其他设计/执行 Works 只读 `specdev/context/` 与 `specdev/adr/`；只有 A 在 change 完成、实现证据验证、毕业评估和用户确认后才能写入永久 namespace。未毕业内容随归档 change 保留，不能从 change 工件消失。
 
 ## 2. 权威顺序
@@ -673,8 +678,9 @@ Change CONTEXT/ADR 是 active change 内的执行权威，不是 workflow 级永
 4. 当前外部行为权威：`specdev/changes/{change}/spec.md`；
 5. 当前 Ticket 契约：`specdev/changes/{change}/ticket/NN-<ticket-name>.md`；
 6. 当前跨 Ticket 编排：`specdev/changes/{change}/goal-plan.md`；
-7. 当前代码与运行事实；
-8. 旧计划、旧日志和未经确认的推断。
+7. 若当前 change 属于父实现 change，父 Implementation Map 对组合 Ticket dependency/serialization 具有权威，父 Implementation Plan 拥有全局 workspace、frontier 与 integration queue；
+8. 当前代码与运行事实；
+9. 旧计划、旧日志和未经确认的推断。
 
 当前 change 决定与永久知识冲突时，必须在 LOG/ADR 中显式说明替代关系；它只约束当前 change，直到 A 决定是否提升并更新永久版本。
 
@@ -799,7 +805,9 @@ workspace/implementation owner 可以是 Lead 或动态 implementation subagent
 
 required 模式 implementation subagent 上限取 Goal Plan、config 和平台能力共同约束，Lead 不计入。current 模式保持单 writer 串行安全不变量，Ticket 严格串行。review/research/test-observation agent 不设置 SpecDev 数字上限，但 Lead 必须避免重复工作与可变环境争用。
 
-**完成标准**：每个项目写入映射到唯一 Ticket、owner 和来源 worktree；shared 与父分支写入 owner 唯一。
+子 change 属于父 Implementation Map 时，再取父 Implementation Plan 的全局 implementation subagent 上限与 workspace 策略；该上限跨全部成员合计。无 dependency 的组合 Ready Tickets 若 writable/shared paths 重叠，也必须在父 Map 建立 serialization。相同 repository/ref 的 parent integration 严格串行；一次父 HEAD 推进会使其他成员旧 candidate 失效。
+
+**完成标准**：每个项目写入映射到唯一 change、Ticket、owner 和来源 worktree；shared 与父分支写入 owner 唯一。
 
 </path-ownership>
 
@@ -857,6 +865,8 @@ required Ticket Done 必须有 source commit、通过 candidate、父分支 resu
 
 Direct Spec Evidence 至少包含：用户批准与轻量合同、Lead、实施前/最终 checkpoint、实际路径、定向/回归/E2E 命令及环境、验收映射、未运行项、偏差、残余风险和提交授权状态。
 
+父实现 change 的 Implementation Orchestration Evidence 不能替代子 Evidence。它至少记录最终 Map revision、全部成员最终状态和子证据指针、dependency/serialization 实际顺序、跨 change 合同检查、aggregate 命令/环境/结果、stale candidate 处理、偏差和残余风险。任何成员未 completed 或整体验证未通过时不得形成父完成证据。
+
 </evidence-and-verification>
 
 <deviation-control>
@@ -884,6 +894,7 @@ Direct Spec Evidence 至少包含：用户批准与轻量合同、Lead、实施
 - 发现新的安全、数据、兼容、性能或迁移风险；
 - 依赖、合同或外部参考权威已变化；
 - 实际行为将与 Spec 或 ADR 不一致。
+- 父 Implementation Map 的成员、组合 Ticket、dependency、serialization 或 revision 已与子状态、路径或 Git 事实不一致。
 
 ## 3. 偏差记录
 
@@ -904,9 +915,42 @@ Direct Spec Evidence 至少包含：用户批准与轻量合同、Lead、实施
 - 未批准的 ticket、spec、architecture 或 release 偏差不得继续实现。
 - 不得通过扩大 `writable_paths`、删除测试、降低断言或把风险改写成“已知限制”来绕过停止。
 - 偏差影响并行执行、source checkpoint 或 candidate 集成时，Lead 必须暂停受影响 Wave，重新计算路径所有权、依赖、Gate 与父分支顺序；任何 subagent 都不能自行改写上层合同。
+- 偏差跨越多个成员时，父 Lead 先递增 Implementation Map revision，再重算 Implementation Plan；旧派单和 candidate 全部标记 stale。
 
 </deviation-control>
 
+<parent-implementation-orchestration>
+
+# Parent Implementation Orchestration
+
+本规则只约束 Ready Spec/Tickets 之后的跨 change 实现，供 O-orchestrate-implementation、I-implement 与 A-archive-and-consolidate 读取。
+
+## 输入边界
+
+父实现 change 只能在所有成员通过 Ready Spec/Tickets 输入门后创建。父 Work 不调用或代行 Triage、Grill、Wayfinder、Spec、Tickets 或普通 Goal Plan；输入不足时不留下父状态或父工件。
+
+## 权威边界
+
+- 父 Implementation Map：成员、组合 Ticket inventory、跨 change dependency/serialization 与 revision 的唯一权威投影。
+- 父 Implementation Plan：Lead、全局 workspace 策略、implementation agent/integration attempt 上限、frontier、Wave、locks 和 integration queue 的唯一权威。
+- 子 change：自己的 Spec、Ticket、内部 Goal Gate、workspace、Git、Evidence 和完成状态的唯一权威。
+
+父工件不得复制完整子合同。子权威变化时停止旧派单、递增父 Map revision 并重算父 Plan；不能从旧父投影覆盖子工件。
+
+## 唯一所有权
+
+一个 active/blocked 子 change 最多属于一个未完成父实现 change。v1 不支持父实现 change 嵌套。父 Lead 是父工件、全部 SpecDev 状态写入、E2E、repository/ref integration queue 和父分支推进的唯一 owner；implementation agent 只写授权项目 workspace。
+
+## I-implement 调用
+
+父 Plan 可以替代缺失的子 Goal Plan 提供 workspace/integration 策略和全局执行边界。子 Goal Plan 存在时继续拥有子 change 内 Gate，但不得与父策略冲突。I-implement 完成或阻塞一个组合 Ticket 后返回父 O Work，不要求用户重新激活 change。
+
+## 归档与完成
+
+未完成父实现 change 的成员不得归档。成员满足普通 change completion 时可以先 completed，但不自动归档。父 change 只有全部成员 completed、Map/Plan completed、aggregate Evidence 完整且无 active dispatch/candidate/lock 后才能 completed；完成或归档均不自动级联。
+
+</parent-implementation-orchestration>
+
 <research>
 
 # SpecDev Research
@@ -966,12 +1010,12 @@ Direct Spec Evidence 至少包含：用户批准与轻量合同、Lead、实施
 
 # Dev Worktree
 
-本 Skill 由 T-tickets/P-goal-plan/I-implement 和 P-prototype 复用。`purpose=ticket` 仅在 Goal Plan 选择 `required` 时使用完整 source → candidate → parent 状态机；`current` Ticket 不调用本 Skill。`purpose=prototype` 只使用调用方批准的临时生命周期。
+本 Skill 由 T-tickets、P-goal-plan 和 I-implement 复用。仅在 Goal Plan 选择 `required` 时使用完整 source → candidate → parent 状态机；`current` Ticket 不调用本 Skill。
 
 ## 输入
 
 - `operation=create | restore | finalize | remove`；
-- `purpose=ticket | prototype`；
+- `purpose=ticket`；
 - repository、父分支、`base_sha`、branch、portable workspace locator；
 - workspace、implementation 和 integration owner；
 - 允许动作、路径合同、验证合同、调用方状态记录位置。
@@ -1000,7 +1044,7 @@ implementation owner 只在来源 worktree 修改授权项目路径，运行 Tic
 
 ## 4. 移除
 
-`operation=remove` 先验证 Ticket 已 `integrated` 或 prototype 已结束、目标 worktree clean、checkpoint 可恢复且删除目标精确。只有明确 cleanup 授权时删除来源 branch/worktree；强制删除需要单独确认。删除后重读 `git worktree list` 与 refs，并只把调用方生命周期状态更新为 `removed`；`base_sha`、source checkpoint、candidate/result、验证、E2E 与 Evidence 字段必须原样保留。
+`operation=remove` 先验证 Ticket 已 `integrated`、目标 worktree clean、checkpoint 可恢复且删除目标精确。只有明确 cleanup 授权时删除来源 branch/worktree；强制删除需要单独确认。删除后重读 `git worktree list` 与 refs，并只把调用方生命周期状态更新为 `removed`；`base_sha`、source checkpoint、candidate/result、验证、E2E 与 Evidence 字段必须原样保留。
 
 **完成标准**：只删除精确授权目标；失败保留现场与恢复命令。
 
@@ -1026,14 +1070,12 @@ implementation owner 只在来源 worktree 修改授权项目路径，运行 Tic
 - `specdev-worktree/` 已由 Speculo init 加入项目 `.gitignore`；
 - 目标 branch/worktree 不覆盖现有用户 workspace，路径合同无冲突。
 
-Prototype 只要求调用方已记录本次临时 branch/worktree 授权、问题、owner、locator 和清理策略；它不写 Ticket worktree 状态。
-
 ## 创建 Ticket 来源 worktree
 
 1. 重读父分支 HEAD、工作树、现有 worktrees 与 refs；父 HEAD 与计划基线不一致时由 Lead决定更新 `base_sha` 或阻塞；
 2. 固定 branch `speculo/<change>/<ticket-id>` 与 locator `specdev-worktree/<ticket-id>`；
 3. 确认目标 branch/path 不存在，或其实际记录精确匹配当前 Ticket；
-4. 从 `base_sha` 创建 Git worktree，不复用其他 Ticket/原型目录；
+4. 从 `base_sha` 创建 Git worktree，不复用其他 Ticket 目录；
 5. 在来源 worktree 读取项目 Agent 指令、依赖、构建与路径合同；
 6. 安装实际需要的依赖，运行最小非 E2E 基线；
 7. Lead 写入 `specdev/changes/{change}/.status.json`，状态为 `active`。
@@ -1194,8 +1236,8 @@ Prototype 只要求调用方已记录本次临时 branch/worktree 授权、问
     "default_depth": "standard",
     "require_ready_gate": true,
     "require_evidence": true,
-    "ui_prototype_default_variants": 3,
-    "ui_prototype_max_variants": 5
+    "ui_design_default_candidates": 3,
+    "ui_design_max_candidates": 4
   }
 }
 ```
@@ -1247,19 +1289,19 @@ Prototype 只要求调用方已记录本次临时 branch/worktree 授权、问
     },
     "planning": {
       "type": "object",
-      "required": ["default_depth", "require_ready_gate", "require_evidence", "ui_prototype_default_variants", "ui_prototype_max_variants"],
+      "required": ["default_depth", "require_ready_gate", "require_evidence", "ui_design_default_candidates", "ui_design_max_candidates"],
       "properties": {
         "default_depth": {"enum": ["lite", "standard", "deep"]},
         "require_ready_gate": {"type": "boolean"},
         "require_evidence": {"type": "boolean"},
-        "ui_prototype_default_variants": {"type": "integer", "minimum": 1},
-        "ui_prototype_max_variants": {"type": "integer", "minimum": 1}
+        "ui_design_default_candidates": {"type": "integer", "minimum": 2, "maximum": 4},
+        "ui_design_max_candidates": {"type": "integer", "minimum": 2, "maximum": 4}
       },
       "additionalProperties": true
     }
   },
   "allOf": [{
-    "$comment": "ui_prototype_default_variants <= ui_prototype_max_variants is enforced by validate-specdev.mjs because JSON Schema cannot compare sibling numeric values."
+    "$comment": "ui_design_default_candidates <= ui_design_max_candidates is enforced by validate-specdev.mjs because JSON Schema cannot compare sibling numeric values."
   }],
   "additionalProperties": false
 }

package/template/canonical/canonical-specdev-wayfinder.md

@@ -36,7 +36,7 @@ Wayfinder 默认进行**规划**：每个 Ticket 解决一个决策，当地图
 - 地图：`specdev/changes/{change}/wayfinder-map.md`
 - 子 Tickets：`specdev/changes/{change}/investigation/`
 - solution comments：`specdev/changes/{change}/investigation/comments/`
-- assignment registry：`specdev/status.json` 的 `claimed_investigations`
+- assignment registry：`specdev/changes/{change}/.status.json` 的 `claimed_investigations`
 
 每次绘制或遍历前加载 下方 `<local-tracker-contract>` 标签。Ticket 和地图模板：
 
@@ -49,7 +49,7 @@ Wayfinder 默认进行**规划**：每个 Ticket 解决一个决策，当地图
 每个 Ticket 要么是 **HITL**，与一个代表自己发言的人类一起工作；要么是 **AFK**，由 Agent 独立驱动。HITL Ticket 只能通过实时交流解决，Agent 绝不代替人类一方发言。
 
 - **Research（AFK）**：阅读文档、第三方 API 或知识库等资源，揭示某个决策等待的事实。调用 下方 `<research>` 标签。当需要当前工作目录之外的知识时使用。
-- **Prototype（HITL）**：调用 “原型阶段” 回答一个 UI/逻辑问题，并把 record、临时 branch/worktree 和运行 URL 链接为 solution comment 资产；P 不实现目的地。
+- **Prototype（HITL）**：调用 “原型阶段” 检测项目 UI、比较功能风格候选并逐步确认设计方向，把 `specdev/changes/{change}/prototypes/{design-id}/design-system.md` 与 comparison locator 链接为 solution comment 资产；`{design-id}` 使用 P 返回的 `UI-NNN`，P 不实现目的地。
 - **Grilling（HITL）**：对话。调用 “设计访谈能力” 的 grilling 与 domain-modeling 能力，但本会话只关闭当前 Wayfinder Ticket。
 - **Task（HITL 或 AFK）**：在决策做出前必须完成的手动工作。它通过为决策解除阻塞赢得位置，不以交付目的地为目标。Agent 能独立驱动时使用 AFK，否则给人类精确清单。
 
@@ -211,7 +211,7 @@ status: active
 | 子 issue | `specdev/changes/{change}/investigation/{investigation-id}.md` |
 | label | Ticket frontmatter 的 `wayfinder:research|prototype|grilling|task` |
 | 阻塞关系 | Ticket frontmatter 的 `blocked_by` |
-| assignment | `specdev/status.json` 当前 change 的 `claimed_investigations` |
+| assignment | `specdev/changes/{change}/.status.json` 的 `claimed_investigations` |
 | solution comment | `specdev/changes/{change}/investigation/comments/{investigation-id}/NN-solution.md` |
 | 关闭 issue | Ticket frontmatter 的 `status: closed` 与 `resolution` |
 
@@ -227,9 +227,9 @@ status: active
 
 ## 原子领取
 
-开始任何工作前，重读全局状态并原子写入 `id`、`owner`、可选 `session` 和 `claimed_at`。已领取则选择下一前沿 Ticket。写回结果前再次重读；完成、释放或取消时删除 claim。
+开始任何工作前，重读当前 change 状态并原子写入 `id`、`owner`、可选 `session` 和 `claimed_at`。已领取则选择下一前沿 Ticket。写回结果前再次重读；完成、释放或取消时删除 claim。
 
-Ticket 文件不重复保存 assignee，地图不重复保存 claim。全局 assignment registry 是领取的单一事实源。
+Ticket 文件不重复保存 assignee，地图不重复保存 claim。change assignment registry 是领取的单一事实源。
 
 ## 解决方案评论
 
@@ -346,8 +346,8 @@ resolution: answered
     "default_depth": "standard",
     "require_ready_gate": true,
     "require_evidence": true,
-    "ui_prototype_default_variants": 3,
-    "ui_prototype_max_variants": 5
+    "ui_design_default_candidates": 3,
+    "ui_design_max_candidates": 4
   }
 }
 ```
@@ -399,19 +399,19 @@ resolution: answered
     },
     "planning": {
       "type": "object",
-      "required": ["default_depth", "require_ready_gate", "require_evidence", "ui_prototype_default_variants", "ui_prototype_max_variants"],
+      "required": ["default_depth", "require_ready_gate", "require_evidence", "ui_design_default_candidates", "ui_design_max_candidates"],
       "properties": {
         "default_depth": {"enum": ["lite", "standard", "deep"]},
         "require_ready_gate": {"type": "boolean"},
         "require_evidence": {"type": "boolean"},
-        "ui_prototype_default_variants": {"type": "integer", "minimum": 1},
-        "ui_prototype_max_variants": {"type": "integer", "minimum": 1}
+        "ui_design_default_candidates": {"type": "integer", "minimum": 2, "maximum": 4},
+        "ui_design_max_candidates": {"type": "integer", "minimum": 2, "maximum": 4}
       },
       "additionalProperties": true
     }
   },
   "allOf": [{
-    "$comment": "ui_prototype_default_variants <= ui_prototype_max_variants is enforced by validate-specdev.mjs because JSON Schema cannot compare sibling numeric values."
+    "$comment": "ui_design_default_candidates <= ui_design_max_candidates is enforced by validate-specdev.mjs because JSON Schema cannot compare sibling numeric values."
   }],
   "additionalProperties": false
 }

package/template/workflows/specdev/A-archive-and-consolidate/A-archive-and-consolidate.md

@@ -23,7 +23,7 @@ A 是 SpecDev 的归档 wrapper：它拥有模式选择、SpecDev 完成门和
 ## Archive 模式
 
 1. 读取全局/change 状态、Ticket、Map、Goal Plan、Evidence、ADR、CONTEXT、LOG、triage 和项目验证事实。
-2. 加载 `<Path>{roots.workflows}/specdev/common/rules/change-completion.md</Path>`，确认 `change_status: completed`、完成 owner 已写入时间和证据、无 blocker/deviation。
+2. 加载 `<Path>{roots.workflows}/specdev/common/rules/change-completion.md</Path>` 与 `<Path>{roots.workflows}/specdev/common/rules/parent-implementation-orchestration.md</Path>`，确认 `change_status: completed`、完成 owner 已写入时间和证据、无 blocker/deviation；若该 change 是未完成父实现 change 的成员则停止，若其自身是父实现 change 则还需所有成员与 aggregate Evidence 完成。
 3. 检查 `<Path>{roots.state}/specdev/changes/{change}/triage.md</Path>` 的 `external_action`：`pending-close` 或 `close-failed` 返回 `<Path>{roots.workflows}/specdev/T-triage/T-triage.md</Path>`；只有 `closed | waived | not-applicable` 继续。
 4. 调用 `<Path>{roots.skills}/archive-and-consolidate/SKILL.md</Path>` 的 `archive-single + dry-run`，传入已解析 workflow/state/changes/archive/knowledge roots。展示完整移动、提升和清理计划。
 5. 只有用户明确批准该计划后调用 `confirmed`。移动、知识写入和清理均使用计划内路径；计划后出现 drift 时停止。

package/template/workflows/specdev/I-implement/I-implement.md

@@ -11,13 +11,15 @@ keywords: [实现, TDD, Lead, subagent, worktree, current workspace, direct-pare
 
 > 激活本 Work 后，先读取 `<Path>{roots.workflows}/specdev/README.md</Path>`，再执行本入口。
 
-本 work 保留模块设计检查、design-it-twice、TDD 红绿循环、双轴审查和证据治理。Ticket 模式按 Goal Plan 的 `ticket_workspace_policy` 选择 current workspace 串行直接父分支或独立 worktree candidate-merge；Lead 根据实际情况自行实现或动态派单。
+本 work 保留模块设计检查、design-it-twice、TDD 红绿循环、双轴审查和证据治理。Ticket 模式按子 Goal Plan 或父 Implementation Plan 的 `ticket_workspace_policy` 选择 current workspace 串行直接父分支或独立 worktree candidate-merge；Lead 根据实际情况自行实现或动态派单。
+
+若当前 change 是未完成父 Implementation Map 的成员，必须读取 `<Path>{roots.workflows}/specdev/common/rules/parent-implementation-orchestration.md</Path>`、父 Map 与父 Plan。父 Plan 提供跨 change dependency/serialization、全局 workspace 策略、组合派单标识、implementation agent cap 和 integration queue；子 Goal Plan 只能增加子内 Gate，不能放宽或冲突。
 
 ## 执行模式
 
 ### Ticket 模式（默认）
 
-读取 Ready Ticket、Tickets Map 和可选 Goal Plan。存在 Goal Plan 时使用其中的 Lead 与 workspace 策略；没有 Goal Plan 时，当前主会话作为该 Ticket 的 Lead，并按 Direct Spec 规则执行，不推断 worktree 策略。`required` 模式每个 Ticket 建立独立 worktree；`current` 模式所有 Ticket 严格串行，使用当前分支和当前 workspace。
+读取 Ready Ticket、Tickets Map、可选子 Goal Plan 和可选父 Implementation Plan。存在父 Plan 时使用其 Lead、workspace/integration 策略和全局门，即使子 Goal Plan 不存在也可以执行；两者都存在时必须策略一致。没有父 Plan 时沿用子 Goal Plan；两者都不存在时，当前主会话作为该 Ticket 的 Lead，并按 Direct Spec 规则执行，不推断 worktree 策略。`required` 模式每个 Ticket 建立独立 worktree；`current` 模式所有受同一计划约束的 Ticket 严格串行，使用当前分支和当前 workspace。
 
 ### Direct Spec 模式
 
@@ -30,7 +32,7 @@ keywords: [实现, TDD, Lead, subagent, worktree, current workspace, direct-pare
 - 当前 Spec：`<Path>{roots.state}/specdev/changes/{change}/spec.md</Path>`
 - 项目配置：`<Path>{roots.state}/specdev/config.json</Path>`
 
-Ticket 模式还必须读取当前 Ticket `<Path>{roots.state}/specdev/changes/{change}/ticket/{ticket-file}.md</Path>` 与 `<Path>{roots.state}/specdev/changes/{change}/tickets-map.md</Path>`；存在 `<Path>{roots.state}/specdev/changes/{change}/goal-plan.md</Path>` 时必须读取。Direct Spec 模式必须读取用户对轻量执行合同和直接实现的明确批准。
+Ticket 模式还必须读取当前 Ticket `<Path>{roots.state}/specdev/changes/{change}/ticket/{ticket-file}.md</Path>` 与 `<Path>{roots.state}/specdev/changes/{change}/tickets-map.md</Path>`；存在 `<Path>{roots.state}/specdev/changes/{change}/goal-plan.md</Path>` 时必须读取。若当前 change 被父 Implementation Map 声明，还必须读取该父 change 的 Map/Plan。Direct Spec 模式必须读取用户对轻量执行合同和直接实现的明确批准。
 
 按存在情况读取：
 
@@ -54,7 +56,7 @@ Git 已处于 merge/rebase 冲突时，先加载 `<Path>{roots.workflows}/specde
 Ticket 模式：
 
 1. 验证 Ready、依赖 Evidence、Spec/ADR/Goal Plan、一致性、路径 owner 和验证接缝；
-2. 确认 Goal Plan schema v6（若存在）、Lead、动态 implementation/integration 上限与授权；
+2. 确认子 Goal Plan schema v6（若存在）与父 Implementation Plan schema v1（若存在）、唯一 Lead、workspace 策略、动态 implementation/integration 上限与授权；
 3. `required` 模式以 `purpose=ticket, operation=create|restore` 调用 `<Path>{roots.workflows}/specdev/common/skills/dev-worktree/SKILL.md</Path>`；`current` 模式读取当前 branch、HEAD、dirty 状态并确认没有其他 Ticket implementation writer；
 4. Lead 把 Ticket 设为 `in_progress`；`required` 模式将 change worktree 记录设为 `active`，`current` 模式建立 current workspace 执行记录；
 5. 当前代码使合同失效时停止并返回对应上游 owner。
@@ -67,7 +69,8 @@ Direct Spec 模式验证用户批准、轻量合同和 current workspace 唯一
 
 Ticket 模式下，Lead 根据 Ticket 独立性、路径冲突、上下文、风险和平台能力决定。派单时以 `operation=dispatch` 调用 `<Path>{roots.workflows}/specdev/common/skills/subagent-delivery/SKILL.md</Path>`。`current` 模式仍可派遣一个 implementation subagent 写当前 workspace，但必须等待其返回、Lead 验收并形成 commit 后才进入下一个 Ticket；`required` 模式 implementation subagent 绑定独立 Ticket worktree。Direct Spec 模式由 Lead 作为 current workspace 唯一写入 owner，不派遣 implementation subagent 写入。
 
-- implementation subagent 同时取 Goal Plan/config/平台能力的共同上限；current 模式保持单 writer 串行安全不变量；Lead 不计入；
+- implementation subagent 同时取适用子 Goal Plan、父 Implementation Plan、config 和平台能力的共同上限；current 模式保持单 writer 串行安全不变量；Lead 不计入；
+- 父实现编排存在时，派单与返回都使用 `<member-change>::<ticket-id>`，并占用父 Plan 的 task/serialization/integration slot；
 - review/research/test-observation agent 不设置 SpecDev 数字上限，但保持只读；
 - implementation Packet 按策略绑定唯一 Ticket workspace 或 current workspace、checkpoint、路径、非 E2E 检查与 commit 返回；
 - subagent 不写 SpecDev 工件、Evidence、父分支或 E2E 结果；
@@ -146,6 +149,8 @@ Ticket 正常状态：`ready → in_progress → review → done`。`required`
 
 按存在和当前模式同步 Ticket、Tickets Map、Goal Plan、`<Path>{roots.state}/specdev/changes/{change}/.status.json</Path>` 和全局状态；Direct Spec 不创建缺失的 Ticket/Map/Goal Plan。最后一个计划内 Ticket 完成后，Goal Plan 的 Lead 按 change completion 关闭；无 Goal Plan 的当前 I owner 承担同一门禁。需要远程 reconcile 时返回 T-triage，否则进入 Archive。
 
+当前 change 属于未完成父实现 change 时，单个组合 Ticket 的子状态与 Evidence 验证完成后必须自动返回 `<Path>{roots.workflows}/specdev/O-orchestrate-implementation/O-orchestrate-implementation.md</Path>`，由父 Lead 重读全部成员并继续下一 frontier；不得要求用户逐个重新激活，不得直接归档子 change，也不得从本 Work 实现另一个成员。
+
 运行：
 
 ```bash

package/template/workflows/specdev/I-implement/execution-preflight.md

@@ -14,6 +14,7 @@
 - [ ] current 模式 source 检查在 current workspace 且不宣称 E2E；required 模式 source 检查明确为非 E2E，required E2E 有 parent-candidate 场景与预期。
 - [ ] 验证命令/环境可用，关键静默失败风险有受控反向验证。
 - [ ] Deep Ticket 批准点已满足。
+- [ ] 若属于父 Implementation Map：父 revision 与 Plan source revision 一致，组合 Ticket 在 tasks/frontier 中，dependency Gate 已满足，serialization lock 可用，派单未重复，workspace 策略一致，全部成员 active implementation 数未超过父上限。
 
 ## Direct Spec 硬检查
 
@@ -36,3 +37,4 @@
 - **delivery-unverified**：候选、provider 声明或附件不能独立核对；保持 unverified。
 - **e2e-owner-invalid**：required 模式 E2E 被安排在 source worktree，或任一模式不是 Lead owner；停止并修 Ticket/Goal Plan。
 - **direct-parent-invalid**：current 模式的 Ticket commit、父 HEAD、验证或 Evidence 不一致；保留最后可信 commit 并阻塞当前 Ticket。
+- **parent-plan-stale**：父 Implementation Map revision、成员 Ticket、serialization、workspace 策略、全局实现配额或 repository/ref 已变化；停止当前派单并返回 O-orchestrate-implementation 重算。

package/template/workflows/specdev/I-init-setup/I-init-setup.md

@@ -55,7 +55,7 @@ keywords: [初始化, 配置, status, tracking, 验证命令]
 仅在上下文未提供时询问：
 
 - 交互语言与持久化工件语言；
-- implementation subagent、集成尝试次数和原型变体上限（初始化时写入 config，Lead 不计入）；
+- implementation subagent、集成尝试次数和 UI 设计候选上限（初始化时写入 config，Lead 不计入）；
 - Deep Ticket 的迁移、发布和不可逆操作是否必须人工批准；
 
 不询问可由仓库事实回答的文件位置、脚本名或默认分支。

package/template/workflows/specdev/I-init-setup/config-template.json

@@ -21,7 +21,7 @@
     "default_depth": "standard",
     "require_ready_gate": true,
     "require_evidence": true,
-    "ui_prototype_default_variants": 3,
-    "ui_prototype_max_variants": 5
+    "ui_design_default_candidates": 3,
+    "ui_design_max_candidates": 4
   }
 }

package/template/workflows/specdev/O-orchestrate-implementation/O-orchestrate-implementation.md

@@ -0,0 +1,129 @@
+---
+id: specdev/orchestrate-implementation
+type: workflow-entry
+workflow: specdev
+name: 编排实现
+description: 将两个或以上已完成 Ready Spec 与 Ready Tickets 的 change 编译为跨 change implementation super-DAG，并由单一 Lead 在一个会话中持续调度实现、验证和集成。
+keywords: [实现编排, 父 change, super-DAG, Ticket, Lead, agent team, worktree, 冲突]
+---
+
+# 编排实现
+
+> 激活本 Work 后，先读取 `<Path>{roots.workflows}/specdev/README.md</Path>`，再执行本入口。
+
+本 Work 只编排实现。它不创建或补写子 change 的 Triage、Grill、Wayfinder、Spec、Ticket 或普通 Goal Plan。父 change 创建前，每个输入 change 都必须已有 Ready Spec、Tickets Map 和决策完备的 Ready Tickets；缺一项就停止并报告具体缺口。
+
+父 change 将所有子 Ticket 投影为 `<member-change>::<ticket-id>` 组合节点，以跨 change implementation super-DAG、全局 workspace 策略、serialization、agent 配额和 integration queue 持续驱动 I-implement。子 Spec/Ticket/Evidence/Git 继续是行为与实现权威，父工件只拥有跨 change 实现编排。
+
+父 change 的主产物是 `<Path>{roots.state}/specdev/changes/{change}/implementation-map.md</Path>` 与 `<Path>{roots.state}/specdev/changes/{change}/implementation-plan.md</Path>`；整体验证写入 `<Path>{roots.state}/specdev/changes/{change}/evidence/implementation-orchestration.md</Path>`。
+
+## 激活输入
+
+创建模式必须获得至少两个用户明确指定的 change。恢复模式由用户指定父 change，或从 active change 中唯一满足 `current_work=specdev/orchestrate-implementation` 且存在父实现产物者确定。
+
+创建父 change 前必须读取并验证：
+
+- `<Path>{roots.state}/specdev/status.json</Path>` 与 `<Path>{roots.state}/specdev/config.json</Path>`；
+- 每个成员的 `<Path>{roots.state}/specdev/changes/{member-change}/.status.json</Path>`；
+- 每个成员的 `<Path>{roots.state}/specdev/changes/{member-change}/spec.md</Path>`；
+- 每个成员的 `<Path>{roots.state}/specdev/changes/{member-change}/tickets-map.md</Path>`；
+- 每个成员的 `<Path>{roots.state}/specdev/changes/{member-change}/ticket/</Path>`；
+- 存在时读取子 Goal Plan、ADR、CONTEXT、LOG、Diagnosis 与 Evidence；
+- 当前 repository、branch、HEAD、dirty 状态、项目 Agent 指令与可用验证命令。
+
+加载 `<Path>{roots.workflows}/specdev/O-orchestrate-implementation/input-readiness.md</Path>` 和 `<Path>{roots.workflows}/specdev/common/rules/parent-implementation-orchestration.md</Path>`。任何成员未实现就绪、已归档、等于父 change、属于另一个未完成父实现 change，或本身是父实现 change 时，不创建父 change。
+
+## 流程
+
+### 1. 先验证全部子 Change，再创建父 Change
+
+对每个成员穷尽检查 Ready Spec、Tickets Map、Ticket frontmatter、合同覆盖、内部 DAG、路径所有权、验证矩阵和高影响未知项。部分 Ticket 可以已经 done/cancelled；其余待实现 Ticket 必须 `ready: true` 且处于可执行状态。全部 Ticket 已终态的成员只作为 satisfied baseline，不占执行 frontier。
+
+只有所有成员通过输入门后，才从 change status 模板创建普通父 change，在全局 `active` 添加仅含 `change` 的索引，把父 `current_work` 设置为 `specdev/orchestrate-implementation`，再写父 Map/Plan。任何预检失败都不得留下半创建父 change。
+
+**完成标准**：父创建是 all-or-nothing；输入成员不少于两个；没有用父 Work 修补任何上游工件。
+
+### 2. 编译 Implementation Super-DAG
+
+加载 `<Path>{roots.workflows}/specdev/O-orchestrate-implementation/super-dag.md</Path>` 与 `<Path>{roots.workflows}/specdev/O-orchestrate-implementation/conflict-and-drift.md</Path>`。
+
+1. 将每个子 Ticket 映射为唯一组合节点；
+2. 将所有子 Ticket `blocked_by` 精确提升为组合 dependency；
+3. 只为真实合同/产物前置关系增加跨 change dependency；
+4. 为无语义依赖但不能并发的 Ticket 增加无方向 serialization pair；
+5. 比较所有待实现 Ticket 的 writable/shared paths、公共合同、repository/ref 和迁移资源；
+6. 检测循环、缺失节点、重复边、无 owner overlap 和子图漂移。
+
+使用 `<Path>{roots.workflows}/specdev/O-orchestrate-implementation/implementation-map-template.md</Path>` 写父 Map。Map 是子 Ticket 图的可重算投影；子 Ticket 变化时先重读权威，再递增 Map revision。
+
+**完成标准**：父 Map 的 members/tasks/internal edges 与全部子工件精确一致；跨 change 边有来源；DAG 无环；每个并行冲突已依赖化、串行化或阻塞。
+
+### 3. 一次决定全局执行策略
+
+只询问一次是否开启 Ticket worktree，默认不开启，并把选择写入父 Plan：
+
+- `current/direct-parent`：全部成员的待实现 Ticket 全局严格串行，只允许一个 current workspace implementation writer；
+- `required/candidate-merge`：依赖满足且无 serialization/path/resource 冲突的 Tickets 可跨 change 并行，每个 Ticket 使用自己的 source worktree。
+
+从 config 读取 implementation agent 与 integration attempt 上限，父 Plan 可以降低但不能提高。Lead 不计入实现 agent 数；review/research/test-observation agents 只读且不受该数字限制。同一 repository/ref 的 integration 永远串行。
+
+使用 `<Path>{roots.workflows}/specdev/O-orchestrate-implementation/implementation-plan-template.md</Path>` 写父 Plan。已有子 Goal Plan 只提供子 change 内的额外 Gate/约束；其 workspace 策略与父 Plan 冲突时阻塞，不能覆盖父级全局选择。
+
+Implementation Plan 固定使用 `orchestration: lead-directed`，并显式持久化 `implementation_agent_limit`、`integration_attempt_limit`、workspace/integration 策略和唯一 Lead；恢复时不得从会话记忆重建这些值。
+
+**完成标准**：Lead、workspace/integration 策略、全局 agent 上限、frontier、Wave、serialization owner 和 integration queue 可从父 Plan 恢复。
+
+### 4. 在一个会话中持续执行
+
+加载 `<Path>{roots.workflows}/specdev/O-orchestrate-implementation/execution-loop.md</Path>`。父 Lead 自动循环，不要求用户逐个激活子 change：
+
+1. 重读父 Map/Plan、所有子 Ticket/status 和 Git；
+2. 计算依赖满足、lock 可用且配额允许的 ready frontier；
+3. current 模式选择一个 Ticket，required 模式选择一组互不冲突的 Tickets；
+4. 将子 `current_work` 设置为 `specdev/implement`，按组合 ID 调用 I-implement；
+5. implementation agent 仅写授权 workspace，Lead 验收 commit/diff/验证/Evidence；
+6. 按 repository/ref queue 串行完成 direct-parent 或 candidate integration；
+7. 先原子提交子 Ticket/change 状态，再更新父 Plan 投影；
+8. 父 HEAD、Map revision 或子合同变化后使旧 dispatch/candidate stale，并重新 preflight；
+9. 仍有 frontier 时立即进入下一轮，否则完成或持久化 blocker。
+
+I-implement 是实际实现 owner；父 Work 不复制 TDD、代码审查、Evidence 或 worktree 逻辑。用户只在合同冲突、高影响偏差、缺失授权、不可逆动作或无合法 frontier 时被打断。
+
+**完成标准**：单次父激活可以连续完成多个子 Ticket；没有第二个 SpecDev 状态 writer、超限 agent、并发 parent integration 或绕过子 I-implement 完成门。
+
+### 5. 关闭子 Changes 与父 Change
+
+一个成员的全部计划内 Ticket done/cancelled 且其 Goal/Evidence/Git 门通过时，父 Lead 按 change completion 关闭该子 change；不等待其他成员才关闭，也不自动归档。
+
+全部成员 completed 后，Lead 运行跨 change aggregate test/typecheck/lint/build 与适用 E2E，核对跨 change 合同、依赖顺序、共享路径、迁移/恢复和最终 Git checkpoint，并使用 `<Path>{roots.workflows}/specdev/O-orchestrate-implementation/implementation-evidence-template.md</Path>` 写整体验证。
+
+只有父 Map/Plan completed、全部成员 completed、无 blocker/deviation/active dispatch/candidate/lock 且整体验证通过时，才清空父 `current_work`、去重加入 `specdev/orchestrate-implementation` 到 `works_run` 并关闭父 change。归档、push、PR、remote merge、deploy 和生产迁移保持独立授权。
+
+运行：
+
+```bash
+node <Path>{roots.workflows}/specdev/common/tools/validate-specdev.mjs</Path> \
+  --stage orchestrate-implementation \
+  <Path>{roots.state}/specdev/changes/{change}</Path>
+```
+
+## 完成标准
+
+- 父 change 只接受 Spec/Tickets 已 Ready 的成员；
+- Implementation Map/Plan 可恢复完整组合 DAG、全局策略、frontier 和 integration queue；
+- 子工件保持权威，父投影与子 Ticket 精确一致；
+- current 全局串行，required 只并行无冲突 Ticket，全部实现受父级 agent cap 约束；
+- I-implement 自动回到父循环，全部子 change 和父 change completed；
+- aggregate Evidence 与 validator 通过；
+- 无未经授权的归档、远程 Git、部署或生产副作用。
+
+## 子文件引用
+
+- 输入就绪门：`<Path>{roots.workflows}/specdev/O-orchestrate-implementation/input-readiness.md</Path>`
+- Super-DAG：`<Path>{roots.workflows}/specdev/O-orchestrate-implementation/super-dag.md</Path>`
+- 执行循环：`<Path>{roots.workflows}/specdev/O-orchestrate-implementation/execution-loop.md</Path>`
+- 冲突与漂移：`<Path>{roots.workflows}/specdev/O-orchestrate-implementation/conflict-and-drift.md</Path>`
+- Map 模板：`<Path>{roots.workflows}/specdev/O-orchestrate-implementation/implementation-map-template.md</Path>`
+- Plan 模板：`<Path>{roots.workflows}/specdev/O-orchestrate-implementation/implementation-plan-template.md</Path>`
+- Evidence 模板：`<Path>{roots.workflows}/specdev/O-orchestrate-implementation/implementation-evidence-template.md</Path>`
+- 共享规则：`<Path>{roots.workflows}/specdev/common/rules/parent-implementation-orchestration.md</Path>`

package/template/workflows/specdev/O-orchestrate-implementation/conflict-and-drift.md

@@ -0,0 +1,18 @@
+# Implementation Conflict and Drift
+
+## 冲突分类
+
+1. **真实依赖**：加入 dependency，前置 Ticket 完成前不启动后置 Ticket。
+2. **资源冲突**：加入 serialization，记录唯一 owner 与释放条件，不改变产品语义。
+3. **合同冲突**：行为、公共接口、数据、安全、范围或验收不一致；阻塞父 Plan，返回子 ADR/Spec/用户 owner。
+4. **基线漂移**：Ticket、Map revision、branch、HEAD、workspace 或 candidate 变化；废弃旧 dispatch/candidate，基于最新事实重新 preflight。
+
+## 路径与共享合同
+
+比较所有非终态 Ticket 的 writable/shared paths。无传递 dependency 的 overlap 必须有父 serialization；若两边 Ticket 的路径 owner 自身不合法，先阻塞并返回原 Ticket owner，父 Map 不能替它补 owner。
+
+同一共享 API/schema/锁文件/迁移索引即使路径预测不重叠，也必须根据实际消费者和集成事实决定 dependency 或 serialization。
+
+## 集成冲突
+
+同一 repository/ref 的 direct-parent/candidate integration 严格串行。一次父 HEAD 推进后，其他 candidate 全部 stale；必须在最新父状态重新组合并重跑要求的 full suite/E2E。需要新行为或上层决定的 merge conflict 立即停止。