平台維運總覽

平台佈建與測試都不是面向租戶的。地端頁面另外涵蓋 Worker 作者與串接方在自架套件上會看到的內容。

平台佈建 — deploy-platform.mjs：dispatcher Worker 出貨的唯一途徑；三個 binding 的環境契約與啟用對照表、兩個 Wrangler 階段加上舊版 deny Worker 的退役步驟、簽章 canary 證明、--check vs --dry-run vs --drift，以及在每次 staging 部署與 production release 之前執行它的 CI job。
地端 Edge Workers — 自架的附加元件：對 Worker 作者與串接方而言哪些保持不變、哪些不同，以及維運人員如何啟用、調整容量、備份、還原與停用它。
測試 — 已發布的測試套件證明了什麼（TS/workerd、Python、host-only E2E harness、地端 kit 驗收、staging 套件），以及 Cloudflare 真實環境測試如何設閘。

操作者速記：

執行期 provider 由 EDGE_WORKERS_PROVIDER 決定：cloudflare（預設）或 onprem。以下關於 dispatcher 與 deploy-platform.mjs 的內容都是 Cloudflare 路徑。
repo 裡的 wrangler.jsonc 無法部署出任何真的東西 — 頂層的 Worker 名稱與 namespace 含有 deploy-via-script-only，且每個區段的公開 JWK 變數都是哨兵值。這是刻意的。
環境：staging = dispatcher teamsync-department-worker-dispatcher-staging；production = teamsync-department-worker-dispatcher-production。兩者綁定同樣三個 dispatch namespace 位置（一個共用位置，加上每個環境一個舊版位置），沒有綁定任何 Outbound Worker — 部門 Worker 保有不受限制的對外連線。某個 Worker 由哪個位置服務，是逐請求決定的：由啟用釘定該位置 — 可以是伺服端擁有的啟用對照表 EDGE_WORKER_SERVING_ROUTES 內的條目，也可以是後端在搬移 Worker時記錄的啟用 — 而後端簽章的呼叫通常會自行指名該 Worker 已記錄的位置；否則 dispatcher 依序查舊版 staging、舊版 production、共用位置。部署順序永遠是 dispatcher 先、接著 settings 讀回（三個 binding、無 outbound、對照表完全一致）、再一次性退役舊版 teamsync-department-worker-outbound-deny-<env> Worker（Cloudflare API；不存在就跳過）、最後 canary。
後端依自己的 API 環境挑選 dispatcher（APP_ENV 或 ENVIRONMENT，或 HOST／PUBLIC_HOST 中的託管 API 主機名稱），絕不依 Worker 所在的位置。缺少或互相矛盾的宣告會讓閘道沒有 dispatcher 可呼叫（Edge Worker dispatcher is not configured）。
dispatcher 不再只能手動部署：staging 部署（environment=staging）與 production release 會在後端 job 之前執行 dispatcher 部署工作流程，只在原始碼 digest 與線上蓋章不一致時重新部署 dispatcher，失敗就擋住後端。digest 涵蓋不到的變更（Infisical 值、金鑰輪替、啟用對照表變更、deploy-platform.mjs 本身）仍需手動執行。
後端的回收迴圈（部署重發、控制面稽核、產物清理）在每個 API replica 內每 60 秒跑一次，另有第二個迴圈每 15 秒重試 Worker 退役（退役）— 兩者都沒有 cron 要維運。
一次部署最多可能要 10 分鐘才回報就緒：上傳之後，部署任務最多等 600 秒（後端 5.22.0 之前為 60 秒）讓新 release 回應，所以在這段時間內回應的 release 不再讓部署以 uncertain 收場（版本與部署）。
調升 builderPolicy.version（截至後端 5.22.0 為 department-worker-project-v2.10）會改變每個新建置的 release generation — 同一壓縮檔重建會得到不同的 release。先前建置的修訂版保留自己記錄的政策，照原樣仍可部署（部署任務以各修訂版自己記錄的政策重新驗證），所以 runtime template 的變更只會透過新提交的修訂版進到 Worker；修訂版能用到哪些執行期功能，取決於它記錄的政策（提交管線）。把它當平台遷移，不是版本號調整。
結構變更走 ORM hotfix 流程 — 這些表沒有 alembic revision（資料庫模型）。