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 比較合併基礎與來源分支，近似於來源分支提議的變更。對於分歧分支、揀選提交或變基，這些可能不等於實際合併差異。對於提議的發布，請同時檢查提交和差異兩種觀點，識別異常情況，必要時僅在獲得授權後使用可拋棄式工作樹/暫存合併。請勿從未經驗證的三點差異中斷言確定的合併結果。對於已完成的發布，如果有的話，請優先使用記錄的合併提交、標籤、已部署的 SHA 或實際的上線前/上線後部署引用。
審查有意義的原始碼檔案、資料庫遷移、配置、API 架構、序列化器、權限、背景任務、整合、測試和部署清單；避免僅依賴提交主旨。在適當情況下從敘述中排除產生的/噪音檔案，但不要隱藏有影響力的產生的遷移或鎖定檔案變更。檢查跨越多個提交且有業務影響的變更。按業務能力分組，而不是列出每個變更的檔案。在可證明時將程式碼連結到工單/PR。
2. 分類變更與影響
區分並說明：
- 業務變更 — 新的或變更的工作流程、資格規則、保險範圍、費用/理賠處理、報告、通知和可觀察的行為。僅在有程式碼、測試或用戶提供的產品背景支援時撰寫；清楚標註推斷或缺少確認。
- 技術變更 — API、Django 模型/遷移、任務/Celery、資料庫/索引、外部整合、設定、安全/權限、可靠性、效能、可觀測性、CI/CD 和重構。
- 相容性與使用者 — REST 端點/方法、請求/回應欄位、狀態碼、認證、網頁/行動用戶端、內部呼叫者、工作者、第三方系統、資料庫和事件。標明
重大變更：是 / 否 / 未知並附上證據。區分 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 歷史或明確提供的發布背景；區分已驗證的事實與推斷。
- 不要列印在差異中找到的機密資訊、令牌、密碼、私人客戶資料或原始憑證。對範例進行去識別化處理。
- 不要將已提交的程式碼等同於已部署的功能，也不要將未執行的測試等同於已通過的測試。
- 當分支包含不相關的變更時，請記錄其範圍和風險，而不是默默地遺漏重要的修改。
- 僅在檢查後才使用明確的
未發現任何項目；否則使用未知 / 未驗證。 - 切勿在記錄移民或復原步驟的一部分時，實際執行遷移、操作生產資料或執行復原。