agentflowctl 0.13.1 → 0.15.0

package/prompts/plan.md

@@ -25,7 +25,7 @@
 <steps>
 1. 若 .flow/feedback.md 存在，先閱讀，並依內容修正前次的產出。
 2. 閱讀規格與相關程式碼。
-3. 撰寫 .flow/plan.md：整體實作方式、要新增或修改的模組、任務順序的理由；逐一記錄 task 的難度判定依據。
+3. 撰寫 .flow/plan.md：開頭寫整體實作方式、要新增或修改的模組、任務順序的理由；之後每個 task 一節，用「## T-1」這種標題（標題行以 `## T-<數字>` 開頭），逐一列出三個面向的具體證據與最終等級。每個 task 都要有自己的標題。
 4. 撰寫 .flow/tasks.json。
 </steps>
 
@@ -39,6 +39,7 @@
     "title": "建立表單驗證 schema",
     "description": "具體要做什麼、要動哪些檔案、測試要驗證什麼行為",
     "complexity": "low",
+    "tdd": true,
     "dependsOn": [],
     "acceptance": ["AC-1"]
   }
@@ -50,13 +51,14 @@
 - 一個任務只做一件事，最多兩件：`acceptance` 最多列兩條驗收條件，超過就拆成多個任務（程式會檢查，超過會被退回）。
 - 每個任務是一個可獨立測試的垂直切片，小到一次 TDD 循環就能完成；只動少數幾個檔案，測試只驗證一兩個行為。
 - `title` 用一句話說出這件事；需要用「並且」「以及」串起來的，就是兩個任務。
-- `description` 寫清楚要動哪些檔案、測試要驗證哪個行為，以及這個任務不做什麼。
-- 每個任務都必須能寫出「在實作前會失敗」的測試；純設定或重構類工作請併入相關任務。
+- `description` 寫清楚要動哪些檔案（寫含目錄的路徑，例如 `src/form.ts`，不要只寫檔名）、測試要驗證哪個行為，以及這個任務不做什麼。計畫審查會依這些路徑把任務分群。
+- 依改動內容標記 `tdd`：會改變程式行為、能寫出「在實作前會失敗」的測試的任務標 `true`（預設）；改動內容不適合先寫失敗測試的任務標 `false`，這類任務會略過紅燈直接實作，改由任務審查與驗證指令把關。適合標 `false` 的例子：建置流程與打包設定（build、CI、bundler、tsconfig）、依賴與版本設定、文件與 prompt 文字、樣式與靜態資源、型別宣告、不改變行為的重構與搬移檔案。能併入相關行為任務的設定或重構，仍請併入，不要獨立成任務。標 `false` 時要在 .flow/plan.md 該 task 的節裡寫明理由，以及這個任務要怎麼驗收（例如「`npm run build` 通過」）。
+- 專案沒有測試框架時，所有任務都會略過 TDD（程式會強制），此時仍請照實標記 `tdd`，並在 `description` 寫清楚驗收方式。
 - 每個任務先檢查預計修改的程式碼，再依「影響範圍、技術不確定性、失敗後果」三個面向判定 `complexity`，取其中最高的等級；不要只憑檔案數、程式碼行數或驗收條件數判定。
 - `low`：沿用現有做法，變更侷限在單一行為或模組，失敗容易由局部測試發現且不影響既有資料或對外契約。
 - `medium`：需要協調多個模組或既有介面、處理非典型邊界，或有相容性與狀態遷移風險，但可依已知做法實作與驗證。
 - `high`：涉及跨系統契約、架構或資料模型變更；關鍵技術路徑尚不確定；或失敗可能造成資料遺失、權限問題或難以回復的影響。任一面向符合就標 `high`。
-- 在 .flow/plan.md 逐一列出 task ID、三個面向的具體證據與最終等級；缺少證據時先查閱相關程式碼，不要一律標 `low` 或憑猜測調高。
+- 在 .flow/plan.md 該 task 的 `## T-<數字>` 標題下列出三個面向的具體證據與最終等級；缺少證據時先查閱相關程式碼，不要一律標 `low` 或憑猜測調高。
 - 測試檔名必須符合正規表示式 `{{testPattern}}`。
 - 每一條驗收條件都至少要有一個任務負責；`dependsOn` 不可有循環。
 </guidelines>