English · 繁體中文

這一頁屬於維護者路徑，供發佈新版本或檢查 release-facing 文件是否對齊時使用。

如果你的目標是在 repository 中安裝或使用 TAT，請先回到 首頁，走使用者路徑。

這一頁負責：

• release checks 與 tarball smoke tests
• changelog 與版本發佈前置條件
• 根層文件與 wiki 的同步責任

它不取代使用者向的安裝頁或快速上手頁。

以下檔案應被視為同一份 release-facing 契約：

• README.md 與 README.zh-TW.md
• CHANGELOG.md
• RELEASING.md
• 核心雙語 wiki 頁面與 _Sidebar.md

根層雙語 README 仍是 repository landing surface。wiki 則是依使用者路徑與維護者路徑分流的 live 文件面。live wiki 只描述目前正式產品，而不是版本差異；雖然套件會 shipped .vscode/*.example.*，但 live .vscode/*.json、.toml、.jsonl 的主權保留在目標 repository。

這個 repository 目前採三段式 release path：

1. npm run release:check 證明目前工作樹可發佈
2. npm run release:notes 預覽標準化的 GitHub release 內容
3. GitHub Actions 的手動 Release workflow 建立 GitHub release 並上傳 .tgz artifact

發佈之前，至少要確認：

• package.json 已經是目標版本
• CHANGELOG.md 已有對應版本條目
• README.md、README.zh-TW.md、RELEASING.md 與成對 release-facing wiki 頁面的說明，已對齊安裝順序、重複 preflight gate 敘事、受支援的本地 Git 主權、明確 SVN handoff 點、.vscode/*.example.* 整合、.tat-local/scripts/ 責任邊界與維護者責任
• main 分支已通過 release checks
• plans/ 內目前使用中的 contract-freeze 資料仍可作為讀者分流與導覽規則的依據

以下頁面應視為核心 wiki 契約，應在同一個 release PR 一起移動：

• Home.md 與 Home.zh-TW.md
• Getting-Started.md 與 Getting-Started.zh-TW.md
• Installation-and-Setup.md 與 Installation-and-Setup.zh-TW.md
• Hosts-and-MCP.md 與 Hosts-and-MCP.zh-TW.md
• Workflow-and-Artifacts.md 與 Workflow-and-Artifacts.zh-TW.md
• Architecture-and-Roadmap.md 與 Architecture-and-Roadmap.zh-TW.md
• Release-Guide.md 與 Release-Guide.zh-TW.md
• _Sidebar.md

只要 release 改到 workflow 形狀、artifact 結構、導覽方式或 MCP 姿態，就應假設這整組頁面都需要一起 review。

更新 wiki 時，優先對照以下主來源：

• README.md 與 README.zh-TW.md
• CHANGELOG.md
• RELEASING.md
• plans/ 內目前使用中的 contract-freeze 資料
• manifests/skills.json
• manifests/prompts.json
• templates/starter-kit/
• scripts/release-check.js

只要這些來源改到安裝說法、導覽策略或維護流程，就要在同一個 release PR 一起更新根層 README 與受影響的 wiki 頁面。

1. 在本機更新版本相關內容
2. 把根層雙語 README、CHANGELOG.md、RELEASING.md 與核心 wiki 集合當成同一份 release-facing 契約一起 review
3. 執行 npm run release:check
4. 若想先預覽 GitHub release 內容，再執行 npm run release:notes
5. 在乾淨目標專案中做雙語 tarball smoke test：
   • npm pack --ignore-scripts
   • npm install --save-dev ./turbo-agent-team-<version>.tgz
   • npm exec tat-setup -- --host copilot-vscode --scope project --locale en
   • 確認 .vscode/settings.example.json、.vscode/mcp.example.json、.vscode/memory-server.example.jsonl 仍以 shipped templates 形式存在
   • 在第二個乾淨目標專案中，以 --locale zh-TW 重跑一次
   • 確認繁體中文安裝也維持 .vscode/*.example.* shipped template 契約，而不是把 live .vscode/*.json 當成安裝器直接擁有的輸出
6. 將驗證過的 commit 推到 main
7. 到 GitHub Actions 手動執行 Release workflow
8. 除非你刻意要從別的 ref 發版，否則 target-ref 保持 main

npm run release:check 目前已自動驗證多個 release-facing 契約：

• 根層 README 的英文與繁體中文 parity
• RELEASING.md 與核心雙語 wiki 契約頁面是否維持支援的安裝路徑、產品邊界與使用者路徑／維護者路徑分流
• 透過 npm exec tat-setup 的 tarball 打包與 packed-install 驗證
• .vscode/*.example.* 安裝輸出，以及 live .vscode/*.json 主權保留在目標 repository 的契約
• 五角色 starter-kit baseline、memory-server 與雙語 runtime 輸出等生成資產契約

但它還不會證明未來任意新增的 wiki 頁面都已更新。若你新增核心集合以外的頁面，就要在同一個 release PR 裡手動檢查，或一起擴充 scripts/release-check.js。

這個 workflow 會：

• 驗證 package version 與 changelog 條目
• 在 GitHub 上重新跑完整 release gate
• 以 npm pack --ignore-scripts 建立 tarball
• 從 CHANGELOG.md 產出標準化的 GitHub release 內容
• 建立 v<version> GitHub release 並附上 tarball artifact

附加在 GitHub release 上的 .tgz 是 npm package tarball。支援的使用者路徑是：

• 站在目標專案根目錄
• 執行 npm install --save-dev ./turbo-agent-team-<version>.tgz
• 執行 npm exec tat-setup

shell wrappers 不再屬於預期 release flow。

• 如果 CHANGELOG.md 沒有目前版本條目，流程會提早停止
• 如果 v<version> tag 已存在，流程會提早停止
• 如果 npm pack 沒有成功產出 tarball，就不會建立 release
• 如果英文或繁體中文 tarball smoke test 失敗，就不能視為實際完成 release 驗證
• 如果 wiki 成對頁面只更新了單一語言，就算 automated gate 綠燈，仍可能留下 drift
• 如果根層雙語 README 與維護者頁面對角色分流或安裝契約講法不同，就算打包檢查通過，release PR 仍不完整

最權威的發佈文件仍然是：

• RELEASING.md