@namewta/speculo 0.3.0 → 0.3.2

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

@@ -1,103 +0,0 @@
-# 治理章节 §6-8 编写规程
-
-编写 goal-plan 的里程碑验收、硬约束和进度回报格式。这三个章节定义"怎么验收"和"怎么追踪"。
-
-## §6 — Milestone-Level Acceptance
-
-### 五项仪式步骤
-
-全部 ticket 关闭后执行以下验收仪式：
-
-1. **合同/ADR 终审** —— 如果激活合同模式：逐行检查合同文档，确认所有行状态为 `done` 或 `deviate`（有记录理由），无 `todo` 残留；如果无合同但激活 ADR 模式：检查 ADR 偏差表条目已解决或明确记录为 `deviate`
-2. **整体验证门禁** —— 运行 spec 或项目脚本声明的整体验证命令（类型检查 + 测试 + 构建的组合），确认全绿
-3. **集成回归走查** —— 完成一次端到端用户旅程脚本走查
-4. **关闭 spec issue** —— 关闭关联的 spec issue，引用 milestone done
-5. **人工 side-by-side 验证清单** —— 输出人工核对清单供用户在真机上执行最终手感验收
-
-### 集成回归走查脚本构造
-
-从 spec.md 的 User Stories 和 ticket 的验收标准推导端到端用户旅程：
-
-- 提取每个 User Story 的关键交互步骤
-- 按用户使用顺序串联（不按 ticket 编号）
-- 每个步骤写为具体的操作指令（命名具体的按钮、输入、期望行为）
-- 覆盖主路径和至少一条备选路径
-
-格式：编号列表，每一步包含"操作 → 期望"。
-
-### 人工 side-by-side 清单构造
-
-- 按门禁层级（P0/P1/P2）分组
-- 如果激活参考权威模式：每项包含参考权威对比步骤（"对照 X 中的 Y——行为是否一致？"）
-- 结尾注明："自动化不替代最终手感环节"
-
-### 草拟与确认
-
-输出 §6 完整草案（五项步骤 + 回归走查脚本 + side-by-side 清单分组）。等待用户确认后进入 §7。
-
-## §7 — Hard Constraints
-
-### 约束推导
-
-从模式检测和 ADR 推导所有非协商约束。每条约束写为一句声明 + 违反后果。
-
-#### 通用约束（所有 goal-plan 包含）
-
-1. **合同/规格冻结** —— 如激活合同模式：「合同一旦冻结不得修改。如需修改，先修改合同再继续实现。违反即返工。」；否则：「spec 的 User Stories 和 Implementation Decisions 为权威。超出 spec 的范围变更需先更新 spec。」
-2. **领域不变量优先** —— 「架构决策中声明的领域不变量先于实现便利。违反即返工。」
-3. **伪完成禁止** —— 「能力存在但手感、交互细节、边界情况、空状态文案与参考/规格不一致，视为未完成。禁止以"API 通了"为由关闭 ticket。」
-4. **Git 纪律** —— 如果使用 Lead+Subagent 模型：「仅 Lead 操作 Git（提交、合并、推送）。子代理输出 diff/patch，Lead 审查后提交。」
-5. **单一真相源** —— 「不复活废弃组件、不创建规格外的新抽象、不引入与 ADR 冲突的外部依赖。所有技术决策追溯到 ADR 或 LOG。」
-6. **沟通语言** —— 「全部代码注释、提交信息、issue 评论、进度报告使用 {report_language}。」（生成 goal-plan 时从 `<Path>{roots.state}/specdev/config.json</Path>` 的 `defaults.report_language` 读取并填入具体语言）
-
-#### 模式特定约束
-
-- **合同模式**：「合同条目状态回写必须在 ticket 关闭前完成。先回写合同，再关闭 issue。」
-- **参考权威模式**：「任何与参考权威的行为差异必须追溯到一个偏差条目（DEV-NN）。无条目偏差视为缺陷。」
-- **Lead+Subagent 模式**：「Lead 不得实现代码。发现 Lead 写实现代码时输出 DELEGATION_VIOLATION 并重新派单。子代理不得提交——只输出 patch。」
-- **偏差模式**：「偏差条目（DEV-NN）关闭条件是：要么通过实现消除偏差，要么在偏差表中记录为 deviate 并附理由。」
-
-### 草拟与确认
-
-输出 §7 完整约束列表。等待用户确认后进入 §8。
-
-## §8 — Progress Reporting Format
-
-### 模板定制
-
-根据执行模型和合同模式定制进度回报格式：
-
-#### TICKET_DONE 格式（Lead+Subagent 模型）
-
-```
-TICKET_DONE <n> (<k>/<N>) gate=<P0|P1|P2> contract_ids=<P0-01,P1-03> verify=<cmd:result> commit=<sha>
-```
-
-字段说明：
-- `<n>` —— ticket 编号（格式见 T-tickets）
-- `(<k>/<N>)` —— 进度计数（当前第几个 / 总数）
-- `gate` —— 门禁层级
-- `contract_ids` —— 如激活合同模式，列出本 ticket 覆盖的合同条目 ID，逗号分隔；如无合同则使用 `adr_ref=<ADR-NNNN>`
-- `verify` —— 验证命令及结果（PASS/FAIL）
-- `commit` —— 提交 SHA
-
-#### MILESTONE_DONE 格式
-
-所有 ticket 关闭后输出：
-
-```
-MILESTONE_DONE issues_closed=<N>/<N> contract_todo=0 verify=GREEN
-```
-
-如果无合同模式：将 `contract_todo=0` 替换为 `adr_deviate_resolved_or_recorded=YES`。
-
-#### 格式变体
-
-- **切面跟踪**（ticket 数 > 15 时推荐）：在 TICKET_DONE 中增加 `slice=<ADR|DATA|SHELL|WORK|...>` 字段，按切面分组追踪进度
-- **简化模型**：使用简化格式 `TICKET_DONE <n> verify=<cmd:result>`
-
-### 草拟与确认
-
-输出 §8 格式定义，包含一个填写示例。等待用户确认。
-
-**完成标准**：§6 五项验收步骤完整、回归走查脚本覆盖主路径和一条备选路径、side-by-side 清单按门禁分组；§7 约束条条为一句声明+后果、模式特定约束已根据检测结果定制；§8 模板字段已填入本里程碑的具体值（N、合同路径、验证命令），经用户确认。

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

