夜間建置提示
完整範本位於 references/overnight-build-template.md。在撰寫前請先閱讀。 不要憑記憶重新推導規則結構 — 請填入使用者提供的 [方括號] 區段內容，並保留他們對自己副本所做的任何編輯。
不可妥協
每個輸出都必須包含 Rule 8 (survive usage resets) 和 LAUNCHER 區段。這是讓建置可重新啟動的關鍵；缺少這些的提示會在第一次使用次數重置後默默地從頭開始，白白浪費一個夜晚。
撰寫步驟
- 閱讀範本。 如果使用者保留了一份編輯過的副本，使用者的版本優先 — 保留他們的變更。
- 填寫規格 — 要建置的內容、背景、設計需求、技術需求、依優先順序排列的功能、種子資料、部署方式、成功標準。此處的明確性是成敗關鍵；模糊的規格會導致模糊的夜晚。
- 設定階段 — 4 到 8 個階段，每個階段必須能獨立完成且可驗證，時間分配總和應符合預算。
- 填寫應變手冊，在範本既有的應變措施之上，加入專案特定的阻礙因素。
- 詢問一次使用者想要哪種啟動器（A：作業系統排程器 · B：bash 迴圈 · C：排程任務 MCP），如果請求中沒有明確說明的話。只詢問一次 — 然後繼續處理。
- 輸出為一個可複製的程式碼區塊，並提醒使用者在啟動前將其儲存為專案根目錄下的
overnight-build-prompt.txt。
完成信號
提示必須指示建置流程在最後一行輸出 BUILD_COMPLETE — bash 迴圈啟動器會擷取這個字串來結束執行。在提示中清楚說明，當任何 P0 標準確實未達成時，不發出 BUILD_COMPLETE 是正確的行為。一個在未完成的建置上就退出的啟動器，比一個持續執行的啟動器更糟。
護欄
無人監控的代理程式沒有人可以向其提問，因此提示必須自帶邊界。
如果目標是現有的生產環境程式碼庫，請先推導檔案所有權和禁止觸碰清單（fleet-brief 技能可以產出這兩者），並將專案的驗證檢查帶入測試階段，這樣「完成」指的是驗證通過，而不只是合併。
絕對不要讓夜間提示授權執行資料庫遷移、推送架構、透過部署 CLI 進行部署、購買或發佈電話號碼或網域，或向真實聯絡人發送外寄訊息。這些操作需要人類在清醒狀態下執行。請將專案自身的不可逆操作也加入該清單。
建置必須寫入的交付物
BUILD_LOG.md— 階段記錄、決策、應變措施、已知問題，以及包含確切下一步的## CHECKPOINT — <ISO>區塊RESEARCH_NOTES.md— 實作開始前的研究發現
恢復執行時，建置流程的第一個實際動作是從頭到尾讀取 BUILD_LOG.md，並從最新的檢查點繼續 — 絕不重新研究、重新建立底層結構或重新開始。