前言

規格六份都齊了，狀態寫著「已核准，實作中」。交給開發之前還差一件事：確認這六份文件講的是同一件事。

昨天說到

昨天把資料模型逐條驗過，補上了一支 trigger，讓「送出即唯讀」真的落到資料庫層。

到這裡，規格階段的主要產出都齊了：

specs/
├── spec.md              3 行   系統總覽（空殼）
├── spec_us1.md        120 行   規格與決策
├── data-model.md       83 行   資料模型
├── contracts/api.md   106 行   身分與 API
├── plan.md            136 行   分層與檔案清單
└── tasks.md            91 行   測試

今天是規格階段最後一天，要把這幾份文件 放在一起檢查一次

交付前自檢：檢什麼

前面幾天寫過一支 /spec-check，把「交付前檢查」做成可重複執行的東西。它分五個面向：

前四項問「這份文件自己完整嗎」，B-5 問的則是：「它們彼此對得上嗎」，這次真正抓出來的缺口，幾乎都在第五項。

為什麼不用 Spec Kit 的現成指令

Spec Kit 有兩支做類似的事：

• /speckit-checklist 它可以針對功能產生一份自訂檢查清單，問題是：它給你的是 Checklist，不是完整的跨文件驗證，最後還是得有人拿著清單去對。

• /speckit-analyze 比較接近，它做 spec / plan / tasks 之間有沒有互相矛盾。

但這次我沒有直接用，因為我現在要檢查的不是：Spec Kit 的文件有沒有互相對上，而是我的 Spec、Plan、Tasks、Contract、Data Model，以及 CLAUDE.md，到底有沒有在描述同一套規則？

跑完之後：四項必補

自檢跑完找出了四個需要在進入實作前補上的問題。

1. required_confirmers 的規則沒有真的被保護

昨天才補上的「送出後唯讀」，只保護了 note_versions，卻漏掉 required_confirmers，這代表送出後雖然版本內容不能改，確認人名單卻還可能被刪除或修改。

這次補上資料庫 trigger，讓 required_confirmers 在建立後也不能 UPDATE / DELETE。但 trigger 也帶來另一個問題：原本測試用 DELETE 清資料，現在會被擋住。

因此測試清理方式也一起改成 TRUNCATE ... CASCADE，並補進 tasks.md。

這次讓我再次確認：規則寫在哪裡，跟規則到底能不能被擋住，是兩件事。

2. spec 和 tasks 對 status 的理解不一致

spec_us1.md 寫的是：status 是流程狀態，也是版本唯一可以變動的欄位，但 tasks.md 的測試描述，卻又把「最後一個確認者確認後，狀態變成 effective」列為流程。兩邊單獨看都合理，放在一起卻產生矛盾。

這不是「哪份文件寫錯」而已，而是提醒我：規格不能只逐份檢查，還要放在一起看。

3. Error Code 有寫，行為卻沒有

contracts/api.md 裡已經列了 DRAFT_ALREADY_EXISTS。

看起來很完整，但實際檢查後發現：

• Endpoint 行為沒有描述
• spec_us1.md 沒提到
• tasks.md 也沒有對應測試

也就是說，實作已經走在規格前面了。這種問題最危險的地方，是文件看起來很完整，很容易讓人以為沒有遺漏。

4. EARS Acceptance Criteria 消失了

當初訪談時決定使用：When , the system shall 作為 Acceptance Criteria 的格式，但這次 grep shall，結果是 0 筆，後來才發現，Acceptance Criteria 在拆分過程中被轉成了 tasks.md 裡的測試條件。

這不一定代表現在的做法比較差，測試其實更接近「可執行規格」，但問題是：這個轉換當初沒有被記錄成一個決策。所以這次沒有硬把 EARS 加回去，而是把「為什麼從 EARS 轉成測試導向」記錄下來。

代價也很清楚：少了一層正式的句型檢查，之後就更需要注意 Acceptance Criteria 裡是否出現「適當地」、「順利地」這種無法驗證的描述。

四個問題其實指向同一件事

看完這四個問題，/spec-check它找到的是四種不同的規格漂移：

所以我最後補的，不只是四個問題本身，而是把**「規格為什麼這樣定、由哪一層保證、怎麼驗證」**補完整。

小結

• 規格寫完，不代表規格階段就結束了。真正交付之前，還需要確認：文件之間沒有互相矛盾，規則有對應的保護層，實作沒有偷偷跑在規格前面，而每個重要的變更也都有留下決策。
• 這次自檢讓我發現，「規格完整」和「規格一致」是兩件不同的事。
• 前面的每一份文件都可以看起來很完整，但只要把它們放在一起，還是可能出現缺口。

這也讓我更確定，AI-Native 開發裡，Spec 的價值不只是「告訴 AI 要做什麼」。更重要的是：讓 AI、程式碼、測試，以及下一個接手的人，都有同一份可以對照的規則。

明天開始，規格不再只是文件。要把這些規格真正拆成可以執行的 Work Units。