Day 28 我把 needs-review 的規則對齊 Day 11 的 Schema。
那天的重點是：
不是每個 needs review 都代表同一種過期。
Target User、Problem、Goal 改了，會讓主要流程和功能規格需要重新檢查。
Platform 改了，除了主要流程和功能規格之外，也會讓專案限制和技術設定需要重看。
Usage Scenario 改了，只影響主要流程。
Project Constraints 內容改了，只影響技術設定。
前三條在 engine 層有測試。
Project Constraints 那條寫在 saveConstraints() 裡，Day 28 是用 browser test 守的。
但 Day 28 結尾我留了兩條 browser 層還沒守住的路徑。
今天先補其中一條：
Usage Scenario 編輯後，只讓主要流程需要重新檢查。
ClarifyBuild 是我這系列正在做的小工具：它會把一個模糊的產品 idea，透過幾站釐清流程，整理成 Project Specification，最後再組成 AI Coding Prompt。
今天沒有改產品程式碼。
只新增一條 browser regression。
npm test 從 37 條變成 38 條，全過。
Day 28 已經有一條 engine test：
usage scenario changes mark only target project user flow for review
它直接呼叫的是規則本身。
也就是把 usageScenario 這個變更原因直接傳進 markRequirementChangeNeedsReview()，確認結果是：
Target Project User Flow -> needsReview
Feature Specification -> 不影響
Project Constraints -> 不影響
Tech Stack -> 不影響
Target Project User Flow 就是畫面上的「主要流程」。
這條測試很重要。
因為它鎖住的是產品規則。
但使用者不會直接呼叫 engine function。
使用者真正會做的是：
這一路中間會經過 UI 表單、事件 handler、資料更新、Scope confirmation、Setup Status render，以及 產生 Project Specification button 的 disabled 判斷。
engine test 只能證明規則函式本身是對的。
它不能證明 saveRequirementEdits() 真的把「使用情境改了」辨識成 usageScenario。
也不能證明 Setup Status 最後呈現的是正確的那四行。
所以 Day 29 補的是接線測試。
不是因為產品邏輯不夠多。
而是因為 Day 28 的產品邏輯已經夠明確，現在要確認它真的走得到使用者會走的那條路。
Day 29 開始前有兩個小方向。
第一條是 Usage Scenario：
從已完成 setup 的 draft 出發，回 Scope，修改 Usage Scenario，再回 Specify，確認只有主要流程需要重新檢查。
第二條是 Project Constraints：
在 Specify 重新按「確認專案限制」，內容不變，確認技術設定仍完成，
產生 Project Specification不會被鎖住。
兩條都小。
但我今天先選第一條。
原因是兩條缺的程度不一樣。
專案限制那條，Day 28 已經有一條 browser test 守「內容改了，會標技術設定」，缺的只是「內容沒改，不該標」那一半。
Usage Scenario 這條，連「改了，會標主要流程」這一半都沒有 browser test。
它不是只在 engine 裡多一個 case。
還牽涉到這段：
const nextUsageScenario = values.usageScenario.trim();
const currentUsageScenario = state.draft.requirements.usageScenario.value ?? "";
if (currentUsageScenario !== nextUsageScenario) {
changedDimensions.push("usageScenario");
}
也就是說，browser test 要守的是：
使用者在「修改前面的需求」表單裡改了使用情境，程式真的會把它視為 Usage Scenario changed。
如果這條接線壞掉，engine 規則再正確也不會被用到。
所以 Day 29 先補它。
Project Constraints 內容不變的那條，我留給 Day 30。
剛好鐵人賽只有 30 天。
最後一天可以用它收束 Day 28 結尾列出的 browser 測試缺口。
今天新增的測試叫：
browser usage scenario edits only mark target project user flow for review
它不是從空白 idea 開始跑完整流程。
而是沿用既有的 loadCurrentDraft() helper，直接載入一個已完成 setup 的 draft。
一開始先確認 Setup Status 的四項（主要流程、功能規格、專案限制、技術設定）都是完成，產生 Project Specification 可以按。
這個前置確認很重要。
因為今天要測的不是「還沒完成 setup 時不能產生 Project Specification」。
今天要測的是：
原本已經完成的 setup，因為 Usage Scenario 改了，所以只讓主要流程從完成變成需要重新檢查。
如果一開始不是完成狀態，後面就很難判斷到底是誰讓按鈕 disabled。
測試接著按 返回調整範圍 進入 Scope，展開 修改前面的需求，只改 Usage Scenario：
研究生在期末整理引用資料時打開產品。
這個欄位在 fixture 裡本來是空的，它是選填，所以這條實際上是從空白補填。
改掉既有內容，或把它清空，走的是同一個比較（currentUsageScenario !== nextUsageScenario）。
我今天沒有各寫一條。
其他 Target User、Problem、Goal、Platform 都不動。
按下儲存後，畫面會出現既有提示：
前段需求已更新，相關規格需要重新檢查。
這句提示對 Usage Scenario 來說說得太重。
它寫「相關規格需要重新檢查」，但下面的斷言是功能規格仍然完成。
文案我今天沒有動。
真正要確認的是回到 Specify 之後，Setup Status 怎麼變。
所以測試再按一次 確認範圍並繼續，回到 Specify。
對照起來是：
| 項目 | 改之前 | 改之後 |
|---|---|---|
| 主要流程 | 完成 | 需要重新檢查 |
| 功能規格 | 1 / 1 | 1 / 1 |
| 專案限制 | 完成 | 完成 |
| 技術設定 | 完成 | 完成 |
產生 Project Specification |
可以按 | 被鎖住 |
按鈕被鎖住。
但是被鎖住的原因不是功能規格，也不是專案限制，更不是技術設定。
原因只有一個：
主要流程需要重新檢查。
測試也確認功能規格卡片仍然顯示完成：
功能規格：搜尋目前論文 完成
這一行是今天最重要的斷言之一。
因為 Usage Scenario 改了，產品最常被打開的情境可能會影響使用者怎麼走主要流程。
但它不應該直接宣告既有功能規格失效。
這條測試看起來很小。
甚至今天沒有改任何 production code。
但我覺得它是 ClarifyBuild 這種工具很需要的測試。
因為 ClarifyBuild 做的不是單純表單。
它中間有很多「狀態還在，但暫時不能算完成」的情況。
例如：
資料保留
但 needsReview = true
所以不能產生 Project Specification
這種狀態如果只看資料有沒有存在，很容易誤判。
主要流程還在。
功能規格還在。
技術設定也還在。
但其中某些資料已經不該被直接送給 Coding Agent。
Day 27 到 Day 29 其實一直在處理同一件事：
不要因為資料還存在，就假裝它仍然有效。
Day 27 是 Setup Status 不可以把結構合法但內容不完整的 draft 說成完成。
Day 28 是 needs-review 不可以把所有過期原因混在一起。
Day 29 則是確認這條細分後的規則，真的有走過 UI。
今天只新增一條 browser test。
所以測試數量從 Day 28 的 37 條變成 38 條。
完整結果是：
npm test
tests 38
pass 38
fail 0
跟前幾天一樣，我的執行環境第一次跑完整測試時，browser tests 因為 local server 不能 bind 到 127.0.0.1 失敗。
放寬本機執行權限後，同一個 npm test 通過。
今天動的程式檔只有 test/browserFlow.test.js。
production source code 沒有變。
鐵人賽只有 30 天。
所以 Day 30 我不想再開一個大功能。
比較好的收束方式是補 Day 28 留下的另一條 browser regression：
Project Constraints 按了確認，但內容沒有變，Tech Stack 不能被標成 needsReview。
也就是確認：
專案限制：完成
技術設定：完成
產生 Project Specification 仍然可以按
這條剛好把 Day 28 的另一個產品判斷補完：
Project Constraints 內容改變才會讓 Tech Stack 需要重新檢查。
不是按一次確認就讓它過期。
還有一件 Day 28 留下的事：Setup Status 斷言的 helper。
我當時說「現在還可以忍」。
今天這條又加了兩組 Setup Status 斷言。
Day 30 補完最後一條，再決定要不要抽。
還有一條沒有測試：沒改內容就按 儲存前段需求，不該標記任何東西。
那條我不排進 30 天內。
Day 30 如果只做 Project Constraints 這一條，再寫一篇收束文，其實就很剛好。
三十天後，ClarifyBuild 不會是一個很大的產品。
但它至少有一個越來越清楚的邊界：
它不只幫你產出規格，也會在規格不該被產出的時候停下來。
Day 29 完成。
明天是最後一天。
再見。
iThome鐵人賽
看影片追技術