需要從終端機檢查或操作 Oysterun 時，請使用本指南。你會找到受支援的產品模組、確認預定的 Host、分辨唯讀命令與會改變狀態的命令，並對受保護變更使用正確的 dry-run 與確認界線。

開始前

起始畫面：在擁有或能連到預定 Host 的機器上開啟終端機。請勿從猜測 action 名稱開始。

1. 找出受支援的產品模組

乾淨的 Host Terminal 顯示 oysterun 說明、命令格式與目前產品模組清單。
畫面 checkpoint：oysterun --help 在乾淨終端機中顯示命令格式與目前受支援的模組。

執行最上層說明命令：

oysterun --help

目前 CLI 會在 Product modules 下列出：

auth, sessions, chat, scheduler, mail, notifications, website, telegram

2. 在進行任何操作前先確認目標

乾淨的 Host Terminal 顯示明確遮蔽的 Host 唯讀命令，以及確切任務目標的成功狀態 envelope。
畫面 checkpoint：已遮蔽 Host 的唯讀命令回傳 ok、sessions status，並在 result envelope 中顯示預定的確切 Session。

有多個 Host 可用時，請提供明確的 --host。先從唯讀操作開始：

oysterun sessions list --host <HOST_ORIGIN> --json

如果你使用先前已核准的 dashboard CLI 存取權，可以在不變更 Session 的情況下檢查：

oysterun auth status --host <HOST_ORIGIN> --json
  1. 閱讀目標與回傳狀態。
  2. 確認列出的 Sessions 屬於預定 Host。
  3. 只從這次可信任的唯讀結果複製確切識別碼；不要從顯示名稱猜測。

3. 辨認唯讀操作

下列受支援的 action 會檢查目前狀態，不會要求產品變更：

模組唯讀 action一般結果
authstatus目前的 dashboard CLI 登入狀態
sessionslist、status、url、profile getSession 身分、狀態、URL 或 profile
chatrecent、messages、messages-around、search、loop list有界訊息、前後文、搜尋結果或 Loop 定義
schedulerlist、get、runs、run-logSchedules 及其已記錄的執行資訊
mailunread-count、list、getMail 計數、清單或單一項目
notificationsstatus目前的通知可用狀態
websitestatus、url、validate、access getWebsite 狀態、URL、驗證結果或存取模式
telegramstatus；sessions telegram getTelegram 或每個 Session 的 Telegram 狀態

需要結構化 envelope 時加入 --json。其中包含 ok、command、contract、result 與 error。

4. 辨認不等待確認的一般變更

下列 action 類別會在必要輸入與授權通過後改變產品狀態。沒有出現確認提示，並不會讓它們變安全：

模組立即改變狀態的 action可能改變的內容
authlogin、logoutCLI 登入狀態
sessionsstart、profile update、rename、resume、branch-resume、Telegram enable/disable/updateSessions 或 Session profile 設定
chatsend；Loop create、update、enable、disable訊息或 Loop 定義與狀態
schedulercreate、update、enable、test-runSchedules 或一次真正的測試執行
mailsend、read、unread、archive、unarchive、updateMail 傳送或項目狀態
notificationssend除非使用該 action 已記載的 dry run，否則會傳送通知
websiteinit、enable除非使用該 action 已記載的 dry run，否則會改變 Website 檔案或啟用狀態

5. 預覽並確認受保護變更

乾淨的 Host Terminal 顯示確切 Session restart dry run 與預定的受保護請求。
畫面 checkpoint：確切目標以 dry_run: true 和 POST /session/restart 預覽；受保護變更並未執行。

下列目前操作具有強制確認界線：

範圍受保護操作界線
Sessionssessions stop、sessions interrupt、sessions restart單獨的 --confirm 或 --dry-run
Chatchat loop delete單獨的 --confirm 或 --dry-run
Schedulerscheduler disable、scheduler delete單獨的 --confirm 或 --dry-run
Mailmail delete單獨的 --confirm 或 --dry-run
Websitewebsite access set、website disable、website password set單獨的 --confirm 或 --dry-run

先預覽確切操作。使用 --json，讓預定請求可見，而不是只看到簡短的人類可讀狀態：

oysterun sessions restart \
  --host <HOST_ORIGIN> \
  --session-id <SESSION_ID> \
  --dry-run \
  --json
  1. 確認結果包含 dry_run: true。
  2. 重新確認你輸入的命令中所指定的 Host；在已遮蔽敏感資訊的計畫裡，檢查 request method、path 與確切目標識別碼。
  3. 任何內容錯誤或不清楚時，請停止。dry run 並未進行變更。
  4. 只有在變更已獲明確授權時，才以單獨的 --confirm 取代 --dry-run，重新執行同一條已檢查的命令。第二條命令會真正進行變更。

6. 閱讀輸出但不暴露私人資料

7. 復原時不要把唯讀變成變更

8. 以安全檢查完成

乾淨的 Host Terminal 顯示同一個確切 Session 目標的唯讀事後狀態。
畫面 checkpoint：最後一次唯讀 status 確認同一個確切 Session 在 dry run 後仍為 active、alive 且 ready。

active、alive 與 ready 是 lifecycle 與 readiness 欄位。這些欄位本身不能證明 provider 正在回應、輸入、被占用或產生有用進度。

  1. 最後再確認一次 Host 與確切目標。
  2. 將命令分類為唯讀、一般變更或受保護變更。
  3. 受保護變更需保留 dry-run 結果與已確認操作的授權。
  4. 每次一般變更或已確認的受保護變更之後，都要對同一個 Host 與確切目標執行相關唯讀命令。dry run 之後，請以事後唯讀確認預定變更並未發生。