@@ -1,94 +0,0 @@
-# 输入验证与模式检测
-
-在开始编写 goal-plan 任何章节之前，验证上游输入完整性并检测适用的编排模式。模式检测在第一步完成，后续所有章节根据检测结果适配内容。
-
-## 1. 必需输入检查
-
-逐项检查以下输入是否存在，缺失时按规则处理：
-
-| 输入 | 路径 | 缺失处理 |
-|------|------|----------|
-| spec.md | `<Path>{roots.state}/specdev/changes/{change}/spec.md</Path>` | **中止**——引导用户先运行 `S-spec`，无 spec 无法定义目标 |
-| tickets-map.md | `<Path>{roots.state}/specdev/changes/{change}/tickets-map.md</Path>` | **中止**——引导用户先运行 `T-tickets`，无 tickets 无法构建 DAG |
-| ADR.md | `<Path>{roots.state}/specdev/changes/{change}/ADR.md</Path>` | 继续但记录——约束推导将缺少架构锚点 |
-| CONTEXT.md | `<Path>{roots.state}/specdev/changes/{change}/CONTEXT.md</Path>` | 继续但记录——术语将草拟而非引用 |
-| LOG.md | `<Path>{roots.state}/specdev/changes/{change}/LOG.md</Path>` | 继续但记录——设计轨迹不可追溯 |
-
-如果 spec.md 和 tickets-map.md 均存在，继续下一步。任何必需项缺失且用户拒绝先运行上游 work，则中止。
-
-## 2. 模式检测
-
-对以下五个问题逐一回答，每个"是"激活对应的编排模式：
-
-### Q1：是否存在冻结合同/验收文档？
-
-在 spec.md 和 ADR.md 中搜索合同/验收文档引用。合同是包含编号验收条目（P0-01、P1-01 等）及状态值（`todo`/`done`/`deviate`/`n/a`）的外部文档。
-
-- **是** → 激活「冻结合同模式」：§2 权威输入优先级表增加合同行；§3 DoD 增加合同状态收敛条目；§5 执行协议包含回写合同步骤；§6 里程碑验收包含合同终审；§7 硬约束包含合同冻结
-- **否** → 使用简化模式：DoD 不含合同条目；执行协议不含回写合同；约束以 ADR 为权威
-
-### Q2：是否存在参考权威（UX 快照、既有代码库）？
-
-在 spec.md 的"解决方案"或"参考"段落中搜索对快照/代码库/产品的引用。
-
-- **是** → 激活「参考权威模式」：§2 权威输入优先级表增加参考权威行；§5 执行协议步骤 1 包含对照路径；§6 人工 side-by-side 清单增加参考权威对比列
-- **否** → 无参考权威：跳过参考对比相关内容
-
-### Q3：是否存在有意偏差（DEV-01...）？
-
-在合同文档或 ADR 中搜索偏差表（DEV-01 及更高编号）。偏差是预先批准的对参考权威的偏离。
-
-- **是** → 激活「偏差模式」：§2 权威输入增加偏差表引用；§3 DoD 增加偏差收敛条目；§5 执行协议步骤 6 包含偏差追踪
-- **否** → 无偏差追踪需求
-
-### Q4：ticket 数量在哪个范围？
-
-统计 tickets-map.md 中的 ticket 条目数：
-
-- **< 10 个** → 「轻量模式」：警告用户 goal-plan 为 10+ tickets 设计，提供两个选项：(a) 继续用简化模板（一步编写全部章节），(b) 跳过 goal-plan 直接进入 I-implement
-- **10-20 个** → 「标准模式」：启用并发控制（max 3），DAG 中等复杂度
-- **> 20 个** → 「复杂模式」：完整并发控制、严格门禁次序（P0→P1→P2）、§9 速查表强制追加
-
-### Q5：采用何种执行模型？
-
-检查用户是否有意使用 Lead+Subagent 模型。默认如果 ticket 数 ≥ 10 或有合同文档，推荐 Lead+Subagent。
-
-- **Lead+Subagent 模型** → §5 执行协议使用完整八步流程（读取→派单→实现→双轴审查→门禁→回写→关闭→纪律）；§7 硬约束包含 Lead 纪律规则；§8 进度回报使用 TICKET_DONE 格式
-- **简化模型** → §5 使用精简协议（读取→实现→审查→门禁→关闭）；不使用 TICKET_DONE 格式
-
-## 3. 冲突裁决顺序
-
-从检测到的模式推导冲突裁决顺序，默认顺序（从高到低）：
-
-1. 领域不变量（来自 ADR.md 架构决策）
-2. 冻结合同（如激活合同模式）
-3. 参考权威手感（如激活参考权威模式）
-4. spec.md 中的用户故事
-
-如果未激活合同模式，跳过第 2 项。如果未激活参考权威模式，跳过第 3 项。
-
-## 4. 输出模式检测摘要
-
-将检测结果汇总为结构化摘要，呈现给用户确认：
-
-```
-## 模式检测摘要
-
-| 检测项 | 结果 | 影响 |
-|--------|------|------|
-| 冻结合同 | 是/否 | ... |
-| 参考权威 | 是/否 | ... |
-| 有意偏差 | 是（DEV-01 至 DEV-0X）/ 否 | ... |
-| Ticket 数量 | N（轻量/标准/复杂） | ... |
-| 执行模型 | Lead+Subagent / 简化 | ... |
-| ADR 可用 | 是/否 | ... |
-| CONTEXT 可用 | 是/否 | ... |
-
-冲突裁决顺序：[推导结果]
-
-是否确认以上模式检测？如有误请纠正后继续。
-```
-
-用户确认或纠正后，进入远景章节编写。
-
-**完成标准**：五个模式检测问题均已回答；冲突裁决顺序已推导；摘要已呈现并获用户确认或纠正。

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

