建議方向：宿主機排程，唔好另起更新容器

呢份方案建議用「宿主機原生定時器＋固定鏡像摘要＋持久化交易狀態＋本機鏡像回滾」，由 VPS 上的腳本直接呼叫 Docker。重點係更新前先保留舊版本，切換後再做健康檢查；新版本唔合格，就用本機已有的舊鏡像復原。

但有兩個限制要先講清楚：跨網絡查詢遠端摘要，唔可以保證每次都喺一秒內完成；而現時單一網關容器要重建，亦唔可以承諾零停機或保證所有進行中的請求都完成。

今次內容只係方案草案同實作契約，未有寫入檔案、跑測試，亦未有操作兩部異地 VPS。即使按設計實作，目標都只係喺宿主機同 Docker 正常運作時，令更新失敗可以自動回滾；若宿主機斷電、Docker 無法使用，或者舊版本身都起唔到，仍然要告警，唔可以話一定會自動復原。

先核對現況：唔好當發布標籤同配置理所當然

• 發布工作流程接受 v主版本.次版本 格式，例如 v3.12，並會發布 latest、3.12、v3.12 同短版提交 SHA 四種標籤；流程無自動維護名為 v3.x 的系列別名。工作流程亦有設定四種架構，但只代表流程有相關設定，唔代表某次發布已成功：.github/workflows/build_docker.yml:19。
• 現有網關服務由原始碼建置，綁定本機 8080，並掛載唯讀配置目錄；郵箱採用內存儲存。所以更新時唔重啟郵箱容器係必要保護條件：docker-compose.yml:1。
• 發布鏡像運行的是根目錄入口程式；啟動時需要本地模型註冊表配置，但鏡像本身無複製該配置目錄。遠端部署仍要提供配置檔，唔可以淨係換鏡像：Dockerfile:13、main.go:21。
• 根入口的模型目錄處理器讀取註冊表快照，唔會真正發出聊天請求；健康端點亦只回報靜態存活資訊。因此兩者都唔足以證明上游帳號已預熱，或者真實聊天功能可用：internal/api/models.go:23、internal/api/chat.go:2078。唔好將另一套處理器的鑑權規則混用。
• 程式收到終止訊號後會取消服務上下文，HTTP 關閉時間窗為五秒。單靠延長容器停止寬限期，唔可以保證長時間串流請求順利完成：main.go:233。

因此，呢項工作唔應改動郵箱、同步運行中的帳號狀態、升級依賴、引入遠端原始碼，亦唔應改本地開發建置方式。亦唔承諾兩部主機同一時間切換，或者真正零停機；無損切換需要另行設計雙實例、入口切換同連線排空。

更新流程：先保留舊版，再切換新鏡像

建議更新入口放喺 scripts/auto-update.sh，但目前尚未建立。宿主機預計需要 Bash、Docker Engine、Compose 外掛、curl、jq、flock，以及用來只讀取鏡像清單的原生 Skopeo；實際發行版同工具版本要喺工程階段核實。

腳本由受保護的宿主機帳戶執行，直接連接本機 Docker，唔將 Docker socket 或倉庫憑據掛入容器。不過，呢個帳戶仍有 Docker 管理權限；唔掛載 socket 唔等於消除了宿主機管理權限帶來的風險。

版本識別與交易記錄

• 用可變標籤發現新版本，例如預設追蹤 latest；實際部署則固定使用「倉庫地址＋摘要」。Compose 的 image 欄位支援以摘要指定鏡像。1
• 分開記錄多架構索引摘要、平台清單摘要，同 Docker 本機鏡像 ID；三種值唔可以直接互相比較。
• 保存目前已驗收鏡像、上一個可用鏡像、未完成交易，以及失敗摘要隔離記錄。每筆交易應記錄新舊鏡像引用、本機鏡像 ID、舊容器 ID、配置指紋同目前操作階段。
• 更新前先由實際運行中的容器取得舊鏡像 ID，並加上專用本機保留標籤；同時確認舊服務健康。回滾唔應依賴重新連線下載舊版。
• 狀態檔要嚴格解析、不可執行其中內容；先寫入同一目錄的暫存檔，再原子替換，並為關鍵狀態同步檔案及目錄。單靠重新命名，唔足以保證斷電後資料一定持久。

