@namewta/speculo 0.6.0 → 0.7.0

package/template/workflows/specdev/P-goal-plan/goal-plan-template.md

@@ -28,7 +28,7 @@ ready_for_execution: false
 | 优先级 | 来源 | 负责内容 | 冲突处理 |
 |---|---|---|---|
 | 1 | 用户最新明确决定 | 产品取舍与批准 | 更新真正拥有该决策的工件 |
-| 2 | `<Path>{roots.state}/specdev/changes/{change}/ADR.md</Path>` | 已接受架构决策 | 通过新决策替代 |
+| 2 | `<Path>{roots.state}/specdev/changes/{change}/ADR.md</Path>` | 当前 change 架构决定 | 通过新决定替代 |
 | 3 | `<Path>{roots.state}/specdev/changes/{change}/spec.md</Path>` | 外部行为、范围与验收 | 下游不得改写 |
 | 4 | `<Path>{roots.state}/specdev/changes/{change}/ticket/{ticket-file}.md</Path>` | 单 Ticket 契约 | Goal Plan 只编排 |
 | 5 | 当前代码事实 | 现状与可行性 | 冲突时触发偏差 |
@@ -48,11 +48,9 @@ ready_for_execution: false
 
 ### Ticket Quick Reference
 
-<!-- Ticket 较多或执行者需要时添加；数据从 Ticket 与 Tickets Map 提取。 -->
-
 | ID | Ticket | 行为产出 | Depth/Risk | Dependencies | Wave/Gate | Owner | Evidence |
 |---|---|---|---|---|---|---|---|
