to-tickets

拆解为工单（To Tickets）

把一份计划、规格或对话拆解成一组 工单——曳光弹式的纵向切片，每个都声明 阻塞（block） 它的那些工单。

issue tracker 与分诊（triage）标签词汇应当已经提供给你——如果没有，运行 /init_goder_harness。

流程

1. 收集上下文

从对话上下文中已有的内容出发。如果用户以参数形式传入了一个引用（一个规格路径、一个 issue 编号或 URL），就获取它并阅读其完整正文和评论。

2. 探索代码库（可选）

如果你还没探索过代码库，就去探索一下，以理解代码当前的状态。工单标题和描述应使用项目的领域词汇表词汇，并尊重你所触及区域内的 ADR。

寻找可以对代码进行 预重构（prefactor） 以让实现更容易的机会。"先让改动变得容易，再做那个容易的改动。"

3. 起草纵向切片

把工作拆解成 曳光弹 工单。

给每个工单标注它的 阻塞边——那些必须在它能开始之前完成的其他工单。没有阻塞项的工单可以立即开始。

宽重构（wide refactor）是纵向切片的例外。 一次 宽重构 是一个机械性的改动（重命名一列、给一个共享符号重新定型），其 波及半径（blast radius） 扇形扩散到整个代码库，以至于单次编辑会一下子破坏成千上万个调用点，没有任何纵向切片能落地为绿。不要把它硬塞进一颗曳光弹；把它按 扩张—收缩（expand–contract） 排序。先扩张：在旧形式旁边添加新形式，使一切都不破。然后按波及半径大小分批（按包、按目录）把调用点迁移过去，每一批都是自己独立的、被扩张工单所阻塞的工单，因为旧形式仍然存在，故 CI 能一批批保持为绿。最后收缩：一旦没有调用方残留，就删掉旧形式，放在一个被每个迁移批次所阻塞的工单里。当连各批次都无法各自保持为绿时，保留这个序列，但让它们共享一个集成分支，该分支阻塞一个最终的"集成并验证"工单——绿只在那里被承诺。

4. 与用户对质核对

把拟定的拆解作为带编号的列表呈现。对每个工单，展示：

• 标题：简短的描述性名称
• 阻塞于（Blocked by）：哪些其他工单（如果有）必须先完成
• 它交付什么：这个工单让哪一段端到端行为得以工作

问用户：

• 粒度感觉对吗？（太粗 / 太细）
• 阻塞边正确吗——每个工单是否只依赖那些确实对它构成门槛的工单？
• 是否应当合并或进一步拆分某些工单？

反复迭代，直到用户认可这份拆解。

5. 把工单发布到已配置的 tracker

发布已认可的工单。怎么发布？ 取决于 /init_goder_harness 配置的 tracker——工单本身两种情况下都一样，只有阻塞边的形态不同：

• 本地文件——在 .scratch/<feature-slug>/issues/<NN>-<slug>.md 下每个工单写一个文件，从 01 起按依赖顺序编号（阻塞项在前）。每个文件的 "Blocked by" 列出它所依赖的编号/标题。使用下面的每工单文件模板——一个工单一个文件，绝不用一个合并的大文件。
• 真实的 issue tracker（GitHub、Linear 等）——按依赖顺序（阻塞项在前）每个工单发布一个 issue，好让每个工单的阻塞边能引用真实的标识符。用平台原生的阻塞 / 子 issue 关系（如果它有的话）；否则把每个工单的 "Blocked by" 设为那些阻塞的 issue。除非另有指示，否则打上 ready-for-agent 分诊标签——这些工单按构造就是可被 agent 领取的。

沿 前沿（frontier） 推进：任何其阻塞项全部完成的工单。对于纯线性链，这意味着自上而下。

不要关闭或修改任何父 issue。

– <工单标题>

要构建什么： 这个工单让哪一段端到端行为得以工作，从用户的视角出发——而不是一份逐层的实现清单。

阻塞于： 对这个工单构成门槛的工单的编号/标题，或 "无——可立即开始"。

状态： ready-for-agent