Day 27 我處理的是 Setup Status 和真正完成條件不一致的問題。
那篇結尾我留了一個差異：needs-review 規則和 Schema〈十四、失效與 Needs Review 規則〉不完全一致。
要不要改，是另一個產品決策，我留給 Day 28 或之後。
今天就是那個決策。
問題是：
前面的需求改了，哪些已經填過的資料需要重新檢查？
Day 24 的時候，我補了一條 browser test，確認「需求改了，填過的東西我留著，但不再算完成」。
那天測的是 Target User 從 研究生 改成 研究生與助教。
當時的程式很保守。只要 Target User、Problem、Goal、Platform 其中一個改了，就會把三種東西標成需要重新檢查：
這個行為很安全。
但 Day 24 我留了一句：
要不要對齊規格，我先記著，不在今天決定。
ClarifyBuild 是我這系列正在做的小工具：它會把一個模糊的產品 idea，透過幾站釐清流程，整理成 Project Specification，最後再組成 AI Coding Prompt。
今天改了 scopeEngine.js、main.js、render.js，更新 browser 和 engine 測試。
npm test 從 33 條變成 37 條，全過。
Day 24 是從 Day 23 結尾那句話出發的：
前段需求或範圍改了，已經存好的流程、功能規格和技術設定就該重新確認，按鈕也不該繼續亮著。
流程和功能規格這兩項，方向沒有錯。
如果使用者把主要使用者從「研究生」改成「研究生與助教」，那原本的主要流程和功能規格很可能需要重新看過。
例如原本的流程只考慮研究生自己整理論文。
加入助教之後，可能會多出：
回頭看，Day 24 真正要守的是：
產品語意變了，舊規格不能直接送給 Coding Agent。
這一點今天沒有改。
今天要改的是另一件事：
技術設定是不是也應該跟著 Target User、Problem、Goal 一起過期？
Day 24 的測試鎖住的是程式當時的行為：會。
但這其實是程式實作比較粗的結果，不是 Schema 的規則。
Day 11 的 Project_Spec_Schema_v0.1.md 第十四節有一張失效規則表。
Target Project User Flow 就是畫面上的「主要流程」。
表裡對 Target User、Problem、Goal 的規則是：
Feature Specification 所有已存在的 Spec -> Needs Review
Target Project User Flow Needs Review
Project Constraints 不影響
Tech Stack 不影響
Platform 則不同：
Feature Specification 所有已存在的 Spec -> Needs Review
Target Project User Flow Needs Review
Project Constraints reviewed = false
Tech Stack needsReview = true
差別在這裡。
Target User、Problem、Goal 改了，改的是產品要服務誰、解決什麼、達成什麼。
這些會影響「功能怎麼運作」和「使用者怎麼走流程」。
但不一定會影響技術選型。
反過來，Platform 改了就很明確。
如果原本是 Web，後來改成 Mobile，技術設定當然需要重看。
不管使用者原本是指定 React + Vite，還是授權 Coding Agent 選技術，Platform 都是技術選擇的邊界。
Project Constraints 也是一樣。
如果限制從：
必須可以部署為靜態網站
改成：
不得使用付費 API
那技術設定也需要重新確認。
因為 Tech Stack 的 ai_delegated 不是「我沒填，所以 AI 隨便猜」。
它的意思是：
使用者明確授權 Coding Agent，在 Platform、Project Constraints 與 AI Decision Boundary 內選擇最適合、最簡單的技術。
授權範圍裡的 Platform 或 Project Constraints 改了，授權本身就要重新 review。
所以 Day 28 選擇對齊 Schema。
也就是：
Target User / Problem / Goal 變更，不再讓 Tech Stack needsReview。
Platform 或 Project Constraints 的內容改變，Tech Stack 才需要 review。
但這不是放鬆所有規則。
今天拆開的是「過期的原因」。
產品語意過期：
建置邊界過期：
Platform 兩邊都算。
它改了，流程和功能規格也要重看。
代價也要說清楚。
主要使用者改了、而且真的牽動技術選擇時，ClarifyBuild 不會再替使用者標出來。
v0.1 不判斷語意，Target User 對 Tech Stack 這一格，我跟著規則表走。
這樣拆之後，畫面比較誠實。
如果使用者只是把 Target User 改得更精確，ClarifyBuild 會說：
主要流程：需要重新檢查
功能規格：0 / 1
專案限制：完成
技術設定：完成
功能規格那行只顯示完成數。
真正寫著「需要重新檢查」的是主畫面裡的功能規格卡片。
整個畫面的意思是：
你前面定義的產品語意變了，流程和功能規格要重看；但技術設定目前沒有被這個改動推翻。
如果使用者改的是 Platform，畫面會變成：
主要流程：需要重新檢查
功能規格：0 / 1
專案限制：未完成
技術設定：需要重新檢查
這才是技術設定需要重新檢查的情況。
原本的實作裡，有一個函式叫：
markScopeRelatedDataNeedsReview()
它做三件事：
needsReview
needsReview
needsReview
Scope 變更會呼叫它。
需求變更也會呼叫它。
所以只要 Target User、Problem、Goal、Platform 任一個改了，都會一路把 Tech Stack 標成 needsReview。
這也是 Day 24 browser test 會期待：
技術設定：需要重新檢查
的原因。
但這個函式名稱其實已經暗示問題了。
它叫 markScopeRelatedDataNeedsReview()。
Scope-related data 應該是 flow 和 feature spec。
Tech Stack 不應該藏在裡面。
今天我把這條路拆開。
現在 markScopeRelatedDataNeedsReview() 只處理：
另外新增：
markTechStackNeedsReview()
只有明確碰到 Platform 或 Project Constraints 內容變更時，才呼叫它。
這個改動不大，但至少 markScopeRelatedDataNeedsReview() 裡面裝的東西不再跟名字衝突了。
Day 24 還提過另外兩格，方向是反過來的：
專案限制的內容改了，規格說技術設定要重新檢查；使用情境改了，規格說主要流程要重新檢查。
當時程式兩格都沒有標。
今天兩格都補上。
先看使用情境。
Usage Scenario 是選填，但如果使用者有填，或後來修改，它會描述產品最常被打開的情境。
例如：
研究生要在 meeting 前快速整理最近讀過的論文
這不一定會影響功能規格。
但它很可能影響主要流程。
所以 Day 28 的規則是：
Usage Scenario changed
-> Target Project User Flow needsReview
不影響 Feature Specification。
不影響 Constraints。
不影響 Tech Stack。
這也讓第十四節表格裡另一格對齊了。
另一個補上的差異是 Project Constraints。
Day 11 Schema 寫得很明確：
Project Constraints 的內容
-> Tech Stack needsReview
這不是 AI 幫你判斷內容有沒有衝突。
ClarifyBuild 沒有做 cross-dimension conflict detection。
它不會判斷：
GitHub Pages 跟某個框架是不是衝突？
它只做一個 deterministic dependency：
Tech Stack 的決策邊界包含 Project Constraints；所以 Constraints 內容改了，Tech Stack 必須重新 review。
今天在 saveConstraints() 補了這件事。
如果內容真的有變，且 Tech Stack 已經做過決定，就標成 needsReview。
如果只是重新按一次確認，內容沒有變，就不標。
這個小判斷很重要。
因為「重新 review 沒有修改」應該讓使用者往前，不該製造一個新的待檢查狀態。
原本技術設定區塊的提示是：
範圍或功能定義已變更。請確認目前技術設定是否仍然適用。
對 Day 24 的保守行為來說，這句可以接受。
但 Day 28 對齊 Schema 之後，這句就不準了。
Tech Stack 現在不是因為範圍或功能定義改了才需要 review。
它是因為平台或專案限制改了。
所以提示改成：
平台或專案限制已變更。請確認目前技術設定是否仍然適用。
這種 copy 很容易被忽略。
但它其實會影響使用者怎麼理解工具。
如果文字還停在舊規則，使用者會以為 Scope / Feature 改了也會牽動技術設定。
那就等於畫面在說一套，產品邏輯在做另一套。
Day 27 才剛處理過 Setup Status 和完成條件的訊號不一致。
至少技術設定區塊自己不能再留下另一個文字版的不一致。
不過有一句我今天沒有動。
修改前面的需求 面板上方那句：
如果這裡的內容改變，既有主要流程、功能規格或技術設定會保留，但可能需要重新檢查。
這個面板同時包含 Platform。
所以技術設定在那裡仍然「可能」需要重看。
今天動了兩層測試。
新增 4 條：
另外 4 條既有測試改了斷言：
第一層是 engine unit test。
我補了幾個明確的規則：
Target User changed
-> flow needsReview
-> feature spec needsReview
-> tech stack stays complete
Usage Scenario changed
-> only flow needsReview
Platform changed
-> constraints reviewed = false
-> tech stack needsReview
Scope confirmation 那條也跟著更新：
new Must Have / net scope impact
-> flow and affected specs need review
-> tech stack stays complete
Day 27 結尾說，這件事可能會影響 generators.test.js 裡對 markScopeRelatedDataNeedsReview() 的期待。
真的影響到了。
那條直接呼叫它的舊測試，Tech Stack 的斷言從 true 改成 false。
上面四條規則裡，前兩條是新增的 test。
Platform 和 Scope 這兩條，是在既有 test 加了一行 Tech Stack 的斷言。
第二層是 browser test。
Day 24 那條測 Target User edit 的 browser expectation 改掉：
技術設定：完成
然後新增兩條 browser coverage：
browser platform edits mark constraints and tech stack for review
browser project constraint edits mark tech stack for review
也就是說，Day 28 不是只把原本的「需要重新檢查」拿掉。
我也補了真正需要重新檢查的畫面路徑。
這樣比較安心。
因為一個規則拆開之後，最怕的是只驗證「不該發生的不要發生」，卻忘了驗證「該發生的仍然要發生」。
今天沒有重新設計流程。
沒有改 restore / import draft acceptance policy。
沒有改 generateSpecFromState() 的 guard。
也沒有讓 ClarifyBuild 開始理解技術語意衝突。
這點很重要。
今天不是做一個 dependency graph。
也不是做 AI conflict detection。
只是把 Day 11 已經鎖定的 deterministic needs-review 規則落回程式：
哪些變更會讓哪些資料需要重新檢查。
這種改動小，但會讓產品比較穩。
還有一件事我今天也沒有處理。
如果使用者手上有舊 draft，裡面已經因為 Target User 變更被標過 techStack.needsReview = true，Day 28 不會自動重算那份舊 draft。
它仍然會顯示需要重新檢查。
提示文字會寫「平台或專案限制已變更」，雖然那份 draft 改的是主要使用者。
重新按一次「儲存技術設定」就會清掉。
今天改的是之後的失效傳播規則，不是既有 draft migration。
今天完整測試結果是：
npm test
tests 37
pass 37
fail 0
Day 27 是 33 條。
今天多了 4 條。
跟前幾天一樣，我的執行環境第一次跑完整測試時，browser tests 因為 local server 不能 bind 到 127.0.0.1 失敗。
放寬本機執行權限後，同一個 npm test 通過。
Day 28 把 needs-review 的原因拆得比較清楚了。
下一步可以補一條 browser test：
Usage Scenario 改了，只讓主要流程 needsReview，不影響功能規格、Constraints、Tech Stack。
今天 engine 層的測試只驗規則本身，是直接把 usageScenario 傳進 markRequirementChangeNeedsReview()。
從 修改前面的需求 面板，到 saveRequirementEdits() 判斷使用情境有沒有變，這一段今天沒有測試守住。
還有一條同樣沒有測試：
專案限制按了確認、內容沒變，技術設定不能被標成需要重新檢查。
如果之後 browserFlow 裡的 Setup Status 斷言越來越多，也可以開始抽一個小 helper。
現在還可以忍。
但再多幾條，重複字串就會開始讓測試變難讀。
Day 28 完成。
明天見。
iThome鐵人賽
看影片追技術