-| T-01 | `<Path>{roots.state}/specdev/changes/{change}/ticket/01-<name>.md</Path>` | ... | standard/medium | — | W0/G0 | lead | `<Path>{roots.state}/specdev/changes/{change}/evidence/T-01.md</Path>` |
+| 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>` |
 
 ## 3. Gates and Completion Evidence
 
@@ -70,17 +68,10 @@ ready_for_execution: false
 
 ## 4. Execution and Integration Protocol
 
-### Delivery Contract
+### Ticket Execution Order
 
-| 字段 | 值 |
-|---|---|
-| Execution model | direct / native-subagent / external-web-subagent |
-| Lead / Provider | `<owner>` / `<provider-or-none>` |
-| Repository / Branch | `<repository-or-local>` / `<branch-or-n/a>` |
-| Checkpoint policy | immutable SHA / local baseline |
-| Source delivery | none / repository-url / source-package / combination |
-| Max concurrency / corrections | `<n>` / `3` |
-| Review | standards + spec + Lead verification + conditional E2E |
+| Ticket | 开始条件 | 执行 owner | 必跑验证 | Evidence | 集成条件 |
+|---|---|---|---|---|---|
 
 ### Authorization Matrix
 
@@ -92,31 +83,9 @@ ready_for_execution: false
 | Deploy / Migration | allowed / not-authorized | ... |
 | Production configuration / feature / real user data | allowed / not-authorized | ... |
 
-### Per-Ticket Dispatch Packets
-
-#### Dispatch: T-01
-
-- **Goal / observable result：**
-- **Priority on conflict：** correctness > contract completeness > speed，或当前项目裁决
-- **Implement / Ticket：** `<Path>{roots.workflows}/specdev/I-implement/I-implement.md</Path>`；`<Path>{roots.state}/specdev/changes/{change}/ticket/01-<name>.md</Path>`
-- **Authority / dependencies：** 相关合同、ADR/CONTEXT、已完成依赖 Evidence
-- **Wave / Gate / hard constraints：**
-- **Writable / read-only / shared owner：**
-- **Baseline / branch / workspace or session locator / package hash：**
-- **Preflight receipt：** 在 `<Path>{roots.state}/specdev/changes/{change}/evidence/T-01.md</Path>` 记录目标、顺序、最大风险和基线差异，不超过 10 行
-- **Verification / baseline / reverse check：**
-- **Authorization / deviation / correction limit：**
-- **Return：** 状态、Evidence、locator、最终 checkpoint、commit/PR、未验证项、待 Lead E2E
-
-并行写代码时记录统一 `base_sha`，并为每个 Ticket 指定分支、`workspace_ref` 和 worktree owner。每个派单块可以独立投递，但不复制完整 Ticket 或历史对话。
-
-### Ticket Execution
-
-引用 `<Path>{roots.workflows}/specdev/I-implement/I-implement.md</Path>` 和对应 `<Path>{roots.state}/specdev/changes/{change}/ticket/{ticket-file}.md</Path>`，不复制 Ticket 全文。
-
 ### Evidence Return and Integration
 
-Worker 将 Ticket 推进到 `review`，返回 Ticket ID 与状态、Evidence 路径、`workspace_ref`、commit 或 PR 引用，以及条件性 Lead E2E；Lead 负责集成、回归和 worktree 收尾。
+每个实现者按 I-implement 与对应 Ticket 执行，写入 Evidence 并同步 Ticket/Map/Goal Plan。最后一个计划内 Implement 汇总 Gate、运行适用集成验证，并按完成合同关闭 change。
 
 ## 5. Constraints, Risk and Recovery
 
@@ -140,15 +109,15 @@ Worker 将 Ticket 推进到 `review`，返回 Ticket ID 与状态、Evidence 路
 
 ### Current Status
 
-记录 Wave/Gate、Ticket、checkpoint、workspace/session locator、修正轮次和未验证项；不使用主观百分比。
+记录 Wave/Gate、Ticket、最近验证证据和未验证项；不使用主观百分比。
 
 ### Pending Decisions and Blockers
 
-达到修正上限时记录最后可信 checkpoint、失败命令、已通过行为、owner 和恢复条件。
+记录失败命令、已通过行为、owner 和恢复条件。
 
 ### Resume Protocol
 
-恢复时读取本 Goal Plan、当前 Ticket、最新 Evidence 和 change 状态，从最后已验证 checkpoint 继续。
+恢复时读取本 Goal Plan、当前 Ticket、最新 Evidence 和 change 状态，从最后已验证事实继续。
 
 ### Reporting Format
 

package/template/workflows/specdev/P-goal-plan/orchestration-protocol.md

@@ -1,6 +1,6 @@
-# Goal Plan 编排协议
+# Goal Plan 核心编排协议
 
-本文件定义 DAG、Wave、Gate、路径所有权、Delivery Contract、Dispatch Packet、Evidence 返回和集成规则。
+本文件定义所有 Goal Plan 都需要的 DAG、Wave、Gate、路径所有权、Evidence 返回和集成规则。它不建立 Lead/subagent 角色或 Agent 交付合同。
 
 ## 1. DAG 与关键路径
 
@@ -19,20 +19,13 @@ Wave 内 Ticket 必须同时满足：
 - 项目写路径不相交；
 - shared path 已由 owner 稳定；
 - 适用 Gate 已打开；
-- 基线和外部合同版本一致。
+- 源码基线和外部合同版本一致。
 
-最大并发从 `<Path>{roots.state}/specdev/config.json</Path>` 读取。并发上限是资源约束，不是强制填满的目标。
+最大并发从 `<Path>{roots.state}/specdev/config.json</Path>` 读取。并发上限是资源约束，不是必须填满的目标；Wave 也不意味着必须使用多个 Agent。
 
 ## 3. Gate
 
-Gate 由可验证状态定义，不用“完成若干 Ticket”作为唯一条件。每个 Gate 必须写明：
-
-- 业务或工程状态；
-- 开启条件；
-- 关闭证据；
-- 阻塞范围；
-- owner 与批准人；
-- 失败时恢复动作。
+Gate 由可验证状态定义，不用“完成若干 Ticket”作为唯一条件。每个 Gate 必须写明业务或工程状态、开启条件、关闭证据、阻塞范围、owner/批准人和失败恢复。
 
 常见 Gate 包括共享合同稳定、首条垂直路径通过、迁移完成、旧调用点归零、发布就绪和观察期结束。名称按项目语义自定义。
 
@@ -40,11 +33,11 @@ Gate 由可验证状态定义，不用“完成若干 Ticket”作为唯一条
 
 规则遵循 `<Path>{roots.workflows}/specdev/common/rules/path-ownership.md</Path>`：
 
-1. 由专用 owner Ticket 或 Lead 修改共享路径；
+1. 由专用 owner Ticket 或计划指定的唯一 owner 修改共享路径；
 2. 形成可验证稳定基线；
 3. 下游消费者在新基线上重新运行 preflight；
-4. 才允许扇出并行；
-5. 共享契约需要变化时暂停消费者并修订上游，不通过多个 Agent 同时修改解决。
+4. 才允许扇出或继续后续 Ticket；
+5. 共享契约需要变化时暂停消费者并修订上游，不通过多个执行者同时修改解决。
 
 ## 5. Expand-contract
 
@@ -58,62 +51,17 @@ Gate 由可验证状态定义，不用“完成若干 Ticket”作为唯一条
 
 收缩不得仅以“所有迁移 Ticket 已完成”为依据。
 
-## 6. Lead 与 Delivery Contract
-
-Lead 负责源码基线、DAG、Wave、shared owner、Gate、权限、Evidence 汇总和集成；已派发 Ticket 的实现由对应执行者负责，Lead 不制造双重 owner。
-
-Goal Plan 选择唯一 execution model：`direct`、`native-subagent` 或 `external-web-subagent`。Lead 以 `operation=plan` 调用 `<Path>{roots.workflows}/specdev/common/skills/subagent-delivery/SKILL.md</Path>`，生成里程碑级 Delivery Contract；Implement 阶段以 `operation=execute` 调用同一 Skill 做恢复和验收。
-
-Delivery Contract 必须固定：
-
-- execution model、Lead、provider 和可恢复 workspace/session locator；
-- repository、branch、不可变 checkpoint 与源码交付方式；
-- 最大并发和默认 3 轮的 `max_correction_rounds`；
-- 标准轴、规范轴、Lead 独立验证和条件性 E2E；
-- local changes、commit、push、PR、merge、deploy、migration 和生产动作的逐项授权；
-- 完成、阻塞、偏差、恢复和返回协议。
-
-并行写代码且配置允许时，Lead 为每个 Ticket 调用 `<Path>{roots.workflows}/specdev/common/skills/dev-worktree/SKILL.md</Path>`。所有并行 Ticket 固定同一 `base_sha`，每个 Ticket 使用独立分支和 `workspace_ref`；Lead 创建、恢复、集成和清理，Worker 只推进到 `review`。只读调查和顺序执行不为形式创建 worktree。
-
-**完成标准**：整个 Goal Plan 只有一个 execution model 和 Lead；每个高影响动作都有明确授权状态。
-
-## 7. Dispatch Packet
+## 6. Ticket 执行、Evidence 与集成
 
-每个计划 Ticket 都生成一个可独立投递的 Dispatch Packet。它不是 Ticket 副本，而是进入权威工件和当前基线的紧凑入口，至少包含：
+每个计划 Ticket 必须写明开始条件、依赖 Evidence、项目路径合同、适用 Gate、必跑验证、Evidence 目标和失败恢复。实际执行仍由 `<Path>{roots.workflows}/specdev/I-implement/I-implement.md</Path>` 与 Ticket 拥有，不在 Goal Plan 复制局部施工步骤。
 
-1. Ticket ID、目标、可观察完成结果和优先级冲突裁决；
-2. `<Path>{roots.workflows}/specdev/I-implement/I-implement.md</Path>` 与 `<Path>{roots.state}/specdev/changes/{change}/ticket/{ticket-file}.md</Path>`；
-3. 相关 Spec 合同、ADR/CONTEXT 条目、Wave、Gate 和不可协商约束；
-4. 已完成依赖及其 `<Path>{roots.state}/specdev/changes/{change}/evidence/{ticket-id}.md</Path>`；
-5. 项目 `writable_paths`、`read_only_paths`、`shared_paths` 与唯一 shared owner；
-6. `base_sha`、branch、workspace/session locator 和 source package hash；
-7. 必跑验证、基线指标、可静默失效门禁的反向验证，以及明确不适用项；
-8. 当前授权、偏差升级、修正上限、Evidence 路径和返回字段。
+每个实现者完成或阻塞时：
 
-派单块将不可违反项写为 Hard Constraints，将低影响实现自由写为 Guidance。执行者必须先核对 checkpoint、项目指令、路径和验证命令，再在 Ticket Evidence 记录不超过 10 行的开工回执：目标、执行顺序、最大风险和发现的基线差异。事实不一致时停止受影响路径并升级，不用更详细文字掩盖失效前提。
-
-Agent 的最小读取顺序为 Implement work、当前 Ticket、Goal Plan 中适用的 Delivery Contract/Dispatch Packet、相关 Spec/ADR/CONTEXT、项目 Agent 指令和当前代码事实。不投递完整历史对话、全部 Ticket 或无关研究。
-
-**完成标准**：每个 Dispatch Packet 可在新上下文中定位全部权威输入、边界、基线、验证、恢复点和返回目标。
-
-## 8. Evidence 返回与集成
-
-Agent 完成或阻塞时：
-
-1. 写入 `<Path>{roots.state}/specdev/changes/{change}/evidence/{ticket-id}.md</Path>`，包含实际修改、命令与退出状态、验收映射、反向验证、修正轮次、checkpoint 和未验证项；
+1. 写入 `<Path>{roots.state}/specdev/changes/{change}/evidence/{ticket-id}.md</Path>`；
 2. 同步 Ticket、Tickets Map、Goal Plan 和 change 状态；
-3. 向 Lead 返回 Ticket ID 与状态、Evidence 完整路径、workspace/session locator、最终 checkpoint、commit/PR 引用和条件性 Lead E2E。
-
-Lead 接收原生或外部候选交付时：
-
-1. 读取 Dispatch Packet、Ticket、Evidence、Goal Plan 和对应代码引用；
-2. 检查 checkpoint、附件 hash、路径授权、依赖和敏感信息边界；
-3. 在隔离基线上应用交付，复跑定向验证和受影响回归；
-4. 仅当用户界面交互受影响时，由 Lead 运行最小 E2E；
-5. 将 provider 声明、模拟结果和静态推断保持为 `unverified`，直到有独立证据；
-6. 验证通过后集成，并按 dev-worktree Skill 更新或清理 worktree；
-7. 同步 Ticket、Map、Evidence 和 Goal Plan，检查 Gate 是否可关闭。
+3. 检查依赖、路径所有权、合同覆盖和适用 Gate；
+4. 返回 Ticket 状态、Evidence 路径、代码引用、未验证项和恢复条件。
 
-同一验收项达到修正上限时标记 blocker，记录最后 checkpoint、错误、已通过行为、责任方和恢复条件。逻辑冲突返回契约 owner 解决，不机械选择某一侧版本。
+最后一个计划内 Implement 按 `<Path>{roots.workflows}/specdev/P-goal-plan/completion-control.md</Path>` 汇总核心计划的 Gate 和 Evidence。委派分支的候选交付与 Lead 集成由独立委派协议拥有，不写入本文件。
 
-**完成标准**：每个完成声明可追溯到 Lead 核对的代码状态和 Evidence；失败也具有可恢复的最后可信 checkpoint。
+**完成标准**：每个执行结果可追溯到代码状态和 Evidence；普通 Goal Plan 可以在不建立角色交付合同的情况下完整恢复和完成。

package/template/workflows/specdev/P-goal-plan/planning-modes.md

@@ -1,6 +1,6 @@
 # Goal Plan 规划模式与输入门禁
 
-本文件由 `<Path>{roots.workflows}/specdev/P-goal-plan/P-goal-plan.md</Path>` 在上游验证和模式选择时加载。
+本文件由 `<Path>{roots.workflows}/specdev/P-goal-plan/P-goal-plan.md</Path>` 在上游验证和角色分支确认时加载。
 
 ## 1. 必需输入门禁
 
@@ -25,75 +25,45 @@
 - 合同 uncovered 且未批准 deferred；
 - 并行候选写路径相交且无 owner 或顺序；
 - Ticket 改写了 Spec 的外部行为、范围或验收；
-- Ticket 与 `<Path>{roots.state}/specdev/changes/{change}/ADR.md</Path>` 的已接受决策冲突；
+- Ticket 与 `<Path>{roots.state}/specdev/changes/{change}/ADR.md</Path>` 的已接受决定冲突；
 - Deep Ticket 缺少关键迁移或恢复信息；
 - 当前代码事实使 Ticket 的核心行为、接口或验证不可执行；
 - 必需外部合同或参考权威不可获得；
-- 选择 delegated execution，但 Lead、checkpoint、可恢复 locator 或交付通道无法建立；
+- 已选择委派，但 Lead、checkpoint、可恢复 locator 或交付通道无法建立；
 - 用户要求的远程或生产动作没有逐动作授权。
 
 按 `<Path>{roots.workflows}/specdev/common/rules/artifact-contract.md</Path>` 和 `<Path>{roots.workflows}/specdev/common/rules/deviation-control.md</Path>` 返回真正拥有该决策的工件。
 
-## 3. 可组合模式
+## 3. 可组合规划模式
 
-### coordination
-
-适用于多 Wave、扇出/汇合、shared path 或 Lead/Subagent。重点是 DAG、owner、Evidence 返回、集成和状态同步。
-
-### migration
-
-适用于 expand-contract、数据迁移、协议迁移或兼容窗口。重点是扩展、分批迁移、收缩条件、数据核对、监控和回滚。
-
-### high-assurance
-
-适用于安全、隐私、资金、数据完整性、法规或不可逆操作。重点是独立审查、人工批准、Evidence 完整性和失败恢复。
-
-### reference-conformance
-
-适用于外部合同、标准、官方实现或指定兼容行为。重点是来源版本、符合性矩阵和冲突裁决。
-
-### release-coordination
-
-适用于发布窗口、跨团队依赖、部署顺序或运营交接。重点是环境前置条件、Gate、观察期和回退。
+- **coordination**：多 Wave、扇出/汇合或 shared path；重点是 DAG、owner、Evidence 返回、集成和状态同步。
+- **migration**：expand-contract、数据或协议迁移；重点是扩展、分批迁移、收缩条件、数据核对、监控和回滚。
+- **high-assurance**：安全、隐私、资金、数据完整性、法规或不可逆操作；重点是独立审查、人工批准、Evidence 完整性和失败恢复。
+- **reference-conformance**：外部合同、标准、官方实现或指定兼容行为；重点是来源版本、符合性矩阵和冲突裁决。
+- **release-coordination**：发布窗口、跨团队依赖、部署顺序或运营交接；重点是环境前置条件、Gate、观察期和回退。
 
 模式可以组合。仅有线性低风险 Ticket 时不应为了形式生成重型 Goal Plan。
 
-## 4. 执行模型与交付事实
+## 4. 每次确认角色分支
 
-规划模式描述“为什么需要治理”，execution model 描述“每个 Ticket 怎样被执行”，两者不得混为同一枚举。每份 Goal Plan 只选一个主 execution model：
+规划模式描述为什么需要跨 Ticket 治理，不决定是否启用 Lead/subagent。每次运行 P 都向用户提供两个选择：
 
-- `direct`：Lead 或当前执行者直接运行 Ticket，不创建子代理交付通道；
-- `native-subagent`：Lead 可直接管理隔离 Agent，写代码并行时配合 `<Path>{roots.workflows}/specdev/common/skills/dev-worktree/SKILL.md</Path>`；
-- `external-web-subagent`：通过网页 provider 交付，输出在 Lead 独立核对前保持候选状态。
+- **普通 Goal Plan**：由实现者按核心计划推进，不创建严格角色、交付通道或派单合同；最终产物不记录一个名为 direct 的模式。
+- **委派 Goal Plan**：启用唯一 Lead 与 `native-subagent` 或 `external-web-subagent`，并加载委派协议。
 
-选择模型前先发现当前平台能力、项目配置和用户请求。只有用户明确指定 provider 或交付通道时才把偏好当作约束；否则优先使用能保留隔离、checkpoint 和 Evidence 的现有原生能力。
+不得根据 Ticket 数量、并行机会或平台能力静默启用委派。选择普通分支后，AI 自适应决定核心计划的适用细节，不把本次角色选择写入 frontmatter，也不在正文生成空章节或“不适用”说明。
 
-必须固定：
+选择委派后才固定：Lead、provider、repository/branch、不可变 `base_sha` 或等价基线、源码交付方式、`max_correction_rounds` 和逐动作授权。认证秘密和机器绝对路径不得进入 Goal Plan。
 
-- `lead` 与不可转移责任；
-- provider 和稳定 workspace/session locator，direct 时为不适用；
-- repository/branch 与不可变 `base_sha` 或等价本地基线；
-- `source_delivery`：none、repository-url、source-package 或 combination；
-- `max_correction_rounds`，默认 3；
-- local changes、commit、push、PR、merge、deploy、migration、production configuration、production feature、real user data 的逐动作授权。
+## 5. 规划摘要
 
-GitHub checkpoint、源码包和 provider 分支由 `<Path>{roots.workflows}/specdev/common/skills/subagent-delivery/SKILL.md</Path>` 按需加载。认证秘密和机器绝对路径不得进入 Goal Plan。
-
-## 5. 模式摘要
-
-写入 `<Path>{roots.state}/specdev/changes/{change}/goal-plan.md</Path>` 前形成：
+写入前形成核心摘要：
 
 ```text
 modes=<mode-list>
