spec-checklisted

# spec-check：spec 完整性稽核＋多面向 premortem 指揮官編排、agents 實查、裁決留人。產出＝修改計畫（落檔），**不直接改 spec**。 交辦範本→本檔附錄 A；修改計畫格式→附錄 B。 ## 硬性約束（違反即流程失敗） - 指揮官不下場逐行實查；agents 只讀不寫。 - **已定決策不重審**：context-pack 列明「已定」的項目，agents 不得提案推翻；除非附新事實證據，單獨標「重啟裁決請求」列出，不混入一般 findings。 - **每條建議必答「不修，會發生什麼具體失敗」**——答不出的降 🟢 或刪。（實測 baseline：11 條建議全是加項、零砍項；premortem 視角天生偏向加東西，這條是唯一反制。） - 修改計畫排最前的是 🔴 需用戶裁決項；用戶核准前不執行任何 spec 修改。 ## 流程 ### 1. 素材盤點 → context-pack 落檔 讀 spec 本體；盤點：對話中已拍板的決策、**spec 裡有寫但尚未經用戶核准的段落**、待定項、用戶提供的資料路徑、相關的既有決策紀錄（若有）。 落檔 spec 同目錄 `YYYY-MM-DD-<spec名>-稽核上下文.md`（`<spec名>`＝spec 檔名主幹；主幹已含日期則不重複加）： - 已定決策（各附出處：對話日期／紀錄檔名） - 待定項與未核准段落（實測 baseline 漏抓這類，因為只存在對話層） - 素材清單＋路徑（agents 據此讀，不各自盲搜——實測單 agent 自行重讀全部素材 ~107K tokens，共用預消化是主要省錢點） - 本輪檢查範圍邊界 - 檔頭標註：「快照，攝於 <日期>；決策長期真值源＝spec 決策點節，修改計畫執行時應吸收本檔內容後封存」 ### 2. 單一確認點（一則訊息給齊，只等用戶一次） - 素材清單：「有沒有我漏掉的資料？」 - **現況圖說**（ASCII）：選型判準＝**哪種圖最能證明你讀懂全文、且呈現 spec 現況**——系統類常是架構圖、流程類是流程圖、內容類是關係圖、其他用章節結構樹＋每節一句話；spec 本身已有架構圖時**不要原樣照抄**（無鑑別力），畫它沒有的視角。目的：用戶 10 秒驗證指揮官有沒有讀錯 spec，讀錯就會派錯工。 - 面向選單：從【技術可行性／使用情境／前端／後端／資料與整合／維運／成本時程】依 spec 性質勾 1〜3 個，**外加必選「過度工程（砍項）」面向**（專找該刪的，不找該加的）。 - 用戶可說「直接跑」跳過等待，事後在修改計畫裡糾正。 ### 3. 並行派工（建議模型路由，依你的環境調整） | 角色 | 數�� | 模型 | 基底 | |---|---|---|---| | 完整性審查 | 1 | opus | 附錄 A-1：內部矛盾／模糊句／驗收判準盲區／素材對照（context-pack 有、spec 沒吸收的） | | premortem 各面向 | 1〜3 | sonnet | 附錄 A-2：「假設照這份 spec 做完後專案失敗了，從你的面向解釋為什麼」 | | 過度工程（砍項） | 1 | sonnet | 附錄 A-2 反向：「哪些內容第一版不需要？刪掉會怎樣？」 | 每個 prompt 必含：context-pack 路徑（必讀）＋「每條 finding 引 spec 章節與行號；禁通用最佳實踐建議；最多 5 條，依嚴重度排序」＋回報格式與行數上限。 規模判斷：sp