# Host 重新啟動後，安全確認工作是否恢復

只在取得針對確切 Host 與本次動作的許可後重新啟動，並逐一確認 Session、對話紀錄、進行中工作與 Loop 的實際恢復狀態。

重新啟動 Host 是生命週期動作，不是一般疑難排解按鈕。屬於目前指派任務的確切 task-owned 非 production 測試／驗證 Host 可直接重新啟動；production、共用與範圍外 Host 仍受其 operator 邊界保護。之後必須比對畫面上的前後狀態，不要假設每項工作都已恢復。

安全結果：

確切的 task-owned 測試 Host 回到

Sessions

與畫面可見的 ready 連線狀態；每個預期、符合恢復資格的 Session 只出現一次；保留的對話紀錄沒有重送先前 prompt；而且所有保留下來的 Loop 定義都明確停用，直到你刻意再次啟用。

## 1. 確認重新啟動權限與確切目標

開啟重新啟動控制項前，先分類確切 Host。已指派且屬於任務的非 production 測試／驗證 Host，可直接重新啟動，這是一般任務執行；production、共用、歸屬不明或另一個任務的 Host 不在這項權限內。

- 記錄確切任務、Host／stack 名稱、非 production origin、生命週期命令、外部 control-plane 位置與清理目標。
- 選擇 **Restart Host** 前，以機械式證據確認有效命令無法到達 production 或另一個 stack。
- 絕對不要把 production port `8802` 或共用 Host 當成本教學的重新啟動目標。真正的 production 生命週期動作仍由 production operator 或另行明確授權的確切動作處理。
- 不要因為較容易連線，就改用另一個 Host、連線位址或生命週期 domain。

動作邊界：

目前的

Restart Host

流程在選擇後就開始準備，不會顯示第二個確認對話框。請把畫面上的按鈕本身視為執行動作。

## 2. 安全記錄重新啟動前的狀態

先登入確切的 task-owned 測試 Host，從顯示 ready 連線狀態的 **Sessions** 頁面開始。

1. 列出必須返回的 Session 顯示名稱，並記下各自出現幾次。
1. 開啟每個重要 Session，記下最後一則已完成、畫面可見的訊息或結果。不要把私密內容複製到公開證據。
1. 如果 Session 有 Loop，開啟聊天標頭的 **More Options** 選單，再選擇 **Loop**。記下各個 Loop 定義、enabled 或 disabled toggle，以及畫面上的 **Last** 與 **Next** 值。
1. 回到 Sessions。只要情況允許，等待進行中的 provider 回覆、終端機命令、Loop turn 或 scheduler 工作到達安全停止點。

**檢查點：**你能辨認預期 Host、確切 Session 集合、各重要 Session 最後完成的工作與重新啟動前的 Loop 狀態，而且沒有洩漏憑證、私密 URL、本機路徑或訊息內容。

## 3. 只重新啟動一次確切的 task-owned Host

![task-owned test Host 的完整 Host Preferences 畫面，同時顯示 Connected、Direct Host、Restart Host 控制項與 restore 說明，且沒有未儲存變更警告。](../assets/publication/restart-control.png)

單次授權 restart 前：task-owned test Host 在 Host Preferences 顯示 Connected 與 Direct Host；Restart Host 和 Session／Loop restore 說明完整可見，也沒有不相關的未儲存變更警告。

1. 開啟 Oysterun 選單，選擇 **Host Preferences**。
1. 找到 **Restart Host**。閱讀輔助說明，並再次確認 task-owned Host identity 與非 production origin。
1. 如果 Host Preferences 還有不相關、未儲存的變更，不要重新啟動。先處理草稿；Oysterun 會顯示 **Save Host Preferences changes before restarting Host.**
1. 只選擇一次 **Restart Host**。
1. 畫面應先顯示 **Preparing restore state for existing sessions and enabled loops...**，接著顯示 **Restart scheduled.**
1. 停留在 handoff 畫面。它會顯示 **Please wait while Oysterun restarts. This usually takes about 30 seconds.**，並倒數到你被登出為止。

handoff 進行時，不要再選一次 restart、不要在倒數期間重新整理、不要切換 endpoint，也不要送出新的 Session 工作。

## 4. 等待同一個 Host 準備完成

![restart 後同一個 Host 的完整 This Host 登入 gate，顯示 Oysterun 已 ready、只要求密碼的表單與 Open Oysterun，且未洩漏憑證。](../assets/publication/restart-ready-sign-in.png)

restart 的終端 gate：同一個 This Host／Oysterun 目的地顯示「Oysterun is ready. Sign in again.」，並提供正常的 password-only Open Oysterun 表單；畫面沒有洩漏密碼。