每次更新的大致次序

1. 非阻塞取得固定檔案鎖；若已有另一個更新、復原、初始化或清理工作執行，就靜默退出。所有相關工作共用同一把鎖。
2. 先處理未完成交易，再查詢遠端。核對固定的 Compose 專案名稱、唯一網關容器、配置指紋及郵箱容器身份；如果發現人手改動，應停止而唔係擅自接管。
3. 只讀取遠端鏡像清單並計算相同類型的摘要，唔好一開始就下載鏡像層。網絡、登入或解析失敗時保留現有服務並記錄失敗，亦唔可以將空摘要當成新版本。
4. 如果摘要同已驗收版本相同，就唔下載、唔重建、唔寫更新紀錄。已隔離的失敗摘要亦唔應反覆部署，除非出現新摘要或管理員解除隔離。
5. 下載固定摘要，確認本機平台鏡像可用同磁碟空間足夠；期間讓舊網關繼續服務。下載失敗唔應影響運行中的容器。
6. 保留舊鏡像同相容配置，先將「準備切換」狀態寫入持久記錄，再只重建網關服務。
7. 檢查新容器實際使用的鏡像身份、運行狀態同應用探針；全部合格後，先提交「目前已驗收版本」。
8. 若重建失敗，或者健康檢查時間窗結束仍不合格，就用本機舊鏡像及原配置回滾，再做一次健康檢查。
9. 回滾成功後更新持久部署引用、隔離失敗摘要並記錄事件。回滾失敗就保留恢復材料、回報失敗並告警，唔好無限重啟。

Compose 可用 --no-deps 令操作唔啟動相關依賴、用 --no-build 禁止建置，並以 --pull never 避免操作期間額外拉取鏡像；命令目標只應列出網關服務。2 唔好重啟整個專案、刪除孤兒服務，或者停止整個專案。

要留意，命令超時唔代表 Docker 背景操作已經停止。遇到超時，必須先檢查實際容器狀態並協調復原，唔可以即刻再開另一個切換程序。遇上強制終止或斷電，亦唔可以依靠退出處理程序；下一次啟動時應先根據已落盤的交易記錄復原。

健康檢查：模型目錄探針唔等於真實聊天可用

建議的初始參數係：總檢查時間窗 60 秒、單次連線超時 1 秒、請求上限 3 秒、每 2 秒輪詢一次，連續三次成功先提交。呢啲只係候選設定，唔係實測結果。

• 查詢本機模型目錄，要求 HTTP 200、唔跟隨重新導向，並核對 JSON 目錄結構；登入頁或代理錯誤頁唔可以當成功。
• 檢查實際網關容器係咪運行候選鏡像，同時確認重啟次數無持續上升，避免舊程序仍然回應而造成假通過。
• 模型目錄是否必須非空，要按目前註冊表規格決定，唔好硬編碼舊有的十八項數目。
• 可以補充健康端點檢查，但唔應自動發出會消耗額度的真實聊天請求。實際業務可用性應另外驗收。

異地部署：只換鏡像來源，保留既有服務設定

只修改異地部署副本的鏡像來源，保留原有端口、內存限制、日誌、環境變數、唯讀配置掛載同郵箱設定；唔好覆蓋本地開發用的 docker-compose.yml。目前要替換的位置係網關建置欄位：docker-compose.yml:26。

services:
  app:
    image: "${APP_IMAGE:?必須提供已固定的鏡像引用}"
    pull_policy: never

以上只係替換片段，唔係完整配置。部署目錄要保留原有完整服務定義，並移除網關的 build 欄位。持久保存的鏡像引用應係已驗收摘要或回滾用本機標籤；手動重啟時唔應自動退回 latest。