@@ -1,158 +0,0 @@
-# Lead 编排协议
-
-本协议扩展 §5 执行协议中的 Lead+Subagent 模型，覆盖 Lead 在子代理协调中的五个关键环节。当 Lead+Subagent 模型激活时，在 §5 步骤 2「派单」时加载，覆盖整个执行生命周期——从派单到收尾。
-
-协议覆盖：子代理派单上下文载荷、执行完成后 handoff 交接、并行执行合并冲突解决、Worktree 隔离的创建与收尾、里程碑完成时的 neat-freak 收尾审查。
-
-## 1. 子代理派单上下文
-
-### 1.1 上下文载荷结构
-
-向子代理派单时，只发送元数据行（`IMPLEMENTER_DISPATCH`）不足以保证子代理产出与规格一致的实现。Lead 必须在派单时为每个子代理组装完整的上下文载荷，包含以下内容：
-
-| 载荷项 | 来源路径 | 说明 |
-|--------|---------|------|
-| 架构决策记录 | `<Path>{roots.state}/specdev/changes/{change}/ADR.md</Path>` 和 `<Path>{roots.state}/specdev/adr/</Path>` | 当前变更的架构约束和已确认的永久架构决策——子代理必须遵守的设计边界 |
-| 领域词汇表 | `<Path>{roots.state}/specdev/changes/{change}/CONTEXT.md</Path>` 和 `<Path>{roots.state}/specdev/context/</Path>` | 当前变更的术语定义和已确认的永久词汇表——子代理的命名和概念必须对齐，使用 `_Avoid_` 列表中的同义词即视为偏离 |
-| 目标规划文档 | `<Path>{roots.state}/specdev/changes/{change}/goal-plan.md</Path>` | 里程碑级约束、门禁次序、Definition of Done——子代理理解全局上下文和自身 ticket 在整体中的位置 |
-| ticket 文件 | `<Path>{roots.state}/specdev/changes/{change}/</Path>` 下对应 ticket | 验收标准、file allowlist、合同引用、阻塞关系——子代理的直接任务定义，包含「要构建什么」「范围边界」「保留/不动」 |
-| 合同验收条目 | 合同文档中本 ticket 覆盖的条目（如激活合同模式） | 编号验收条目及当前状态——子代理必须逐个满足的可检查条件 |
-| 实现方法参考 | `<Path>{roots.workflows}/specdev/I-implement/I-implement.md</Path>` | 深层模块设计原则、TDD 红绿循环、双轴审查流程——子代理的实现方法论；子代理开始实现前**必须先读**，与 goal-plan §5 步骤 1 第一项一致 |
-
-### 1.2 派单模板
-
-Lead 向子代理发送的内容应包含以下结构化信息块，而非仅一行元数据：
-
-```
-IMPLEMENTER_DISPATCH <n>
-  issue: <url>
-  gate: <P0|P1|P2>
-  allowlist: <files>
-  contract_ids: <...>
-
-附加上下文——子代理在开始实现前读取：
-  adr: <{roots.state}/specdev/changes/{change}/ADR.md>
-  permanent_adr: <{roots.state}/specdev/adr/>
-  context: <{roots.state}/specdev/changes/{change}/CONTEXT.md>
-  permanent_context: <{roots.state}/specdev/context/>
-  goal_plan: <{roots.state}/specdev/changes/{change}/goal-plan.md>
-  ticket_file: <{roots.state}/specdev/changes/{change}/ticket/<nn>-<slug>.md>
-  implement_ref: <{roots.workflows}/specdev/I-implement/I-implement.md>
-```
-
-其中 `<n>` / `<nn>` 为 ticket 编号（格式见 T-tickets：两位零填充纯数字，不含 `#`）。
-
-Lead 在生成子代理时将以上文件作为上下文传入，确保子代理在开始实现前已读取全部载荷。永久 ADR 和永久 CONTEXT 目录可能为空——静默继续。
-
-**完成标准**：每个子代理在启动时收到完整的上下文载荷（ADR、CONTEXT、goal-plan、ticket 文件、合同条目、I-implement 参考），所有路径指向真实存在的文件；IMPLEMENTER_DISPATCH 行和附加上下文已一并传递给子代理。
-
-## 2. 子代理完成后交接
-
-### 2.1 启动 handoff 技能
-
-子代理完成 ticket 实现并通过双轴审查和门禁后（§5 步骤 3-5 完成），Lead 执行交接流程：
-
-1. Lead 调用 `<Path>{roots.workflows}/specdev/common/handoff/SKILL.md</Path>` 压缩子代理的对话上下文
-2. handoff 技能产出交接文档，包含：实现了什么、做出的关键决策、与 spec 的任何偏差及原因、测试结果摘要、建议后续 agent 调用的 skills
-3. handoff 剥离敏感信息，不重复已存在于 spec/plan/ADR/commit/diff 中的内容——改用路径或 URL 引用
-4. 交接文档保存到操作系统临时目录
-
-### 2.2 回写 ticket 文件
-
-压缩后的交接摘要回写到对应 ticket 文件，使后续 agent 可通过 ticket 文件获取实现上下文，无需读取完整子代理转录：
-
-1. Lead 从 handoff 输出中提取关键信息：commit SHA、测试结果、决策与偏差、引用的产物路径
-2. Lead 在 ticket 文件末尾追加 `## 实现交接摘要` 小节，包含以上信息
-3. 格式：
-
-```
-## 实现交接摘要
-
-- **Commit**: <sha>
-- **测试结果**: <summary>
-- **关键决策**: <decision>（如有）
-- **偏差**: <deviation + reason>（如有）
-- **产物引用**: <paths to spec/ADR/contract updated>
-- **交接文档**: <path to OS temp handoff doc>
-```
-
-**完成标准**：每个 ticket 完成后，Lead 已调用 handoff 技能压缩对话；交接摘要已回写到 ticket 文件的「实现交接摘要」小节；后续 agent 可通过 ticket 文件获取实现上下文，无需读取完整子代理转录。
-
-## 3. 合并冲突解决
-
-### 3.1 触发条件
-
-并行执行时，Lead 从多个子代理 worktree 向 base 分支合并时可能产生冲突。尽管 file allowlist 非重叠规则降低了冲突概率，共享依赖（package.json、lockfile）或配置文件仍可能在合并时冲突。Lead 从 worktree finalize（§4.2）或手动合并时检测到冲突即触发本协议。
-
-### 3.2 解决协议
-
-1. Lead 检测到合并冲突后，调用 `<Path>{roots.workflows}/specdev/common/resolving-merge-conflicts/SKILL.md</Path>`
-2. 遵循该技能的 5 步协议：
-   - **查看状态**：检查 git merge/rebase 当前状态，列出冲突文件
-   - **溯源一手来源**：阅读每个冲突的 commit 消息、检查 PR、查看原始 issue/ticket，理解每方更改的原始意图
-   - **逐块解决**：尽可能保留双方意图。不兼容时，选择与合并既定目标一致的一方，记录权衡。不发明新行为。务必解决，不执行 `--abort`
-   - **运行检查**：按类型检查、测试、格式化的顺序运行自动化检查，修复合并破坏的任何内容
-   - **完成合并**：暂存所有内容并提交。如果是 rebase，继续直到所有 commits 已 rebase
-3. 解决后，Lead 在合并结果上重跑测试，确认通过后再继续
-4. 如果解决需要修改子代理产出，Lead 将变更记录到 `<Path>{roots.state}/specdev/changes/{change}/LOG.md</Path>`：记录冲突的 ticket、冲突文件、做出的权衡
-
-**完成标准**：合并冲突已通过 resolving-merge-conflicts 技能的 5 步协议解决；双方意图已尽可能保留；不兼容处已选择与合并目标一致的方案并记录权衡；自动化检查全绿；合并结果测试通过；如有子代理产出修改，已记录到 LOG.md。
-
-## 4. 并行 Worktree 隔离
-
-### 4.1 为并发子代理创建隔离 Worktree
-
-当 DAG 允许 3-4 个 ticket 并行执行时，Lead 为每个并发子代理创建独立的 git worktree：
-
-1. Lead 对每个并发子代理调用 `<Path>{roots.workflows}/specdev/common/dev-worktree/SKILL.md</Path>` Phase A
-2. 每个 worktree 使用唯一分支名：`speculo/specdev/<change>-<ticket-n>`
-3. Worktree 路径：`<Path>{roots.state}/specdev/changes/{change}/.worktree-<ticket-n>/</Path>`
-4. Lead 在派单前确认：
-   - 每个子代理的 file allowlist 与其 worktree 范围对应
-   - 两两子代理的 file allowlist 无重叠（共享文件仅 Lead 修改）
-   - 每个 worktree 中基线测试通过（基线失败阻断派单）
-5. 子代理在其隔离 worktree 内工作，无法看到其他子代理的进行中工作
-6. Lead 在 `.status.json` 中记录每个 worktree 的状态：`worktree_status: active`、`ticket_ref`、`base_branch`
-
-### 4.2 子代理完成后的 Worktree 收尾
-
-子代理完成实现并通过审查和门禁后：
-
-1. Lead 调用 `<Path>{roots.workflows}/specdev/common/dev-worktree/SKILL.md</Path>` Phase B（完整命令序列见 `common/dev-worktree/references/finalize.md`）
-2. 默认选项为本地合并；合并冲突跳转到 §3
-3. 更新 `.status.json`：`worktree_status: removed`
-
-**完成标准**：每个并发子代理在独立 worktree 中工作，分支名 `speculo/specdev/<change>-<ticket-n>`；任意两个子代理的 file allowlist 无重叠；基线测试在 worktree 创建时通过；子代理完成后 worktree 已按 finalize 规程合并并清理；`.status.json` 反映最终状态。
-
-## 5. 里程碑收尾审查与清理
-
-### 5.1 触发 neat-freak
-
-当 Lead 判断里程碑完成——所有 ticket 关闭、全部门禁通过、§6 里程碑验收仪式完成：
-
-1. Lead 调用 `<Path>{roots.workflows}/specdev/common/neat-freak/SKILL.md</Path>` 执行知识治理收尾
-2. neat-freak 跨六个事实面进行一致性核对：
-   - **Code** — 当前分支的代码实际实现了什么
-   - **Runtime** — 用户实际获得的行为
-   - **Docs** — 人类/下游文档是否与现状一致
-   - **Rules** — Agent 约束是否单一来源、无死引用
-   - **Memory** — 快照是否准确、是否授权修改
-   - **Workspace** — 是否有未清理的会话残留
-3. 每个事实面标记状态：`verified-current`、`changed-and-verified`、`pending`、`out-of-scope`、`not-applicable`
-4. 清理候选：临时计划文档、调试脚本、过期副本（`xxx_old.*`、`xxx_backup/`、`xxx_v2.*`）、孤立 worktree 产物
-5. 清理前必须经用户确认——预授权不替代最终报告的确认
-
-### 5.2 收尾清单
-
-Lead 在输出 `MILESTONE_DONE` 前逐项确认：
-
-- [ ] 所有 ticket 的 handoff 摘要已回写到对应 ticket 文件的「实现交接摘要」小节
-- [ ] 所有 worktree 已合并且清理——`git worktree list` 无本变更残留
-- [ ] 所有临时分支已删除——仅保留 base 和已合并的 change 分支
-- [ ] neat-freak 已运行——文档、ADR、CONTEXT 与代码现状一致，六个事实面状态明确
-- [ ] `.status.json` 反映最终状态——所有 `worktree_status: removed`
-- [ ] `<Path>{roots.state}/specdev/changes/{change}/LOG.md</Path>` 已追加里程碑完成记录（日期、ticket 数、关键决策、合并冲突及解决摘要）
-- [ ] 检查 `<Path>{roots.state}/specdev/adr/</Path>` 和 `<Path>{roots.state}/specdev/context/</Path>`——是否需要将 change 中的新 ADR 条目和术语提升到永久目录
-- [ ] 输出 `MILESTONE_DONE` 格式的完成报告
-
-**完成标准**：neat-freak 知识治理收尾已完成——六个事实面状态明确、文档与代码一致、无过期引用；所有 worktree 和临时分支已清理；ticket 交接摘要齐全且可追溯；LOG.md 已记录里程碑完成；永久 ADR 和 CONTEXT 目录已检查并提升新条目（如有）；MILESTONE_DONE 报告已输出。

