Day 21 結尾我留了一個很具體的方向。

如果 Day 22 要繼續補 browser test，就補一條從 Idea Entry 一路走到 Prompt Preview 的 happy path。

今天就是那一條。

測試名稱是：

browser fresh idea happy path reaches prompt preview

它打開全新的 index.html，透過畫面上的欄位和按鈕，從 Idea 一路走到 Prompt。

不預先塞 draft。

不直接操作 state。

不跳過畫面。

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

今天這條測試走的是進度列上的六站：

Idea -> Clarify -> Scope -> Specify -> Spec -> Prompt

中間還會經過 Optional Details，只是進度列仍歸在 Clarify。

結果是：npm test 28 條全過，27 條舊的，加今天這 1 條。

產品程式沒有改。

今天只新增兩樣東西：

• 一條 browser happy path
• browser test 工具，也就是 harness 裡的兩個 helper：fill() 和 select()

為什麼這次要從空白開始

其實要讓 browser test 很快到 Prompt Preview，有一條比較省事的路。

先做一份完整 draft，塞進 localStorage，重新載入頁面。

Day 20 的 draft import tests 就是這樣做的。

那是合理的。

因為 Day 20 要測的是「匯入 draft 時，使用者確認之前不能覆蓋目前內容」。

它需要的是一份完整 draft，才能很快產生目前的 Spec / Prompt，接著去測匯入、取消、確認這幾條路徑。

但 Day 22 要測的不是匯入。

今天要測的是：

使用者第一次打開 ClarifyBuild，能不能靠畫面一路走到最後的 Prompt？

所以我沒有塞 draft。

這條測試從 Idea Entry 的 textarea 開始。

輸入：

我想做一個讓研究生整理論文的網站

這句話會觸發 ClarifyBuild 現在的 candidate detection。

candidate detection 是很小的推測機制：看到 網站，就先猜平台可能是 Web；看到「讓研究生整理」，就先猜主要使用者可能是研究生。

所以 Clarify 階段一開始不是直接問空白題，而是先請使用者確認：

確認我對 Idea 的理解

六站各做了什麼，整理成這張表：

六站我都用進度列上亮起來的那一項確認過。

這裡有一個容易漏掉的地方。

欄位填完不算數。

Specification Setup，也就是 Specify 這一站，四個區塊都要各自按一次存檔的按鈕。

所以測試也照著這個節奏走：填一段、存一段，再填下一段。

這條測試守到什麼

test/mvpFlow.test.js 其實早就有一條 happy path。

它用的是同一組故事：

• 研究生
• 論文資料散落在不同地方
• 搜尋論文
• 搜尋頁

但那條測試是從函式呼叫走。

它驗的是 domain、engine 和 generator 接得起來。

今天這一條是從按鈕走。

它驗的是畫面接得起來。

同一個故事，兩個高度。

這條 browser happy path 守的是這些事情：

• candidate confirmation 的按鈕能把推測值寫進 draft
• 略過選填資訊後，流程能進 Scope
• Scope 下拉選單選 Must Have 後，確認範圍能進 Specify
• 四個 Specification Setup 區塊填完並儲存後，能產生 Spec
• Spec Preview 能再產生 Prompt
• 使用者輸入過的關鍵內容，最後真的出現在 Prompt 裡

前四項，Day 20 的三條 import 測試都沒走過。

它們從存好的 draft 開始，不用確認候選、略過選填、選 Must Have，也不用填寫並儲存四個區塊。

最後這一點，要先講清楚它守的範圍。

這條測試沒有逐一檢查 Spec 的每個區塊。

它最後確認的是 Prompt 裡有：

Development Instructions
# Project Specification

以及一路從畫面輸入過的 10 句話：

我想做一個讓研究生整理論文的網站
論文資料散落在不同地方
搜尋論文
搜尋頁
輸入關鍵字並檢視結果
輸入論文名稱
依名稱過濾論文清單
顯示符合的論文
不改變原始資料
必須可以部署為靜態網站

也就是說，這條測試不只是看進度列變成 Prompt。

它也確認，idea、problem、核心功能、主要流程、行為規則和專案限制，這些一路填進去的內容，有被帶進最後輸出。

但它不是完整的 Spec schema 驗證。

那種責任還是比較適合留給 generator 或 app flow 的測試。

browser test 這裡要守的是：

使用者按出來的流程，最後接得到正確的輸出。

fill() 和 select() 剛好補上昨天預告的洞