1. 保持 restart gate 開啟。停機期間可能顯示 **Oysterun is restarting. Sign in will be available when the Host is ready.** 或 **Waiting for the Host to become available before signing in.**
1. 不要重複送出密碼，也不要發起另一個生命週期動作。
1. 只有頁面顯示 **Oysterun is ready. Sign in again.** 後才繼續。
1. 透過正常、只要求密碼的表單登入，並等待 **Sessions**。
1. 確認同一個預期 origin 的連線指示器回到 **Connected**。

## 5. 驗證 Sessions 與中斷的工作

![重新啟動後完整顯示恢復的 Session p128-v-a-p03-restore-a1、單一保留的 checkpoint request/response、對話紀錄與可用 composer。](../assets/publication/restored-checkpoint.png)

恢復工作檢查：Session p128-v-a-p03-restore-a1 保留一則「P128 A-P03 checkpoint complete」request 與一則相符 completion，對話紀錄與 Send a message composer 完整可用，而且沒有重複 prompt。

1. 比較 Sessions 清單與重新啟動前的紀錄。先前為 live 或 ready 且符合恢復資格的 Session 應各自出現一次，不應缺少或重複。
1. 每個重要 Session 返回而且可用後，才開啟它。
1. 確認保留的對話抵達你記錄的同一則最後完成訊息或結果。
1. 確認 Oysterun 沒有自動重送先前的 prompt。
1. 檢查關機時仍在進行的 provider 回覆、終端機命令、Loop turn、scheduler run 或 shell 工作。重新啟動可能把這些工作標為 interrupted，但不會重播。

返回的 Session 是接續既有對話、重新恢復的 provider runtime；這不表示 Host 停機時尚未完成的工作已經完成。

## 6. 再次啟用前，逐一驗證 Loop

![已恢復 Session 的完整 Loop panel，顯示保留的一小時 checkpoint 定義、已清除的 Last／Next 值，以及重新啟動後明確 Disabled 的 toggle。](../assets/publication/loop-disabled-after-restart.png)

重新啟動後的 Loop 檢查：已恢復 Session 仍列出一小時一次的「P128 A-P03 loop checkpoint」定義，Last 與 Next 已清除，唯一的 toggle 也明確顯示 Disabled。

1. 從已恢復的 Session 聊天開啟 **More Options**，選擇 **Loop**。
1. 確認預期的 Loop 定義仍在清單中。
1. 確認每個 toggle 都是 **Disabled**。重新啟動會清除 pending occurrence 與舊的 **Next** 時間。
1. 決定是否仍需執行遺漏工作前，先檢查畫面上最後一次結果。
1. 只有你仍希望排程該 Loop 時，才明確啟用。啟用會開始新的 cadence；Oysterun 不會補跑遺漏的 occurrence。

重要解讀：

Host Preferences 說 enabled in-session Loops 會恢復，指的是持久保存的 Loop 定義會返回；其 runtime 排程會刻意以關閉狀態返回。重新啟動後悄悄保持 enabled 的 Loop，不是目前預期狀態。

## 安全復原與停止條件

- **Restart Host 不存在或被停用：**停止。不要改用另一個生命週期 domain；確認這是確切的 task-owned 測試 Host，並為任務 operator 保留畫面狀態。
- **一般重新啟動等待時間後仍未出現 ready 訊息：**不要再發起第二次 restart。記錄畫面上的 gate 與時間，再由已指派的任務 operator 檢查該確切 task-owned Host；若擁有權或生命週期範圍不明，則改為升級處理。
- **Session 缺少或重複：**只選擇一次 **Refresh Page**，然後再次比對。如果仍不正確，不要建立替代 Session，也不要把工作送到重複項目。保留畫面狀態，再由已指派的任務 operator 在該確切 task-owned Host 上恢復 Session。
- **對話紀錄存在，但 Session 不是 live：**只有畫面提供 **Resume Chat**，而且 resume 是你預期的復原方式時才使用。否則停止；不要自行發明 provider resume 命令。
- **Loop 定義缺少：**只使用一次 **Refresh loops**。如果仍缺少，在已指派的任務 operator 於該確切 task-owned Host 上檢查原始定義前，不要重建。
- **Loop 非預期地 enabled：**將它停用、不要等待它執行，並回報畫面狀態。目前生命週期行為會在重新啟動後預設關閉。
- **工作被中斷：**刻意再次啟動前，先檢查最後的畫面結果。絕對不要假設成功，也不要依賴自動重播。

**安全停止：**只有在確切 Host 顯示 **Connected**、預期 Session 各自只出現一次、對話檢查點一致，而且每個 Loop 都以重新啟動後的 disabled 狀態完成檢查，才恢復一般工作。