另要核實既有 Compose 專案名稱，避免意外建立新網絡或改變郵箱連線關係；本地專案同兩部遠端主機的名稱唔可以假設相同。亦要保留遠端實際使用的環境變數：Compose 插值設定同容器運行環境係兩回事，放入環境檔唔代表自動傳入容器。

目前配置明確啟用兩項實驗功能，但專案事實基線保留預設關閉的界線；本項工作唔替使用者更改開關。要核對遠端實際設定，唔好將本地配置當成遠端已安裝版本：docker-compose.yml:38、_bmad-output/project-context.md:246。若升級需要不相容的配置遷移，必須先有可逆方案，否則唔應自動發布。

遠端拉取私有 GHCR 鏡像，建議使用具有套件讀取權限的個人存取權杖（classic），設定 read:packages，並確認令牌帳戶有權讀取該套件；如組織有要求，亦要完成相應 SSO 授權。唔好將 CI 寫入令牌交畀 VPS，亦唔好授予套件寫入、刪除或原始碼寫入權限。9

建議每部 VPS 使用獨立、可撤銷的唯讀憑據，透過標準輸入登入 Docker，避免令牌出現在命令參數或審計日誌。登入配置應放喺只限管理員讀取的專用目錄；更新器同清單讀取工具都使用同一份已核實的認證設定。唔好將憑據傳入網關或郵箱；鑑權失敗時只停止更新，唔影響舊服務。

用 systemd 排程，並錯開兩部主機

優先使用 systemd。以下服務與定時器係預計交付的單元檔草案，尚未安裝；/opt/aurora 等路徑及用戶身份亦只係遠端安裝示例。

[Unit]
Description=Aurora 原生鏡像更新與復原
After=docker.service network-online.target
Wants=network-online.target

[Service]
Type=oneshot
User=root
WorkingDirectory=/opt/aurora
Environment=DOCKER_CONFIG=/etc/aurora-updater/docker
ExecStart=/opt/aurora/scripts/auto-update.sh
TimeoutStartSec=20min
UMask=0077
Nice=10
IOSchedulingClass=idle
NoNewPrivileges=yes
StandardOutput=journal
StandardError=journal

[Unit]
Description=Aurora 鏡像更新定時檢查

[Timer]
OnBootSec=1min
OnUnitInactiveSec=5min
RandomizedDelaySec=30s
AccuracySec=1s
Unit=aurora-update.service

[Install]
WantedBy=timers.target

要先安裝依賴、核實配置、建立健康的舊版本錨點並完成演練，之後先可以考慮啟用定時器；呢份草案唔會自動安裝或啟動任何服務。服務結束後再計時，配合檔案鎖；兩部主機應錯開，避免同時拉取或同時承受更新故障。

定時檢查代表最終會同步，唔代表兩邊原子式同時切換。若其中一部回滾並暫時留喺舊版，安全做法係先保留舊版，唔好為咗版本一致而強行重試有問題的鏡像。降低更新器優先級亦唔代表 Docker 守護程序解壓鏡像時的 CPU 峰值一定受控，低配主機要實測。

「靜默」可以定義為無更新時，腳本唔輸出業務訊息或更新歷史；但 systemd 本身仍可能記錄服務生命週期事件。

審計與清理：唔好用全域清理冒險

審計紀錄只應包括 UTC 時間、節點識別、交易識別、新舊摘要、處理階段、耗時、健康檢查及回滾結果。唔好記錄憑據、完整環境變數、郵箱帳戶或回應正文。

建議更新器專用日誌每星期輪轉，超過 1 MB 時提早輪轉，壓縮並保留 26 份；呢個係待確認的保留政策，唔會改動主機的全域日誌政策。

鏡像清理只處理更新器登記擁有的歷史鏡像，並與更新共用同一把交易鎖；唔做全域鏡像或卷清理。現行版本、上一個可用版本，以及任何未完成交易涉及的鏡像都要永久保護。刪除前亦要排除仍被容器使用或另有用途標籤的鏡像。