-execution_model=<direct|native-subagent|external-web-subagent>
-lead=<owner>
-provider=<id|none>
 tickets=<count>
 critical_path=<ticket-list>
 parallel_capacity=<n>
-checkpoint=<sha-or-local-baseline>
-source_delivery=<mode>
-max_correction_rounds=<n>
 shared_owners=<owner-map>
 gates=<gate-list>
 authorization=<action-summary>
@@ -101,4 +71,6 @@ hard_stops=<none-or-list>
 adopted_assumptions=<low-impact-only>
 ```
 
-**完成标准**：可组合 modes 与唯一 execution model 分离；源码、交付、权限和恢复字段都有可验证值。
+委派分支额外形成 `execution_model`、`lead`、`provider`、`checkpoint`、`source_delivery`、`max_correction_rounds` 和 locator；这些字段只进入委派附录。
+
+**完成标准**：规划 modes 与角色选择互不代替；普通计划没有委派痕迹；委派计划的源码、交付、权限和恢复字段都有可验证值。

package/template/workflows/specdev/P-prototype/P-prototype.md

@@ -0,0 +1,46 @@
+---
+id: specdev/prototype
+type: workflow-entry
+workflow: specdev
+name: 原型
+description: 在获授权的临时 branch/worktree 中构建一次性 Logic 或 UI 原型，回答一个明确设计问题并持久化答案、资产定位和清理状态。
+keywords: [prototype, 原型, logic, UI, variant, 一次性代码, 设计问题]
+---
+
+# 原型
+
+原型是**回答一个问题的一次性代码**。P 不交付生产实现，也不把原型代码提升到 main；它把答案和一手资料 locator 交给后续 G/S/Tickets/I。
+
+## 输入与所有权
+
+- 一个可精确陈述的问题，来自用户、G、Spec 或 `<Path>{roots.state}/specdev/changes/{change}/investigation/{investigation-id}.md</Path>`；
+- 相关代码、组件系统、领域上下文和 ADR；
+- 获授权的项目可写范围及临时 branch/worktree。
+
+P 拥有 `<Path>{roots.state}/specdev/changes/{change}/prototypes/{prototype-id}/record.md</Path>`。代码写在临时 workspace 的项目路径附近；state 只保存项目相对 Path、branch、commit 和可迁移 `workspace_ref`。
+
+## 流程
+
+1. **锁定问题**：一个 record 只回答一个问题。业务逻辑、状态转换或数据形态使用 Logic；页面外观、信息层级或交互布局使用 UI。问题含糊且用户不在线时按周围代码选择，并在 record 写明假设。
+2. **建立临时工作区**：按 `<Path>{roots.workflows}/specdev/common/skills/dev-worktree/SKILL.md</Path>` 创建/恢复工作区。创建 branch、commit 或删除 worktree 分别遵守现有授权边界；路径名明确包含 prototype。
+3. **执行分支**：Logic 加载 `<Path>{roots.workflows}/specdev/P-prototype/logic-prototype.md</Path>`；UI 加载 `<Path>{roots.workflows}/specdev/P-prototype/ui-prototype.md</Path>`。两个分支都把完整状态呈现给评审者，不依赖生产数据写入。
+4. **捕获答案**：使用 `<Path>{roots.workflows}/specdev/P-prototype/prototype-record-template.md</Path>` 记录问题、运行方法、资产、验证反馈、赢家/拒绝项、结论、promotion target 和清理状态，原子重读。
+5. **关闭或阻塞**：答案已确认时 `status: answered`；用户选择不继续时 `discarded`；原型无法回答问题时 `blocked` 并说明缺失输入。Wayfinder 调用时，把 record/branch/URL 写入当前 Ticket 的 solution comment，并只关闭该 Ticket。
+6. **验证与路由**：使用 `<Path>{roots.workflows}/specdev/common/tools/validate-specdev.mjs</Path>` 的 `--stage prototype` 校验当前 change。需要产品决定返回 G，需要外部行为合同返回 S，需要执行计划返回 Tickets；生产实现只进入 I。
+
+## 完成标准
+
+- 只有一个问题和一个正确分支；
+- 原型极易运行，完整状态可见；
+- 临时 branch/worktree 与项目路径可恢复且不含机器绝对路径；
+- 原型没有测试、生产数据库依赖或伪装成生产代码；
+- 答案、资产、赢家、拒绝项、promotion target 和清理状态完整；
+- main 不保留落选变体、switcher 或原型外壳；
+- Wayfinder Ticket、solution comment 与 prototype record 可互相定位。
+
+## 子文件引用
+
+- Logic：`<Path>{roots.workflows}/specdev/P-prototype/logic-prototype.md</Path>`
+- UI：`<Path>{roots.workflows}/specdev/P-prototype/ui-prototype.md</Path>`
+- Record：`<Path>{roots.workflows}/specdev/P-prototype/prototype-record-template.md</Path>`
+- Schema：`<Path>{roots.workflows}/specdev/common/schemas/prototype-record.schema.json</Path>`

package/template/workflows/specdev/P-prototype/logic-prototype.md

@@ -0,0 +1,24 @@
+# Logic Prototype
+
+当问题涉及业务逻辑、状态转换或数据形态时使用。
+
+## 形态
+
+构建单个自包含 HTML/CSS/JS 文件，无框架、打包器或服务器，双击即可运行。顶部用领域语言写明唯一问题。
+
+实际逻辑放在独立纯模块中，可使用 reducer、状态机、纯函数集或有清晰方法面的模块；逻辑不得引用 DOM。页面只是调用模块的薄外壳。
+
+## 界面
+
+按顺序呈现：
+
+1. 问题与一行说明；
+2. 带字段标签的完整当前状态；
+3. 每个动作一个、始终可用的自由按钮；
+4. 至少 happy、edge、illegal 三个引导演练，每次从已知初始状态开始。
+
+每次操作后重绘完整相关状态，并说明刚发生的变化。标签使用业务语言，不显示 reducer/内部代码术语。
+
+## 边界
+
+默认内存状态；问题明确涉及持久化时才使用标记为 `PROTOTYPE - DELETE` 的临时本地数据。无测试、生产数据库、抽象层或超出问题的错误处理。答案确认后由 I 正式实现；HTML 外壳只保留在临时分支。

package/template/workflows/specdev/P-prototype/prototype-record-template.md

@@ -0,0 +1,46 @@
+---
+schema_version: 1
+artifact: prototype-record
+change: <YYYY-MM-DD-topic>
+prototype_id: PROTO-001
+question: <one design question>
+branch: logic
+status: active
+workspace_ref: <portable-locator>
+project_paths: []
+assets: []
+winner: null
+promotion_target: null
+cleanup_status: pending
+updated_at: <ISO-8601>
+---
+
+# Prototype PROTO-001: <问题短名>
+
+## Question and Assumption
+
+- **Question:**
+- **Why a prototype is needed:**
+- **Branch selection evidence:**
+- **Assumption when user was unavailable:** none / ...
+
+## Run and Assets
+
+- **Command or URL:**
+- **Branch / commit:**
+- **Workspace locator:**
+- **Project-relative assets:**
+
+## Evaluation
+
+- **Scenarios or variants reviewed:**
+- **Observed feedback:**
+- **Answer:** unresolved / ...
+- **Winner and rejected options:**
+
+## Promotion and Cleanup
+
+- **Promotion target:** none / `<Path>{roots.state}/specdev/changes/{change}/ticket/{ticket-file}.md</Path>`
+- **Main cleanup:** pending / clean
+- **Temporary branch retained:** yes / no / pending authorization
+- **Wayfinder solution comment:** not-applicable / `<Path>{roots.state}/specdev/changes/{change}/investigation/comments/{investigation-id}/NN-solution.md</Path>`

package/template/workflows/specdev/P-prototype/ui-prototype.md

@@ -0,0 +1,21 @@
+# UI Prototype
+
+当问题是页面外观、信息层级或交互布局时使用。
+
+## 选择宿主
+
+优先把变体嵌入现有页面，保留真实页头、侧栏、数据获取、参数和认证，只切换渲染子树。确实没有合理宿主时，才按项目约定创建明显标注 prototype 的临时路由。
+
+## 变体
+
+默认 3 个，最多 5 个。每个变体必须在布局、信息层级或主要操作入口上结构不同，不能只换颜色或文案。使用项目现有组件和样式系统，但不要共享会限制结构探索的布局抽象。
+
+## 切换器
+
+使用 `?variant=` 保存并分享选择。浮动底栏提供前一项、当前名称、后一项和循环切换；左右方向键可切换，但 input、textarea 或 contenteditable 聚焦时不截获。切换器必须在 production build 隐藏。
+
+变更操作使用桩；UI 原型不写生产数据。完整相关状态在每个变体中可见。
+
+## 收束
+
+记录赢家、组合选择和理由。I 依据答案正确重写生产实现；落选变体、临时路由和 switcher 从 main 删除，完整集合保留在临时分支作为一手资料。

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

@@ -96,7 +96,7 @@ keywords: [architecture, review, module, interface, depth, seam, adapter, levera
 
 - 新概念加入 change CONTEXT；永久 CONTEXT 不存在时延迟到归档提升；
 - 模糊术语当场精炼；
-- 用户以长期有效理由拒绝候选时，询问是否记录 ADR，暂时性或自明理由不制造 ADR；
+- 用户的选择同时难以逆转、没有上下文会令人惊讶且来自真实权衡时，询问是否记录 ADR；任一条件不满足就留在 LOG/Ticket，不制造 ADR；
 - 替代 interface 需要探索时使用 `<Path>{roots.workflows}/specdev/I-implement/design-it-twice.md</Path>`。
 
 将选择、访谈状态与结论同步到 Markdown/HTML；每次运行只访谈用户选择的候选，不批量迫使用户决定所有卡片。

package/template/workflows/specdev/S-spec/S-spec.md

@@ -17,7 +17,7 @@ Spec 决定“为什么、为谁、系统应表现为何”。它可以锁定影
 
 按存在情况读取：
 
-- `<Path>{roots.state}/specdev/changes/{change}/source-issue.md</Path>`
+- `<Path>{roots.state}/specdev/changes/{change}/source.md</Path>`
 - `<Path>{roots.state}/specdev/changes/{change}/triage.md</Path>`
 - `<Path>{roots.state}/specdev/changes/{change}/diagnosis.md</Path>`
 - `<Path>{roots.state}/specdev/changes/{change}/LOG.md</Path>`
@@ -121,6 +121,7 @@ Spec 决定“为什么、为谁、系统应表现为何”。它可以锁定影
 
 ```bash
 node <Path>{roots.workflows}/specdev/common/tools/validate-specdev.mjs</Path> \
