指令詳解

/opsx:verify 指令詳解

如何使用 /opsx:verify 驗證程式碼實作是否符合規格與設計

指令用途

/opsx:verify 是實作完成後、歸檔 (Archive) 之前的「把關者」。它的作用是嚴格審查你修改的程式碼,驗證其實作細節是否與變更計畫 (Change) 中定義的規格 (Specs)設計方案 (Design) 以及任務清單 (Tasks) 百分之百吻合。

透過靜態掃描程式碼與交叉比對,/opsx:verify 能確保你沒有遺漏任何一項任務,也沒有漏掉任何一個驗收場景 (Scenario),是避免「改 A 壞 B」或「文件與代碼脫節」的關鍵防線。


三大驗證維度

/opsx:verify 會自動產生一份包含以下三個維度的驗證報告:

  1. 完整性 (Completeness)
    • 任務完成度:檢查 tasks.md 中是否還有未勾選 (- [ ]) 的項目。
    • 規格覆蓋度:檢查暫存規格書中所列的每條 Requirement,是否都能在程式碼中找到對應的實作痕跡。
  2. 正確性 (Correctness)
    • 需求映射:評估程式碼實作是否符合規格的字面意圖,找出可能的理解偏差。
    • 場景覆蓋度:檢查規格定義的每個 Scenario 條件是否在代碼中被處理,或是否有對應的測試案例。
  3. 一致性 (Coherence)
    • 設計遵循度:若有 design.md,比對實作是否遵循了當初規劃的技術架構與關鍵決策。
    • 代碼風格:評估新寫的程式碼是否與既有專案的開發模式 (Design Patterns) 一致。

議題分級與影響

報告中的發現會被分為三個等級:

  • 🔴 CRITICAL (關鍵議題):有未完成的任務或未實作的規格。會直接阻擋歸檔流程,必須修正後才能繼續。
  • 🟡 WARNING (警告事項):實作可能與設計有偏離,或缺少測試覆蓋。建議修正,但不會強行中斷。
  • 🔵 SUGGESTION (最佳化建議):代碼風格或重構上的建議,供開發者參考。

實戰對話範例

範例一:驗證成功(可安全歸檔)

  • You:
    /opsx:verify
    
  • AI:

    正在針對變更計畫 add-logout-feature 執行規格驗證:

    🔍 規格驗證報告 (Verification Report)

    1. 完整性 (Completeness): PASS

    • 任務清單:3/3 任務皆已完成。
    • 規格覆蓋:已在 src/components/LogoutButton.astro 找到對應實作。

    2. 正確性 (Correctness): PASS

    • 場景覆蓋:所有登出場景皆已覆蓋。
    • 測試:已在 tests/auth.test.ts 中驗證成功。

    3. 一致性 (Coherence): PASS

    • 設計遵循:已確認 Session 清除機制符合 design.md 設計。

    🎉 驗證成功! 本次實作完美符合規格。您可以安全執行以下指令進行歸檔:

    /opsx:archive
    

範例二:驗證失敗(有關鍵議題阻擋)

  • You:
    /opsx:verify
    
  • AI:

    正在針對變更計畫 add-logout-feature 執行規格驗證:

    🔍 規格驗證報告 (Verification Report)

    🔴 CRITICAL (關鍵議題): 完整性檢查未通過

    • 偵測到 tasks.md 中,任務「3.3 撰寫登出 API 單元測試」仍為未完成狀態 (- [ ])。

    🟡 WARNING (警告事項): 正確性檢查有疑慮

    • src/components/LogoutButton.astro 中,並未發現針對「[AC-SF-03] 登出後自動重導向至登入頁」的對應邏輯。

    驗證失敗! 請先完成上述關鍵任務,或更新任務勾選狀態後,再次執行 /opsx:verify


範例三:實作與設計方案偏離

  • You:
    /opsx:verify
    
  • AI:

    正在針對變更計畫 add-logout-feature 執行規格驗證:

    🔍 規格驗證報告 (Verification Report)

    🟡 WARNING (警告事項): 一致性偏離

    • 設計不吻合design.md 中規劃使用 localStorage 來清除本地 token,但實作程式碼卻是呼叫了後端的 Cookie 清除 API。

    建議處理方式

    1. 修改程式碼以符合原設計。
    2. 若後端 Cookie 方案是更佳的實作,請修改 design.md 以反映真實代碼架構。