Tarragon

"抽象層"

• 2026-04-25 2 次門檻：第一次是運氣、第二次是訊號 同一個問題出現第 2 次時、就該停下來把處理層級升一階 — 從推理升到量測、從手動驗證升到自動化、從同方向嘗試升到換思路。第 1 次失敗的資訊不足、第 2 次提供「重複出現」的證據、值得付出升級成本。本文是 #11 / #15 / #20 / #23 四篇實作的共同抽象。
• 2026-04-25 最小必要範圍是 sanity 防線：保護行為可預測性 縮 selector 範圍、observer 範圍、JS 操作範圍 — 不是為了效能、是為了讓行為可預測、不被未來變動打破。本文是 #13 / #14 / #29 三篇實作的共同抽象。
• 2026-04-25 Single Source of Truth：值的住址只能有一處 同一個值（CSS token、視覺基準、runtime 量測）的權威來源只能有一個位置 — 多源時會分歧、會漏改、會讓讀者不知道哪個生效。本文是 #3 / #26 / #27 三篇實作的共同抽象。
• 2026-04-25 跟外部組件合作的層次：離介面越近、合作越穩 客製外部組件的穩定性與「離組件作者保證的對外介面多遠」成反比。每往內推一層、依賴前提增加、升級風險上升、可逆性下降。本文是 #1 / #5 / #19 / #24 四篇實作的共同抽象。
• 2026-04-26 寫作便利度跟意圖對齊反相關 寫程式時最容易寫出的版本、通常是離意圖最遠的版本。便利度建立在「現有上下文 / 已 materialize 資料 / 已存在 API」上、而意圖對齊需要找到正確的層、處理上游、跨抽象層 — 兩者方向相反。識別這個反相關 = 識別自己掉進「容易寫的陷阱」。
• 2026-04-26 Test-First：先看到 RED 才相信 GREEN 一個只看過 GREEN 的測試是「未驗證的訊號」、不是「會抓回歸的測試」。必須先在「該失敗的版本」上看到 RED、再在「該通過的版本」上看到 GREEN — 兩次跑都對、才能相信測試真的 catch 到該 catch 的東西。跳過 RED 等於把驗收標準降到「跑得通」、漏掉「測試自己有沒有 bug」這層。
• 2026-04-26 URL 是 stateful UI 的儲存層 — 哪些 state 該寫進 URL 互動式 UI 的 state 散落在多層（in-memory / URL / localStorage / server / index）、每層有不同特性。可分享 / 可恢復 / 可導航的 state 該寫進 URL — 不寫進 = silent 把這些特性犧牲掉。本文展開「state 的儲存層選擇」協議與 URL 的具體位置。
• 2026-04-26 Tab Order = DOM Order = Mental Model 三者對齊 Tab 順序由 DOM 順序決定（除非用 tabindex 強制覆寫）。三者該對齊：DOM 順序、tab 順序、使用者 mental model 的互動順序。三者不一致時、優先重排 DOM 而非用 tabindex — tabindex > 0 是反模式（[#52]）。
• 2026-04-26 高 ROI 無外部觸發的工作會被結構性跳過 工作有兩個獨立維度：ROI 高低 + 是否有外部觸發。高 ROI + 無觸發 = ROI 的承諾、拖延的現實。靠紀律不可行 — 結構性偏差需要結構性對策（外部觸發 / CI / hook / 排程 / pair）。本卡是 #67 便利反相關、#68 checkpoint 跳過、#69 RED 跳過的共同上位原則。
• 2026-04-26 主策略 + 補強策略：選擇不必互斥 多策略並非「五選一」、可分層疊加：root-cause fix（解結構問題） + UX 補強（解使用者感知）通常雙打比單選更穩。判準三條：解不同層 / 沒副作用衝突 / 增量成本可接受。把「策略選擇」預設成單選、會放掉互補可能、產生「結構修了但使用者體驗仍差」或「UX 蓋過去但結構還壞」。
• 2026-04-26 分批 ship：低風險可見價值先行、結構性下輪 「一次 ship 全部」的衝動 vs 「分批 ship」的設計：判準三軸（使用者可見性 / 風險暴露面 / 驗證需求）。低風險 + 高可見 = 立刻 ship；高風險 + 需驗證 = 下輪。對抗「完整才完整」的全做衝動、避免一次塞太多 review surface 拖延上線。
• 2026-04-26 決策對話的五個維度：保持完整選擇空間 對話中的「決策」不是單一動作、是多維度選擇空間：呈現格式 / 策略疊加 / 批次邊界 / 時間軸 / 選項類型。預設多半 collapse 到最窄格（開放問 + 單策略 + 一次完成 + 立刻決 + 單選）、塞使用者進最少自由度的盒子。本卡是 #74-#78 的上層串連 — 五張卡各對應一個維度的鬆綁。
• 2026-04-26 卡片系統的迭代浮現：原子卡 → meta-卡 → reference 三層展開 知識卡片系統不是一次寫成、是 dialogue → 原子卡 → meta-卡 → reference 的迭代浮現。每一輪迭代解決上一輪的 over-fit / under-fit、串連分散的卡片、抽出 meta-原則、最後沉澱成可直接套用的 reference 文件。本卡是 cards-skills 系統設計的 process-level 元原則。
• 2026-04-26 字面攔截 vs 行為精煉：驗證手段跟錯誤層次的對齊 驗證手段必須跟錯誤層次對齊：字面錯誤（typo / syntax / 缺欄位）用 hook / lint / CI 攔截；行為錯誤（思考偏差 / 判斷錯位 / collapse 反模式）用 multi-pass spiral 收斂。強行用 hook 蓋行為錯誤 = 給出 false confidence、反而比沒保護危險。本卡是 #72 結構性對策在「驗證粒度」維度的 ceiling — 不是所有錯誤都該被攔截。
• 2026-04-26 Methodology 的 multi-pass 該升級為 pillar 層：核心結構才會被執行 任何「教做事方法」的 methodology / SKILL / playbook、應該把 multi-pass refinement 放在 pillar / 核心原則層、不是放在末尾「附帶提醒」段。Pillar 層 = 結構性必跑、appendix 層 = 看心情選擇 = 永遠不跑。本卡是 #82 行為驗證 + #72 結構性對策在「方法論設計本身」這一層的展現。
• 2026-04-26 Capability gap 的對策三層階梯：expectation → augment → rebuild 系統有 capability gap（功能不滿足使用者預期）時、對策有三層階梯：L1 expectation alignment（UX hint、訊息精準）、L2 augmenting computation（補一層計算 close gap）、L3 structural rebuild（換 index / engine / 演算法）。三層成本、覆蓋率、脆弱度遞增、不必每次跳到 L3。本卡是 #75 主+補強策略的「不疊加、選層級」變種、跟 #59 五策略矩陣可疊加使用。
• 2026-04-26 Build-time 預處理 vs Runtime 計算的光譜：何時把成本前置 計算可放 build-time（預處理一次、runtime 0）或 runtime（per query 算）— 兩極之間有 hybrid 段（hot path 預算、cold path runtime）。判準四軸：query 頻率 / dataset 大小 / freshness 需求 / build pipeline 複雜度。Build-time 不是「永遠較好」、freshness / 多樣性高時 runtime 反而對。本卡把 #59 五策略中「query-side pushdown vs client-side fallback」的取捨抽象化、跨領域適用。
• 2026-04-28 視覺手段對齊錯誤層次：CSS / emoji 修不到語意 / 邏輯問題 修視覺問題的工具（CSS、emoji、顏色、排版）只能擋視覺層、不能修語意 / 邏輯層。把語意 / 邏輯問題當成視覺問題修 = 蓋住症狀根因不動 + false confidence、跟 #82 用 hook 蓋行為錯誤同骨。三層優先序：邏輯 → 語意 → 視覺、修法從深層往淺層走、不從症狀往回推。本卡是 #82 在「呈現層」的具體實例、是 #83 multi-pass review 缺的 vertical 軸。
• 2026-05-18 Collapse 是隱形預設：多維空間被壓成單格的三類典型 決策對話、決策呈現、批量輸出三個 surface 都有同一個 pattern — 高維選擇空間預設被 collapse 到 1-2 個窄格、且這個 collapse 因為「便利 / 合規 / 簡潔」被當成中性預設、不被覺察；#80 是 decision surface 上的極致 collapse、#79 是 dialogue 五維 collapse、#123 是 output framing 在 constraint 下 collapse；三者共骨：*某個高自由度空間被便利驅動 reduce 到最少格子*；對策不是去除 collapse、是讓 collapse 變顯性、由設計者決定要 collapse 哪一維、不是預設全 collapse
• 2026-05-18 寫作 review 是多軸完整性、不是單軸深度 寫作 review 的完整性不是單一軸越做越深、是多軸交集都對齊；#83 frame 軸 + #121 instance 軸 + #97 surface 軸 + #95 scope 軸 + #122 cadence 軸 + #124 timing 軸 + #114 granularity 軸、七軸正交、缺任一軸都會 systematic miss；review 設計時要 enumerate 七軸覆蓋狀況、不是只跑一兩個維度做深；是 #79 五維決策對話在 review 工具設計的姊妹卡
• 2026-05-19 Process content 結構由最大差異維度決定、不是 universal phased 跨 X process content（migration / upgrade / rollout / playbook）的結構由 source / target 之間 *差異維度組合* 決定、不存在 universal phased 模板；6 種 migration / process type 實證（schema 差 / drop-in / operational / multi-tool / paradigm / topology re-layout）跑出 6 種不同結構；寫作前必須做 *6 維 diff dimension audit* 才能決定結構、跳過會套錯模板
• 2026-05-19 Data topology 是 process content 的第 6 audit 維度 Process content 的 diff dimension audit 原本 5 維（schema / operational / paradigm / components / application change）漏了 *data topology* — 資料在 cluster / partition / region 之間的分佈拓樸；topology 不在既有 5 維任一個、但決定 re-sharding / partition redesign / multi-region rollout 的結構；本卡擴 audit 到 6 維、新增 Type F「Topology re-layout」結構