Day 22 結尾，我留了一句話：

還沒填完時，產生 Project Specification 應該不能按。

今天就補這一條。

ClarifyBuild 是我這系列正在做的小工具：它會把一個模糊的產品 idea，透過幾站釐清流程，整理成 Project Specification，最後再組成 AI Coding Prompt。

Day 22 的 happy path 問的是「能不能往前」：使用者靠畫面操作，能不能從空白 Idea 一路走到 Prompt Preview。

今天這條問的是反過來的事：還沒準備好的時候，能不能擋住，不讓使用者先產生一份看起來很完整的文件。

測試名稱是：

browser specification setup keeps spec generation disabled until every setup section is complete

它守的是 Specification Setup 這一站。

也就是進度列上的 Specify。

這一站有四件事要完成：

• 主要流程：使用者在產品裡會走過哪幾個畫面，測試裡是「搜尋頁」
• 功能規格：每個 Must Have 到底怎麼運作
• 專案限制：硬條件，例如「必須可以部署為靜態網站」
• 技術設定：技術自己指定，還是交給 Coding Agent 選

四個都完成之前，畫面上的 產生 Project Specification 必須保持 disabled。

結果是：npm test 29 條全過。

產品程式沒有改。

今天新增的是：

• 一條 browser negative path
• browser harness 裡一個很小的 helper：disabled()
• 測試檔裡兩個 local helper：載入未完成 setup 的 draft、建立未完成 setup 的 state

為什麼今天不再從空白 Idea 開始

Day 22 已經從空白 Idea 走完一遍。

今天如果再從頭走，測試要先做十幾個操作才到 Specify。

那十幾個操作只要有一個壞掉，今天這條也會跟著紅，可是它要守的是 Specify 那顆按鈕。

Day 22 其實預告過這件事。我當時沒有抽「一口氣走到底」的 helper，理由是：

下一條測試不一定要走完整條路。

今天就是那條。

所以這條測試從一份 draft 起跳：前段需求都有，已經有一個 Must Have，但主要流程、功能規格、專案限制、技術設定四塊都沒做。

做法是拿測試裡既有的完整 MVP state，把這四塊拆掉，形成 incompleteSetupState()。

代價是這個起點由測試手工造，可能跟 Scope 那一站真正產生的 draft 有落差。

Scope 走到 Specify 的接縫，還是由 Day 22 那條 happy path 看著。

這條 negative path 怎麼走

測試載入 draft，進度列亮在 Specify。

接著它一段一段存，每存一段就檢查一次右側的 Setup Status 和產生 Spec 的按鈕：

重點在最右邊那一欄：前四列都是 disabled，要到四塊都完成，最後一列才翻成可以按。

測試最後按下按鈕，確認進度列變成 Spec，文件裡有「搜尋論文」。

這一步只是收尾，要守的是前面那四列。

這條測試用固定順序逐步完成 setup，所以它最直接守住的是：每一步畫面狀態有沒有同步，以及最後一塊完成前按鈕不能先亮。

前面三塊是不是各自不可缺，這條測試看不出來。那是純邏輯的事，比較適合在 unit 層一塊一塊拿掉來驗。

為什麼要在 browser 層守

src/engine/scopeEngine.js 裡的 isSpecificationSetupComplete() 定義了完成條件。

它檢查：

• Must Have 功能至少要有一個
• 主要流程要有步驟，而且不需要重新檢查
• 每個 Must Have 都要有完整且目前有效的功能規格
• 專案限制要 review 過
• 技術設定要完成，而且不需要重新檢查

純邏輯這一層可以用 unit test 守，不過目前直接檢查 isSpecificationSetupComplete() 的斷言只有三個，各個條件還沒有單獨的測試。

但今天要守的是畫面有沒有真的接上這個邏輯。

按鈕用 isSpecificationSetupComplete() 判斷 disabled，Setup Status 四行則是在 render.js 裡各自算出來。

同一件事有兩套判斷，要知道它們有沒有一致，得從畫面看。

今天這條 browser test 守的就是這個 UI contract：

Setup Status 和按鈕 disabled 要一致。

如果右側狀態顯示未完成，按鈕卻已經可以按，使用者會困惑。

如果右側狀態顯示完成，按鈕卻還鎖著，使用者也會困惑。

browser test 很適合守這種接線位置。

這種 negative path，沒有任何壞輸入

Day 20 那條「匯入壞檔案」是我比較熟的 negative path：丟一個壞東西進去，看系統會不會倒。

今天這條每一步輸入都合法，沒有壞檔案，也沒有錯誤格式，只是還沒做完。

要看的是：使用者還沒完成必要動作的時候，產品有沒有擋住他進下一步。

ClarifyBuild 的 Project Specification 要承接前面釐清過的需求，也要承接 Specify 裡四個更具體的區塊。

如果少了主要流程，Spec 會缺少產品怎麼被使用。

如果少了功能規格，Spec 會缺少 Must Have 到底怎麼運作。

如果少了專案限制，Spec 可能漏掉部署、資料、範圍上的硬條件。

如果少了技術設定，後面的 AI Coding Prompt 就少了一個很重要的實作邊界。

所以這個 disabled 是流程的一部分。

它在說：

還沒準備好，先不要產生看起來很完整的文件。

這也是為什麼今天要測它。

今天新增的工具

Day 23 補了一個 browser harness helper：disabled(selector)。

它只做一件事：找到某個 DOM element，回傳它是不是 disabled。

如果找不到，就直接丟出帶 selector 的錯誤。

這跟 Day 22 的 fill()、select() 是同一條線：都是 browser mechanics。

產品情境仍然留在 test/browserFlow.test.js。

這裡也出現了一個小訊號：loadSetupDraft() 和既有的 loadCurrentDraft() 有不少重複。

目前我先讓它留在測試檔裡：只有兩份，而且差異一眼看得出來，只差放進去的是哪一份 draft。

如果 Day 24 也要載入不同階段的 draft，就可以回頭抽一個更小的載入 helper。

測試結果

Day 23 結束時，完整測試是：

npm test
tests 29
pass 29
fail 0

Day 22 是 28 條，今天多了這 1 條。

跟 Day 22 一樣，我的執行環境第一次跑 browser tests 時，會因為 local server 不能 bind 到 127.0.0.1 而失敗。放寬本機執行權限後，同一組測試通過。

Day 24 可以接哪裡

今天的 Setup Status 只出現兩種字：「未完成」和「完成」。

主要流程和技術設定這兩行其實還有第三種：「需要重新檢查」。

使用者很少一路往前走到底。更常見的是走到 Specify，才想到：

我剛剛好像講錯了，回去改一下。

前段需求或範圍改了，已經存好的流程、功能規格和技術設定就該重新確認，按鈕也不該繼續亮著。

一個整理需求的工具，最怕的就是前面改了，後面還假裝沒事。

今天守住「缺資料不能往前」，Day 24 很適合接「資料變了要重新確認」。

Day 23 完成。

明天見。