隔離程度類指令的澄清時機
隔離程度類指令的澄清時機
核心原則
「隔離」「不要動 X」是描述意圖的詞、不是描述實作的詞。 實作前先確認隔離邊界是哪一種：DOM 結構、layout flow、state、framework 管轄區。每種邊界的實作策略不同、混淆會做出不符合使用者意圖的隔離。
為什麼隔離需要澄清
商業邏輯
「隔離」這個詞涵蓋多種獨立的概念：
| 隔離類型 | 含義 | 實作策略 |
|---|---|---|
| DOM 結構隔離 | 兩個元件不在同一 DOM 子樹 | 分開放在不同 ancestor |
| Layout flow 隔離 | 一個元件的 layout 不影響另一個 | absolute / fixed 跳出 flow |
| State 隔離 | 兩個元件的 state 互不影響 | 各自有獨立 state container |
| Framework 管轄區隔離 | 客製 UI 與 framework UI 各自管自己 | 客製 UI 留在 framework 邊界外 |
每種需要的實作完全不同。執行者選錯邊界 = 做了不符合使用者意圖的「隔離」。
這次任務的實際情境
觀察
| 指令 | 我的初次理解 | 使用者實際意圖 |
|---|---|---|
| 「不動 pagefind 行為」 | 不改 pagefind 的 search 邏輯 | 包含「不在 pagefind DOM 內塞客製元素」 |
| 「左右不要在同一層」 | DOM 層級分開 | Layout flow 互不影響（用 absolute 疊層） |
「不動 pagefind 行為」這句、我多次把 scope UI 注入 pagefind DOM、違反使用者的隔離意圖 — 我以為「不動」只指邏輯、實際包含 DOM 結構。
判讀
執行前該確認：「不動 / 隔離」的邊界是哪一種類型？
執行：邊界類型確認 protocol
收到隔離類指令時、列四種可能的邊界：
1你說的「不動 pagefind」涵蓋哪些？
2 □ 不改 pagefind 的搜尋邏輯（不 fork / patch source）
3 □ 不改 pagefind 渲染的 DOM 結構（不在內部 appendChild）
4 □ 不改 pagefind 的 state（checkbox 勾選等）
5 □ 完全不互動（連 CSS 都不覆寫）使用者勾選對應項、執行者照那個邊界實作。
或更簡單的問法：「具體來說、什麼算動、什麼不算動？」
內在屬性比較：四種隔離邊界的特徵
| 邊界類型 | 偵測方式 | 違反的後果 |
|---|---|---|
| DOM 結構 | 看 ancestor chain 是否相同 | 一個元件可能影響另一個的 layout / 樣式 |
| Layout flow | 看是否在同一 flow（grid / flex / block） | 一個元件撐開影響另一個位置 |
| State | 看 state 是否共用 store | 一個元件改 state 影響另一個顯示 |
| Framework 管轄區 | 看是否在 framework 渲染週期內 | Framework patch 時客製被清掉 |
執行前確認邊界類型 — 不確定就問。
隔離邊界的辨識技巧
1. 從「會發生什麼」反推
問使用者：「如果 X 改了、Y 應該也跟著改嗎？」
| 答案 | 對應邊界 |
|---|---|
| 是 — Y 跟著動 | 沒有隔離、共用 state |
| 否 — Y 不動 | State 隔離 |
| 否 — 連 layout 都不變 | Layout flow 隔離 |
| 否 — Y 完全感知不到 X | DOM 隔離 |
2. 從「動誰會壞」反推
問：「我能在哪個 DOM 區域加東西？」
| 答案 | 對應邊界 |
|---|---|
| 任何地方都可以 | 沒有隔離 |
| 自家元件內可以、X 元件內不行 | Framework 管轄區隔離 |
| 自家元件內也要小心、不能影響 X 的 layout | Layout flow 隔離 |
| 完全分開、不能放在同一 DOM 子樹 | DOM 結構隔離 |
3. 從「升級時誰要動」反推
問：「X 升級時、我們要回頭改什麼嗎？」
| 答案 | 對應邊界 |
|---|---|
| 不用、客製跟 X 完全分開 | DOM + framework 管轄區隔離 |
| 可能要調整客製 CSS | Layout / state 邊界內客製 |
| 客製要重做 | 沒有隔離、客製深入 X 內部 |
設計取捨：隔離指令的處理策略
四種做法、各自機會成本不同。這個專案選 A（列邊界類型確認）當預設、其他做法在特定情境合理。
A：列四種邊界類型確認（這個專案的預設）
- 機制：列出 DOM 結構 / layout flow / state / framework 管轄區四選項、使用者勾選對應項
- 選 A 的理由：明確 + 完整、使用者快速指出真正想要的隔離
- 適合：隔離意圖不明確的情境
- 代價：多一段四選項描述
B：反推法（從「會發生什麼」「動誰會壞」反推）
- 機制：問「如果 X 改了、Y 應該也跟著改嗎？」「我能在哪個區域加東西？」根據答案歸類邊界
- 跟 A 的取捨：B 對使用者比較不負擔（不需理解四種邊界術語）、A 直接呈現答案空間
- B 比 A 好的情境：使用者不熟悉 DOM / layout / framework 術語
C：依直覺選一種實作
- 機制：執行者自己解讀「隔離」、選一種實作
- 跟 A/B 的取捨：C 跳過確認、A/B 確認；C 在意圖一致時省時間、不一致時重做
- C 是反模式：「隔離」這個詞本身就太模糊、跳過確認等於賭 — 意圖不一致時重做的成本遠大於確認的對話成本
D：通用問法「具體什麼算動」
- 機制：直接問「具體來說、什麼算動、什麼不算動？」
- 跟 A 的取捨：D 比 A 更簡略、把分類負擔丟給使用者；A 直接給選項使用者只需勾選
- D 比 A 好的情境：使用者已經想得很清楚、只需要表達 — A 反而過於 structured
判讀徵兆
| 訊號 | 應該觸發澄清的指令 | 第一個該確認的 |
|---|---|---|
| 「不要動 X」 | 動哪個層面（邏輯 / DOM / state / 樣式）？ | 邊界類型 |
| 「X 跟 Y 隔離」 | 隔離 DOM、layout、state、還是 framework？ | 邊界類型 |
| 「X 跟 Y 獨立」 | 獨立指什麼？哪個改不影響另一個？ | 哪個維度獨立 |
| 「X 不能影響 Y」 | 影響的方式（layout / state / 樣式）？ | 影響途徑 |
核心原則：隔離指令的核心是「隔離邊界類型」 — 這個答案決定實作策略。沒確認邊界就動手 = 隨機選一種隔離、可能與使用者意圖不一致。