"Pattern"
- Pattern：Document 全文件 query
`document.querySelector` 從整個頁面找元素 — 是探索期與一次性 script 的合理工具、不是 production 客製的預設。本文展開這個 pattern 的適用邊界。
- Pattern：元件根變數 query
把元件根 `var shell = document.querySelector('.shell')` 一次存變數、之後所有 query 從 shell 開始 — 是 production 客製的預設起點。本文展開這個 pattern 的設計細節與邊界。
- Pattern：起點當函式參數
把元件根當函式參數傳入 — `function setup(shell) { shell.querySelector(...) }`、外部呼叫 `forEach(setup)` 處理多實例。本文展開純函式設計與多實例支援的取捨。
- Pattern：closest 反向找根
事件處理時用 `e.target.closest('.shell')` 從事件目標反向找元件根 — 適合動態元件、SPA 路由切換、事件委派場景。本文展開反向定位 pattern 的應用邊界。
- Pattern：DOM attribute idempotency 標記
用 `:not([data-x])` 過濾 + 處理後 `setAttribute('data-x', 'true')` 保證每元素只處理一次 — 是 production apply 函式的預設 idempotency 工具。本文展開命名、生命週期、跟 framework 共處的設計細節。
- Pattern：WeakMap idempotency 紀錄
用 `WeakMap` 紀錄已處理的元素 — 不污染 DOM、適合第三方 library、跟 framework 衝突場景。本文展開 GC 行為、debug 替代方案、跟 attribute 標記的取捨。
- Pattern：跨 slot 同節點搬遷
Stateful UI 在兩個 slot 之間用 `appendChild` 搬同一個 DOM 節點、不複製兩份 — 避免 state 分歧。本文展開搬遷 pattern 的設計細節與適用邊界。
- Pattern：自動續抓直到湊滿 quota
Pattern 卡片：分批 source + post-filter 時、自動續抓直到湊滿 N 個 match。含上限保護、進度顯示、可中斷三個必要元件。對應 #59 策略 B 的具體實作。
- Pattern：把 filter 推進 query 引擎
Pattern 卡片：把 client-side filter 推進 source 的 query 引擎、由 source 直接回符合的。對應 #59 策略 A 的具體實作。前提是 source capabilities 支援該 filter 條件、否則要評估重 index。
- Pattern：誠實進度 UX（已掃 N / 命中 K / 共 M）
Pattern 卡片：當 filter 跟 source 必然有層錯位、用三數字（已掃 N / 命中 K / 共 M）讓使用者看見掃描範圍、避免誤以為「沒命中」。對應 #59 策略 D 的具體實作。
- Pattern：預先建獨立 index（每種 mode 一份）
Pattern 卡片：build time 為每種 filter mode 各建一份 source / index、runtime 切換 mode = 切 source。對應 #59 策略 C 的具體實作。前提是能控 source 的 build pipeline、且 mode 數量有限。
- Pattern：明示語意縮小（不承諾全集）
Pattern 卡片：當 filter 必然只能在 subset 上做、明確告訴使用者「這只在已載入範圍內找」、不假裝是全集 filter。對應 #59 策略 E 的具體實作。重點是「明示」、silent 縮小是反模式。
- 決策呈現：選項 + 推薦 + 開放修改
讓使用者做決定時、不要開放問「你覺得呢」 — 給選項、加適配性、標推薦、開放修改。開放問把「整理問題」的成本丟給使用者、推薦把判斷攤開供質疑、開放修改保留使用者的最終決定權。本卡是 #58 篩選三問、requirement-protocol 原則 1 的呈現面展開。
- 反省任務預設複選：互斥要證明、不互斥是預設
反省 / retrospective / 改進方向類問題、預設應給「複選」而非「單選」 — 互斥需要明示證明、不互斥是預設。用 radio 限縮會讓使用者被迫排序、丟失多面向的同時性。本卡是 #74 決策呈現的反省場景特化、跟一般「執行類決策」（多半互斥）對立。
- Yes/No 二選是隱式 collapse：把多選空間壓成 1 bit
「需要我繼續嗎？」「要做嗎？」「OK 嗎？」這類 yes/no 問句、看似最簡單其實是五維 collapse 的極致形態：1 bit 編碼掉「改 / 延後 / 疊加 / 分批 / 反問」五種合法回應。本卡是 #74-#79 系列在「最常見、最隱形」變種的特化卡。
- Writing 的 multi-pass review：N 輪 review、每輪換 frame
寫文章 / 註解 / 文件 / prompt 的「寫」不是單次動作 — 是 N 輪 review。第 1 輪生成、第 2 輪對意圖（#67）、第 3 輪檢查機會成本語氣、第 4 輪 grep-ability、第 5 輪反例 / 邊界。每輪不同 frame、單輪寫不出全部維度。本卡是 #82 在「寫」這個 output 動作的具體實例。
- Naming 是 iterated artifact：第一個名字幾乎不對、四輪 review 才收斂
命名（變數 / 函式 / 檔名 / slug / API endpoint）幾乎沒有「一次寫對」的可能：第一個名字基於當下狹窄的 context、會在後續 cross-call-site / grep / 重構中暴露錯位。命名的正確設計是 iterated — 寫第一版 → grep-ability 測試 → cross-call-site 一致性 → impl 洩漏 → 重命名。本卡是 #83 在「命名」場景的特化。
- Engine 不可調時、把 transformation 移到外層
當底層 engine 沒開放某能力的客製 API、不該硬戳 engine 內部、改在 engine 的「輸入層」做 transformation。Search engine 不支援 substring → build-time 加 suffix tokens；LLM 不支援某 reasoning → prompt 層做 chain-of-thought；DB 不支援某 query → 預先 denormalize column；compiler 不可調 → source-level macro。本卡是 #45 外部組件合作四層 + #87 build-time vs runtime 的具體實作 pattern。
- L1 + L2 疊加時的訊號一致性：UX hint 跟自動 fallback 講的話要對齊
把 expectation alignment（L1）跟 augmenting computation（L2）疊加時、兩個 layer 給使用者的訊號可能矛盾：L1 說「請改打字」、L2 卻自動找到了；L1 說「資料可能延遲」、L2 卻 stale-while-revalidate 自動 refresh。沒對齊時使用者困惑。本卡定設計 protocol：兩個 layer 講同一個 capability gap、訊號要 layered consistent、不是 redundant 也不是 conflicting。本卡是 #75 + #86 + #79 在「使用者訊號層」的整合。