package/template/workflows/specdev/P-goal-plan/quick-reference-table.md

@@ -1,60 +0,0 @@
-# 速查表 §9 编写规程
-
-可选的 Ticket 一览速查表，为 Lead 提供快速全局视图。
-
-## 触发条件
-
-满足以下任一条件时追加 §9：
-
-- ticket 数量 ≥ 10 个
-- 用户显式要求"加速查表"或"加 ticket 一览"
-
-不满足时，在 goal-plan.md 末尾添加一行说明并跳过：「§9 速查表已跳过（ticket 数量 < 10）。」
-
-## 表格模板
-
-五列表格，每行一个 ticket：
-
-| # | 切片 | 闸门 | 被阻塞于 | 端到端交付 |
-|---|------|------|----------|-----------|
-| <n> | <slice_name> | <P0\|P1\|P2> | <ticket titles> | <一句话交付描述> |
-
-### 列填充规则
-
-- **#** —— ticket 编号，与 issues 对应
-- **切片** —— 从 ticket 内容分析其所属的功能切面（如 DATA、SHELL、WORK、PLANNER、SCHEDULE、BOARDS、GATE、ADR）。一个 ticket 属于一个切面。从 ticket 标题和"要构建什么"段落推断切面名
-- **闸门** —— 从 DAG 分析中分配的 P0/P1/P2 层级
-- **被阻塞于** —— 从 tickets-map.md 的依赖边提取，用 ticket 标题（非编号）列出前置
-- **端到端交付** —— 一句话描述本 ticket 的用户可见交付物。不写技术实现细节，写用户能感知的变化
-
-### 行生成
-
-1. 从 tickets-map.md 逐行读取 ticket
-2. 对每个 ticket，读取其内容摘要（标题 + "要构建什么"首句）
-3. 推断切片名——检查标题中是否包含领域关键词（DATA→数据层、SHELL→外壳/布局、WORK→核心工作流等），默认归入 WORK
-4. 从 DAG 分析复制 gate 层级和阻塞关系
-5. 将"要构建什么"浓缩为一句话，删除技术细节（"使用 React 实现..."→"用户可以看到..."）
-6. 按 gate 层级排序（P0 在前），gate 内按 ticket 编号排序
-
-## 可选：Lead 开篇清单
-
-在速查表之后可选追加一段 Lead 在里程碑启动前需确认的检查项：
-
-```
-## Lead 开篇清单
-
-启动里程碑前确认：
-
-- [ ] 所有 issues 已在 GitHub 创建且标签正确
-- [ ] 合同/ADR 偏差表已与用户对齐
-- [ ] 参考权威快照路径可访问
-- [ ] 子代理 file allowlist 无重叠
-- [ ] 共享文件修改权仅 Lead 持有
-- [ ] 门禁次序和并发规则已向用户确认
-```
-
-## 写入
-
-将表格（和可选的开篇清单）追加到 goal-plan.md 作为 §9。如果跳过，写入跳过说明。
-
-**完成标准**：速查表已追加（或跳过说明已写入）；行数据与 tickets-map.md 一致；切片分类合理；端到端交付描述均为用户可见变化。

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