Day 21 抽出來的 browserHarness.js 已經有 goto()、click()、text()、waitForText() 這些點、讀、等的工具，但還沒有能填文字欄位、選下拉選單的。

fill(selector, value)
select(selector, value)

這剛好接上 Day 21 留下的話。

我昨天寫過：如果要補 Idea Entry 到 Prompt Preview，多半可以把注意力放在流程本身，頂多再補一兩個像 fill() 或 select() 的小 helper。

今天補的剛好就是這兩個。

它們都不是 ClarifyBuild 專用邏輯。

fill() 只是找到欄位、設值，然後送出 input 和 change event。

select() 也是找到 select、設值、送 event。

差別是 select() 現在會多做一個檢查：如果傳進去的選項值不存在，它會直接丟出比較清楚的錯誤，而不是讓測試五秒後才用「等不到條件」失敗。

這是今天順手補的一個小洞。

因為下拉選單如果選不到值，畫面會留在原狀；晚一點才 timeout，會讓人比較難知道真正壞在哪。

至於為什麼 fill() 和 select() 都送 input 和 change？

目前文字欄位其實沒有即時 listener。

ClarifyBuild 是在按下按鈕那一刻，才讀 textarea 或 input 的值。

但 Scope 的下拉選單有 change listener。

少了 change，Must Have 就不會寫進 state，後面也進不了 Specify。

所以我讓兩個 helper 都模擬比較完整的使用者輸入事件。

哪天文字欄位加了即時驗證，helper 也不用再跟著改。

Day 21 我也寫過 Playwright 的重新評估條件：如果為了下一條測試，harness 開始需要新增很多 fill()、select()、keyboard helper，就該重新看要不要換工具。

今天只補了兩個，每個都很小，我判斷還沒到。

機制進 harness，情境留在測試

今天我沒有抽出 completeFreshIdeaFlow()。

也沒有做什麼「ClarifyBuild browser fixture」。

這是刻意的。

fill()、select() 是 browser mechanics。

它們只知道怎麼操作頁面。

但「從 Idea Entry 到 Prompt Preview 要怎麼走」是產品情境。

這個情境目前先留在 test/browserFlow.test.js 裡。

原因很簡單：下一條測試不一定要走完整條路。

例如 Day 23 如果要測 Specification Setup 的防呆，測試可能需要停在 Specify 中間。

如果今天先抽一個一口氣走到底的大 helper，下一條測試反而要想辦法繞開它。

所以今天的界線是：

browser 操作方法可以抽，產品流程先不要急著抽。

這也是 Day 21 沒有抽 ClarifyBuild fixture 的延續。

先等重複長出穩定形狀，再抽。

Day 21 的整理值在哪裡

如果沒有 Day 21，今天這條測試其實也寫得出來。

因為 Day 20 的 withBrowserApp() 原本就在同一個測試檔裡。

所以我不想把話說成「沒有昨天就做不到今天」。

更準確地說，是 diff 變乾淨了。

今天新增的測試都在描述使用者做了什麼。

今天新增的 harness helper 都在描述怎麼操作頁面。

兩邊的責任沒有混在一起。

這就是 Day 21 整理開始回本的地方。

它不是讓 happy path 突然變可能。

而是讓 happy path 的程式碼比較像 happy path。

讀測試時，我不用先跨過 local server、Chrome 啟動、CDP connection，才看得到使用者流程。

這對後面繼續補 browser test 會很重要。

測試結果

Day 22 完成後，focused browser tests 是：

node --test test/browserFlow.test.js
tests 4
pass 4
fail 0

完整測試是：

npm test
tests 28
pass 28
fail 0

跟 Day 20、Day 21 一樣，我的執行環境第一次跑 browser tests 時，會因為 local server 不能 bind 到 127.0.0.1 而失敗。

放寬本機執行權限後，同一組測試通過。

今天補到的，和明天想補的

今天這條測試，從空白開始，是為了讓它走的是使用者真的會走的路。

機制放進 harness，是為了讓測試檔讀起來就是那條路。

六站每一站，進度列上都有一個斷言看著。

但反方向，browser 層還沒有人守。

也就是：

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

這件事現在是產品邏輯的一部分。

Specification Setup 右邊有 Setup Status。

主要流程、功能規格、專案限制、技術設定，四個都完成，產生 Project Specification 按鈕才會解鎖。

Day 23 很適合補這條 browser negative path。

今天先到這裡。

Day 22 完成。

明天見。