OxideTerm 版本發佈是做什麼的？

透過倉庫自有自動化工具發佈 OxideTerm 版本。將使用者完成的 GUI 執行視為發佈閘門，預設不執行 Cargo 測試。

必要的發佈輸入

在進行版本變更前，請先確定以下數值：

目標版本。
目標頻道：stable、beta 或 gpui-preview。
使用者已執行 GUI 應用程式並批准發佈的明確確認。
當使用者明確要求 minimal、medium 或 detailed 時，採用該發佈說明詳細程度；否則使用 detailed。

僅在版本號明確無歧義時推斷頻道。若缺少 GUI 批准，請在發佈前詢問。準備更新日誌或試執行（dry run）不需要批准。

頻道合約

頻道	版本	標籤	更新日誌	基礎備註
Stable	`X.Y.Z`	`vX.Y.Z`	`.github/release-notes/stable-changelog.md`	`.github/release-notes/stable.md`
Beta	`X.Y.Z-beta.N`	`vX.Y.Z-beta.N`	`.github/release-notes/beta-changelog.md`	`.github/release-notes/beta.md`
GPUI preview	`X.Y.Z-gpui-preview.N`	`gpui-vX.Y.Z-gpui-preview.N`	`.github/release-notes/gpui-preview-changelog.md`	`.github/release-notes/gpui-preview.md`

請勿自創其他標籤前綴。原生套件工作流程透過其 release_tag 排程輸入接收現有標籤，並從該標籤選取發佈備註。

工作流程

1. 檢查倉庫狀態

從 OxideTerm 倉庫根目錄開始。讀取 AGENTS.md，然後檢查：

git status --short --branch
git remote -v
git log -10 --oneline --decorate

在判定標籤可用之前，先擷取發佈遠端與標籤：

git fetch origin --tags

確認分支未落後或偏離其上流，並檢查本地與遠端的目標標籤：

git rev-list --left-right --count HEAD...@{upstream}
git tag --list <tag>
git ls-remote --tags origin refs/tags/<tag> refs/tags/<tag>^{}

保留使用者的不相關變更。若無法安全分離預期的發佈範圍或分支已偏離，請停止。對於一般發佈，當目標標籤已存在時停止。僅能透過下方明確的取消發佈恢復程序移動現有標籤。

2. 建立更新日誌範圍

在撰寫更新日誌前，先執行內建輔助工具：

python3 .agents/skills/oxideterm-release/scripts/release_context.py \
  --repo . --channel <channel> --version <version>

優先使用相同頻道上一個可到達的標籤作為基準線：

Stable 與前一個 stable 標籤比較。
Beta 與前一個 beta 標籤比較。
GPUI preview 與前一個 GPUI preview 標籤比較。

對於某頻道的首次發佈，使用三個頻道中最新可到達的發佈標籤作為引導基準線。僅在倉庫沒有任何較早可到達的發佈標籤時，才使用根提交。這能將首次 beta 或 preview 的更新日誌範圍限定在自實際前一次發佈以來的工作，而非總結整個倉庫。

輔助工具會輸出精確的範圍、提交與差異摘要。同時檢查實際變更，包括預期的未提交變更：

git diff <previous-tag>..HEAD
git diff
git diff --cached

請勿僅從提交標題推導發佈說明。請閱讀有意義的實作與使用者可見差異。排除機械性的版本號提升、更新日誌編輯、僅格式化的更動，以及不影響發佈的內部細節。

解析 Pull Request 與貢獻者

對於每個發佈頻道，在草擬備註前，先將精確發佈範圍內的變更對應到其原始 Pull Request。輔助工具的提交清單排除合併提交；請同時檢查合併歷史與 GitHub 的提交對 PR 關聯，以便合併、壓縮合併與變基合併都能獲得歸屬：

git log --format='%H %s' <previous-tag>..<target-ref>
gh api --paginate repos/<owner>/<repo>/commits/<commit-sha>/pulls \
  --jq '.[] | {number, title, url: .html_url, author: .user.login, merged_at, merge_commit_sha}'
gh pr view <number> --repo <owner>/<repo> \
  --json number,title,url,author,mergedAt,mergeCommit,commits

維護每個納入 PR 的編號、URL、作者登入名稱與實際貢獻的工作映射。對多次提交重複傳回的 PR 進行去重。根據目標歷史與差異確認納入範圍；僅憑合併日期無法確定發佈範圍。驗證 cherry-picked 變更的原始 PR 來源。完全還原的變更不得呈現為已發布的功能。

