昨天整理評論時，模型雖然保留了來源，仍把「適合工作」拿來對照會議需求，介面的未知提示也有待修正。這些結果還不能直接寫回店家資料。
今天換成一個不用呼叫模型的測試：把已經明確定義的工作條件交給程式計分，看看每一分從哪裡來。
Work Score 先留在獨立的本機測試頁，不接首頁、不採用昨天尚未確認的評論摘要。這次要檢查的是公式是否說得清楚，而不是替店家貼上一個客觀好壞的標籤。

1. 先限定這個分數回答的問題

第一版以「帶筆電到咖啡廳工作」為用途，考慮插座、Wi-Fi、音量、時間限制與會議適用性。不同人重視的條件不同，所以權重只代表這次測試的偏好。

原本想把資料可信度也加進總分，但資料齊全不等於條件好。這次改成分開呈現：

• 工作條件分數：依已知條件與權重計算。
• 已知資料覆蓋率：五個計分項目中，有幾項能確定分值。
• 資料來源與限制：保留示範資料標示、備註與更新資訊，不轉成另一個神祕分數。

評論摘要中的 confidence 也不參與計分。它表示文字證據支持程度，不能直接當成店家資料的真實性。

2. 寫下欄位分值，再設定權重

先對照 Cafe 型別與 DATA_FIELDS.md，再寫下這次實驗使用的分值。實際欄位若有差異，要先列清楚，不能把無法識別的值算成零分。

這次核對時發現，既有 Cafe 的會議適用性只有 suitable、unsuitable 與 unknown，沒有 conditional。測試頁另外支援 conditional＝50，供虛構店家 C 比較中間分值使用；這是本機計分實驗的設定，不代表正式 Cafe 資料已新增這個值。
unknown、null、缺欄位或無法識別的值都算未知。Wi-Fi 若只知道有提供、卻不知道穩定度，也維持未知；若欄位互相矛盾，標示需核對，不硬算分。
「有時間限制」給零分，只表示在這套偏好中不加分，不代表不能去。「有條件不限時」給 50 分也只是簡化的計分規則，不能據此保證能坐滿三小時。
先保留兩組固定權重：

計算方式：

各項貢獻分＝項目分值 × 權重 ÷ 100
總分＝五項貢獻分相加

不為未知資料補值。只有五項都有可用分值時，才顯示正式總分並參與排名。
若有未知項，另外顯示「已知項貢獻」與可能分數區間：

區間下限＝已知項貢獻合計
區間上限＝下限＋未知項的權重合計

區間不是預測，也不是把未知當成零分；它只是說明缺資料可能影響多少分。覆蓋率依可計分項目數計算，例如四項已知就是 4/5，不稱為可信度。

3. 準備三間虛構店家，先手算預期

這次不用真實店名，也不修改 Firestore。以下 A、B、C 都是獨立測試資料。

三間的五項資料都已知，方便先單獨比較條件。C 代表中間分值較多的組合，不因資料完整就額外加分。

以上是依公式手算的預期，不是程式已通過的測試紀錄。兩版都由 B 排第一，但 A 與 B 的差距從 27.5 分縮成 5 分。比較權重不一定要出現名次翻轉，分差也能反映偏好改變。
另外複製 B 建立 U，僅把 Wi-Fi 穩定度改成 unknown。預期 U 不參與排名，覆蓋率為 4/5：

• v1：已知貢獻 62.5，可能區間 62.5～82.5。
• v2：已知貢獻 55，可能區間 55～80。

這筆專門確認未知資料沒有被悄悄補成好或壞。

4. 在 Antigravity 規劃並建立測試頁

這次新增 /test/work-score，先完成實作，再開啟頁面。已有同名入口時，先檢查能否沿用。
先貼規劃指令：

請規劃 WorkCafe 的本機 Work Score 測試，先列計畫，不修改檔案。