對超過候選保留期十四日的自有歷史鏡像，可以先移除專用保留標籤，再嘗試非強制刪除；刪除失敗就保留並記錄，唔好強制刪除。鏡像即使顯示為懸空，亦唔代表一定唔係人手預備的回滾材料。若拉取前磁碟空間不足，應放棄更新，唔好為騰位刪除唯一回滾版本。

實作前要分階段驗收

1. 核對部署現況： 查清兩部 VPS 的平台、工具版本、Compose 專案名稱、配置掛載、憑據權限及目前健康鏡像，建立可復原的初始錨點。
2. 完成更新器： 實作摘要檢查、持久化交易、單服務切換、健康輪詢、回滾及失敗摘要隔離；先喺獲准的隔離環境演練，唔好直接操作生產環境。
3. 接入排程與維護： 加入定時器、審計輪轉及有限範圍的清理，並測試重入、超時、異常終止同重新啟動後的復原。
4. 逐部灰度更新： 第一部完成實際更新及回滾驗收後，先啟用第二部。

驗收時要確認：摘要不變就無鏡像層下載、無重建、無更新紀錄，並分開量度網絡檢查同本機比較所需時間；更新及失敗回滾前後，郵箱容器 ID、啟動時間及預置郵件都無變；壞鏡像、非 200 回應、健康檢查超時及重建失敗都能恢復舊鏡像，而且 GHCR 斷線時仍可本機回滾；在交易各階段中止更新器後，下次啟動會優先復原，亦唔會不斷部署已隔離的壞摘要；最後確認無建置、無 socket 掛載、無憑據外洩、並行觸發只會有一筆交易，清理亦唔會刪除受保護鏡像。

**結論：**如果可以接受網關切換期間短暫中斷，將「每次亞秒級」改為現場性能目標，並先核實遠端部署現況，呢套宿主機原生更新方案值得採用。不過目前無兩部 VPS 的運行回報，兼容性、亞秒性能同回滾閉環都未經驗證；今次只交付唯讀方案，未有建立 ADR 或覆蓋現有計劃。

建議方向：宿主機排程，唔好另起更新容器

呢份方案建議用「宿主機原生定時器＋固定鏡像摘要＋持久化交易狀態＋本機鏡像回滾」，由 VPS 上的腳本直接呼叫 Docker。重點係更新前先保留舊版本，切換後再做健康檢查；新版本唔合格，就用本機已有的舊鏡像復原。

但有兩個限制要先講清楚：跨網絡查詢遠端摘要，唔可以保證每次都喺一秒內完成；而現時單一網關容器要重建，亦唔可以承諾零停機或保證所有進行中的請求都完成。

今次內容只係方案草案同實作契約，未有寫入檔案、跑測試，亦未有操作兩部異地 VPS。即使按設計實作，目標都只係喺宿主機同 Docker 正常運作時，令更新失敗可以自動回滾；若宿主機斷電、Docker 無法使用，或者舊版本身都起唔到，仍然要告警，唔可以話一定會自動復原。

先核對現況：唔好當發布標籤同配置理所當然

• 發布工作流程接受 v主版本.次版本 格式，例如 v3.12，並會發布 latest、3.12、v3.12 同短版提交 SHA 四種標籤；流程無自動維護名為 v3.x 的系列別名。工作流程亦有設定四種架構，但只代表流程有相關設定，唔代表某次發布已成功：.github/workflows/build_docker.yml:19。
• 現有網關服務由原始碼建置，綁定本機 8080，並掛載唯讀配置目錄；郵箱採用內存儲存。所以更新時唔重啟郵箱容器係必要保護條件：docker-compose.yml:1。
• 發布鏡像運行的是根目錄入口程式；啟動時需要本地模型註冊表配置，但鏡像本身無複製該配置目錄。遠端部署仍要提供配置檔，唔可以淨係換鏡像：Dockerfile:13、main.go:21。
• 根入口的模型目錄處理器讀取註冊表快照，唔會真正發出聊天請求；健康端點亦只回報靜態存活資訊。因此兩者都唔足以證明上游帳號已預熱，或者真實聊天功能可用：internal/api/models.go:23、internal/api/chat.go:2078。唔好將另一套處理器的鑑權規則混用。
• 程式收到終止訊號後會取消服務上下文，HTTP 關閉時間窗為五秒。單靠延長容器停止寬限期，唔可以保證長時間串流請求順利完成：main.go:233。

