@namewta/speculo 1.0.2 → 1.0.3

package/template/workflows/specdev/{O-orchestrate-implementation/O-orchestrate-implementation.md → P-goal-plan/references/multi-change-plan.md}

@@ -1,15 +1,7 @@
----
-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, 冲突]
----
+# 多 change Goal 规划与执行
 
-# 编排实现
+本参考由统一 P 按模式调用。plan 只完成步骤 1–3、父总控入口和计划审查；步骤 4–5 仅在显式 run/resume 且执行授权有效时进入。verify 不重新执行已完成票。旧 O current_work 作为兼容恢复键保留，新 P 父 Goal 可用 specdev/goal-plan。
 
-> 激活本 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；缺一项就停止并报告具体缺口。
 
@@ -17,16 +9,10 @@ keywords: [实现编排, 父 change, super-DAG, Ticket, Lead, agent team, worktr
 
 父 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>`。
 
-## 读取范围
-
-1. 先读取 `<Path>{roots.workflows}/specdev/README.md</Path>` 与当前 Work 的状态入口。
-2. 再读取 `<Path>{roots.workflows}/specdev/common/rules/activation-and-memory.md</Path>`，按当前分支、状态和关键词定位最小相关工件。
-3. 只在本 Work 明确要求恢复、冲突、执行安全或归档证据时扩展为全量读取；缺少匹配证据或 owner/gateway 时停止受影响分支。
-
 
 ## 激活输入
 
-创建模式必须获得至少两个用户明确指定的 change。恢复模式由用户指定父 change，或从 active change 中唯一满足 `current_work=specdev/orchestrate-implementation` 且存在父实现产物者确定。
+创建模式必须获得至少两个用户明确指定的 change。恢复模式由用户指定父 change，或从 active change 中唯一存在父实现产物且 current_work 为 specdev/goal-plan 或 specdev/goal-plan 者确定。
 
 创建父 change 前必须读取并验证：
 
@@ -40,7 +26,7 @@ keywords: [实现编排, 父 change, super-DAG, Ticket, Lead, agent team, worktr
 
 成员的 Spec、Tickets Map、Ticket frontmatter、状态和父级编排证据是 super-DAG 的权威输入，必须完整读取；成员的 ADR、CONTEXT、LOG、Diagnosis、Evidence、研究资料和项目 Skills 先按索引、状态和关键词定位，只读取命中的条目。恢复、冲突、漂移和集成失败时按本 Work 的证据合同扩展为全量读取。
 
-加载 `<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。
+加载 `<Path>{roots.workflows}/specdev/P-goal-plan/references/multi-input-readiness.md</Path>` 和 `<Path>{roots.workflows}/specdev/common/rules/parent-implementation-orchestration.md</Path>`。任何成员未实现就绪、已归档、等于父 change、属于另一个未完成父实现 change，或本身是父实现 change 时，不创建父 change。
 
 ## 流程
 
@@ -48,13 +34,13 @@ keywords: [实现编排, 父 change, super-DAG, Ticket, Lead, agent team, worktr
 
 对每个成员穷尽检查 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。
+只有所有成员通过输入门后，才从 change status 模板创建普通父 change，在全局 `active` 添加仅含 `change` 的索引，把父 `current_work` 设置为本次入口的 specdev/goal-plan 或兼容 specdev/goal-plan，再写父 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>`。
+加载 `<Path>{roots.workflows}/specdev/P-goal-plan/references/multi-super-dag.md</Path>` 与 `<Path>{roots.workflows}/specdev/P-goal-plan/references/multi-conflict-and-drift.md</Path>`。
 
 1. 将每个子 Ticket 映射为唯一组合节点；
 2. 将所有子 Ticket `blocked_by` 精确提升为组合 dependency；
@@ -63,7 +49,7 @@ keywords: [实现编排, 父 change, super-DAG, Ticket, Lead, agent team, worktr
 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。
+使用 `<Path>{roots.workflows}/specdev/P-goal-plan/goal-plan-template.md</Path>` 写父 Map。Map 是子 Ticket 图的可重算投影；子 Ticket 变化时先重读权威，再递增 Map revision。
 
 **完成标准**：父 Map 的 members/tasks/internal edges 与全部子工件精确一致；跨 change 边有来源；DAG 无环；每个并行冲突已依赖化、串行化或阻塞。
 
@@ -76,15 +62,17 @@ keywords: [实现编排, 父 change, super-DAG, Ticket, Lead, agent team, worktr
 
 从 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 冲突时阻塞，不能覆盖父级全局选择。
+使用 `<Path>{roots.workflows}/specdev/P-goal-plan/goal-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 恢复。
 
+随后用 `<Path>{roots.workflows}/specdev/P-goal-plan/references/goal-tickets-map-template.md</Path>` 写父无状态总控入口，并执行 `<Path>{roots.workflows}/specdev/common/skills/plan-quality-review/SKILL.md</Path>`。plan 到此返回计划、门禁和缺失授权；不得自行进入执行循环。
+
 ### 4. 在一个会话中持续执行
 
-加载 `<Path>{roots.workflows}/specdev/O-orchestrate-implementation/execution-loop.md</Path>`。父 Lead 自动循环，不要求用户逐个激活子 change：
+加载 `<Path>{roots.workflows}/specdev/P-goal-plan/references/multi-execution-loop.md</Path>`。父 Lead 自动循环，不要求用户逐个激活子 change：
 
 1. 重读父 Map/Plan、所有子 Ticket/status 和 Git；
 2. 计算依赖满足、lock 可用且配额允许的 ready frontier；
@@ -104,15 +92,15 @@ I-implement 是实际实现 owner；父 Work 不复制 TDD、代码审查、Evid
 
 一个成员的全部计划内 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>` 写整体验证。
+全部成员 completed 后，Lead 运行跨 change aggregate test/typecheck/lint/build 与适用 E2E，核对跨 change 合同、依赖顺序、共享路径、迁移/恢复和最终 Git checkpoint，并使用 `<Path>{roots.workflows}/specdev/P-goal-plan/goal-plan-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 和生产迁移保持独立授权。
+只有父 Map/Plan completed、全部成员 completed、无 blocker/deviation/active dispatch/candidate/lock 且整体验证通过时，才清空父 `current_work`、去重加入 `specdev/goal-plan` 到 `works_run` 并关闭父 change。归档、push、PR、remote merge、deploy 和生产迁移保持独立授权。
 
 运行：
 
 ```bash
 node <Path>{roots.workflows}/specdev/common/tools/validate-specdev.mjs</Path> \
-  --stage orchestrate-implementation \
+  --stage goal-plan \
   <Path>{roots.state}/specdev/changes/{change}</Path>
 ```
 
@@ -128,11 +116,11 @@ node <Path>{roots.workflows}/specdev/common/tools/validate-specdev.mjs</Path> \
 
 ## 子文件引用
 
-- 输入就绪门：`<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/P-goal-plan/references/multi-input-readiness.md</Path>`
+- Super-DAG：`<Path>{roots.workflows}/specdev/P-goal-plan/references/multi-super-dag.md</Path>`
+- 执行循环：`<Path>{roots.workflows}/specdev/P-goal-plan/references/multi-execution-loop.md</Path>`
+- 冲突与漂移：`<Path>{roots.workflows}/specdev/P-goal-plan/references/multi-conflict-and-drift.md</Path>`
+- Map 模板：`<Path>{roots.workflows}/specdev/P-goal-plan/goal-plan-template.md</Path>`
+- Plan 模板：`<Path>{roots.workflows}/specdev/P-goal-plan/goal-plan-template.md</Path>`
+- Evidence 模板：`<Path>{roots.workflows}/specdev/P-goal-plan/goal-plan-template.md</Path>`
 - 共享规则：`<Path>{roots.workflows}/specdev/common/rules/parent-implementation-orchestration.md</Path>`

package/template/workflows/specdev/P-goal-plan/references/replan-and-recovery.md

@@ -0,0 +1,21 @@
+# 重规划、旧票升级与恢复
+
+## 失效范围
+
+导致公共行为、接口、数据、安全、范围、验收或输出数量改变的事实，回到相应上游 owner 决定。记录旧摘要、新摘要、原因、用户决定和受影响票。沿真实依赖边计算失效闭包；同一 change 的 Spec 改变会使相关票重新核对，不能从旧 map 覆盖子合同。独立 change 未受影响的票继续。
+
+父计划沿用 `revision` 与 `source_map_revision`；单 change 新版 map 用 `plan_revision`。先保留旧证据，再生成新活动投影；不能回写旧记录伪装为原先就已批准。
+
+## 旧票升级
+
+既有 v3 Ticket/Map 保持可读；已完成或已归档票不追溯改写。下一次执行未完成旧票前：
+
+1. 核验归属、当前工作树与未闭合事务；保留原文件备份和摘要，不碰其他任务。
+2. 先读取票的背景和验收，扫描真实项目 Skill 入口，补充 `plan_contract_version: 1`、`skill_scan`、`skill_bindings`、`resource_claims` 与调用/停止章节。
+3. Map 补充版本、用户交付数量及其确认记录、控制入口；已有字段和默认行为保持。
+4. 重新执行 T 的 Ready 与计划审查，再运行 tickets 校验。用户指定数量、权限、默认工具或集成策略变化必须明确批准；不能默默“升级”权限。
+5. 从备份与变更清单恢复应只覆盖本任务实际改动，保留原软链接和元数据。任何失败只阻塞受影响票，不将整个 Goal 判为完成。
+
+## 恢复动作
+
+读取而非重建检查点；确认 HEAD、source commit、parent result、Evidence 和 owner。已提交未集成、已执行迁移未验证、已开始正式记忆事务等状态只通过原流程恢复。未知归属或缺少恢复证据时不自动撤销、不解锁、不重试不可逆动作；报告人工恢复要求。

package/template/workflows/specdev/P-goal-plan/references/single-change-plan.md

@@ -0,0 +1,149 @@
+# 目标规划
+
+
+Goal Plan 只拥有单个 Ticket 无法独立决定的事情：整体 Outcome、跨 Ticket 顺序与并发、共享所有权、里程碑 Gate、动态派单边界、父分支集成、迁移/发布顺序、偏差升级和恢复。Ticket 继续拥有局部实现合同。
+
+每次 Goal Plan 都采用 `lead-directed`：当前主会话是唯一 Lead，负责计划、SpecDev 状态、Evidence、派单、验收、父分支推进和最终回复。形成 Goal Plan 时，用户尚未明确才询问是否开启 worktree 开发，默认不开启；选择写入当前 Goal Plan，不修改全局配置。不开启时 Ticket 严格串行，允许动态派遣 implementation subagent，但同一时间只有一个 implementation owner 可写当前 workspace；开启时沿用每 Ticket 独立 worktree 与 candidate-merge。
+
+产物写入 `<Path>{roots.state}/specdev/changes/{change}/goal-plan.md</Path>`。
+
+
+## 何时运行
+
+满足任一条件时运行：
+
+- 多个 Ticket 可以或需要并行；
+- 存在 shared path、共享合同或集中 owner；
+- 存在 Deep Ticket、expand-contract、迁移、兼容窗口或不可逆步骤；
+- 存在多个 Gate、外部审批、发布窗口或高事故半径；
+- Ticket DAG 的关键路径、汇合点或恢复策略无法由 Tickets Map 安全表达；
+- 用户明确要求正式跨 Ticket Plan。
+
+少量、线性、低风险的 Ready Tickets 可以不生成厚重编排正文，但执行前仍要有最小 Goal Plan 记录 workspace、Lead、Gate 和授权引用；不得引用不存在的当前 Goal Plan。没有 Ticket 的获批小型 Direct Spec 不受 Ticket workspace 合同约束；一旦需要切片，先运行 T-tickets。
+
+## 输入
+
+必须读取：
+
+- `<Path>{roots.state}/specdev/changes/{change}/spec.md</Path>`
+- `<Path>{roots.state}/specdev/changes/{change}/tickets-map.md</Path>`
+- `<Path>{roots.state}/specdev/changes/{change}/ticket/</Path>`：先枚举 Ticket 入口的 frontmatter、依赖和状态，按 DAG、路径和风险定位需要完整读取的 Ticket。
+- `<Path>{roots.state}/specdev/config.json</Path>`
+
+按存在情况读取：
+
+- 当前 change 架构决策：`<Path>{roots.state}/specdev/changes/{change}/ADR.md</Path>`
+- 当前 change 领域上下文：`<Path>{roots.state}/specdev/changes/{change}/CONTEXT.md</Path>`
+- 当前 change 设计日志：`<Path>{roots.state}/specdev/changes/{change}/LOG.md</Path>`
+- 当前 change 诊断：`<Path>{roots.state}/specdev/changes/{change}/diagnosis.md</Path>`
+- 永久架构决策：`<Path>{roots.state}/specdev/adr/</Path>`
+- 永久领域上下文：`<Path>{roots.state}/specdev/context/</Path>`
+- 用户提供的合同、标准、参考实现、环境限制、发布窗口和批准策略。
+
+非当前分支的 ADR、CONTEXT、LOG、Diagnosis、Evidence、研究资料和永久目录先通过索引、状态和关键词定位；只有被当前 Gate、依赖、冲突或恢复条件命中的条目才回读原文。Tickets Map、当前计划和决定 DAG 的 Ticket frontmatter 是权威编排输入，仍需完整读取。
+
+永久目录可以为空，静默继续。缺少 Spec 或 Tickets Map 时返回 `<Path>{roots.workflows}/specdev/S-spec/S-spec.md</Path>` 或 `<Path>{roots.workflows}/specdev/T-tickets/T-tickets.md</Path>`；当前 ADR/CONTEXT 缺失且规划依赖对应决定时返回 `<Path>{roots.workflows}/specdev/G-grill-with-docs/G-grill-with-docs.md</Path>`，不在 Goal Plan 中补造上游权威。
+
+## 流程
+
+### 1. 验证上游与执行边界
+
+加载 `<Path>{roots.workflows}/specdev/P-goal-plan/planning-modes.md</Path>`：
+
+1. 验证 Spec、Tickets、合同覆盖、DAG、路径所有权和 Deep Ticket 完整性；
+2. 只读探索影响调度的代码与项目事实；
+3. 识别 migration、high-assurance、reference-conformance、release-coordination 等适用模式；
+4. 从 config 读取 `max_implementation_agents` 与 `max_integration_attempts`，将实际值快照到 `implementation_agent_limit` 与 `integration_attempt_limit`；本计划可以降低但不得超过 config 或平台能力，Lead 不计入；
+5. 根据 workspace 策略记录实现 commit 与 direct-parent/candidate integration 授权事实；缺失时仍可完成 plan 文档，但 ready_for_execution 保持 false，并列为 run 的阻塞条件；
+6. 只询问无法发现且会改变 Gate、Wave、owner、迁移、批准或验收的问题。
+
+**完成标准**：所有计划内 Ticket Ready；Lead、授权、实现并发上限和父分支可判定；没有用 Goal Plan 掩盖上游缺口。
+
+### 2. 构建 Outcome、DAG、Wave 与 Gate
+
+加载 `<Path>{roots.workflows}/specdev/P-goal-plan/orchestration-protocol.md</Path>`：
+
+1. 压缩 Outcome、成功/伪完成、非目标和权威来源；
+2. 从 Ticket frontmatter 构建 DAG、关键路径、扇出与汇合点；
+3. 为 shared path、共享合同和集中修改指定唯一 owner；
+4. 将依赖满足且项目写路径不相交的 Ticket 分入 Wave；current 模式仍按依赖顺序串行执行，不得把 Wave 当作并发授权；
+5. 为合同稳定、垂直路径、迁移完成、发布就绪等状态定义 Gate；
+6. 为每个 Ticket 记录开始条件、workspace 策略、验证层级、Evidence 目标、集成顺序和失败恢复。
+
+**完成标准**：DAG、Wave、Gate 与 Tickets Map 一致；每个 Ticket 有唯一项目写 owner、worktree 合同和可验证集成出口。
+
+### 3. 固定 Lead 编排与动态派单合同
+
+加载 `<Path>{roots.workflows}/specdev/P-goal-plan/lead-orchestration.md</Path>`，并以 `operation=plan` 调用 `<Path>{roots.workflows}/specdev/common/skills/subagent-delivery/SKILL.md</Path>`：
+
+1. 固定 Lead 的可恢复 owner/session locator；
+2. 声明 implementation subagent 的 config/平台约束上限，Lead 不计入；
+3. 不为只读 review/research/test-observation agent 写 SpecDev 数字上限；
+4. current 模式固定只有一个 implementation writer 写项目路径，Lead 仍是唯一 SpecDev 工件与状态写入者；required 模式 implementation owner 写自己的 Ticket worktree；
+5. 定义执行期动态 Dispatch Packet、候选返回和 Lead 验收；
+6. provider、模型和具体派单在 Ticket 开始时按事实选择，不在 Goal Plan 中预分配。
+
+**完成标准**：Lead 可以在恢复后重建派单边界；任何 subagent 都不能成为第二个 SpecDev 状态写入者或父分支 integration owner。
+
+### 4. 定义完成、证据与恢复
+
+加载 `<Path>{roots.workflows}/specdev/P-goal-plan/completion-control.md</Path>`：
+
+1. 定义整体 Definition of Done 和每个 Gate 的关闭证据；
+2. 固化不可协商约束与允许的局部实现自由；
+3. 按 workspace 策略为每个 Ticket 明确 current-workspace/direct-parent 检查或 source-worktree/parent-candidate 检查；
+4. E2E 按 Ticket 实际跨边界风险标记 required 或 not-required；
+5. 定义 direct-parent 验证失败、candidate 冲突/失败、父 HEAD 漂移、偏差、暂停、批准和恢复动作；
+6. 定义 change 完成、远程 reconcile、残余风险和回滚要求。
+
+**完成标准**：每个完成声明映射到不可变 commit、候选/父分支 SHA、命令、Evidence 或人工批准。
+
+### 5. 写入、同步与验证
+
+使用 `<Path>{roots.workflows}/specdev/P-goal-plan/goal-plan-template.md</Path>` 写入 Goal Plan：
+
+1. 只保留适用 planning modes，不创建条件性 topology addendum；
+2. 将 Wave、Gate 和 owner 投影同步到 Tickets Map；
+3. 对照 `<Path>{roots.workflows}/specdev/common/schemas/goal-plan.schema.json</Path>`；
+4. 运行：
+
+```bash
+node <Path>{roots.workflows}/specdev/common/tools/validate-specdev.mjs</Path> \
+  --stage goal-plan \
+  <Path>{roots.state}/specdev/changes/{change}</Path>
+```
+
+5. 原子更新 Goal Plan、Tickets Map、全局/current change 状态并重新读取；
+6. 向用户报告 Outcome、关键路径、Wave/Gate、Lead、实现 agent 上限、shared owner、E2E disposition、迁移与主要风险；
+7. 未经用户要求，不自动进入实现。
+
+## 决策完备标准
+
+每份 Goal Plan 必须让 Lead 无需重新决定：
+
+- Outcome、权威来源和整体完成；
+- 跨 Ticket 先后、Wave、Gate 和关键汇合点；
+- shared path 与共享合同 owner；
+- implementation subagent 上限及动态派单边界；
+- 每 Ticket workspace、implementation commit、对应验证和父分支推进规则；
+- E2E disposition、偏差、暂停、批准和恢复路径。
+
+Goal Plan 不复制 Ticket 的局部施工路线、全部文件预测或逐项验收清单。
+
+## 完成标准
+
+- Goal Plan schema v6 且 `ready_for_execution` 与状态一致；
+- Lead 唯一，implementation subagent 上限来自 config/平台能力，review/research agent 不受 SpecDev 数字限制；
+- 每个实现 Ticket 都有 workspace、commit、对应 integration gate 和 Evidence 出口；
+- current 模式不创建 source/candidate worktree，适用 E2E 由 Lead 在 current workspace 运行；required 模式保持 source/parent-candidate 边界；
+- 计划只保留当前固定 Lead 与选定 workspace/integration 合同；
+- validator 无 error，Tickets Map 投影同步，用户收到下一步选择。
+
+## 子文件引用
+
+- 规划模式与输入门禁：`<Path>{roots.workflows}/specdev/P-goal-plan/planning-modes.md</Path>`
+- DAG、Wave、Gate 与集成队列：`<Path>{roots.workflows}/specdev/P-goal-plan/orchestration-protocol.md</Path>`
+- Lead 与动态派单：`<Path>{roots.workflows}/specdev/P-goal-plan/lead-orchestration.md</Path>`
+- 完成、证据与恢复：`<Path>{roots.workflows}/specdev/P-goal-plan/completion-control.md</Path>`
+- Goal Plan 模板：`<Path>{roots.workflows}/specdev/P-goal-plan/goal-plan-template.md</Path>`
+- Agent 交付合同：`<Path>{roots.workflows}/specdev/common/skills/subagent-delivery/SKILL.md</Path>`

package/template/workflows/specdev/R-review-architecture/R-review-architecture.md

@@ -3,29 +3,26 @@ id: specdev/review-architecture
 type: workflow-entry
 workflow: specdev
 name: 架构审查
-description: 从用户指定范围或 Git 热点扫描代码库的深化机会，以持久化可视化 HTML 呈现候选，并对用户选择的一个方案运行设计树访谈。
-keywords: [architecture, review, module, interface, depth, seam, adapter, leverage, locality, HTML]
+description: 从用户指定范围或 Git 热点扫描代码库中的结构性坏味道、代码 judo 机会和维护性风险，以中文 Markdown 记录高置信候选，并对用户选择的一个方案运行设计树访谈。
+keywords: [架构审查, 维护性, 浅模块, 深模块, 局部性, 杠杆, 接缝, code-judo]
 ---
 
-# 改善代码库架构
+# 架构审查
 
 > 激活本 Work 后，先读取 `<Path>{roots.workflows}/specdev/README.md</Path>`，再执行本入口。
 
-揭示架构摩擦，提出**深化机会**——将 shallow module 转变为 deep module 的重构。目标是可测试性和 AI 可导航性。
+本 work 以热核级维护性标准审查当前范围：先找会让 module 变浅的结构性坏味道，再找能删掉复杂性的 `code-judo` 机会，再找真正值得深化的 seam。行为正确不构成通过；如果存在更简单的路径，就优先把复杂性删掉，而不是搬家。
 
-本 work 基于项目领域模型，并建立在共享设计词汇之上：
+本 work 只审查、呈现和访谈，不直接修改产品代码。报告阶段只产出 Markdown 决策记录，不生成 HTML。
 
-- 读取 `<Path>{roots.workflows}/specdev/common/rules/codebase-design.md</Path>`，在每个建议中严格使用 module、interface、depth、seam、adapter、leverage、locality，不滑向含义更松散的替代词。
-- 当前 change 与永久 CONTEXT 中的领域语言为好的 seam 提供名称；ADR 记录本 work 不应重新争论的决定。
-
-本 work 只审查、呈现和访谈，不直接修改产品代码。
+本 work 的候选筛选、排序和删除测试见 `<Path>{roots.workflows}/specdev/R-review-architecture/review-rubric.md</Path>`。审查语言必须使用 module、interface、depth、seam、adapter、leverage、locality。
 
 ## 读取范围
 
 1. 先读取 `<Path>{roots.workflows}/specdev/README.md</Path>` 与当前 Work 的状态入口。
-2. 再读取 `<Path>{roots.workflows}/specdev/common/rules/activation-and-memory.md</Path>`，按当前分支、状态和关键词定位最小相关工件。
+2. 再读取 `<Path>{roots.workflows}/specdev/common/rules/activation-and-memory.md</Path>`、`<Path>{roots.workflows}/specdev/common/rules/codebase-design.md</Path>` 和 `<Path>{roots.workflows}/specdev/common/rules/evidence-and-verification.md</Path>`，按当前分支、状态和关键词定位最小相关工件。
 3. 只在本 Work 明确要求恢复、冲突、执行安全或归档证据时扩展为全量读取；缺少匹配证据或 owner/gateway 时停止受影响分支。
-
+4. 用户指定范围优先于 Git 热点；若未指定，则从最近 churn、重复编辑和报错/回归轨迹中找出最值得审查的 module。
 
 ## 输入与产物
 
@@ -43,61 +40,57 @@ keywords: [architecture, review, module, interface, depth, seam, adapter, levera
 产物：
 
 - `<Path>{roots.state}/specdev/changes/{change}/architecture-review.md</Path>`
-- `<Path>{roots.state}/specdev/changes/{change}/architecture-review.html</Path>`
-- 系统临时目录中名称为 architecture-review-&lt;timestamp&gt;.html 的打开副本。
+
+每个候选都必须说明：files、structural problem、code-judo move、deleted complexity、dependency class、strength、ADR conflict、interview state 和 user conclusion。文件若因为本次变化接近或超过 1k lines，必须显式标注 decomposition pressure，不得默默吞掉。
 
 ## 流程
 
 ### 1. 探索
 
-**扫描前先划定范围——YAGNI。** 深化一个模块的价值在于让未来变更更容易，因此特别关注近期发生过变更的部分。
+**先找结构压力，再找方案。** YAGNI 仍然成立，但只有真正的代码压力才值得写入报告。
 
-- 用户指明模块、子系统或痛点时直接采用，跳过热点推断；
-- 否则翻阅足够长的 `git log --oneline`，找出反复出现的文件和位置；
-- 变更散落、没有明确热点时才扩大搜索范围。
+- 用户指明 module、子系统或痛点时直接采用，跳过热点推断；
+- 否则翻阅足够长的 `git log --oneline`，找出反复出现的 files、call sites 和 test surfaces；
+- 变更散落、没有明确热点时才扩大搜索范围；
+- 只接受能通过删除测试的候选：删掉该 module 后，复杂性应集中或消失，而不是换一个地方继续蔓延；
+- 优先挑出结构性回归、重复 special cases、wrong-layer logic、thin wrappers、identity abstractions、type boundary drift、sequential orchestration 和 file-size/decomposition pressure；
+- 如果一个更 canonical 的 helper 已经存在，优先复用它；如果 proposal 只是 rearrange complexity，不算候选。
 
-首先阅读项目领域词汇和接触区域的 ADR。然后有机探索代码库，注意在哪里遇到摩擦：
+首先阅读项目领域词汇和接触区域的 ADR。然后有机探索 codebase，注意哪里会让 maintenance knowledge 分散：
 
-- 理解一个概念是否需要在多个小模块间反复跳跃；
-- 哪些模块是 shallow，interface 几乎与实现一样复杂；
-- 哪些纯函数仅为可测试性抽出，bug 却藏在缺少 locality 的调用方式中；
-- 哪些紧密耦合模块在 seam 泄漏；
-- 哪些区域未经测试，或难以通过当前 interface 测试。
+- 哪些 module 是 shallow，interface 几乎与 implementation 一样复杂；
+- 哪些 seam 正在 leak；
+- 哪些纯函数只是为了可测试性被拆出，但 bug 实际藏在缺少 locality 的调用方式中；
+- 哪些模块因为 ad-hoc conditionals、mode flags 或 one-off branches 变得更 spaghetti；
+- 哪些区域正在把 feature logic 泄漏进 shared path 或 canonical helper 之外；
+- 哪些结构已经逼近或超过 1k lines，应该先 decomposition 再 review；
+- 哪些 orchestration 本可以并行或更 atomic，却被无谓串行化。
 
-对每个怀疑对象应用删除测试。候选必须有真实路径、调用或测试证据，并说明不做的实际后果。与业务目标、近期变化压力、测试改善或风险降低无关的候选过滤掉。
+对每个怀疑对象应用删除测试。候选必须有真实路径、调用或测试证据，并说明不做的实际后果。与业务目标、近期变化压力、测试改善或风险降低无关的候选过滤掉。若没有任何候选通过这条线，明确写出“没有高置信候选”，不要为了填表而硬造一个。
 
-**完成标准**：审查范围、排除范围、领域/ADR 输入和每个候选的代码压力均可追踪。
+**完成标准**：审查范围、排除范围、领域/ADR 输入和每个候选的 code pressure 均可追踪；没有把行为正确但结构平庸的地方当成通过。
 
-### 2. 生成 Markdown 与 HTML 报告
+### 2. 生成 Markdown 报告
 
 使用 `<Path>{roots.workflows}/specdev/R-review-architecture/architecture-review-template.md</Path>` 写入 Markdown 决策记录。
 
-加载 `<Path>{roots.workflows}/specdev/R-review-architecture/architecture-report-contract.md</Path>` 和 `<Path>{roots.workflows}/specdev/R-review-architecture/architecture-review-report-template.html</Path>`，写入持久化 HTML。报告使用 Tailwind CDN 布局、Mermaid CDN 表达调用/依赖/序列，并混合手写 CSS/SVG 呈现质量图、横截面和调用图坍缩。
-
-每个候选包含：
+每个候选以高置信 finding 的顺序展示，而不是按文件顺序排列。每个候选包含：
 
-- **文件**——涉及的文件和 modules；
+- **文件**——涉及的 files 和 modules；
 - **问题**——当前架构造成的摩擦；
-- **解决方案**——简明描述会发生什么；
-- **收益**——用 locality、leverage 和测试改善解释；
-- **前后对比图**——并排展示 shallow 与 deep；
+- **代码 judo**——保留行为但删掉什么复杂性；
+- **收益**——用 locality、leverage、depth 和测试改善解释；
+- **删除测试**——删掉这个 module 后复杂性是否真的消失；
+- **前后对比**——用文本图示或 Mermaid 记录 shallow 与 deep；
 - **建议强度**——`Strong | Worth exploring | Speculative`；
 - **依赖类别**——`in-process | local-substitutable | ports & adapters | mock`；
 - **ADR 冲突**——只在摩擦真实到值得重审时显示警告。
 
-报告以“最佳推荐”结束。此时**不提出 interface**，只询问用户想探索哪一个候选。
-
-**完成标准**：每个候选字段完整、图表承担主要关系、最佳推荐唯一，Markdown 与 HTML 已原子写入并重读。
-
-### 3. 持久化并打开报告
-
-从 `$TMPDIR` 解析临时目录，回退 `/tmp`，Windows 使用 `%TEMP%`。把持久化 HTML 复制到全新的 architecture-review-&lt;timestamp&gt;.html，再用平台命令打开：Linux `xdg-open`、macOS `open`、Windows `start`。
-
-打开失败不删除任一文件；向用户返回 state 主件和临时副本的绝对路径，以及失败命令。敏感值和机器路径不写回持久化报告。
+报告以“最佳推荐”结束；若没有高置信候选，就明确写 `无高置信候选`。此时**不提出 interface**，只询问用户想探索哪一个候选，或者为何没有候选。
 
-**完成标准**：持久化主件可重读；临时副本名称唯一；打开成功或失败证据已报告。
+**完成标准**：每个候选字段完整、最佳推荐唯一或明确为空，Markdown 已原子写入并重读。
 
-### 4. 访谈用户选择的一个候选
+### 3. 访谈用户选择的一个候选
 
 用户选择候选后，调用 `<Path>{roots.workflows}/specdev/G-grill-with-docs/G-grill-with-docs.md</Path>`，用完整 frontier 遍历约束、依赖、deep module 形状、seam 后面的内容和保留测试。
 
@@ -106,31 +99,33 @@ keywords: [architecture, review, module, interface, depth, seam, adapter, levera
 - 新概念加入 change CONTEXT；永久 CONTEXT 不存在时延迟到归档提升；
 - 模糊术语当场精炼；
 - 用户的选择同时难以逆转、没有上下文会令人惊讶且来自真实权衡时，询问是否记录 ADR；任一条件不满足就留在 LOG/Ticket，不制造 ADR；
-- 替代 interface 需要探索时使用 `<Path>{roots.workflows}/specdev/I-implement/design-it-twice.md</Path>`。
+- 替代 interface 需要探索时使用 `<Path>{roots.workflows}/specdev/I-implement/design-it-twice.md</Path>`；
+- 如果候选最终只是把复杂性搬家，而不是删掉它，在访谈中直接回退，不把它升级成 Ticket。
 
-将选择、访谈状态与结论同步到 Markdown/HTML；每次运行只访谈用户选择的候选，不批量迫使用户决定所有卡片。
+将选择、访谈状态与结论同步到 Markdown；每次运行只访谈用户选择的候选，不批量迫使用户决定所有卡片。
 
 **完成标准**：被选候选的设计树达到共识或明确 blocked；领域词汇、LOG、ADR 和审查报告一致。
 
-### 5. 转化为执行工作
+### 4. 转化为执行工作
 
-只有被接受且有具体变更压力的提案进入 `<Path>{roots.workflows}/specdev/T-tickets/T-tickets.md</Path>`。加载 `<Path>{roots.workflows}/specdev/R-review-architecture/proposal-to-ticket.md</Path>`，按 Prefactor、Standard 或 Deep/expand-contract 建立 Ready 治理。
+只有被接受且有具体变更压力的提案进入 `<Path>{roots.workflows}/specdev/T-tickets/T-tickets.md</Path>`。加载 `<Path>{roots.workflows}/specdev/R-review-architecture/proposal-to-ticket.md</Path>`，按 Prefactor、Standard 或 Deep/expand-contract 建立 Ready 治理；只有能删除复杂性的提案才继续，纯重排和 thin wrapper 不进入 Ticket。
 
 ## 完成标准
 
 - 范围来自用户方向或 Git 热点，未进行无边界扫描；
 - 每个候选通过删除测试并有真实代码压力；
 - 领域使用 CONTEXT 词汇，架构严格使用共享词汇；
-- 持久化 Markdown/HTML 与临时打开副本均可定位；
-- 每个候选有 Before/After、强度、收益和 ADR 冲突处理；
+- Markdown 决策记录可重读；
+- 每个候选有前后对比、强度、收益和 ADR 冲突处理；
 - 报告阶段没有提前设计 interface；
 - 用户选择的一个候选完成完整 frontier 访谈；
-- 接受项进入 Ticket 治理，没有直接修改产品代码。
+- 接受项进入 Ticket 治理，没有直接修改产品代码；
+- 没有把结构性弱候选包装成最佳推荐。
 
 ## 子文件引用
 
 - 共享设计规则：`<Path>{roots.workflows}/specdev/common/rules/codebase-design.md</Path>`
+- 证据与验证：`<Path>{roots.workflows}/specdev/common/rules/evidence-and-verification.md</Path>`
+- 审查准则：`<Path>{roots.workflows}/specdev/R-review-architecture/review-rubric.md</Path>`
 - Markdown 模板：`<Path>{roots.workflows}/specdev/R-review-architecture/architecture-review-template.md</Path>`
-- HTML 报告合同：`<Path>{roots.workflows}/specdev/R-review-architecture/architecture-report-contract.md</Path>`
-- HTML 模板：`<Path>{roots.workflows}/specdev/R-review-architecture/architecture-review-report-template.html</Path>`
 - 提案转 Ticket：`<Path>{roots.workflows}/specdev/R-review-architecture/proposal-to-ticket.md</Path>`

package/template/workflows/specdev/R-review-architecture/architecture-review-template.md

@@ -4,10 +4,10 @@ change: <YYYY-MM-DD-topic>
 status: draft
 ---
 
-# Architecture Review: <范围>
+# 架构审查：<范围>
 
 - **决策记录：** `<Path>{roots.state}/specdev/changes/{change}/architecture-review.md</Path>`
-- **可视化报告：** `<Path>{roots.state}/specdev/changes/{change}/architecture-review.html</Path>`
+- **审查准则：** `<Path>{roots.workflows}/specdev/R-review-architecture/review-rubric.md</Path>`
 
 ## 1. 审查压力与范围
 
@@ -17,33 +17,42 @@ status: draft
 - 不审查范围：
 - 成功标准：
 - 热点依据：用户指定 / Git 历史
+- 结构性压力：file-size、spaghetti growth、boundary drift、wrong-layer logic、thin wrapper、sequential orchestration
 
 ## 2. 当前结构地图
 
-### Modules 与 Interfaces
+### 模块与接口
 
-### 数据、控制与错误流及 Seams
+### 数据、控制与错误流及 seam
 
-### 变化热点、Locality 与测试表面
+### 变化热点、locality 与测试表面
+
+### 拆分压力
+
+- 接近或超过 1k lines 的文件：
+- 需要先删除还是先拆分的复杂性：
 
 ## 3. 候选提案
 
 ### AR-001: <标题>
 
 - **文件：** `<Path>project/relative/path</Path>`
+- **结构类别：** structural blocker / missed simplification / spaghetti growth / boundary drift / file-size pressure / wrong-layer logic
 - **问题：** 当前架构如何造成摩擦
-- **解决方案：** 将发生什么变化；报告阶段不提出具体 interface
-- **收益：** locality、leverage 与测试改善
+- **代码 judo：** 保留行为但删掉什么复杂性
+- **删除复杂性：** 会消失的 branch、helper、wrapper、mode、special case
+- **删除测试：** 删除当前 shallow module 会集中复杂性 / 只移动复杂性
+- **收益：** locality、leverage、depth 与测试改善
 - **建议强度：** Strong / Worth exploring / Speculative
 - **依赖类别：** in-process / local-substitutable / ports & adapters / mock
-- **删除测试：** 删除当前 shallow module 会集中复杂性 / 只移动复杂性
 - **ADR 冲突：** 无 / ADR-###，值得重审因为 ...
 
-#### Before / After
+#### 前后对比
 
 - Before：shallow interface、leaking seam 与分散 locality。
 - After：deep module、稳定 interface 与集中测试表面。
 
+- **证据：** `CODE:<Path>project/relative/path</Path>`、git log、测试输出
 - **推荐：**
 - **访谈状态：** unselected / selected / consensus / blocked / rejected
 - **用户结论：**
@@ -51,7 +60,7 @@ status: draft
 
 ## 4. 最佳推荐
 
-首先探索：AR-###。原因：<一句话>。
+首先探索：AR-###。原因：<一句话>。若没有高置信候选，明确写 `无高置信候选`。
 
 ## 5. 下一步
 

package/template/workflows/specdev/R-review-architecture/proposal-to-ticket.md

@@ -3,9 +3,11 @@
 本规则由 `<Path>{roots.workflows}/specdev/R-review-architecture/R-review-architecture.md</Path>` 在候选被用户接受后加载。
 
 - 只有有代码证据、具体收益和用户接受的提案才生成 Ticket。
-- Prefactor Ticket 必须指出解除的后续阻碍、受益 Ticket 或行为，以及独立验证。
+- 先确认提案真正在删除复杂性，而不是把复杂性搬家；纯重排、纯改名或 thin wrapper 不进入 Ticket。
+- 前置 Ticket 必须指出解除的后续阻碍、受益 Ticket 或行为，以及独立验证。
 - 修改公共接口、schema、数据或大范围调用方时使用 Deep，并采用 expand → migrate → observe → contract。
 - 架构报告中的项目路径只是审查证据；生成 Ticket 时重新确认当前项目路径和所有权。
 - 不把“清理整个模块”写成单一 Ticket；按可验证安全落点拆分。
+- 如果候选会让文件越过 1k lines、引入更多 special cases，或者只是在已经忙乱的流程里再加一层分支，先继续分解，再考虑 Ticket。
 - 任何会改变外部行为或验收合同的提案先修订 `<Path>{roots.state}/specdev/changes/{change}/spec.md</Path>`。
 - 任何会改变已接受架构决策的提案先更新 `<Path>{roots.state}/specdev/changes/{change}/ADR.md</Path>`。

package/template/workflows/specdev/R-review-architecture/review-rubric.md

@@ -0,0 +1,52 @@
+# 架构审查准则
+
+本准则只在 `<Path>{roots.workflows}/specdev/R-review-architecture/R-review-architecture.md</Path>` 激活时生效。它把热核级维护性标准转成候选筛选和排序规则。
+
+使用 `<Path>{roots.workflows}/specdev/common/rules/codebase-design.md</Path>` 的术语：module、interface、depth、seam、adapter、leverage、locality。描述架构时不要滑向更弱的替代词。
+
+## 重点观察
+
+优先寻找有真实代码压力的候选：
+
+- 结构性回退：module 变浅，interface 正在向 implementation 膨胀；
+- 代码 judo 机会：删掉一个 branch、helper、wrapper、mode 或 special case；
+- spaghetti growth：ad-hoc conditionals、散落例外或一次性 flags；
+- boundary drift：cast、`any`、`unknown` 或 optionality 掩盖真实不变量；
+- 文件大小或拆分压力，尤其是把文件推到 1k lines 以上；
+- wrong-layer logic 泄漏进共享路径或 canonical helper；
+- 重复的 canonical helper、identity abstraction 或 pass-through wrapper；
+- 原本可以更原子化的顺序编排或部分更新；
+- seam 正在把测试、错误或状态处理复杂性泄漏给调用方。
+
+## 删除测试
+
+只有删除当前 module、helper 或 branch 后，复杂性真的消失，或者至少集中到更容易推理的位置，候选才算成立。
+
+拒绝以下候选：
+
+- 只是重新摆放复杂性；
+- 只是改名；
+- 只是把一个 shallow module 换成另一个 shallow module；
+- 只是加一个 thin wrapper、adapter 或 identity abstraction，却没有换来 leverage；
+- 依赖 speculative generality，而不是当前真实压力；
+- 没有文件、调用点或测试证据。
+
+## 排序规则
+
+按严重度和代码压力排序：
+
+1. 结构性阻塞；
+2. 明显的代码 judo；
+3. 重复 special case 和 spaghetti growth；
+4. boundary 与 type contract 漂移；
+5. 文件大小和拆分压力；
+6. wrong-layer logic 和 canonical helper 重复；
+7. 低信号的可读性问题。
+
+## 文件大小规则
+
+不要让一个候选轻易把文件从 1k lines 以下推到 1k lines 以上。默认把它当成拆分压力，而不是通过项。
+
+## 报告门槛
+
+不要把报告写成杂音集合。只保留高置信 finding。若没有候选通过门槛，就直接写 `无高置信候选`，不要硬造一个来填模板。