/opsx:update 指令詳解

指令用途

/opsx:update 是一個 實驗性 (Experimental) 指令。它的主要用途是在實作中途「調整需求或設計」時，用來同步修改所有已生成的規劃產物，確保文件之間的一致性 (Coherence)。

在真實開發中，我們經常在寫程式碼（apply）時才發現原先的設計行不通。這時，我們不能只改程式碼而不改文件，否則會導致規格與代碼脫節。/opsx:update 就是為了解決這個問題——它只修改規格、提案或設計文件，絕對不會觸碰你的實體程式碼。

運作與一致性機制

當你對計畫發起 /opsx:update 時，AI 助手會遵循以下核心機制：

1. 雙向一致性校正：如果你要求修改後期的設計（design.md），AI 不僅會修改設計，還會自動回頭檢查早期的提案（proposal.md）與規格書（specs/），以及後期的任務清單（tasks.md），將所有矛盾的文字一併修正。
2. 僅修改既有檔案 (Existing Files Only)：此指令只會修改已經存在於磁碟上的文件，不會越界建立新的規劃產物（這是 /opsx:continue 的工作）。
3. 確認後寫入 (Confirm Before Write)：AI 在修改任何文件前，都會先展示修改方案（Diff 差異）並說明理由，在獲得你的確認後才進行寫入。
4. 「更新 vs. 另起爐灶」啟發式判斷 (Update vs. Start Fresh)：如果你的修改要求已經大幅偏離了該計畫的初衷（例如在「登出功能」計畫中要求順便實作「商品評論」），AI 會主動提示你這不是 update，建議你使用 /opsx:new 另開一個獨立的變更計畫 (Change)。

實戰對話範例

範例一：因技術調整修改設計方案

• You:

  /opsx:update "我們不打算用 Redis 快取了，改用記憶體內的 Map 快取即可。"
  

• AI:

  偵測到進行中的計畫：cache-orders-api。 為了將快取改為 記憶體 Map，我建議進行以下一致性修改：

  1. 修改 design.md：將 Redis 連線與設定章節改為簡單的記憶體 LRU Map 實作說明。
  2. 修改 tasks.md：將任務「安裝 Redis 套件」與「配置 Redis 連線」刪除，改為「引入 LRU-Cache 函式庫」。

  請問是否同意並寫入這些修改？ (Y/N)

範例二：無明確修改指令時的自我檢查

• You:

  /opsx:update
  

• AI:

  正在為您讀取變更計畫 cache-orders-api 的所有現有文件，並執行一致性審查：

  • proposal.md 中提到預計修改 2 個 API。
  • design.md 中詳細規劃了此 2 個 API 的快取邏輯。
  • tasks.md 中列出了對應的實作與測試任務。

  審查結果：目前所有規劃文件邏輯一致，無矛盾或缺漏，無須進行修改。 您可以直接執行 /opsx:apply 繼續實作程式碼。

範例三：意圖偏差過大（引導新建計畫）

• You:

  /opsx:update "順便幫我把購物車頁面的結帳按鈕改成紅色"
  

• AI:

  ⚠️ 建議另起爐灶： 您目前正處於 add-logout-feature (登出功能) 變更計畫中。修改「購物車頁面的結帳按鈕樣式」與登出邏輯並無關聯。

  為了保持規格與 Git 提交歷史的乾淨，我不建議在當前計畫中進行此修改。

  建議您：

  1. 先完成或暫停當前的登出任務。
  2. 另開一個新計畫來處理 UI 修改：

     /opsx:new "redesign-checkout-button-color"