Day 23 我補了一條 browser negative path：

Specification Setup 還沒填完時，不能產生 Project Specification。

今天接著補另一種更容易被忽略的狀態：

已經填完了，但前面的需求變了，也不能假裝還是完成。

這件事聽起來很小，可是對 ClarifyBuild 這種工具很重要。

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

如果 Project Specification 要被拿去交給 Coding Agent，那它不能只是「曾經正確」。

它要對目前的需求正確。

Day 23 守的是：

缺資料不能往前。

Day 24 守的是：

資料變了，要重新確認。

今天新增一條 browser regression。也就是把已經對的行為釘住，之後改壞就會紅的測試：

browser requirement edits mark setup data for review and disable spec generation

結果是：npm test 30 條全過。

產品程式沒有改。

今天新增的是一條 browser test，確認既有產品行為真的從畫面接起來。

填完之後，需求變了

Day 23 的測試從一份四個區塊都沒做的 draft 開始，一塊一塊存。

前三塊存完，按鈕都還是 disabled，要到第四塊存完才解鎖。

這守住的是「缺資料不能往前」。

但真實使用者不一定是線性往前走。

很常見的情況是：他已經到了 Specify，甚至四塊 setup 都填完了，才發現前面某個需求講錯。

例如原本的主要使用者是「研究生」，後來發現其實應該是「研究生與助教」。

這時候原本的主要流程、功能規格、技術設定可能還可以用，也可能不可以。

ClarifyBuild 不應該直接把這些資料丟掉，因為使用者已經填過了。

但它也不應該繼續說「全部完成，可以產生 Project Specification」。

比較合理的狀態是：

我保留你填過的東西，但請你重新檢查。

ClarifyBuild 在 Scope 頁面那塊 修改前面的需求 裡，自己就是這樣寫的：「如果這裡的內容改變，既有主要流程、功能規格或技術設定會保留，但可能需要重新檢查。」

所以今天要測的是這個中間狀態。

不是未完成。

也不是完成。

而是：需要重新檢查。

今天走的路

Day 23 最後一節我留的方向是：

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

這句話其實有兩條路可以測：

• 改前段需求
• 改 scope 或 feature

兩條都接得上 Day 23 那句話，我挑前段需求，是因為它的路比較短。

改範圍那條會多繞一站：把唯一的 Must Have 改名再確認範圍，畫面先跳出一題 Feature-level 的問題，答完再確認一次，才會回到 Specify。

那條路留給之後。

改前段需求就單純很多。Scope 頁面本來就有一塊 修改前面的需求，只有一個儲存鈕，所以測試不用繞路，也不用直接改 state。

它可以走真正的畫面操作：

1. 從已完成 Specification Setup 的 draft 起跳
2. 確認 產生 Project Specification 一開始是可用的
3. 點 返回調整範圍
4. 展開 修改前面的需求
5. 把主要使用者改成 研究生與助教
6. 儲存前段需求
7. 再次確認範圍，回到 Specify
8. 檢查 setup 狀態與按鈕

這條路徑很短。

也很像實際使用的情況。

畫面變了什麼

這次測試的起點是一份已經完成 Specification Setup 的 draft。

Day 23 說過，如果 Day 24 還要載入不同階段的 draft，就可以回頭抽載入 helper。今天直接用既有的 loadCurrentDraft()，沒有多出第三份，所以還不用抽。

一開始，畫面在 Specify，產生 Project Specification 可以按，Setup Status 也全部是完成狀態。

測試把主要使用者從 研究生 改成 研究生與助教。

儲存後，畫面出現 toast：

前段需求已更新，相關規格需要重新檢查。

接著測試重新確認範圍，回到 Specify。

這時候前後對照變成：

這裡有幾個細節。

第一，主要流程沒有被清空，而是顯示 需要重新檢查。

使用者前面填過的流程還在，只是它可能不再完全符合新的主要使用者。

第二，右側 Setup Status 的功能規格變成 0 / 1。

這個數字數的是「目前有效的功能規格」。那份規格還在，只是已經標成需要重新檢查，所以不算進去。

功能規格區塊本身也會顯示 功能規格：搜尋目前論文 需要重新檢查。

第三，技術設定也變成 需要重新檢查。

這一行我要講清楚。現在的程式很保守：主要使用者、問題、目標、平台這四項，只要有一項改了，主要流程、有規格的功能和技術設定就會一起標成需要重新檢查。它不會去判斷「主要使用者改了，技術選擇還適不適合」。

我回頭翻了 Day 11 那份 Schema 的失效規則表：Target User 改了，Tech Stack 寫的是「不影響」，只有 Platform 和 Project Constraints 的內容會動到它。

所以在這一格，程式比規格表更保守，今天這條測試鎖住的是程式現在的行為。

反過來，有兩格程式沒有照規格標：專案限制的內容改了，規格說技術設定要重新檢查；使用情境改了，規格說主要流程要重新檢查。

要不要對齊規格，我先記著，不在今天決定。

第四，專案限制仍然是 完成。

這是我很喜歡的一個小地方。

今天改的是主要使用者，不是 platform，而現有的程式裡，只有 platform 變更會讓專案限制回到未完成。

所以這條測試沒有期待「全部重置」，它期待專案限制原地不動。

這比全部清空更像一個能用的工具。

為什麼放在 browser 層

底層邏輯其實已經存在。

src/engine/scopeEngine.js 裡有：

• markRequirementChangeNeedsReview()
• markScopeRelatedDataNeedsReview()
• isSpecificationSetupComplete()

這些函式負責把相關資料標成需要 review，並且讓 setup 不再被視為完成。

但今天要守的是使用者看得到的整條接線：

• Scope 頁面能修改前段需求
• 儲存後會標記相關 setup data
• 再回到 Specify 時，Setup Status 會顯示正確狀態
• 產生 Project Specification 會重新鎖住

這些東西分散在不同地方：

• action 寫在 main.js
• 完成條件在 scopeEngine.js
• Setup Status 顯示在 render.js
• 測試操作透過 browser harness 跑真 DOM

還有一個很實際的理由：saveRequirementEdits() 在 main.js 裡，今天之前沒有任何測試點過 儲存前段需求。

所以我用 browser test 確認畫面上這條路徑成立；條件一個一個驗，留給 unit test。

這種測試很小。

但它守的是產品信任感。

如果使用者看到 完成，他會相信這份資料是目前可用的。

如果資料已經過期，畫面就要誠實地說：

需要重新檢查

這比直接清空溫柔。

也比假裝沒事可靠。

測試結果

今天只新增一條 browser test 和狀態紀錄。

完整測試結果是：

npm test
tests 30
pass 30
fail 0

Day 23 是 29 條，今天多了這 1 條。

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

Day 25 可以接哪裡

Day 23 和 Day 24 都在 browser 層守 UI contract。

一條守「沒完成不能產生」，一條守「資料變了不能直接產生」。

不過今天這條有一件事看不出來：按鈕到底是被哪一個條件鎖住的。

回頭看，主要流程、功能規格、技術設定三個地方是同時被標成需要重新檢查的。按鈕鎖住了，我只知道至少有一個在鎖，不知道是哪一個。

這種事要一個條件一個條件驗，比較適合 unit test。

isSpecificationSetupComplete() 就是決定 產生 Project Specification 能不能按的判斷。

Day 25 我想給它補 focused unit coverage：每個條件單獨壞一次，看它自己能不能讓整個判斷不通過。

Day 24 完成。

明天見。