使用 PR 的作者，而非合併者或機器人。對於貢獻者感謝，排除已確認的專案維護者與機器人帳號；不要因為 GitHub 標記為 COLLABORATOR 或 MEMBER 就假設人類貢獻者是維護者。當維護者進行了後續修正時，仍保留外部 PR 工作的致謝。引用的 Issue 編號不等於 PR 或其作者的證據。如果 GitHub 查詢失敗，請將未解決的歸屬保留在工作筆記中，並在最終確定發佈說明前解決；不要將查詢失敗解釋為沒有貢獻。

3. 撰寫頻道更新日誌

在選定的更新日誌中插入 ## <version> 作為最新條目。標題必須完全符合版本號，因為 .github/scripts/compose_release_notes.py 使用它來定位條目。該標題是一個提取邊界，不一定是已發布版本內容的一部分。

每個版本條目必須按此順序撰寫兩個完整的語言區塊（中文在前，英文在後）。組合器會在所有頻道的雙語發佈說明最上方添加語言跳轉連結：

## <version>

### 中文

<中文摘要與章節>

### English

<English summary and sections>

兩個區塊的結構必須保持一致：它們必須以相同順序描述相同的成果、限制、驗證狀態與升級要求。翻譯時應使用自然的發佈說明語言，而非逐字翻譯；當翻譯會降低精確度時，保留產品名稱、指令、檔案名稱與協定名稱不變。請勿將英文與中文合併到同一項目符號中。英文使用簡潔的使用者視角過去式，中文使用簡潔的已完成動作措辭。每個語言的開頭摘要段落應保持在同一行，以免 GitHub Release 編輯器顯示人為換行。將相關的提交合併為一個成果，避免原始提交標題傾倒、實作細節、未經證實的效能聲明或未驗證的主張。在兩個區塊的每個主要 stable 發佈章節標題上使用一個剋制、語義相關的表情符號；請勿裝飾每個項目符號或在一個章節內混合多種表情符號樣式。

對於 fork 發佈，每個語言區塊必須清楚區分繼承自官方 OxideTerm 上遊的變更與 fork 實作的變更。使用相當於 Upstream changes / 上游更新 和 Fork-specific changes / Fork 自有更新 的明確本地化標題；子系統標題可在詳細程度允許時嵌套在它們下方。無論提交作者為何，將合併或 cherry-picked 的官方工作歸類為上游，將僅在發佈 fork 中出現的行為歸類為 fork 自有。當 fork 修改了上游功能時，在上游描述繼承的能力，在 fork 自有變更中描述 fork 的實質差異。如果任一類別在發佈範圍內沒有變更，請明確說明而非省略該類別。切勿讓合併的摘要或項目符號暗示 fork 撰寫了上游工作。

PR 引用與貢獻者感謝

遵循 NyaTerm v1.2.12 的歸屬模式：PR 引用緊接在其引入的變更旁，再加上一個專用的貢獻者章節。實際條目應從 OxideTerm 的發佈範圍推導。