閱讀 docs/ CURRENT 規格、README、Cafe 型別、DATA_FIELDS.md、
現有本機測試頁及 routes/web.php。
沿用 Laravel＋Inertia＋React。
本次只做確定性計分，不呼叫 Gemini 或 Places，
不讀寫 Firestore、不使用評論抽取結果、不讀取帳號或收藏。

新增僅限 local 的 GET /test/work-score。
使用獨立虛構 fixture A/B/C/U，清楚標示測試資料；
不改既有 mock 店家與首頁。
檢查實際欄位和 enum 能否對應接下來的分值表，
不相符時列出差異，不默默猜值。

列出必要檔案、計分函式、未知值處理、v1/v2 比較、
分數拆解、來源標示及測試方式。
完成計畫後先停下。

確認計畫後，再送出以下實作指令：

依確認的計畫，建立 WorkCafe 本機 Work Score 測試頁。

GET /test/work-score 僅在 local 環境開放。
以純函式計分，固定相同輸入會得到相同結果。
不呼叫任何外部 API，不讀寫 Firestore，不改首頁或既有 mock。
不採用自然語言解析或評論抽取結果。

先對照實際 Cafe 型別：
插座 many=100、limited=50、none=0；
Wi-Fi 有提供且 stable=100、有提供且 unstable=25、
明確無提供=0；只有提供狀態但穩定度未知時不可計分。
音量 quiet=100、normal=50、loud=0；
時間規則 none=100、conditional=50、always=0；
會議 suitable=100、conditional=50、unsuitable=0。
已確認既有 Cafe 的會議 enum 沒有 conditional。
本輪僅在獨立計分測試型別中支援 meeting conditional=50，供 fixture C 使用，
並在頁面註明差異；不要擴充正式 Cafe 型別或 DATA_FIELDS.md。
其餘 enum 或欄位與現況不符時，列出差異並停在該項，不自行猜測。

未知、null、缺欄位或非法值都標為不可計分；
明顯矛盾的 Wi-Fi 欄位組合標為需核對。
不得把未知轉為零分、平均分或正向條件。

固定兩版權重，依序為插座、Wi-Fi、音量、時間、會議：
v1=[15,20,35,20,10]；
v2=[30,25,20,20,5]。
權重必須非負且合計 100，不提供任意調整滑桿。

項目貢獻=分值*權重/100。
五項都有分值才產生正式總分並排名。
有未知項時總分為 null、不排名，
顯示已知貢獻、已知項數/5、下限及上限。
下限=已知貢獻，上限=已知貢獻+未知項權重合計。
這是缺資料的可能區間，不是預測分數。
以未四捨五入的數值計算及排序，顯示最多兩位小數。
同分顯示並列，不用 fixture ID 當成優劣判斷。

建立獨立虛構 fixture：
A：插座 many、Wi-Fi yes/stable、音量 loud、時間 none、會議 unsuitable。
B：插座 limited、Wi-Fi yes/stable、音量 quiet、時間 none、會議 unsuitable。
C：插座 limited、Wi-Fi yes/unstable、音量 normal、時間 conditional、會議 conditional。
U：複製 B，僅將 Wi-Fi 穩定度改為 unknown。
使用實際欄位路徑承接以上語意，不產生真實店名或虛構評論來源。
資料來源標為自製 fixture，不捏造觀察日期或查核紀錄。

頁面顯示分值規則、兩版權重、資料欄位與來源、
逐項分值/權重/貢獻、總分或未知區間。
提供 v1/v2 同資料比較表，保留版本名稱；
U 與完整資料店家分區顯示，不混入排名。
清楚標示分數代表本輪偏好，不代表真實店家品質。

撰寫有手算基準的測試：
v1 A=55、B=82.5、C=45；
v2 A=75、B=80、C=43.75。
U 覆蓋率 4/5，總分 null；
v1 已知貢獻 62.5、區間 62.5～82.5；
v2 已知貢獻 55、區間 55～80。
另驗證全未知時 0/5、總分 null、區間 0～100，
非法 enum、矛盾 Wi-Fi、權重不合法、同分並列及精度處理。
不要為通過測試而修改預期值；不一致先回查公式。