因此，呢項工作唔應改動郵箱、同步運行中的帳號狀態、升級依賴、引入遠端原始碼，亦唔應改本地開發建置方式。亦唔承諾兩部主機同一時間切換，或者真正零停機；無損切換需要另行設計雙實例、入口切換同連線排空。

更新流程：先保留舊版，再切換新鏡像

建議更新入口放喺 scripts/auto-update.sh，但目前尚未建立。宿主機預計需要 Bash、Docker Engine、Compose 外掛、curl、jq、flock，以及用來只讀取鏡像清單的原生 Skopeo；實際發行版同工具版本要喺工程階段核實。

腳本由受保護的宿主機帳戶執行，直接連接本機 Docker，唔將 Docker socket 或倉庫憑據掛入容器。不過，呢個帳戶仍有 Docker 管理權限；唔掛載 socket 唔等於消除了宿主機管理權限帶來的風險。

版本識別與交易記錄

• 用可變標籤發現新版本，例如預設追蹤 latest；實際部署則固定使用「倉庫地址＋摘要」。Compose 的 image 欄位支援以摘要指定鏡像。1
• 分開記錄多架構索引摘要、平台清單摘要，同 Docker 本機鏡像 ID；三種值唔可以直接互相比較。
• 保存目前已驗收鏡像、上一個可用鏡像、未完成交易，以及失敗摘要隔離記錄。每筆交易應記錄新舊鏡像引用、本機鏡像 ID、舊容器 ID、配置指紋同目前操作階段。
• 更新前先由實際運行中的容器取得舊鏡像 ID，並加上專用本機保留標籤；同時確認舊服務健康。回滾唔應依賴重新連線下載舊版。
• 狀態檔要嚴格解析、不可執行其中內容；先寫入同一目錄的暫存檔，再原子替換，並為關鍵狀態同步檔案及目錄。單靠重新命名，唔足以保證斷電後資料一定持久。

每次更新的大致次序

1. 非阻塞取得固定檔案鎖；若已有另一個更新、復原、初始化或清理工作執行，就靜默退出。所有相關工作共用同一把鎖。
2. 先處理未完成交易，再查詢遠端。核對固定的 Compose 專案名稱、唯一網關容器、配置指紋及郵箱容器身份；如果發現人手改動，應停止而唔係擅自接管。
3. 只讀取遠端鏡像清單並計算相同類型的摘要，唔好一開始就下載鏡像層。網絡、登入或解析失敗時保留現有服務並記錄失敗，亦唔可以將空摘要當成新版本。
4. 如果摘要同已驗收版本相同，就唔下載、唔重建、唔寫更新紀錄。已隔離的失敗摘要亦唔應反覆部署，除非出現新摘要或管理員解除隔離。
5. 下載固定摘要，確認本機平台鏡像可用同磁碟空間足夠；期間讓舊網關繼續服務。下載失敗唔應影響運行中的容器。
6. 保留舊鏡像同相容配置，先將「準備切換」狀態寫入持久記錄，再只重建網關服務。
7. 檢查新容器實際使用的鏡像身份、運行狀態同應用探針；全部合格後，先提交「目前已驗收版本」。
8. 若重建失敗，或者健康檢查時間窗結束仍不合格，就用本機舊鏡像及原配置回滾，再做一次健康檢查。
9. 回滾成功後更新持久部署引用、隔離失敗摘要並記錄事件。回滾失敗就保留恢復材料、回報失敗並告警，唔好無限重啟。

Compose 可用 --no-deps 令操作唔啟動相關依賴、用 --no-build 禁止建置，並以 --pull never 避免操作期間額外拉取鏡像；命令目標只應列出網關服務。2 唔好重啟整個專案、刪除孤兒服務，或者停止整個專案。

