/bedtime — 夜間自主模式
使用者將睡眠約 7–8 小時。要避免的失敗：他們醒來時什麼也沒發生。第二失敗：計算資源被浪費在無意義的事情上。第三失敗：一個會話內監控程式在凌晨 02:00 隨會話終止，導致 GPU 閒置。按此順序針對這三種失敗進行設計。
1. 確認（≤ 4 行，不發問）
使用者即將離開。不要問任何問題。說明：目前正在執行什麼、你將在夜間做什麼（選定的項目+備援方案）、以及晨間報告存放位置。如果某個決定確實需要由他們做，則採取能讓計算保持忙碌且可逆的預設值，在確認訊息中說明這個假設，並在晨間的 NEED YOU 中再次提及。
2. 盤點 — 資源與候選任務（≤ 10 分鐘，廉價檢查）
- 運算資源： 本機
nvidia-smi（與其他使用者共用 — 只取用空閒的顯示卡，謹慎安排長時間任務，絕不碰他們的資源）；專案機器清單中的遠端節點（如果有的話）；叢集佇列（如果有的話）。記錄哪些資源空閒、哪些忙碌、哪些即將完成。 - Claude 用量： 檢查剩餘額度。夜間執行的工作流程可能消耗整週的額度；保持在使用者設定的停止門檻內。優先使用磁碟驅動程式（執行時消耗 0 token）而非代理驅動的迴圈。
- 候選任務，按優先順序排列 — 選取符合可用運算資源的最高優先任務：
- 使用者已排入佇列的工作：今日對話、作戰計畫的下一階段、最新交接檔中「下一個會話應處理」的部分、WRAPUP_PLAN / TODO 檔案。
- 最能降低當前目標（通常是論文）不確定性的實驗：審查者會要求的消融實驗、缺少的基準線、隨機種子重複。
- 已完成的檢查點評估/指標（專案指標）— 成本低且永遠有用。
- 對已完成結果的分析 → 繪圖/報告，存放於專案的 reports 資料夾。
- 程式碼清理 — 僅在沒有需要運算資源的工作時進行。 優先選擇消耗 GPU 時數的工作：夜間浪費的是閒置的 GPU 時數，而非你的時間。跳過任何需要使用者決策才有用、已知無意義、或觸及使用者已確定的設計的工作。控制比較：一次只改變一個因素，不可破壞與基準線的可比較性。
3. 啟動 — 遵循常規紀律，加上持久性
- 解析設定，並在日誌中記錄輸入內容（資料列、過濾條件、分割、與基準線的每個差異），不只是記在腦中。先用確切指令進行煙霧測試。
- 磁碟上的獨立驅動程式，而非代理迴圈：
nohup setsid <driver>.sh，將state.txt/result.txt/ 日誌寫入<run>/目錄（final_now_driver.sh模式）。驅動程式自行階段→階段、任務→下一任務的銜接，每個階段都有會大聲失敗的截止時間。即使此會話中斷，GPU 仍保持忙碌。 - 驗證效果而非動作：啟動後處理程序存活、第一行日誌、第一個 wandb 資料點；將 wandb URL 放入晨間報告。
- 每張空閒 GPU 最多一個項目；如果室友的任務明顯即將完成且會需要該 GPU，則保留一張顯示卡 — 共用機器。
4. 監控 — 稀疏、持久
- 啟動一個監控器（Monitor 工具 / ScheduleWakeup ~30–60 分鐘），其唯一任務是：程序死亡？→ 診斷；如果原因簡單且已知（OOM → 較小批次、路徑拼寫錯誤）則重新啟動；否則轉向下一個候選任務。已完成？→ 驅動程式應已啟動下一個任務；如果沒有，則啟動它。每次喚醒時若有閒置 GPU = 立即處理，而非記錄。
- 每次喚醒先預期再觀察：陳述預期的 loss/epoch/step，進行比較，在夜間日誌中記錄一行。
- 上下文快用盡時 → 立即寫入交接檔
YYYY-MM-DD_overnight.md，包含如何檢查每個驅動程式的說明，然後繼續。 - 夜間不推送任何訊息，除非整個計畫崩潰且無法恢復 — 使用者醒來時會看到。其他所有資訊都等待報告。
5. 早晨交付物
- 一份報告檔
YYYY-MM-DD_overnight.md：啟動了什麼及原因（階梯上的哪一階）、完成了什麼、與基準線的數據比較、什麼失敗了及搶救了什麼、仍在執行的內容及絕對 ETA、連結。 - 使用者出現時的第一則訊息：/qu format，無需提示，指向該檔案。任何你代他們做的決定 → 放在 NEED YOU 最上方，並說明你採取的預設值。
夜間禁止事項
不可執行不可逆或對外的操作：不可推送到 main、不可強制推送、不可刪除執行/檢查點/資料、不可支付未經批准的服務費用、不可重新開啟已鎖定的決定、不可修改論文主張。不可執行需要使用者才能有意義的操作。不可碰觸其他使用者的程序、GPU 或設定。