+  --stage spec \
   <Path>{roots.state}/specdev/changes/{change}</Path>
 ```
 

package/template/workflows/specdev/T-tickets/T-tickets.md

@@ -111,7 +111,7 @@ Ticket 是**决策完备的微型执行计划**：它消除执行者在目标、
 - 有序执行路线和安全落点；
 - expected、writable、read-only、shared 路径；
 - 正常、失败和回归验证矩阵；
-- 用户界面交互受影响时的 Lead E2E Gate；
+- 用户界面交互受影响时的 E2E Gate 与执行 owner；后续委派 Goal Plan 可以显式把该 Gate 转交 Lead；
 - Deep 的迁移、兼容窗口、监控、回滚和不可逆批准点；
 - 可判定验收标准。
 
@@ -124,7 +124,7 @@ Ticket 是**决策完备的微型执行计划**：它消除执行者在目标、
 3. 识别根 Ticket、汇合点、扇出与收缩点；
 4. 为每个 Spec 验收合同映射至少一个 Ticket；
 5. 检查并行候选的 `writable_paths` 是否相交；
-6. 共享路径必须指定唯一 owner，通常由 Lead 或专门 Ticket 修改；
+6. 共享路径必须指定唯一 owner，通常由专门 Ticket 或明确的集成 owner 修改；
 7. 不得用依赖边表达“可能更方便”或纯粹的人员交接。
 
 使用 `<Path>{roots.workflows}/specdev/T-tickets/tickets-map-template.md</Path>` 草拟总体 Map。
@@ -192,6 +192,7 @@ Ticket 是**决策完备的微型执行计划**：它消除执行者在目标、
 
 ```bash
 node <Path>{roots.workflows}/specdev/common/tools/validate-specdev.mjs</Path> \
