release-brief

当需要把「一个已关闭的 issue」和「一段已合并的 diff」变成对外可读的发布摘要时，按下面的固定步骤执行，不要临场发挥顺序。

触发条件

• 输入里同时存在一个 issue 标识（例如 LP-42）和一段 diff 或变更文件列表。
• 目标是产出发布摘要，而不是继续写代码。

固定步骤

1. 读 issue：提取标题、问题描述与验收标准。
2. 读 diff：列出被改动的文件与关键函数。
3. 归类改动：区分是缺陷修复、功能新增还是纯重构。
4. 评估风险：指出回归面与需要人工确认的点。
5. 写验证步骤：给出可复制的复现或回归命令。

输出契约

生成的发布摘要必须是一个 JSON 对象，且包含以下字段，缺一不可：

• issue：issue 标识字符串。
• summary：一句话说明这次发布做了什么。
• change_type：fix / feature / refactor 之一。
• risk：风险说明，至少一句。
• verification：字符串数组，至少一条可执行验证命令。

反例

• 只写 summary 而不给 verification：契约检查会失败。
• 把顺序打乱、先写风险再猜 issue 内容：违反固定步骤，产出不可复用。