對於每個透過 PR 引入的發佈說明項目（包括維護者撰寫的 PR），附加連結的 PR 編號。中文使用 （PR [#<number>](<pr-url>)），英文使用 (PR [#<number>](<pr-url>))。將引用放在相關項目符號或功能段落末尾，而非僅放在貢獻者清單或完整更新日誌連結中。保持 Issue 連結與 PR 連結的區別。直接提交沒有發明的 PR 編號。
當多個 PR 貢獻於一個分組項目時，在該項目中包含所有相關的 PR 編號一次。僅歸屬每個 PR 支援的成果；當分組會導致錯誤的作者歸屬時，請將維護者的獨立後續變更分開處理。對於來自其他儲存庫的 PR，使用 owner/repo#number 限定連結標籤。
每當發佈包含外部 PR 貢獻時，在中文區塊內添加 #### 👥 贡献者，在英文區塊內添加 #### 👥 Contributors，位於變更章節之後、升級注意事項（如有）之前。感謝每位其貢獻納入此發佈的外部 PR 作者，包括回饋貢獻者，以及其工作可能不需要獨立功能項目說明的文件、翻譯、建置或打包貢獻者。
每個語言區塊中，每位作者僅列出一次，使用其已驗證的 GitHub @login、其貢獻的簡短說明以及連結的 PR 編號。兩個語言的作者與 PR 引用必須吻合。泛泛的感謝或 GitHub 的自動頭像條列不能取代這些條目。如需識別首次貢獻者，請驗證先前的倉庫貢獻；New Contributors 清單是完整感謝章節的補充，而非替代。
在所有詳細程度與所有頻道中應用歸屬。如果驗證範圍內沒有任何外部 PR 貢獻，請省略貢獻者章節，而非添加空標題。不在發佈範圍內的 PR 不會被視為對此版本的新貢獻。

貢獻者條目範例（請將佔位符替換為已驗證的發佈資料）：

#### 👥 贡献者

感谢以下外部贡献者参与本次更新：

- @<login>：<具体贡献>（PR [#<number>](<pr-url>)）。

#### 👥 Contributors

Thank you to the external contributors to this release:

- @<login>: <specific contribution> (PR [#<number>](<pr-url>)).

將這兩個範例章節放置在其各自的語言區塊中，而非一起作為第三個雙語章節。

發佈說明詳細程度

英文與中文區塊使用相同的詳細程度。詳細程度控制涵蓋範圍與分組方式，而非強制的字數。切勿為了滿足較短的詳細程度而省略中斷性變更、安全邊界、升級要求、已知限制或重大的相容性問題。

層級	要求密度
`minimal`	僅在使用者明確要求時使用。撰寫一個簡短摘要，接著約 2–5 個高度整合的成果項目符號，最多使用一或兩個標題（當它們能實質改善掃讀時）。僅涵蓋發佈中定義使用者可見的變更與必要的警告。
`medium`	僅在使用者明確要求時使用。撰寫一個摘要、少量有用的章節，以及涵蓋主要功能、修復與安全性或相容性成果的分組項目符號。合併相關的支援工作流程，而非逐一列舉。
`detailed`	除非使用者明確選擇其他層級，否則為預設值。按有意義的子系統或工作流程組織備註，為每個獨立的使用者可見功能、行為變更、相容性修復、支援的限制以及已驗證的效能或驗證結果提供足夠空間，以便不需閱讀差異即可理解。包含對使用者理解或使用變更有實質影響的支援工作流程，但當發佈實際變更較少時，不要添加填充內容。

將這些層級視為涵蓋範圍與分組指引，而非固定模板。先確定完整的事實差異，再將其整合到選定的層級。如果使用者只說「撰寫發佈說明」或「準備發佈」，請使用 detailed。

套用頻道特定的重點：

Stable： 總結自上次 stable 標籤以來的完整差異。在每個語言區塊中，以簡短的發佈摘要開頭，然後僅使用有用的章節，例如 #### ✨ Highlights / #### ✨ 重点更新、#### 🛠️ Fixes / #### 🛠️ 修复、#### 🔒 Security / #### 🔒 安全 或 #### 🧰 Release Maintenance / #### 🧰 发布维护。強調使用者可見的行為與相容性。組合後的 GitHub Release 內容必須以 [中文](#中文) | [English](#english) 導覽開頭，接著是完整的 ### 中文 區塊，然後是對應的 ### English 區塊；省略如 # OxideTerm 2.0 的產品主要標題以及如 ## 2.0.7 的重複版本標題，然後在兩個語言區塊之後放置 ## 📥 Download for your system、安裝提示與連結。
Beta： 以完整的英文與中文區塊總結自上次 beta 標籤以來的差異。說明哪些功能接近穩定、有何變更以及哪些工作流程需要驗證。僅在差異或 Issue 上下文支援時提及已知限制，並在兩種語言中都包含。
GPUI preview： 以完整的英文與中文區塊總結自上次 GPUI preview 標籤以來的差異。專注於新可測試的原生 UI/執行時期工作、一致性、粗糙邊緣與具體測試目標。套用選定的詳細程度，同時保持寫作以測試為導向，而非將預覽備註變成 stable 發佈的行銷內容。

如果該頻道沒有較早的標籤，請說明使用了哪個先前的發佈標籤作為引導基準線。

4. 執行倉庫版本腳本

始終使用倉庫腳本；切勿手動編輯工作區版本或 lockfile：

python3 scripts/release/bump_version.py <version>

此腳本會驗證 SemVer、更新 [workspace.package] 並離線重新整理 Cargo.lock。README 徽章會自動顯示最新的 GitHub Release，無需編輯版本號。

5. 執行輕量級發佈驗證

不要執行 cargo test，

…[截斷以利翻譯]

OxideTerm 版本發佈