+  --stage tickets \
   <Path>{roots.state}/specdev/changes/{change}</Path>
 ```
 

package/template/workflows/specdev/T-tickets/ticket-readiness.md

@@ -14,7 +14,7 @@
 - [ ] `writable_paths` 非空，或明确为仅文档、调查或无代码变更。
 - [ ] 每个 shared path 在 `shared_path_owners` 中有唯一 owner。
 - [ ] 正常、失败和回归至少各有一条验证，或有可信的不适用原因。
-- [ ] 仅当用户界面交互受影响时定义 E2E，且 owner 为 Lead 集成 Gate。
+- [ ] 仅当用户界面交互受影响时定义 E2E 与当前执行 owner；Ticket 不预设 Lead/Worker，委派 Goal Plan 可以显式改由 Lead 集成。
 - [ ] Evidence 位置明确为 `<Path>{roots.state}/specdev/changes/{change}/evidence/{ticket-id}.md</Path>`。
 - [ ] 单个全新上下文能够完成；否则已拆分。
 - [ ] 所有内部文件与目录引用使用完整根变量 Path 标签。

package/template/workflows/specdev/T-tickets/ticket-template.md

@@ -102,7 +102,7 @@ shared_path_owners: []
 
 不适用的关键风险类别必须写“不适用：原因”。
 
-仅当用户界面交互受影响时增加 E2E 行；owner 固定为 Lead 集成 Gate，Worker 只提供场景与预期。
+仅当用户界面交互受影响时增加 E2E 行并指定当前执行 owner。若后续 Goal Plan 含委派附录，再由该计划显式转交 Lead；Ticket 不预设 Lead/Worker 角色。
 
 ## 9. 发布、迁移与恢复
 

package/template/workflows/specdev/T-tickets/tickets-map-template.md

@@ -47,7 +47,7 @@ T-01 [READY]
 ## 5. 并行与路径所有权
 
 - 最大并发来自 `<Path>{roots.state}/specdev/config.json</Path>`。
-- shared owner 为 Lead 或专用 Ticket。
+- shared owner 为专用 Ticket 或明确的集成 owner；只有委派 Goal Plan 才使用 Lead 角色。
 - 项目路径契约以 Ticket frontmatter 为准。
 - 并行写代码的 Ticket 使用独立 worktree；只读调查不需要。