Treatment Backend 发布说明
根据仓库中的实际证据，生成一份准确、可审计的英文发布说明，用于将源分支晋升到目标分支（特别是 stage 或 production）。在撰写发布说明后，在对话中单独生成一份波斯语标题摘要。切勿将波斯语摘要附加、嵌入或写入发布说明或任何其他项目文件中。
跨 Agent 执行合约
- 此技能可在 Codex、OpenCode 和 Claude Code 之间移植，无需特定供应商的工具。在调用时请阅读本
SKILL.md和链接的references/文件。 - 一个权威副本存储在
.agents/skills/treatment-backend-release-note/目录下；使用捆绑安装程序时，.claude/skills/和.opencode/skills/指向同一副本。请勿维护不同的副本。 - 如果工具或权限不可用，请如实报告限制；不要捏造 Git 证据或发布状态。
- 接受自然语言调用，或 Codex 中的
$treatment-backend-release-note、Claude Code 及支持的 OpenCode 配置中的/treatment-backend-release-note。所有调用遵循完全相同的工作流和输出策略。
输入和范围
- 必需：
source_branch（源分支）、target_branch（目标分支）（仅当用户明确建立项目约定时才使用默认目标；否则在真正无法获取时询问）。 - 可选：发布版本、部署窗口、工单引用、输出文件名（存储在
docs/releases/下）、部署方法、负责人。 - 在收集变更之前，请检测远程仓库并验证引用、工作树状态和仓库根目录。未经明确授权，不得切换分支、拉取、获取、提交、合并、打标签、部署或修改应用代码。
- 如果未指定源/目标，请尝试根据清晰上下文推断（例如用户说“将 develop 发布到 stage”）；否则询问。切勿将当前检出的分支默认为源分支。
- 两个引用可以是本地分支或远程跟踪分支；请明确说明解析了哪些引用和提交哈希。
- 将报告解释为源分支引入目标分支的变更，而非源分支上所有历史提交。
工作流
1. 预检和 Git 证据
从仓库根目录开始，检查以下命令（安全适配引用名称，不要插值不受信任的 shell 参数）：
git status --short
git remote -v
git branch -a
git rev-parse --verify <source>^{commit}
git rev-parse --verify <target>^{commit}
git merge-base <target> <source>
git log --date=short --format='%h %ad %s' <target>..<source>
git diff --stat <target>...<source>
git diff --name-status <target>...<source>
git diff <target>...<source> -- <relevant-paths>
target..source 标识从目标分支无法到达的提交。git diff 中的 target...source 比较合并基与源分支，近似源分支提议的变更。这些对于分歧分支、cherry-pick 或变基，可能不等于确切的合并差异。对于提议的发布，请检查提交和差异两个视角，识别异常，并在必要时仅在获得授权后使用一次性工作树/临时合并。不要从未经验证的三点差异中断言最终的合并结果。对于已完成发布，如果可用，优先使用记录的合并提交、标签、部署 SHA 或实际的部署前后引用。
审查有意义的源文件、迁移、配置、API 模式、序列化器、权限、后台任务、集成、测试和部署清单；避免仅依赖提交主题。在适当情况下从叙述中排除生成/噪音文件，但不要隐藏有影响力的生成迁移或锁文件变更。检查跨多个提交的业务影响变更。按业务能力分组，而不是列出每个更改的文件。在可证明时将代码链接到工单/PR。
2. 分类变更和影响
分类并描述：
- 业务变更 — 新的或更改的工作流、资格规则、覆盖范围、费用/索赔处理、报告、通知和可观察行为。仅在代码、测试或用户提供的产品上下文支持时撰写；明确标记为推断或缺少确认。
- 技术变更 — API、Django 模型/迁移、任务/Celery、数据库/索引、外部集成、设置、安全/权限、可靠性、性能、可观测性、CI/CD 和重构。
- 兼容性和消费者 — REST 端点/方法、请求/响应字段、状态码、认证、Web/移动客户端、内部调用者、工作者、第三方系统、数据库和事件。明确说明
Breaking change: Yes / No / Unknown，并提供证据。区分 API 兼容性与部署/数据兼容性。在必要时解释所需的消费者操作和推出顺序。 - 验证和可追溯性 — 确切的源/目标引用 + SHA、基础 SHA、值得注意的提交、找到的工单/PR 链接、测试及其实际观察到的状态、迁移计划、审批者/状态（如果提供）。未执行测试或未获得可靠测试结果时，不得声称测试通过。
- 回滚 — 描述适合目标的步骤和前提条件，分别处理应用回滚、可逆模式迁移、不可逆数据迁移、可重放任务、消息、幂等性和第三方副作用。始终区分 Git 回滚与操作回滚。未检查迁移和副作用之前，不得断言回滚是安全的。
请查看 references/review-checklist.md 中的完整检查清单。
3. 编写并保存英文发布说明
遵循 references/release-note-template.md。所有保存到发布说明中的内容（包括标题）均使用英文。保持简洁但信息丰富，适合工程和业务评审。使用“未验证”、“未知”或“需确认”，而不是编造细节。
规范的项目输出目录是 docs/releases/。将所有发布说明保存在该目录下；不要创建根目录下的 release-notes/ 目录。默认输出为 docs/releases/YYYY-MM-DD-<source>-to-<target>.md，其中分支斜杠替换为连字符。尊重明确请求的文件名，但确保文件仍在 docs/releases/ 下。避免覆盖已有的发布说明。如果目标文件已存在，请选择唯一文件名或寻求明确的替换批准。仅使用生成日期作为文档日期，不要捏造部署日期。发布说明在部署验证之前被视为提议的发布。
保存后，请读回文件并验证：分支方向与提交身份、业务/技术变更、兼容性、验证、可追溯性、回滚，以及不含波斯语摘要。除非请求，否则不要自动暂存或提交发布说明。报告保存的相对路径。
4. 仅对话中的波斯语摘要（必需）
仅在成功保存和验证之后，在最终的 Agent 回复中呈现一个简短的标题风格波斯语摘要。专注于业务可读的结果、有意义的风险、所需的消费者/部署操作以及就绪/未知状态。通常为 3–7 个简短要点，除非必要，否则不包含低级实现细节。示例格式：
خلاصه برای ارائه به بیزینس (فقط در پاسخ Agent، خارج از فایل):
- بهبود فرآیند ...
- تغییر در رفتار ...
- نیاز به هماهنگی با ...
- وضعیت اعتبارسنجی: ...
- ریسک و برنامه بازگشت: ...
仅包含在审查期间确定的声明。勿将此摘要保存到任何文件中，日志、提交消息或发布说明附录也不可。如果写入失败，不得声称发布说明已注册；请解释障碍，并在有助于解决问题时提供明确标记为临时的临时摘要。
质量关卡
- 每一项变更和声明都必须基于检查的差异、测试、Git 历史或明确提供的发布上下文；区分已验证事实与推断。
- 不要打印在差异中找到的密钥、令牌、密码、私人客户数据或原始凭据。对示例进行脱敏处理。
- 不要将已提交的代码等同于已部署的功能，也不要将未运行的测试等同于已通过的测试。
- 当分支包含不相关的更改时，记录范围和风险，而不是默默地忽略重要修改。
- 仅在实际检查后才使用明确的
None identified；否则使用Unknown / Not verified。 - 切勿在记录迁移、操作生产数据或执行回滚时作为文档的一部分运行它们。