@namewta/speculo 0.3.0 → 0.3.2

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

@@ -1,51 +0,0 @@
-# 知识毕业标准
-
-判定变更中的知识是否值得提取到 specdev 的永久知识库（`adr/`、`context/`、`research/`）。默认只提取满足标准的；其余归为 `ephemeral`，留在归档变更中供未来按需查阅。
-
-## 毕业标准（三项满足任一即提取）
-
-1. **稳定机制**：知识描述的是持久架构模式、设计原则或系统约束，不是临时实现细节或过渡方案。
-   - ✅ "认证模块使用 JWT + refresh token 双令牌机制"
-   - ❌ "临时绕过了 rate limiter，等待 PR #342 合并后移除"
-
-2. **重复教训**：同一洞察在多个变更中出现（>1 个变更引用或触及）。
-   - ✅ 三个不同变更都遇到"时区转换必须用 UTC 存储、展示层转换"的坑
-   - ❌ 仅在一个变更的调试过程中发现，未被其他变更证实
-
-3. **接手者必知**：缺少此知识会导致后续开发者做出错误决策或重复已解决的争论。
-   - ✅ "选择 PostgreSQL 而非 MongoDB 的原因：需要 ACID 事务和 JSONB 的混合查询能力"
-   - ❌ "lint 配置将 max-line-length 设为 120 而非 100"
-
-## 反毕业标准（满足任一项则不提取）
-
-- 仅适用于单次变更的实现细节（具体行号、临时变量名、中间重构步骤）
-- 已解决的临时变通方案（workaround 已被正式修复取代）
-- 调试日志、故障排查过程记录（除非提炼出可复用的诊断方法）
-- 变更自身的 ADR.md 已充分捕获的决策（不重复提取）
-- 脱离完整变更上下文会产生误导的内容
-- 纯个人偏好且无项目级约束力
-
-## 决策流程
-
-对每段待评估知识：
-
-```
-1. 满足任一毕业标准？ → 否 → ephemeral（留在归档变更）
-2. 触发任一反毕业标准？ → 是 → ephemeral
-3. 提取 → 进入目标知识库的比对与合并
-```
-
-## specdev 三文件模型映射
-
-specdev 每个变更遵循三文件模型（参见 `<Path>{roots.workflows}/specdev/G-grill-with-docs/G-grill-with-docs.md</Path>`）。知识提取按以下映射：
-
-| 来源文件 | 知识类型 | 判定特征 | 目标知识库 |
-|---------|---------|---------|-----------|
-| **ADR.md** | 架构决策 | `## NNNN: Title` 条目，满足三条件（难以逆转 + 令人意外 + 真实权衡） | `<Path>{roots.state}/specdev/adr/</Path>` |
-| **CONTEXT.md** | 领域术语 | `**术语名**：定义` + `_Avoid_` 条目，项目特有概念 | `<Path>{roots.state}/specdev/context/</Path>` |
-| **LOG.md** | 设计决策 | `LOG-XXXX: accepted` 条目，满足 ADR 三条件但未正式记录 → 提升为 ADR | `<Path>{roots.state}/specdev/adr/</Path>` |
-| **research/** | 研究产物 | 跨变更相关的研究发现（>1 变更引用或覆盖共享技术栈） | `<Path>{roots.state}/specdev/research/</Path>` |
-
-## Ephemeral 分类
-
-被判定为 `ephemeral` 的知识**不删除**——它随归档变更保留在 `<Path>{roots.state}/specdev/archive/<YYYY-MM>/<change>/</Path>` 中，供未来按需查阅。只是不提升到 workflow 级永久知识库。

package/template/workflows/specdev/D-diagnose-bugs/cleanup-postmortem.md

@@ -1,37 +0,0 @@
-# 清理与事后分析
-
-诊断完成、修复已由 I-implement 执行后，必须完成以下清理和复盘。
-
-## 清理检查清单
-
-逐项确认：
-
-- [ ] 原始复现不再复现——重新运行阶段 2 的反馈回路，确认变绿
-- [ ] 回归测试通过——I-implement 已为修复编写并通过回归测试
-- [ ] 所有 `[DEBUG-xxxx]` 插桩已移除——`grep -r "\[DEBUG-"` 项目根目录，确认无残留
-- [ ] 一次性原型已删除——移除所有为诊断创建的临时脚本、测试夹具、mock 数据
-- [ ] 被证实的假设已记录到 `<Path>{roots.state}/specdev/changes/{change}/LOG.md</Path>`，以便下一个调试者学习
-
-## 记录根因
-
-在 `<Path>{roots.state}/specdev/changes/{change}/LOG.md</Path>` 中追加条目：
-
-```markdown
-## [YYYY-MM-DD] 诊断：<bug 简述>
-
-- **根因**：<被证实的假设，包含技术细节>
-- **验证方式**：<哪个探测确认了根因>
-- **修复提交**：<I-implement 的提交 hash 或描述>
-- **预防建议**：<什么本可以预防此 bug>
-```
-
-## 事后分析
-
-问：什么本可以预防这个 bug？从以下维度审视：
-
-- **测试接缝**——是否缺少合适的测试接缝？如果有好的接缝，此 bug 是否会被更早发现？
-- **接口设计**——接口是否暴露了容易误用的契约？深度是否足够防止调用者犯错？
-- **数据边界**——是否缺少输入校验、类型约束或边界条件处理？
-- **耦合**——是否因模块间的隐藏耦合导致变更的连锁反应？
-
-如果答案涉及架构变更（没有好的测试接缝、纠缠的调用者、隐藏的耦合），将具体情况记录到 LOG.md 的预防建议中。在修复之后提出建议——此时比诊断开始时拥有更多信息。

package/template/workflows/specdev/D-diagnose-bugs/feedback-loop-techniques.md

@@ -1,84 +0,0 @@
-# 反馈回路构建技术
-
-反馈回路是诊断的核心——一个紧凑的通过/失败信号，锚定 bug 的症状。以下技术按大致优先级排列，从最理想到最后手段。
-
-## 构建方式
-
-按顺序尝试，直到获得一个可工作的回路：
-
-### 1. 失败测试
-
-在能触及 bug 的任意接缝编写——单元测试、集成测试、端到端测试。优先选择现有的测试接缝。观察项目中已有的测试了解如何注入测试。
-
-### 2. Curl / HTTP 脚本
-
-针对正在运行的开发服务器。固定请求参数，对响应状态码和关键字段进行断言。
-
-### 3. CLI 调用
-
-带固定输入调用 CLI，将 stdout 与已知良好快照进行 diff。适合命令行工具和数据管道。
-
-### 4. 无头浏览器脚本
-
-Playwright 或 Puppeteer 驱动 UI，对 DOM 状态、控制台输出、网络请求进行断言。适合前端 bug。
-
-### 5. 回放捕获的追踪数据
-
-将真实网络请求、负载、事件日志保存到磁盘，在隔离环境中通过代码路径回放。适合需要真实数据的场景。
-
-### 6. 一次性测试夹具
-
-启动系统的最小子集——一个服务、模拟依赖——用单个函数调用驱动 bug 代码路径。适合微服务或多组件交互的 bug。
-
-### 7. 属性 / 模糊测试循环
-
-如果 bug 表现为"有时输出错误"，运行 1000 次随机输入寻找故障模式。适合数据相关或边界条件 bug。
-
-### 8. 二分查找夹具
-
-如果 bug 出现在两个已知状态之间（commit、数据集、版本），自动化"在状态 X 启动、检查、重复"以便 `git bisect run`。
-
-### 9. 差分循环
-
-通过旧版本 vs 新版本（或两种配置）运行相同输入，对输出进行 diff。适合回归 bug。
-
-### 10. HITL bash 脚本
-
-最后手段。如果必须由人工点击，使用 `<Path>{roots.workflows}/specdev/common/scripts/hitl-loop.template.sh</Path>` 驱动人工操作，使循环仍然结构化。捕获的输出反馈给 agent。
-
-复制模板，编辑步骤，运行脚本。脚本中的 `step` 函数显示指令并等待按 Enter，`capture` 函数显示问题并读取响应。结束时以 `KEY=VALUE` 格式打印捕获的值供 agent 解析。
-
-## 收紧回路
-
-将回路视为产品。一旦有了一个回路，收紧它：
-
-- **更快**——缓存设置、跳过无关初始化、缩小测试范围
-- **更清晰**——针对具体症状断言，而非"没崩溃"
-- **更确定**——固定时间、种子随机数、隔离文件系统、冻结网络
-
-一个 30 秒的抖动回路比没有回路好不了多少；一个 2 秒的确定性回路是调试的超能力。
-
-## 非确定性 bug
-
-目标不是干净的复现，而是更高的复现率。循环触发 100 次，并行化，增加压力，缩小时间窗口，注入 sleep。50% 抖动的 bug 是可调试的；1% 则不行——持续提高复现率直到可调试。
-
-## 当确实无法构建回路时
-
-停下来，明确说明。列出已尝试的方法。向用户请求：
-
-1. 访问能复现的任何环境
-2. 一个捕获的产物——HAR 文件、日志转储、核心转储、带时间戳的屏幕录制
-3. 添加临时生产环境插桩的许可
-
-在没有回路的情况下进入假设阶段是本规程要防止的核心失败模式。没有变红能力的命令，就没有后续阶段。
-
-## 最小化协议
-
-复现后，将场景缩小到仍能变红的最小场景。逐个削减以下元素，每次削减后重新运行回路：
-
-1. 输入数据——减少字段、缩小数据集、简化参数
-2. 调用者——移除中间层、直接调用核心逻辑
-3. 配置——使用默认值、移除环境变量
-4. 步骤——跳过前置操作、合并中间步骤
-
-每个剩余元素必须有负载作用——移除其中任何一个都会使回路变绿。最小复现场景缩小了假设空间，并成为最终的回归测试基础。

package/template/workflows/specdev/D-diagnose-bugs/hypothesis-format.md

@@ -1,46 +0,0 @@
-# 假设格式与诊断计划
-
-在插桩之前生成多个排名假设。单一假设会锚定在第一个看似合理的想法上。每个假设必须是可证伪的——陈述其预测。
-
-## 假设格式
-
-每个假设使用以下模板：
-
-> 如果 `<根因>` 是原因，那么 `<改变 X>` 会使 bug 消失 / `<改变 Z>` 会使它更糟。
-
-无法陈述预测的假设只是感觉——精炼或丢弃它。
-
-示例：
-
-> 如果缓存键在用户 ID 包含特殊字符时生成错误，那么将用户 ID 替换为纯字母数字字符串会使 bug 消失，而保持原 ID 并在缓存查询前打印键值会显示格式错误的键。
-
-## 排名规则
-
-生成 3-5 个假设，按以下优先级排名：
-
-1. **最近变更**——最近修改的代码区域优先。新代码是 bug 最常见的来源。
-2. **数据边界**——涉及空值、特殊字符、极限值、类型转换的假设优先于一般逻辑错误。
-3. **时序与并发**——涉及竞态条件、异步顺序、超时的假设在单线程同步假设之后。
-4. **外部依赖**——涉及第三方库、API 响应变更、环境差异的假设排在最后。
-
-## 诊断计划呈现
-
-将排名假设列表作为诊断计划呈现给用户。使用以下格式：
-
-```markdown
-## 诊断计划
-
-基于当前症状和代码库理解，以下是 3-5 个按优先级排名的可证伪假设：
-
-1. **[假设名称]** —— 如果 `<根因>` 是原因，那么 `<预测>`。
-2. **[假设名称]** —— 如果 `<根因>` 是原因，那么 `<预测>`。
-...
-
-请确认计划或调整优先级。你是否已经排除了其中任何一个？
-```
-
-用户通常拥有能立即重排名的领域知识——低成本检查点，大幅节省时间。向用户展示后等待确认。
-
-## AFK 默认行为
-
-如果用户 AFK（无响应），按排名继续——从排名最高的假设开始插桩验证。在每个假设被排除后，更新排名并继续下一个，无需等待确认。

package/template/workflows/specdev/D-diagnose-bugs/instrumentation-rules.md

@@ -1,51 +0,0 @@
-# 插桩验证规则
-
-每个探测必须映射到诊断计划中的一个具体预测。每次只改变一个变量。
-
-## 探测映射
-
-在添加任何插桩之前，明确陈述：
-
-- 此探测验证诊断计划中的哪个假设、哪个预测
-- 期望看到什么结果（如果假设正确）
-- 期望看到什么结果（如果假设错误）
-
-每次探测后记录实际结果，与预测对照。如果预测不匹配，该假设被排除，移至下一个。
-
-## 工具偏好
-
-按优先级选择插桩方式：
-
-### 1. 调试器 / REPL 检查
-
-如果环境支持，优先使用。一个断点胜过十行日志。在关键路径上设置条件断点，检查变量状态和调用栈。
-
-### 2. 针对性日志
-
-在能区分假设的边界处添加日志——模块接口、数据转换点、分支条件。日志内容应包含：
-
-- 所在假设的简短标识
-- 关键变量的值
-- 与预测相关的状态信息
-
-### 3. 每条日志必须有明确的验证目标
-
-全量日志淹没信号。每条日志单独对应一个假设预测，通过唯一前缀追溯到诊断计划中的具体条目。
-
-## 调试日志标记
-
-所有调试日志使用唯一前缀标记，格式为 `[DEBUG-xxxx]`，其中 `xxxx` 为 4 位随机字母数字（如 `[DEBUG-a4f2]`）。在日志消息中包含：
-
-```javascript
-console.log(`[DEBUG-a4f2] 缓存键: ${cacheKey}, 用户ID: ${userId}`)
-```
-
-最终的清理只需一次 `grep`——未标记的日志保留，已标记的日志删除。
-
-## 性能分支
-
-对于性能回归，日志通常是错误工具。替代方案：
-
-1. 建立基线测量——计时夹具、`performance.now()`、分析器、查询计划
-2. 二分查找——定位引入回归的变更点
-3. 先测量，后修复——在没有测量基线的情况下，任何优化都是猜测

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

@@ -1,55 +0,0 @@
-# 领域文档布局
-
-specdev 各 work 在探索代码库时应如何使用该仓库的领域文档。
-
-## 布局：单上下文
-
-specdev 使用单上下文布局——整个 workflow 共享一套领域术语和架构决策。每个变更目录 `changes/<change>/` 下维护三文件模型：
-
-```
-{state_root}/changes/<change>/
-├── CONTEXT.md    ← 领域词汇表
-├── ADR.md        ← 本变更相关的架构决策记录
-└── LOG.md        ← 设计决策日志
-```
-
-三个文件的权威格式由 `G-grill-with-docs` 定义，本文件不重复：
-
-- **CONTEXT.md** —— 格式见 `<Path>{roots.workflows}/specdev/G-grill-with-docs/context-format.md</Path>`（规范术语 + `_Avoid_` 同义词列表）
-- **ADR.md** —— 格式见 `<Path>{roots.workflows}/specdev/G-grill-with-docs/adr-format.md</Path>`（单文件、`## NNNN: 标题` 分段）
-- **LOG.md** —— 格式见 `<Path>{roots.workflows}/specdev/G-grill-with-docs/log-format.md</Path>`（`## LOG-XXXX` 编号条目、文件末尾追加）
-
-> specdev 将变更内领域文档限定在 `changes/<change>/` 目录内。经确认后的 ADR/CONTEXT 由 `A-archive-and-consolidate` 提升到永久目录 `{roots.state}/specdev/adr/` 与 `{roots.state}/specdev/context/`，始终反映项目当前现状。
-
-## 路径解析规则
-
-**本文件描述的路径均为相对于 `{state_root}` 的逻辑路径。** 实际写入时由 Speculo persistence 层映射到 `{roots.state}/specdev/` 命名空间下。
-
-- `CONTEXT.md` → `{state_root}/changes/<current_change>/CONTEXT.md`
-- `ADR.md` → `{state_root}/changes/<current_change>/ADR.md`
-- `LOG.md` → `{state_root}/changes/<current_change>/LOG.md`
-- `{state_root}` 由 runtime-context 解析为 `{roots.state}/specdev/`
-- `<current_change>` 按 INDEX 启动协议从 `status.json` 的 `active` 数组确定
-
-## 在探索之前
-
-当 specdev work 需要领域上下文时，按以下顺序读取：
-
-1. **永久目录**（若存在）—— `{state_root}/context/` 与 `{state_root}/adr/`，反映项目当前现状
-2. **`CONTEXT.md`**（当前变更目录内）—— 本变更的领域语言
-3. **`ADR.md`**（当前变更目录内）—— 涉及当前变更的架构决策
-4. **`LOG.md`**（当前变更目录内）—— 设计决策历史
-
-如果这些文件都不存在，静默继续。不要标记它们的缺失或预先建议创建。`G-grill-with-docs` 在领域知识或决策实际被确定时延迟创建它们。
-
-## 使用术语表的词汇
-
-输出中命名领域概念时，使用 `CONTEXT.md` 中定义的术语，不偏离到 `_Avoid_` 列表明确避免的同义词。如果需要的新概念尚未在术语表中，按 context-format 的增删改操作记录到 `CONTEXT.md` 并通知用户。
-
-## 标记 ADR 冲突
-
-如果输出与现有 ADR 矛盾，明确提出而不是默默覆盖：
-
-> _与 ADR NNNN 矛盾 — 但值得重新讨论，因为……_
-
-同时按 log-format 在 `LOG.md` 末尾追加一条日志条目（状态 `deferred`）记录冲突内容与重新讨论的理由；如采纳新方案，按 adr-format 的修改规则更新对应 ADR 状态。

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

@@ -1,53 +0,0 @@
-# 状态标签
-
-specdev 的 issue 分诊（`T-triage` 及 `common/triage` skill）使用五种规范的状态角色来追踪工作项的生命周期。本文件将这些角色映射到持久化文件中使用的实际标签字符串。
-
-| 角色 | 标签 | 含义 |
-|------|------|------|
-| `needs-triage` | `needs-triage` | 需要评估 —— 维护者需要判断此工作项的性质、优先级和归属 |
-| `needs-info` | `needs-info` | 等待补充信息 —— 工作项描述不足，等待报告者或需求方提供更多上下文 |
-| `ready-for-agent` | `ready-for-agent` | 可执行 —— 已完整定义，agent 无需额外人工上下文即可领取并开始工作 |
-| `ready-for-human` | `ready-for-human` | 需人工处理 —— 工作项需要人工判断、审批或执行，不适合 agent 自动处理 |
-| `wontfix` | `wontfix` | 不处理 —— 经评估后决定不予处理，保留记录以供追溯 |
-
-## 使用方式
-
-当 work 提及某个角色（例如"标记为需要评估"、"应用 ready-for-agent 状态"）时，使用此表中对应的标签字符串写入持久化文件。
-
-标签字符串写入位置取决于具体 work：
-
-- **T-triage** —— 写入变更目录 `triage.md` 的推荐 status 字段（参见 T-triage 步骤 4）
-- **其他 work** —— 引用这些角色时，在变更目录的相应产物文件中以元数据行形式记录
-
-## 状态流转
-
-```
-needs-triage ──→ needs-info ──→ needs-triage ──→ ready-for-agent
-     │                                                │
-     │                                                ├──→ ready-for-human
-     │                                                │
-     └──────────────────→ wontfix ←──────────────────┘
-```
-
-- `needs-triage` → `needs-info`：评估后发现信息不足，退回补充
-- `needs-triage` → `ready-for-agent`：已完整定义，可供 agent 执行
-- `needs-triage` → `ready-for-human`：需要人工处理
-- `needs-triage` → `wontfix`：决定不予处理
-- `needs-info` → `needs-triage`：补充信息后重新评估
-- `ready-for-agent` → `wontfix`：执行过程中发现不再适用
-
-## 自定义标签
-
-如果你的项目已有不同的标签命名习惯（例如使用 `bug:triage` 而不是 `needs-triage`），编辑右侧的"标签"列以匹配你实际使用的字符串。左侧的"角色"列不变——各 work 通过角色名引用状态，不直接依赖标签字符串。
-
-例如，如果你的项目使用中文标签：
-
-| 角色 | 标签 |
-|------|------|
-| `needs-triage` | `待评估` |
-| `needs-info` | `待补充` |
-| `ready-for-agent` | `可执行` |
-| `ready-for-human` | `需人工` |
-| `wontfix` | `不处理` |
-
-确保标签字符串在实际使用位置（triage.md 等产物文件）保持一致。

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

@@ -1,52 +0,0 @@
-# 变更追踪：本地 Markdown
-
-specdev workflow 的变更以 markdown 目录形式存储在 `{roots.state}/specdev/changes/` 中。
-
-## 约定
-
-- 每个变更一个目录：`{roots.state}/specdev/changes/<YYYY-MM-DD>-<topic>/`
-  - 例如：`changes/2026-07-21-add-auth-layer/`
-- 当前活跃变更通过 `{roots.state}/specdev/status.json` 的 `active` 数组追踪，每个条目为包含 `change`、`current_work`、`works_run`、`result` 等字段的对象——完整字段定义见 `<Path>{roots.workflows}/specdev/INDEX.md</Path>` 的「状态字段」一节，此处不重复
-- 归档变更移至：`{roots.state}/specdev/archive/YYYY-MM/<change>/`
-  - 例如：`archive/2026-07/2026-07-21-add-auth-layer/`
-- 变更目录内的工作产物由各 work 定义，典型结构：
-  ```
-  changes/<YYYY-MM-DD>-<topic>/
-  ├── .status.json    ← 本 change 的个体状态（见 INDEX.md「Per-change 状态文件」）
-  ├── CONTEXT.md      ← 领域词汇表（G-grill-with-docs 创建/更新）
-  ├── ADR.md          ← 架构决策记录（G-grill-with-docs 创建/更新）
-  ├── LOG.md          ← 设计决策日志（各 work 追加结论）
-  ├── spec.md         ← 需求规格（S-spec 创建）
-  ├── tickets-map.md  ← ticket 总体地图与执行清单（T-tickets 创建）
-  ├── ticket/         ← 独立 ticket 文件（T-tickets 创建）
-  │   └── NN-<name>.md
-  ├── map.md          ← 寻路地图（W-wayfinder 创建）
-  ├── goal-plan.md    ← 目标规划文档（P-goal-plan 创建）
-  ├── research/       ← 研究产物（common/research 维护，含 index.md）
-  └── prototype/      ← 原型产物（common/prototype 维护，含 index.md）
-  ```
-
-## 当 work 说"发布到变更目录"时
-
-在 `{roots.state}/specdev/changes/<change>/` 下创建或更新指定文件。如果变更目录尚未加入 `active` 数组，将其作为新条目（`{ change, current_work: null, works_run: [], result: null }`）追加到 `status.json` 的 `active` 中。
-
-例如：`S-spec` 说"将规格发布到变更目录" → 写入 `<Path>{roots.state}/specdev/changes/<change>/spec.md</Path>`。
-
-## 当 work 说"获取当前变更"时
-
-按 `<Path>{roots.workflows}/specdev/INDEX.md</Path>` 启动协议执行：读取 `status.json` 的 `active` 数组——用户指定则匹配对应条目；唯一活跃则直接使用；无活跃则创建新变更目录并追加条目；多个候选则由用户消歧。
-
-## 当 work 说"归档变更"时
-
-将变更目录从 `{roots.state}/specdev/changes/<change>/` 移动到 `{roots.state}/specdev/archive/YYYY-MM/<change>/`（YYYY-MM 取变更日期中的年月），从 `status.json` 的 `active` 数组中移除对应条目，追加归档记录到 `completed` 数组。完整归档与知识沉淀规程见 `<Path>{roots.workflows}/specdev/A-archive-and-consolidate/A-archive-and-consolidate.md</Path>`。
-
-## Wayfinding 操作
-
-供 `W-wayfinder` 使用。**地图是单个文件** `{roots.state}/specdev/changes/<change>/map.md`，tickets 是地图文件内的编号小节，不是独立文件：
-
-- **状态**：checkbox 标记——`- [ ]` 开放、`- [x]` 已解决
-- **阻塞**：ticket 小节内的「被阻塞于」字段，以 ticket 标题引用
-- **领取**：将 ticket 名称追加到 `status.json` 当前 change 条目的 `claimed_tickets` 数组，完成后移除
-- **前沿**：开放、未被阻塞、未被领取的 tickets
-
-完整地图结构与遍历规程见 `<Path>{roots.workflows}/specdev/W-wayfinder/W-wayfinder.md</Path>`。

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

@@ -1,126 +0,0 @@
-# 执行章节 §4-5 编写规程
-
-编写 goal-plan 的 Ticket DAG 和单 ticket 执行协议。这两个章节是 goal-plan 的核心工程内容，决定"按什么顺序做"和"每个怎么做"。
-
-## §4 — Ticket DAG and Scheduling Order
-
-tickets-map.md 的格式遵循权威模板 `<Path>{roots.workflows}/specdev/T-tickets/tickets-map-template.md</Path>`——执行清单为六列表格（编号 | Ticket | 被阻塞于 | Gate | Contract ID | 状态），依赖关系节支持门禁标注 DAG。
-
-### DAG 构造
-
-从 tickets-map.md 读取并丰富依赖图：
-
-1. **读取 tickets-map.md** —— 读取执行清单表的 `被阻塞于` 列和基础 ASCII 依赖树
-2. **构建邻接表** —— ticket A 阻塞 ticket B = A → B 的有向边
-3. **检测循环** —— 如果有循环依赖，报告并停止，让用户先修复 tickets
-4. **标注门禁层级** —— 结合合同或 spec 的优先级（P0/P1/P2）给每个 ticket 分配 gate 层级，将 Gate 标注**回写**到 tickets-map.md 执行清单表的 Gate 列：
-   - P0 = 阻塞所有后续工作的核心基础设施
-   - P1 = 主要功能切片
-   - P2 = 增强和边界情况
-5. **填写 Contract ID** —— 如激活合同模式，将每个 ticket 覆盖的验收条目 ID 回写到 tickets-map.md 执行清单表的 Contract ID 列
-
-### 门禁次序
-
-P0 门禁先开，阻塞所有 P1/P2 关闭。ticket 可以在其依赖就绪后开始，不依赖门禁——但门禁关闭（和里程碑推进）严格遵循 P0→P1→P2 顺序。
-
-### ASCII 图绘制
-
-在 tickets-map.md 的「依赖关系」节中，将 T-tickets 写入的基础 ASCII 树形图**丰富**为门禁标注 DAG。遵循以下约定：
-
-- 每行一个 ticket，缩进表示依赖深度
-- `→` 表示依赖关系（A → B 表示 B 依赖 A）
-- 用注释标注门禁边界：`--- P0 gate ---`
-- 可立即开始的 ticket 标注 `[READY]`
-- 扇出点标注 `[FAN-OUT: N路并行]`
-- ticket 编号格式见 T-tickets（两位零填充纯数字，不含 `#`）
-
-示例格式：
-```
-04 [READY]  →  05 [FAN-OUT: 3路并行]
-                     ├→ 06 [P0]
-                     ├→ 07 [P1]
-                     └→ 08 [P1]
---- P0 gate ---
-06  →  09 [P1]  →  10 [P2]
-```
-
-将丰富后的 DAG 回写到 tickets-map.md 的「依赖关系」节，替换 T-tickets 写入的基础版本。
-
-### 并行规则
-
-tickets-map.md 的「并行规则」节已由模板预设默认值（最大 3 并发、allowlist 不重叠、共享文件仅 Lead 修改）。P-goal-plan 根据实际 ticket 数量调整并发数（> 20 时可调至 4），并在 goal-plan.md §4 中引用 tickets-map.md 的并行规则（避免重复）。
-
-### 草拟与确认
-
-输出 DAG 图、门禁次序声明、并行规则。等待用户确认后，将门禁标注和 Contract ID 回写到 tickets-map.md，将完整 DAG 和门禁次序写入 goal-plan.md §4。
-
-## §5 — Per-Ticket Execution Protocol
-
-本协议是对 I-implement 的实例化执行；实现者必须同时遵循 I-implement 四步协议（设计检查→TDD→双轴审查→提交）。权威入口：`<Path>{roots.workflows}/specdev/I-implement/I-implement.md</Path>`。
-
-### 协议定制
-
-根据 input-validation.md 检测到的执行模型选择协议骨架：
-
-#### Lead+Subagent 模型（完整八步）
-
-1. **读取** —— 实现者（Lead 与子代理）在开始前**必须按顺序读取以下文件**建立完整上下文：
-
-   | # | 文件 | 用途 |
-   |---|------|------|
-   | 1 | `<Path>{roots.workflows}/specdev/I-implement/I-implement.md</Path>` | specdev 实现流程入口——设计检查、TDD 循环、双轴审查、提交 |
-   | 2 | 本 ticket 全文 | 验收标准、范围边界、交付物、保留/不动 |
-   | 3 | 合同/参考权威对应行（如激活） | 编号验收条目或对照路径 |
-   | 4 | 项目 skills（如有） | 前后端编排、构建规范、路由/菜单、数据库标准等项目级约定——按实际检出的 skill 路径追加，可变 |
-
-   Lead 读取 issue 全文、合同/参考权威对应行、ticket 的验收标准。如果激活参考权威模式，对照参考快照中的对应交互路径。
-
-2. **派单** —— Lead 输出结构化派单行 `IMPLEMENTER_DISPATCH <n> issue=<url> gate=<P0|P1|P2> allowlist=<files> contract_ids=<...>`（`<n>` 编号格式见 T-tickets），然后生成实现子代理（使用当前可用的最强实现模型，唯一 name）。Lead+Subagent 模型下，加载 `<Path>{roots.workflows}/specdev/P-goal-plan/lead-orchestration-protocol.md</Path>` 获取完整的编排协议——包括子代理上下文载荷结构、handoff 交接、合并冲突解决、Worktree 隔离和收尾审查的详细步骤。
-3. **实现** —— 子代理在 file allowlist 内实现变更，按 ticket 指定的测试矩阵运行测试；实现过程遵循 I-implement 的设计检查与 TDD 红绿循环。
-4. **双轴审查** —— 实现完成后，立即启动两个审查子代理并行运行：
-   - `reviewer-standards-<n>`：代码质量、架构、测试覆盖
-   - `reviewer-spec-<n>`：spec 合规、验收标准
-   - 任一返回 REQUEST_CHANGES 则启动修复子代理
-5. **门禁** —— 类型检查、测试、lint 全部通过。
-6. **回写** —— 如果激活合同模式：更新合同条目状态为 `done` 或 `deviate`；如激活 ADR 模式：检查 ADR 状态无需变更。偏差条目如有则由 Lead 同步偏差表。
-7. **关闭 issue** —— 附上验证证据（测试输出、commit SHA、如适用附截图）。
-8. **Lead 纪律** —— Lead 自身不得实现代码。如果 Lead 发现自己在写实现代码，输出 `DELEGATION_VIOLATION` 并重新派单。子代理不得操作 Git——只由 Lead 提交。
-
-#### 简化模型（精简协议）
-
-1. **读取** —— 实现者在开始前**必须按顺序读取以下文件**建立完整上下文：
-
-   | # | 文件 | 用途 |
-   |---|------|------|
-   | 1 | `<Path>{roots.workflows}/specdev/I-implement/I-implement.md</Path>` | specdev 实现流程入口——设计检查、TDD 循环、双轴审查、提交 |
-   | 2 | 本 ticket 文件 | 验收标准、范围边界、交付物 |
-   | 3 | spec 对应 User Story / 验收标准 | 行为与验收锚点 |
-   | 4 | 项目 skills（如有） | 项目级约定——按实际检出路径追加，可变 |
-
-2. **实现** — 在 ticket 声明的范围内实现变更；遵循 I-implement 的设计检查与 TDD 红绿循环。
-3. **审查** — 单审查者检查代码质量和 spec 合规（对齐 I-implement 双轴审查意图）。
-4. **门禁** — 类型检查、测试通过。
-5. **关闭** — 提交并关闭 issue。
-
-### 草拟规则
-
-- 协议步骤中的具体路径（合同路径、参考快照路径）从 input-validation 的检测结果填入
-- 测试矩阵从 tickets 或 spec 的 Test Decisions 提取
-- 双轴审查的派单模板写为可复制的文本块
-- Lead 纪律写为不可协商的约束
-- **§5 步骤 1 表格必须以 I-implement 为第一行**；项目 skills 仅作为后续可变项追加，不得因 skills 列表变化而挤掉或省略 I-implement
-- ticket 编号、派单行、进度行一律使用纯数字（`01`），不使用 `#01`
-
-### 草拟与确认
-
-输出 §5 完整协议文本。等待用户确认后进入治理章节。
-
-**完成标准**：§4 DAG 图无循环、门禁标注正确、对照表完整且经用户确认；§5 执行协议八步/精简流程已定制填入具体路径、测试矩阵和双轴审查模板，步骤 1 清单以 I-implement 为首项，经用户确认。
-
-## 子文件引用
-
-本文件按需加载以下子文件：
-
-| 文件 | 内容 | 触发条件 |
-|------|------|----------|
-| `<Path>{roots.workflows}/specdev/P-goal-plan/lead-orchestration-protocol.md</Path>` | Lead 编排协议——派单上下文载荷、handoff 交接、合并冲突解决、Worktree 隔离的创建与收尾、里程碑收尾审查 | 使用 Lead+Subagent 模型时，在 §5 步骤 2「派单」加载，覆盖从派单到收尾的完整执行生命周期 |