tracer-to-tickets

转换为工单

将计划、规范或对话拆分为一组 工单——追踪子弹式的垂直切片，每个切片都声明阻塞它的工单。

**发布位置：**如果 docs/agents/issue-tracker.md 配置了跟踪器（通过 /tracer-setup 设置），则发布到该跟踪器——其中记录了阻塞边和前沿查询的确切命令；否则，将本地文件写入 .tracer/<feature-slug>/issues/。

流程

1. 收集上下文

基于对话上下文中已有的信息开展工作。如果用户传入了引用（规范路径、议题编号或 URL）作为参数，请获取并阅读其完整正文和评论。

如果该引用是 wayfinder:map 或本地 Wayfinder map.md，请停止并先通过 /tracer-to-spec 处理。地图是分布式决策的低分辨率索引，不是实现规范；直接将其拆分为工单会丢失链接中的决策。

2. 探索代码库（可选）

如果尚未探索代码库，请先了解代码的当前状态。工单标题和描述应使用项目领域词汇表中的术语，并遵循所涉及区域的 ADR。

寻找预先重构代码、让实现更容易的机会。“先让变更容易，再进行容易的变更。”

3. 起草垂直切片

将工作拆分为 追踪子弹式工单。

• 每个切片都应贯穿每一层（架构、API、UI、测试），形成一条范围狭窄但完整的路径——是垂直切片，不是某一层的水平切片
• 每个已完成的切片都能独立演示或验证
• 每个切片的规模都应适合在一个全新的上下文窗口中完成
• 任何预先重构都应先完成

为每个工单指定其 阻塞边——必须先完成的其他工单。没有阻塞项的工单可以立即开始。

大范围重构是垂直切片的例外。 大范围重构是指一项机械性变更——例如重命名列、重新定义共享符号类型——其影响范围遍及整个代码库，导致一次编辑就会破坏成千上万个调用点，且无法通过任何垂直切片保持构建通过。不要强行将其拆成追踪子弹；应按 扩展–收缩顺序安排。首先扩展：在保留旧形式的同时添加新形式，避免破坏现有功能。然后分批迁移调用点，每批的规模按影响范围确定（每个包、每个目录），每批作为一个受扩展步骤阻塞的独立工单；由于旧形式仍然存在，各批之间都能保持 CI 通过。最后收缩：在没有调用方继续使用旧形式后，删除旧形式；该工单由所有迁移批次阻塞。如果连各批次都无法单独保持构建通过，就保留原有顺序，但让它们共用一个集成分支，并全部阻塞最终的集成与验证工单——只有在那里才保证构建通过。

4. 向用户确认

以编号列表的形式展示建议的拆分。对每个工单，列出：

• 标题：简短的描述性名称
• 阻塞项：必须先完成的其他工单（如有）
• 交付内容：该工单实现的端到端行为

询问用户：

• 粒度是否合适？（过粗 / 过细）
• 阻塞边是否正确——每个工单是否只依赖真正构成前置条件的工单？
• 是否应合并任何工单，或进一步拆分？

反复调整，直到用户批准该拆分。

5. 发布工单

发布已批准的工单——无论采用哪种方式，工单内容都相同，只有阻塞边的形式不同：

• 本地文件 → 在 .tracer/<feature-slug>/issues/<NN>-<slug>.md 下为每个工单写入一个文件，按依赖顺序从 01 开始编号（先列阻塞项）。每个文件的“阻塞项”列出其依赖工单的编号／标题。使用下方的单工单文件模板——每个文件只放一个工单，绝不合并到单个文件中。
• 真实的工单跟踪系统（GitHub、Linear 等） → 按依赖顺序为每个工单发布一个议题（先发布阻塞项），以便每个工单的阻塞边都能引用真实标识符。如果平台支持原生阻塞／子议题关系，就使用该关系；否则，在每个工单的“阻塞项”中列出阻塞它的议题。除非另有指示，否则应用 ready-for-agent 分流标签——这些工单本身就可由 Agent 直接领取。

处理前沿工单：所有阻塞项都已完成的工单。对于纯线性链条，这意味着从上到下依次处理。对每个工单启动一次 /tracer-implement，并在每次之间清除上下文。彼此之间没有依赖边的前沿工单可以并行处理——每个工单启动一个 /tracer-implement 会话，并在各自的工作树中运行（/tracer-worktrees）；每项任务都会提交，因此并行会话不会在未提交的工作树上发生冲突。

不要关闭或修改任何父议题。

— <工单标题>

要构建的内容： 从用户角度描述该工单实现的端到端行为，而不是逐层列出实现步骤。

阻塞项： 阻塞此工单的工单编号／标题，或“无——可以立即开始”。

状态： ready-for-agent

• 验收标准 1
• 验收标准 2

父议题

指向跟踪系统中父议题的引用（如果来源是已有议题；否则省略此部分）。

要构建的内容

从用户角度描述该工单实现的端到端行为，而不是逐层列出实现步骤。

验收标准

• 标准 1
• 标准 2

阻塞项

• 对每个阻塞工单的引用，或“无——可以立即开始”。

无论采用哪种形式，都应避免写入具体文件路径或代码片段——它们很快就会过时；这类精确细节应放在 /tracer-implement 的临时任务计划中。例外：如果原型生成的代码片段比文字描述更精确地表达了一项决策（状态机、归约器、架构、类型形状），则可将其内联，并简要注明它来自原型。只保留能清晰体现决策的部分——不要放入可运行的演示，只保留重要内容。