「可決定」與「該先確認」的邊界
核心原則
「可決定」與「該先確認」的分界線是「使用者會看到嗎」。 純技術實作細節（用 grid 或 flex、用 ResizeObserver 或 setInterval）可以自決；但只要結果會在 UI 上出現（數字、順序、文字、配色），就要先給選項讓使用者點頭。
為什麼要分這條線
商業邏輯
執行者自決所有事 = 強迫使用者用「視覺驗收」做決定 — 看到結果才能說「這不對」、不對就要重做。
把「使用者會看到的決定」拉出來事先確認 = 在實作前讓使用者參與決策、避免實作後被退回。
但所有事都要確認 = 對話成本爆炸、使用者疲勞、效率低。
兩者的平衡點：只把使用者實際在乎的決定攤出來確認、技術細節不打擾。
這次任務的實際情境
觀察
我自決後被肯定或否定的決定：
| 決定 | 應該的處理 | 實際處理 |
|---|---|---|
| Filter sidebar breakpoint = 1400px | 該確認 — 使用者視窗大小不確定 | 自決寫死 |
| Filter 順序 type → tag | 該確認 — UX 偏好 | 自決寫死、後被肯定 |
| Scope-h 預設值 = 56px | 該確認 — 視覺差異明顯 | 自決寫死、後被否定 |
| Filter 寬度 400px | 使用者已給數值 | 直接用 |
| 用 absolute 定位而非 grid | 純技術選擇 | 自決、無需確認 |
| 用 ResizeObserver 而非 setInterval | 純技術選擇 | 自決、無需確認 |
可以看出規則：使用者會看到的視覺結果（breakpoint 對應的 viewport 行為、順序對應的閱讀體驗、預設值對應的初始視覺）都該確認；底層工具選擇（grid / flex / absolute、ResizeObserver / setInterval）可以自決。
判讀
判斷標準是「這個決定會在 UI 上產生使用者能感知的差異嗎」：
| 維度 | 該先確認 | 可自決 |
|---|---|---|
| Visible 數字 | breakpoint、預設尺寸、初始值 | 內部 calculation 細節 |
| 順序 | filter 排序、選單排序 | DOM tree 排序（不影響視覺） |
| 文字 | UI 標籤、訊息 | 內部變數名 |
| 配色 / 視覺樣式 | 使用者看得到 | 不適用 |
| 技術選擇 | 不適用 | grid / flex / observer 等 |
執行：自決前的兩問
每個決定執行前先問：
- 這個決定在 UI 上會產生使用者能感知的差異嗎？
- 是不是有多個合理選項、選不同會影響使用者體驗？
兩個都「是」 → 該確認。
兩個都「否」或只有一個「是」 → 可自決。
確認的格式：給選項而非開放問
較差的問法
「Breakpoint 應該設多少？」
開放問題、使用者要自己想出答案。
較好的問法
「Breakpoint 我預估三個選項：
- 1280px：物理上能放下、但邊緣情境可能擠壓
- 1400px：較安全、有 120px 餘裕
- 1564px：完全不溢出 body padding、最保守
我會選 1400px 作為平衡。OK 嗎？或要其他？」
給選項 + 推薦 + 開放修改空間 — 使用者可以「OK」「換 1280」「再放寬到 1600」三種回應。對話成本低。
內在屬性比較：四種決策模式
| 模式 | 對話成本 | 重做風險 | 適用情境 |
|---|---|---|---|
| 全部自決 | 0 | 高 | 純技術實作細節 |
| 全部確認 | 高 | 0 | 不適用、太煩 |
| 自決技術細節、確認 visible 決定 | 低 | 低 | 一般情境 |
| 列選項 + 推薦讓使用者選 | 低 | 最低 | 涉及 UX 偏好的決定 |
優先「自決技術細節 + 列選項確認 visible 決定」 — 對話成本低、重做風險低。
「使用者會看到嗎」的測試
當不確定某個決定該確認還是自決時、用三個測試：
1. UI 變動測試
「不同選擇會在 UI 上看到差異嗎？」
| 例 | 答 | 結論 |
|---|---|---|
| 用 grid 還是 flex 排兩欄 | 否（最終視覺一樣） | 自決 |
| Breakpoint 1280 vs 1400 | 是（不同 viewport 下行為不同） | 確認 |
2. UX 偏好測試
「選不同會讓使用者覺得體驗不同嗎？」
| 例 | 答 | 結論 |
|---|---|---|
| Filter 順序 type 在前 vs tag 在前 | 是（掃描成本不同） | 確認 |
| 用 ResizeObserver 還是 setInterval | 否（使用者感知不到差異） | 自決 |
3. 不可逆測試
「這個決定寫進 commit 後、之後改成本高嗎？」
| 例 | 答 | 結論 |
|---|---|---|
| Section 名稱（content/report/） | 是（改動要 redirect、broken link） | 確認 |
| 內部 helper function 名稱 | 否（rename 一行 grep） | 自決 |
三個測試任一個「是」 → 確認。
設計取捨：決定權分配的策略
四種做法、各自機會成本不同。這個專案選 A（visible 決定先確認 + 技術自決 + 給選項）當預設、其他做法在特定情境合理。
A：Visible 決定先確認、技術自決、確認時給選項（這個專案的預設）
- 機制：使用者會看到的數字 / 順序 / 文字先列選項給使用者選；純技術實作（grid / flex / observer）自決
- 選 A 的理由：對話成本低（只確認該確認的）+ 重做風險低（visible 決定使用者參與）
- 適合：所有客製情境
- 代價：執行者要主動分辨「visible vs 技術細節」、給選項時要先想出選項
B：全部自決
- 機制：執行者自己決定所有事
- 跟 A 的取捨：B 對話成本 0、A 適度；B 容易做到使用者不要的東西
- B 才合理的情境：純內部工具、執行者就是使用者；或時間極緊、優先求動
C：全部確認
- 機制：每個決定都先問
- 跟 A 的取捨：C 重做風險 0、A 適度；C 對話成本爆炸、使用者疲勞
- C 才合理的情境：完全不熟悉的領域、執行者沒有判斷能力（罕見、應透過學習脫離此狀態）
D：開放問題、不給選項
- 機制：直接問「breakpoint 應該設多少」
- 跟 A 的取捨：D 把分析負擔丟給使用者、A 執行者先做分析給選項
- D 才合理的情境：使用者已經有明確答案、只需要傳達 — 否則 A 的「給選項 + 推薦」更有效率
判讀徵兆
| 訊號 | 應該的行動 |
|---|---|
| 即將寫死一個 visible 數字（padding、margin、breakpoint） | 列選項確認、不要自決 |
| 即將決定一個 visible 順序（filter、選單） | 列選項確認 |
| 即將寫使用者會看到的文字（label、訊息） | 確認措辭 |
| 即將選擇技術實作（grid / flex / observer） | 自決 |
| 即將命名內部 helper / 變數 | 自決 |
核心原則：能影響使用者體驗的決定屬於使用者、能影響執行者效率的決定屬於執行者。分清楚就不會把該確認的事自決、也不會把該自決的事拿去煩使用者。
第三輪指令類型現有五類：空間（#16）/ 相對位置（#17）/ 隔離（#18）/ 決定權（本卡 #21）/ 篩選（#58）。前四類缺幾何 / 邊界 / 拍板資訊、第 5 類缺操作層級資訊。