執行相關測試、npm run typecheck、npm run build，
以及 php artisan route:list --path=test/work-score。
回報修改檔案、實際入口、檢查結果與未驗證事項。
不自動 commit 或 push。

5. 確認路由，逐間檢查分數

等 Agent 回報完成實作與檢查，再於專案 Terminal 執行：

php artisan route:list --path=test/work-score

確認有 GET|HEAD，才在原本 WorkCafe 本機網址開啟 /test/work-score。若入口不同，以 Agent 實際回報為準。
沒有路由時先確認程式已建立，再查 php artisan env 是否為 local。程式和環境都正確但路由未更新時，才清除路由快取後重查。不要把「計畫完成」當成「頁面完成」。
完成實作後，先核對頁面的分值表、v1／v2 權重與未知資料規則，再看計算結果。

📸 圖片 1｜Work Score 分值、權重與未知資料規則

選擇 v1 後，畫面顯示 B 為 82.5 分、A 為 55 分、C 為 45 分，與前面的手算預期一致。再展開 B 的分數拆解，逐項加總：

插座 7.5＋Wi-Fi 20＋音量 35＋時間 20＋會議 0＝82.5

U 的畫面則顯示總分 null、覆蓋率 4/5，並列在不予排名區。已知項貢獻為 62.5 分，可能區間為 62.5～82.5 分，符合 Wi-Fi 穩定度未知的設定。這裡的 62.5 是已知項合計，不是 U 的正式總分。

📸 圖片 2-1｜v1 排名：B 82.5 分、A 55 分、C 45 分

📸 圖片 2-2｜B 的分數拆解：五項加總為 82.5 分

📸 圖片 2-3｜U 的 Wi-Fi 穩定度未知：保留分數區間，不參與排名

6. 比較權重，不為了排名改答案

切到 v2，保持 A、B、C、U 的資料不變，再核對比較表。
比較表顯示，A 從 55 分升到 75 分，B 從 82.5 分變成 80 分，C 從 45 分變成 43.75 分。兩版排名都是 B、A、C，但 A 與 B 的差距從 27.5 分縮成 5 分。
U 在兩版都沒有正式總分，也不參與排名。它的區間從 62.5～82.5 變成 55～80，與 Wi-Fi 權重由 20% 調高到 25% 的設定一致。這些畫面中的數值都符合手算預期；至於非法值、同分、全未知等其他案例，仍需另外核對測試紀錄，不能只靠這幾張圖判定全部通過。
這個結果說明的是偏好改變後，分數如何跟著變動。v2 不一定比 v1 好，也不需要刻意把權重調到某間店排第一。若結果與手算不同，就回頭查欄位對應、權重與加總。

📸 圖片 3｜相同資料、不同權重：比較 v1 與 v2 的分數和排名

如果請 Agent 協助核對，附上實際結果與分值表，再使用：

請核對附件中的 WorkCafe Work Score 測試。
逐項重算 A/B/C 的分值、權重、貢獻與總分，
以及 U 的未知項、覆蓋率和分數區間。
確認兩版使用相同 fixture，只改權重，
未知資料沒有被補值，U 沒有參與排名。
分開列出手算預期、可見實際結果與差異；
未提供的結果標為未驗證，不補造通過紀錄。
不要調整權重迎合排名，不修改程式、不呼叫外部 API，
不自動 commit 或 push。

分數後面，還要看得到條件

昨天的摘要提醒我，來源有留下來才查得出問題。分數也是一樣：除了總分，還要看得到欄位、權重與缺漏。
這次的本機畫面已能對上 A、B、C 的兩版總分，以及 U 的未知資料區間。會議欄位的 conditional 仍是測試專用設定，Work Score 也先留在獨立測試頁。
分數算對，只表示這幾筆資料依照設定的公式得到預期結果。這套權重是否符合使用者的工作需求，還要另外驗證。