指令用途

$ultragoal 是 OMX 的持久完成（persistent completion）工作流。v0.21.x 不應把它理解成「收到一句模糊需求後自己包辦訪談、規劃、執行」；canonical staged flow 是：

$deep-interview → $ralplan → $ultragoal

• $deep-interview：收斂真正需要人決定的需求分歧。
• $ralplan：Planner → Architect → Critic 交換 evidence，形成 advisory plan。
• $ultragoal：承接已收斂的目標與驗收條件，持續執行、驗證、修復直到完成。

omx autopilot 在 v0.21.0 成為 canonical orchestrator，會使用這條 staged chain。$team 只在任務確實可平行時加入，不是必經階段。

運作流程

1. 接收已收斂目標：目標應已經過 $deep-interview 與 $ralplan，具備清楚 scope 與 acceptance criteria。
2. 建立執行狀態：把執行所需的 mission / state 寫入 .omx/ runtime state。
3. 持久執行：依計畫修改程式碼並跑 build / test / acceptance checks。
4. 失敗修復：遇到可修正失敗時，以 evidence 驅動下一輪修補，而不是把一次失敗當任務終點。
5. 完成 gate：只有驗收條件真的成立才結束；advisory review 本身不等於 execution success。

實戰使用方式

先完成需求訪談：

$deep-interview 為 BillingService 補齊單元測試；覆蓋率至少 85%，不得改 public API。

再交給 $ralplan 形成可審查計畫：

$ralplan 依訪談結果規劃 BillingService 測試補強，列出 coverage、mock 邊界與驗收證據。

確認計畫後才進入持久完成：

$ultragoal 依已核准計畫完成 BillingService 測試補強，直到 build、test 與 coverage gate 全部通過。

v0.21.4 的模型預設

若沒有任何 explicit model choice，v0.21.4 會讓多數 agent tiers 預設使用 gpt-6-astra。既有 profile、per-agent override、CLI / environment 設定與 provider-specific model name 仍優先，不會被 $ultragoal 強制換模型。

關鍵學習點

$ultragoal 的價值是持久完成，不是跳過規劃。把需求澄清、advisory planning、execution authority 分成三層，可以讓 agent autonomy 更高，同時降低「規劃建議被誤當成執行授權」的風險。