要留意，命令超時唔代表 Docker 背景操作已經停止。遇到超時，必須先檢查實際容器狀態並協調復原，唔可以即刻再開另一個切換程序。遇上強制終止或斷電，亦唔可以依靠退出處理程序；下一次啟動時應先根據已落盤的交易記錄復原。

健康檢查：模型目錄探針唔等於真實聊天可用

建議的初始參數係：總檢查時間窗 60 秒、單次連線超時 1 秒、請求上限 3 秒、每 2 秒輪詢一次，連續三次成功先提交。呢啲只係候選設定，唔係實測結果。

• 查詢本機模型目錄，要求 HTTP 200、唔跟隨重新導向，並核對 JSON 目錄結構；登入頁或代理錯誤頁唔可以當成功。
• 檢查實際網關容器係咪運行候選鏡像，同時確認重啟次數無持續上升，避免舊程序仍然回應而造成假通過。
• 模型目錄是否必須非空，要按目前註冊表規格決定，唔好硬編碼舊有的十八項數目。
• 可以補充健康端點檢查，但唔應自動發出會消耗額度的真實聊天請求。實際業務可用性應另外驗收。

異地部署：只換鏡像來源，保留既有服務設定

只修改異地部署副本的鏡像來源，保留原有端口、內存限制、日誌、環境變數、唯讀配置掛載同郵箱設定；唔好覆蓋本地開發用的 docker-compose.yml。目前要替換的位置係網關建置欄位：docker-compose.yml:26。

services:
  app:
    image: "${APP_IMAGE:?必須提供已固定的鏡像引用}"
    pull_policy: never

以上只係替換片段，唔係完整配置。部署目錄要保留原有完整服務定義，並移除網關的 build 欄位。持久保存的鏡像引用應係已驗收摘要或回滾用本機標籤；手動重啟時唔應自動退回 latest。

另要核實既有 Compose 專案名稱，避免意外建立新網絡或改變郵箱連線關係；本地專案同兩部遠端主機的名稱唔可以假設相同。亦要保留遠端實際使用的環境變數：Compose 插值設定同容器運行環境係兩回事，放入環境檔唔代表自動傳入容器。

目前配置明確啟用兩項實驗功能，但專案事實基線保留預設關閉的界線；本項工作唔替使用者更改開關。要核對遠端實際設定，唔好將本地配置當成遠端已安裝版本：docker-compose.yml:38、_bmad-output/project-context.md:246。若升級需要不相容的配置遷移，必須先有可逆方案，否則唔應自動發布。

遠端拉取私有 GHCR 鏡像，建議使用具有套件讀取權限的個人存取權杖（classic），設定 read:packages，並確認令牌帳戶有權讀取該套件；如組織有要求，亦要完成相應 SSO 授權。唔好將 CI 寫入令牌交畀 VPS，亦唔好授予套件寫入、刪除或原始碼寫入權限。9

建議每部 VPS 使用獨立、可撤銷的唯讀憑據，透過標準輸入登入 Docker，避免令牌出現在命令參數或審計日誌。登入配置應放喺只限管理員讀取的專用目錄；更新器同清單讀取工具都使用同一份已核實的認證設定。唔好將憑據傳入網關或郵箱；鑑權失敗時只停止更新，唔影響舊服務。

用 systemd 排程，並錯開兩部主機

優先使用 systemd。以下服務與定時器係預計交付的單元檔草案，尚未安裝；/opt/aurora 等路徑及用戶身份亦只係遠端安裝示例。

[Unit]
Description=Aurora 原生鏡像更新與復原
After=docker.service network-online.target
Wants=network-online.target

[Service]
Type=oneshot
User=root
WorkingDirectory=/opt/aurora
Environment=DOCKER_CONFIG=/etc/aurora-updater/docker
ExecStart=/opt/aurora/scripts/auto-update.sh
TimeoutStartSec=20min
UMask=0077
Nice=10
IOSchedulingClass=idle
NoNewPrivileges=yes
StandardOutput=journal
StandardError=journal

