版本重點
OpenSpec v1.12.0 沒有重寫既有的 Change lifecycle，而是把兩個日常痛點補完整：驗證結果太吵，以及 agent 在 repo 已經有答案時仍反問使用者。
這兩個改動對教學很重要，因為它們分別代表兩個可泛用到其他 AI coding agent 的原則：
- 輸出格式（reporting）與成功/失敗語意（semantics）應分離。
- 規劃應先以 repository evidence 為基礎，再向人詢問真正需要決策的事項。
Findings-only validation report
v1.12.0 新增：
openspec validate --all --report findings--report findings 只顯示 error、warning 與 informational findings，但仍保留完整 run totals 與原本 exit code。因此它很適合 CI：人看到的 log 更短，automation 的判定契約卻不變。
何時使用
- Pull Request CI 只想列出要處理的問題。
- 大量 changes / specs 做 bulk validation。
- 想把 validation report 貼到 review comment，但不想貼整份成功明細。
不要誤解
--report findings 不是「忽略成功項目」的驗證模式；它只是改變報告長相。真正是否通過仍由原本 validation semantics 與 exit code 決定。
Code-grounded planning
v1.12.0 的 Propose 與 fast-forward workflow 會在起草 artifacts 前先看相關：
- source code
- tests
- documentation
- 既有 OpenSpec artifacts
例如你說「新增 retry 次數設定」，repo 內已經有 RetryOptions 與對應測試時，agent 應先讀它們，再決定 proposal / design / tasks 要怎麼寫，而不是先問你「目前 retry 設定放哪裡？」。
Explore 也先查 repo 再問
Explore mode 會優先找 repository 中已存在的事實，再提出 dependency-aware questions。問題應集中在：
- 產品取捨
- 不在 repo 裡的外部限制
- 多個可行方案之間需要人決定的方向
而不是把「檔案在哪、現有 class 叫什麼、測試框架是哪個」這些可自行查證的問題丟回使用者。
初始化與可靠性
v1.12.0 也修補：
- 空 OpenSpec 目錄仍可被 Git 追蹤。
- 重跑 init 可安全恢復缺失 marker。
- init / update 使用一致的 IDE restart guidance。
- npm Git install 不再要求使用者本機必須先有 pnpm。
- merge conflict 以 informational finding 呈現，不改變原 exit code。
- filesystem read error 與 missing spec 不再混為同一種錯誤。
實務建議
把 v1.12.0 的工作方式套到自己的 agent prompt 時，可以濃縮成一句：
先讀 code、tests、docs 與現有規格；只詢問 repository 無法回答、且確實需要人做決策的問題。
這比「少問問題」更精確：不是少問，而是只問高價值問題。