用途
wtf.refine 用于从新的洞察出发，更新已有的 Epic、Feature 或 Trace 工单。它能合并来自任何来源的洞察，找出哪些章节发生变化，只重新运行这些变化所需的校验，在写入前展示精确的差异，并把场景编辑级联到声明这些场景的 Trace，防止内容失效。
该技能也是唯一的 Re-aim 机制。当某个 Trace 落地后，Feature 的 Trace Plan 会吸收该 Trace 所揭示的内容。它有两个入口点：人工交互式运行；或由 wtf.loop 在每次验证过的 Trace 之后以无头模式运行。
主要能力
- 从命令行参数、对话上下文、GitHub 评论、被引用文件（本地文件路径或 URL）等来源收集洞察，并合并为一份洞察清单交由用户确认。
- 根据洞察对工单的章节影响进行分类，形成变更映射（change map），驱动后续校验与重写。
- 只重新运行相关校验：范围变更时重跑纵向切片与范围门（scope gate）；领域语言变更时重跑 DDD 语言守卫；Feature 的验收标准变更时重做场景派生；Trace 的 Scenario Claim 变更时重做声明检查；Trace 落地后的 Re-aim 重做分区检查（partition re-check）。
- 逐章节展示改写前后的差异，供用户确认后再写入。
- 处理历史遗留（legacy）Task 工单，将其视为 legacy Trace，并沿 Trace 校验路径处理。
- 生命周期标签检查：根据变更类型判断哪些标签（如 implemented、verified）已失效，询问用户是否剥离。
- 以保留未变更内容的方式合并修改后的章节，并写入工单正文。
- 发布结构化审计追踪评论，记录本次精化。
- 把变更级联到受影响的子工单。
使用方式
流程分为九个步骤：
- GitHub CLI 设置：运行 gh-setup 参考文档的第 1–2 步（安装检查与认证检查）。若 gh 未安装或未认证则停止。若本会话已确认过 gh-setup，可跳过此步。
- 识别工单及其层级：若已传入工单号则直接使用，否则通过 AskUserQuestion 询问要精化哪个工单，选项来自最近更新的开放工单（涵盖 epic、feature、trace 及 legacy task）。随后拉取工单内容，检测其类型（Epic、Feature、Trace，或视为 legacy Trace 的 Task），并拉取父级与子级工单作为上下文与级联规划依据。
- 从所有来源收集洞察：并行处理命令行/对话上下文、上次精化之后的 GitHub 评论、被引用的文件或 URL，合并成编号清单并请用户确认。
- 分类变更：判断每条洞察影响哪些章节、属于什么变更类型，输出变更映射。
- 只重跑相关校验。
- 起草章节更新并展示差异。
- 生命周期标签检查。
- 应用变更：读取当前工单正文，只合并变更章节，保留其余内容原样写入。
- 发布审计追踪评论（两种模式均为强制）。
- 级联到受影响的子工单，包括机械同步（Feature 的场景或声明变化时）。
涉及的具体命令与代码示例（如 gh issue view、gh issue list、python3 .wtf/gh-body.py read/edit/comment 等）均按原文保留，未作改动。
适用场景
- 新洞察改变已有 Epic、Feature 或 Trace 的范围、验收标准、场景、领域语言或技术约束时。
- 某个 Trace 落地后，需要据此重新瞄准（Re-aim）Feature 的剩余计划时。
- 由人工交互式精化工单，或由 wtf.loop 在每次验证过的 Trace 之后以无头模式精化。
限制
- 需要 GitHub CLI（gh）已安装并完成认证，否则流程停止。
- 部分功能依赖 gh 扩展（用于层级拉取与级联）。
- 场景文本的规范版本位于父级 Feature 上，Trace 上的同步副本仅为便利投影；若某洞察试图编辑 Trace 上的场景文本，会触发规范性守卫，需改向精化 Feature、仅编辑声明或取消。legacy Trace 例外，其自身正文即其 Gherkin 规范来源。
- 无头模式下，新增或删除场景属于集合变更，只提出建议，不自动应用；已落地（checked，或对应 Trace 带有 implemented 或 verified）的条目不可改动。
- 具体安装方式、收费、价格与平台支持等信息暂未提供。