@@ -1,80 +0,0 @@
-# 远景章节 §1-3 编写规程
-
-编写 goal-plan 的前三个章节——定义"做什么"和"怎么算做完"。逐节草拟，每节经用户确认后再进入下一节。不一口气抛出全部三节。
-
-## §1 — Goal
-
-### 五要素公式
-
-从 spec.md 的 Problem Statement 和 Solution 段落提取，合成一段密集声明，包含五个要素：
-
-1. **构建什么**（what）——从 spec.md Solution 的第一句提炼
-2. **不可协商的约束**（constraints）——从 ADR.md 架构决策中提取，至少一条
-3. **具体交付物**（deliverable）——ticket 数量 + issue 范围（如 "#18-#38，共 21 个 issues"）
-4. **质量标杆**（quality bar）——如果激活参考权威模式，声明与参考权威的对应关系（如"与 openhanako 手感一致"）；否则从 spec.md 的 Test Decisions 提取
-5. **反模式**（anti-pattern）——声明禁止的伪完成（如"能力存在但手感不像 X"）
-
-### 编写规则
-
-- 一段写到底，不分点、不用列表
-- 每个要素是可检查的声明，不是模糊愿望
-- 反模式必须具体到可识别——禁止"代码写完但交互细节不匹配"
-
-### 草拟与确认
-
-先输出 §1 草案，等待用户确认。确认后进入 §2。
-
-## §2 — Authoritative Inputs
-
-### 优先级表
-
-构建一张三列表格：优先级 | 文件路径 | 角色说明。行按优先级降序排列。
-
-按检测到的模式逐行添加：
-
-1. **合同行**（如激活合同模式）——优先级 1，路径指向合同文档，角色："冻结合同——含编号验收条目，先于所有其他参考"
-2. **参考权威行**（如激活参考权威模式）——优先级 2，路径指向参考快照，角色："UX 真理——冻结快照，不随上游漂移。手感比对基准"
-3. **ADR 行**——从 ADR.md 和永久 ADR 目录（`<Path>{roots.state}/specdev/adr/</Path>`）提取，每份一个行，优先级按 ADR 编号
-4. **领域文档行**——从 CONTEXT.md 提取，每份一个行，角色："领域词汇表——术语定义和弃用同义词的权威来源"
-5. **Spec/Ticket 行**——spec.md 和 tickets-map.md，优先级最低
-
-### 冲突裁决顺序
-
-从 input-validation.md 的推导结果复制，写为编号列表。
-
-### 锁定产品裁定
-
-从 ADR.md 的架构决策和 spec.md 的 Implementation Decisions 中提取不可推翻的裁定。每条裁定写为一句声明，标注来源（ADR 编号或 Issue 编号）。
-
-- 裁定必须是已做出且不可推翻的——只提取 ADR 中标记为"决定"状态的条目
-- 如果激活偏差模式，在此声明偏差编号和每条偏差的理由
-
-### 草拟与确认
-
-先输出 §2 完整草案（优先级表 + 冲突顺序 + 锁定裁定），等待用户确认。确认后进入 §3。
-
-## §3 — Definition of Done
-
-### 六道门禁骨架
-
-逐道门禁填空，每道门禁写为一条可客观验证的全部或无声明：
-
-1. **Issue 全绿**——填写 ticket 数量和仓库引用。格式：「所有 <N> 个 issues 全部关闭，每个 issue 的 checklist 全部勾选为 [x]」
-2. **合同/ADR 状态收敛**——如果激活合同模式：填写合同文档名和待验收条目数。格式：「`<合同>` 中所有 <P0|P1|P2> 条目状态非 `todo`——`done` 或 `deviate`（有记录理由）」；如果无合同：填写 ADR 编号。格式：「ADR-<NNNN> 状态保持 `accepted`，偏差表条目已解决或明确记录为 `deviate`」
-3. **验证门禁绿**——从 spec.md 的 Test Decisions 提取验证命令。格式：「`<verify_cmd>` 全绿」
-4. **架构不回退**——填写 lint 和类型检查。格式：「无架构退化——<lint rules>」
-5. **已锁裁定不松动**——引用 §2 的锁定产品裁定。格式：「§2 的 <N> 条锁定产品裁定全部满足，无静默推翻」
-6. **可追溯**——填写 commit 到 issue 的链接要求。格式：「每个关闭的 issue 包含实现 commit 引用和验证截图/日志」
-
-### 填充规则
-
-- ticket 数量从 tickets-map.md 统计
-- 合同条目从合同文档的表格行计数
-- verify 命令从 spec.md Test Decisions 提取，如无则从项目脚本（package.json scripts、Makefile 等）探测整体验证命令，不确定时询问用户
-- 锁定裁定数量从 §2 提取
-
-### 草拟与确认
-
-输出 §3 完整草案，等待用户确认。
-
-**完成标准**：§1 目标声明五要素齐全且经用户确认；§2 优先级表、冲突裁决顺序、锁定裁定完整且经用户确认；§3 六道门禁全部填充为可客观验证的声明且经用户确认。

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

