為什麼中間需要 Ralplan？

只做需求訪談就直接自動執行，會把「理解需求」與「驗證計畫」混成同一步。v0.21.x 把 canonical chain 明確化為：

$deep-interview → $ralplan → $ultragoal

$ralplan 的 Planner → Architect → Critic evidence 是 advisory；它不會因 review 通過就自動取得 execution authority。

步驟 1：Deep Interview 收斂需求

$deep-interview 將 WCF 通訊模組升級成 Web API；先確認同步/非同步、認證、相容範圍。

目標是把真正需要人決策的分歧收斂，不開始實作。

步驟 2：Ralplan 產生與挑戰計畫

把已收斂的需求交給 $ralplan。Planner 起草、Architect 檢查架構約束、Critic 挑出證據不足或驗收不明確的部分。

重要：這一輪只產生 planning evidence，不等於授權修改 code。

步驟 3：確認 execution boundary

在進入 $ultragoal 前，確認 scope、驗收條件與任何需要人工批准的風險點。這是 advisory → execution 的權限邊界。

步驟 4：Ultragoal 持久執行

$ultragoal 依已核准的 WCF → Web API 計畫完成遷移，直到 build/test/acceptance 全部通過。

OMX 會把執行狀態保存在 .omx/，失敗時依 evidence 修復並繼續。

步驟 5：只有真的可平行時才用 Team

$team 是條件式 parallel execution，不是 canonical chain 的必經站。只有前後端、獨立 modules 等工作彼此低耦合時才值得開多 worker。

v0.21.4 的模型注意事項

若沒有 explicit model choice，部分 agent tiers 預設改成 gpt-6-astra；已設定的 profile、per-agent model、CLI / env override 仍優先，不會被 default 覆蓋。