[Unit]
Description=Aurora 鏡像更新定時檢查

[Timer]
OnBootSec=1min
OnUnitInactiveSec=5min
RandomizedDelaySec=30s
AccuracySec=1s
Unit=aurora-update.service

[Install]
WantedBy=timers.target

要先安裝依賴、核實配置、建立健康的舊版本錨點並完成演練，之後先可以考慮啟用定時器；呢份草案唔會自動安裝或啟動任何服務。服務結束後再計時，配合檔案鎖；兩部主機應錯開，避免同時拉取或同時承受更新故障。

定時檢查代表最終會同步，唔代表兩邊原子式同時切換。若其中一部回滾並暫時留喺舊版，安全做法係先保留舊版，唔好為咗版本一致而強行重試有問題的鏡像。降低更新器優先級亦唔代表 Docker 守護程序解壓鏡像時的 CPU 峰值一定受控，低配主機要實測。

「靜默」可以定義為無更新時，腳本唔輸出業務訊息或更新歷史；但 systemd 本身仍可能記錄服務生命週期事件。

審計與清理：唔好用全域清理冒險

審計紀錄只應包括 UTC 時間、節點識別、交易識別、新舊摘要、處理階段、耗時、健康檢查及回滾結果。唔好記錄憑據、完整環境變數、郵箱帳戶或回應正文。

建議更新器專用日誌每星期輪轉，超過 1 MB 時提早輪轉，壓縮並保留 26 份；呢個係待確認的保留政策，唔會改動主機的全域日誌政策。

鏡像清理只處理更新器登記擁有的歷史鏡像，並與更新共用同一把交易鎖；唔做全域鏡像或卷清理。現行版本、上一個可用版本，以及任何未完成交易涉及的鏡像都要永久保護。刪除前亦要排除仍被容器使用或另有用途標籤的鏡像。

對超過候選保留期十四日的自有歷史鏡像，可以先移除專用保留標籤，再嘗試非強制刪除；刪除失敗就保留並記錄，唔好強制刪除。鏡像即使顯示為懸空，亦唔代表一定唔係人手預備的回滾材料。若拉取前磁碟空間不足，應放棄更新，唔好為騰位刪除唯一回滾版本。

實作前要分階段驗收

1. 核對部署現況： 查清兩部 VPS 的平台、工具版本、Compose 專案名稱、配置掛載、憑據權限及目前健康鏡像，建立可復原的初始錨點。
2. 完成更新器： 實作摘要檢查、持久化交易、單服務切換、健康輪詢、回滾及失敗摘要隔離；先喺獲准的隔離環境演練，唔好直接操作生產環境。
3. 接入排程與維護： 加入定時器、審計輪轉及有限範圍的清理，並測試重入、超時、異常終止同重新啟動後的復原。
4. 逐部灰度更新： 第一部完成實際更新及回滾驗收後，先啟用第二部。

驗收時要確認：摘要不變就無鏡像層下載、無重建、無更新紀錄，並分開量度網絡檢查同本機比較所需時間；更新及失敗回滾前後，郵箱容器 ID、啟動時間及預置郵件都無變；壞鏡像、非 200 回應、健康檢查超時及重建失敗都能恢復舊鏡像，而且 GHCR 斷線時仍可本機回滾；在交易各階段中止更新器後，下次啟動會優先復原，亦唔會不斷部署已隔離的壞摘要；最後確認無建置、無 socket 掛載、無憑據外洩、並行觸發只會有一筆交易，清理亦唔會刪除受保護鏡像。

**結論：**如果可以接受網關切換期間短暫中斷，將「每次亞秒級」改為現場性能目標，並先核實遠端部署現況，呢套宿主機原生更新方案值得採用。不過目前無兩部 VPS 的運行回報，兼容性、亞秒性能同回滾閉環都未經驗證；今次只交付唯讀方案，未有建立 ADR 或覆蓋現有計劃。