@@ -1,103 +0,0 @@
-# 探索指南
-
-有机遍历代码仓以发现架构摩擦，将每个摩擦点转化为可操作的深化候选。使用 `<Path>{roots.workflows}/specdev/I-implement/codebase-design-glossary.md</Path>` 中的术语——module、interface、depth、seam、adapter、leverage、locality——一致地描述每个发现。
-
-## 探索方式
-
-使用 Agent 工具的 `subagent_type=Explore` 遍历代码仓。不遵循僵化启发式——有机地探索，注意你在何处遇到摩擦。目标是发现将浅模块转化为深模块的机会。
-
-## 摩擦信号
-
-探索时注意以下信号，每个信号指向一个潜在的深化候选：
-
-### 浅模块
-
-模块的接口几乎和实现一样复杂——大量方法、复杂参数，但内部仅是透传或简单委托。
-
-识别方法：
-- 模块的方法数量接近或超过其内部逻辑行数
-- 调用者需要理解多个方法才能完成一件事
-- 模块仅仅是另一个模块的重命名包装
-
-### 接缝泄漏
-
-两个模块的接口边界存在泄漏——一方的实现细节暴露给另一方。
-
-识别方法：
-- 调用者需要了解被调用模块的内部数据结构
-- 修改一个模块的实现需要同步修改调用者
-- 错误处理分散在调用链的多个层级
-
-### 局部性缺陷
-
-理解一个概念需要跨多个小模块反复跳跃——相关代码分散而非集中。
-
-识别方法：
-- 修改一个行为需要编辑 3 个以上文件
-- 纯函数仅为可测试性提取，但真正的 bug 隐藏在调用方式中（无局部性）
-- 同一领域的验证逻辑散布在多处
-
-### 不可测试代码
-
-模块难以通过其公共接口测试，或根本未经测试。
-
-识别方法：
-- 模块在构造时创建依赖而非接收依赖
-- 模块产生副作用而不返回结果
-- 测试文件不存在，或测试绕过接口直接操纵内部状态
-
-### 单一适配器接缝
-
-接口只有一个适配器——仅为了"以后可能替换"而引入的接缝。
-
-识别方法：
-- 接口只有一个实现类，且无测试替身
-- 接口的存在理由是"解耦"，但依赖方向并未改变
-- 接口的方法签名与唯一实现完全一致
-
-## 删除测试
-
-对每个可疑模块应用删除测试：
-
-1. 想象删除此模块
-2. 如果复杂性消失——它只是透传层 → **浅模块，候选合并**
-3. 如果复杂性在 N 个调用者中重新出现——它在发挥价值 → **保留，或深化其接口**
-
-删除测试的核心洞察：一个模块的价值不在于它做了什么，而在于如果它不存在会发生什么。
-
-## 接缝评估
-
-对每个候选评估其接缝质量：
-
-- **接缝位置**：接口放在哪里？调用者和实现之间的边界是否干净？
-- **适配器证明**：是否存在至少两个适配器（生产 + 测试）来证明接缝是真实的？一个适配器意味着假设性接缝。
-- **依赖类别**：接缝处的依赖属于哪个类别？参见 `<Path>{roots.workflows}/specdev/I-implement/deepening.md</Path>`——进程内、本地可替换、远程但自有、真正外部依赖。类别决定了深化后的测试策略。
-
-## ADR 冲突检测
-
-探索中对照已有 ADR 检查每个候选：
-
-1. 读取 `<Path>{roots.state}/specdev/adr/</Path>` 下所有 ADR 文件
-2. 读取 `<Path>{roots.state}/specdev/changes/{change}/ADR.md</Path>` 中的本变更决策
-3. 如果候选方案与已有 ADR 矛盾：
-   - **摩擦真实且值得重新审视** → 在候选卡片中以警告框标注（例如："与 ADR-0007 矛盾——但值得重新审视因为……"）
-   - **ADR 理由仍然成立** → 不提出该候选——不要列出 ADR 禁止的所有理论重构
-4. 仅在探索结束后统一评估，不要在探索过程中逐条争论 ADR
-
-## 候选记录格式
-
-每个候选在内部记录以下信息，供步骤 3 生成报告使用：
-
-- **涉及文件**（路径列表）
-- **摩擦类型**（浅模块 / 接缝泄漏 / 局部性缺陷 / 不可测试 / 单一适配器）
-- **问题描述**（一句）
-- **解决方向**（一句——深化模块、合并浅包装、重划接缝、引入适配器）
-- **依赖类别**（进程内 / 本地可替换 / 远程但自有 / 真正外部依赖）
-- **删除测试结果**（"复杂度集中"或"复杂度转移"）
-- **推荐强度**（Strong / Worth exploring / Speculative）
-- **ADR 冲突**（如有——引用 ADR 编号和重新审视的理由）
-
-推荐强度判断：
-- **Strong**：删除测试通过（复杂度会集中），接缝有两个以上适配器，依赖为进程内或本地可替换
-- **Worth exploring**：删除测试通过但依赖为远程或外部，或接缝仅有一个适配器
-- **Speculative**：删除测试结果不明确，或预期的深度提升较小