- 在外部組件上加客製功能：以邊界為中心的方法選擇 客製外部組件穩定的程度取決於『離組件邊界多近』。本文用 Pagefind 整合到 Hugo theme 的三個情境（索引邊界、重置邊界、specificity 邊界）展開：在邊界上客製為什麼穩、各種替代方案的不足、以及下次提早辨識的訊號。
- 跨 viewport 雙模式 UI 的物理空間預算 Responsive 設計的 breakpoint 不該憑感覺取、該由元件的固有尺寸加總推算。本文展開「先列尺寸預算、再決定 breakpoint」的方法。
- 視覺對齊用單一真實來源 視覺對齊的本質是『同一條基準線在多個元素上重現』 — 任何元素的尺寸沒有來源明確的數字，整條線都靠不住。本文說明 CSS 變數 + 必要時 ResizeObserver 寫回，讓多處引用同一個值。
- 拓樸理解先行於 CSS 規則 寫 CSS 之前看真實 DOM tree、不靠 class name 推測層級。本文以『drawer 在 form 內、不是 form 的 sibling』這個假設錯誤為例，展開『拓樸理解 → CSS 規則』的順序。
- 客製 UI 留 framework 邊界外、用 CSS 控制視覺位置 Svelte / React 等框架對自己管轄的 DOM 子樹有完整渲染週期 — 客製 UI 注入這個子樹會被框架重繪清掉。本文展開「邊界外 + CSS 視覺定位」這條策略：為什麼 framework 會清外來節點、CSS 怎麼達到注入想要的視覺效果、什麼時候這條策略不適用。
- Filter 順序由使用者掃描成本決定 多選 facet 的順序不該按字母排序、要按使用者掃描成本 — 短清單先讓使用者快速收斂、再面對長清單。本文展開 type→tag 順序的決策。
- 量測值缺一不可：依賴未測量值會錯位 對齊本質是『同一條基準線在多個元素上重現』 — 任何一個元素的高度沒有確定值、整條線都靠不住。本文展開『把對齊問題當線性方程組』的角度。
- 置中元件與絕對定位元件並存：用疊層而非排擠 中央欄需要置中、側邊元件需要指定位置 — 兩者要共存，關鍵是讓側邊元件用 absolute 跳出 layout 流，中央欄完全感知不到它。本文展開疊層式並存的設計。
- 同一個元件在三種互動狀態下顯示位置不同的 root cause 當元件「跟著狀態飄」、不同互動狀態下出現在不同位置 — 不是元件本身的問題，是它依賴的『定位錨點』本身在動。本文以 scope UI 三狀態飄移為例，展開錨點分析法。
- 從色塊 placeholder 開始的漸進式 UI 除錯 UI 除錯的最小可驗證單位是『一個有顏色的盒子』 — 版型先用色塊確認、內容後填。本文說明為什麼漸進式驗證比一次組裝完整 UI 容易 debug。
- 在開發循環裡早一點用 playwright 看真實結果 靜態 CSS 推理跟視覺截圖溝通有極限 — 當行為與預期不符 ≥ 2 次，stop 推理、改用 playwright browser_evaluate 直接讀 live DOM。本文說明工具引入時機。
- 排版精度的工具選擇：CSS-only vs JS-assisted CSS 適合 build-time 可決定的 layout、JS 適合 runtime 才知道的尺寸與 DOM 移動。混淆兩者會讓 layout 跟 framework 渲染週期競爭。本文展開選擇規則。
- JS 操作 framework 元件：邊界辨識與安全規則 操作 framework 管的 DOM 前先界定『動什麼、邊界在哪、state 由誰維護』。本文展開邊界辨識的決策樹、整節點 reparent 的具體 do/don't 規則、灰區操作的 fail-safe 設計。
- Selector 精準度：讓 query 只命中你想要的元素 JS 的 DOM query 是 sanity 防線、不是優化選項。從『起點 / 範圍 / 過濾』三層收斂、避免誤命中、避免未來頁面結構變動讓 query 撈到不該撈的東西。本文是 selector 設計的完整指引。
- 用前端測試把排版問題自動化 排版問題傳統靠人眼檢查、容易遺漏邊界 case。當一個版型被 debug 兩次以上、就值得寫成 playwright 測試把規範固定下來。本文展開測試替代手動檢查的時機。
- 空間 / 尺寸類指令的澄清時機 聽到「對齊 X」「擺在 Y 旁邊」但沒給數字時，先列計算過程讓使用者確認、不直接寫死。本文展開這類指令的處理 protocol。
- 元件相對位置類指令的澄清時機 聽到「X 在 Y 旁邊」時、先用文字畫個 layout 草圖讓使用者確認、不憑直覺擺。本文展開這類指令的處理 protocol。
- 隔離程度類指令的澄清時機 聽到「隔離」「不要動 X」時、先確認邊界是 DOM 結構、layout flow、state、還是 framework 管轄區。本文展開隔離邊界的四種類型與澄清方式。
- 覆寫深度的成本告知 客製可能對抗 UA + 跨瀏覽器 + framework 三層時、先報需要寫多少規則 / 哪幾條 / 殘留風險、讓使用者判斷值不值再開工。本文展開覆寫深度的事前告知 protocol。
- 同方向反覆失敗的轉折點 第 2 次同方向失敗就停下來回報「假設可能錯了、要不要換思路」、不要等第 4 次失敗才被使用者打斷。本文展開失敗計數與方向切換的判斷。
- 「可決定」與「該先確認」的邊界 寫死任何使用者會看到的數字 / 順序 / 文字之前、先給選項讓使用者點頭。技術實作細節可以自決。本文展開兩者的區分原則。
- 「先還原」「先重來」類退出指令的處理 聽到「還原 / 重來」時、先問「還原到哪個 commit？要不要先 commit 一個 checkpoint 再動、方便日後比對？」本文展開退出指令的安全處理 protocol。
- 驗證方法的選擇時機 靜態 CSS 推理 ≥ 2 次失敗就主動提『啟個 server、用 playwright 看 live DOM 比較快』、不要繼續猜。本文展開驗證工具的引入時機。
- CSS Layers 取代 specificity 戰 用 @import url('vendor.css') layer(vendor) 把外部組件 CSS 包進低權層、自家 CSS 留在 unlayered 自動贏 — 不論 specificity 數值。本文展開取代 !important 與雙寫的方法。
- CSS / JS 拆出獨立檔案 Hugo template 內 inline CSS / JS 超過 30 行就值得拆檔、走 resources pipeline。本文展開拆檔的理由、步驟、與得益。
- CSS 變數定義位置統一 CSS 變數一次定義在離 root 最近的合適位置、其他地方只引用、不重複宣告。改 token 只動一處、避免散落多處難同步。
- runtime 量測模式統一 對齊基準上的所有元素、要嘛全部寫死、要嘛全部用 ResizeObserver 量測 — 不要混搭。混搭時某些字型 / theme 變化會打破對齊、且難以重現。
- 以 class toggle 取代 inline `display: none !important` JS 用 `el.style.setProperty('display', 'none', 'important')` 是低層次 hack。在 CSS Layers 環境下、用語意化 class + JS toggle 可以更乾淨、更易 debug。
- MutationObserver 範圍與觸發頻率：監聽最少必要的變動 MutationObserver 是非同步監聽工具、跟同步 selector 是不同議題。範圍寬會頻繁觸發、option 勾多會在不關心的變動上跑邏輯、apply 自己改 DOM 會觸發無限循環。本文是 observer 設計的完整指引。
- setTimeout 輪詢換 MutationObserver 等元素出現的場景、用 MutationObserver 監聽 DOM 變化、看到目標就 disconnect — 沒延遲、CPU 不被輪詢吃。本文展開兩種等待機制的差異。
- Init function 是 orchestrator、職責拆出獨立 function 一個 init function 同時做多件事 → 按職責拆成多個獨立函式、各自有清楚的 input / output、init 退化為組合各職責的 orchestrator。Debug 時知道哪個壞了、也容易單獨重用。
- baseof.html override 範圍最小化 Override theme 檔案時、只動非改不可的部分、註解標明跟 theme 版本的差異 — 升級時容易 sync 變更、不會吃掉本地客製。
- Reactive 監聽器的效能 audit：跨 listener 類型盤點觸發頻率 MutationObserver / ResizeObserver / event listener 各自的觸發頻率怎麼盤點。本文是效能 audit 視角 — 找問題用、跟 #29 (observer 設計指引) 互補不重複。
- Runtime 計算成本：每筆迭代與正則 Scope filter 對每筆結果跑 regex — 結果數量大時成為 frame budget 的主要消耗。本文盤點此類「每筆迭代 + per-item 計算」的風險點與評估方法。
- Layout reflow / repaint 的可量化評估 Filter slot 切換、CSS 變數寫入、絕對定位重算 — 哪些操作觸發 reflow 而非僅 repaint、用什麼工具量、評估值落在哪個區間值得優化。
- 資源載入時序：lazy chunk 與 critical path Pagefind 的 index 採 chunked lazy load — 首次互動延遲與 critical path 之間的取捨怎麼盤點。預載 entry chunk 的時機與不預載的代價。
- 動態 DOM 移動時的 focus 管理 Filter slot 跨 viewport 搬節點、scope filter 隱藏結果 — 這類 DOM 變動會讓鍵盤 focus 跑掉或停在不可見位置。本文盤點動態 DOM 對 focus 的影響與檢查方法。
- Screen reader 與動態內容變動的 live region 設計 Scope filter 切換、結果數量變動 — screen reader 使用者看不到視覺變動、需要 aria-live region 主動朗讀。本文盤點 live region 的設計選擇與適用情境。
- Native HTML element 優先於 ARIA role 的取捨 用 `<fieldset><legend>` 比 `<div role="radiogroup">` 安全、用 `<button>` 比 `<div role="button">` 直接 — native element 自帶完整無障礙語意與行為。本文盤點 ARIA role 是 fallback、不是 default。
- 視覺輔助：對比度、放大、字型 zoom 的 layout 適配 色弱、低對比敏感、低視力使用者跟一般使用者「看到的不是同一個 UI」 — 對比度足夠嗎、絕對定位元件在放大模式下是否可達、字型放大 200% 後 layout 還好嗎。本文盤點視覺呈現面的 a11y 風險點。
- Mode 與 Facet 是不同語意層級、UI 區域分開擺放 搜尋 UI 看似都是『縮小結果』的控制、語意層級不同 — Mode 改變搜尋演算法本身、Facet 在結果上篩選。混在同一區會讓使用者誤判控制效果。本文展開兩者的視覺分區策略。
- 2 次門檻：第一次是運氣、第二次是訊號 同一個問題出現第 2 次時、就該停下來把處理層級升一階 — 從推理升到量測、從手動驗證升到自動化、從同方向嘗試升到換思路。第 1 次失敗的資訊不足、第 2 次提供「重複出現」的證據、值得付出升級成本。本文是 #11 / #15 / #20 / #23 四篇實作的共同抽象。
- 最小必要範圍是 sanity 防線：保護行為可預測性 縮 selector 範圍、observer 範圍、JS 操作範圍 — 不是為了效能、是為了讓行為可預測、不被未來變動打破。本文是 #13 / #14 / #29 三篇實作的共同抽象。
- Single Source of Truth：值的住址只能有一處 同一個值（CSS token、視覺基準、runtime 量測）的權威來源只能有一個位置 — 多源時會分歧、會漏改、會讓讀者不知道哪個生效。本文是 #3 / #26 / #27 三篇實作的共同抽象。
- 跟外部組件合作的層次：離介面越近、合作越穩 客製外部組件的穩定性與「離組件作者保證的對外介面多遠」成反比。每往內推一層、依賴前提增加、升級風險上升、可逆性下降。本文是 #1 / #5 / #19 / #24 四篇實作的共同抽象。
- 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 標記的取捨。
- 鍵盤可達性：focus indicator、tab 順序、escape 路徑 鍵盤使用者用 tab / shift+tab 導航、enter / space 激活、esc 退出。三件事決定可不可用：focus 是否可見、tab 順序是否合理、modal / overlay 有沒有 escape 路徑。本文盤點搜尋頁的鍵盤 a11y 風險點。
- Motor 可達性：hit target、間距、誤點防護 Hit target 太小會讓行動裝置使用者誤點、motor 障礙使用者更甚。WCAG AAA 建議 ≥ 44×44px、間距足夠避免誤觸。本文展開 hit target 設計與相關 motor a11y 風險點。
- Pattern：跨 slot 同節點搬遷 Stateful UI 在兩個 slot 之間用 `appendChild` 搬同一個 DOM 節點、不複製兩份 — 避免 state 分歧。本文展開搬遷 pattern 的設計細節與適用邊界。
- Filter 與 Source 的抽象層錯位 Filter 必須跟它過濾的資料源在同一層運作。視覺層的 filter 套在資料層分批產出的 source 上、會在「一筆」的定義上產生語意縫 — 使用者要的「全部符合」變成「目前載入的符合」、然後 silent 失敗。本文展開層錯位的識別與糾正。
- 視覺完成 ≠ 功能完成 「畫面對了」是視覺驗收訊號、不是功能驗收訊號。視覺完成早於功能完成、容易掩蓋語意缺口。本文展開兩者的區分與識別「畫面對但功能漏」的訊號。
- Loading / Empty / End 三狀態的區分 「還沒抓」「沒命中」「抓完無更多」三個狀態語意不同、UX 必須區分。共用同個畫面（「空白」或 spinner）會讓使用者無法判斷下一步。本文展開三狀態的內在屬性與 UX 規則。
- 篩選類指令的澄清時機 「依 X 篩選」這類指令必須先澄清三件事才能寫：定義域（已載入 / 全部 / 子集）、資料分批方式、空狀態的語意。三問跑完才寫、否則必然寫成視覺層 post-filter、撞上 #55 層錯位。
- Filter × Source 的合成策略五選一 Filter 跟 paginated / streaming source 合成的五種策略、各自機會成本不同：A 推進 query / B 自動續抓 / C 預先 index / D 誠實 UX / E 接受語意縮小。沒有絕對最佳、看 source capabilities、match 密度、UX 容忍度而定。
- 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 的具體實作。
- 資料源的形狀決定 feature 的形狀 Feature 設計要服從資料源的形狀（一次性 / 分批 / streaming / cached）— 不能憑 UI 想要的形狀去倒推資料層。憑 UI 倒推 = 在錯誤的層解錯誤的問題、產生 #55 層錯位類 bug。
- Feature 操作要跟 Source 同層合成 Filter / sort / count / transform / search 是 stream 操作、必須跟 stream 的 materialization 同層或更上游合成。在下游做 = 操作 subset 不是 stream。本原則跨前端 UI、後端 API、演算法管線通用、不只是視覺層 vs 資料層。
- 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 縮小是反模式。
- 寫作便利度跟意圖對齊反相關 寫程式時最容易寫出的版本、通常是離意圖最遠的版本。便利度建立在「現有上下文 / 已 materialize 資料 / 已存在 API」上、而意圖對齊需要找到正確的層、處理上游、跨抽象層 — 兩者方向相反。識別這個反相關 = 識別自己掉進「容易寫的陷阱」。
- 驗收的時間軸：四個 checkpoint 驗收不是單一動作、是分散在四個時點（寫之前 / 開發中 / ship 前 / ship 後）的累積判斷。每個 checkpoint 能 catch 不同類型的失敗、成本不同。早期 checkpoint 抓越多、晚期 checkpoint 越輕鬆。實務上常常 collapse 成「寫的時候 + ship 後出問題才修」、跳過寫之前 / ship 前。
- Test-First：先看到 RED 才相信 GREEN 一個只看過 GREEN 的測試是「未驗證的訊號」、不是「會抓回歸的測試」。必須先在「該失敗的版本」上看到 RED、再在「該通過的版本」上看到 GREEN — 兩次跑都對、才能相信測試真的 catch 到該 catch 的東西。跳過 RED 等於把驗收標準降到「跑得通」、漏掉「測試自己有沒有 bug」這層。
- URL 是 stateful UI 的儲存層 — 哪些 state 該寫進 URL 互動式 UI 的 state 散落在多層（in-memory / URL / localStorage / server / index）、每層有不同特性。可分享 / 可恢復 / 可導航的 state 該寫進 URL — 不寫進 = silent 把這些特性犧牲掉。本文展開「state 的儲存層選擇」協議與 URL 的具體位置。
- Tab Order = DOM Order = Mental Model 三者對齊 Tab 順序由 DOM 順序決定（除非用 tabindex 強制覆寫）。三者該對齊：DOM 順序、tab 順序、使用者 mental model 的互動順序。三者不一致時、優先重排 DOM 而非用 tabindex — tabindex > 0 是反模式（[#52]）。
- 高 ROI 無外部觸發的工作會被結構性跳過 工作有兩個獨立維度：ROI 高低 + 是否有外部觸發。高 ROI + 無觸發 = ROI 的承諾、拖延的現實。靠紀律不可行 — 結構性偏差需要結構性對策（外部觸發 / CI / hook / 排程 / pair）。本卡是 #67 便利反相關、#68 checkpoint 跳過、#69 RED 跳過的共同上位原則。
- 搜尋引擎的匹配模式跟使用者預期的對齊 搜尋引擎的匹配模式（prefix / substring / fuzzy / semantic）各有不同。預設多半是 prefix（為了 index size）、但使用者被 Google 訓練成預期 substring。沒對齊 = silent 失敗：搜「pre」找不到 backpressure。本卡展開五種匹配模式、跟使用者意圖的對齊協議、五個合成策略。
- 決策呈現：選項 + 推薦 + 開放修改 讓使用者做決定時、不要開放問「你覺得呢」 — 給選項、加適配性、標推薦、開放修改。開放問把「整理問題」的成本丟給使用者、推薦把判斷攤開供質疑、開放修改保留使用者的最終決定權。本卡是 #58 篩選三問、requirement-protocol 原則 1 的呈現面展開。
- 主策略 + 補強策略：選擇不必互斥 多策略並非「五選一」、可分層疊加：root-cause fix（解結構問題） + UX 補強（解使用者感知）通常雙打比單選更穩。判準三條：解不同層 / 沒副作用衝突 / 增量成本可接受。把「策略選擇」預設成單選、會放掉互補可能、產生「結構修了但使用者體驗仍差」或「UX 蓋過去但結構還壞」。
- 分批 ship：低風險可見價值先行、結構性下輪 「一次 ship 全部」的衝動 vs 「分批 ship」的設計：判準三軸（使用者可見性 / 風險暴露面 / 驗證需求）。低風險 + 高可見 = 立刻 ship；高風險 + 需驗證 = 下輪。對抗「完整才完整」的全做衝動、避免一次塞太多 review surface 拖延上線。
- 「現在不決定」是合法選項：context 不足時延後決策 被問到時不一定要立刻答 — 「先補 context、回頭再決」是合法選項、卻常被當「拖延」忽略。LLM / agent 預設「問了就要立刻答」是錯誤前提：使用者有權延後到 context 補齊、推薦時應主動標出「也可選『先 X 再回來決』」。本卡是 #58 篩選三問、#74 決策呈現的時間軸延伸。
- 反省任務預設複選：互斥要證明、不互斥是預設 反省 / retrospective / 改進方向類問題、預設應給「複選」而非「單選」 — 互斥需要明示證明、不互斥是預設。用 radio 限縮會讓使用者被迫排序、丟失多面向的同時性。本卡是 #74 決策呈現的反省場景特化、跟一般「執行類決策」（多半互斥）對立。
- 決策對話的五個維度：保持完整選擇空間 對話中的「決策」不是單一動作、是多維度選擇空間：呈現格式 / 策略疊加 / 批次邊界 / 時間軸 / 選項類型。預設多半 collapse 到最窄格（開放問 + 單策略 + 一次完成 + 立刻決 + 單選）、塞使用者進最少自由度的盒子。本卡是 #74-#78 的上層串連 — 五張卡各對應一個維度的鬆綁。
- Yes/No 二選是隱式 collapse：把多選空間壓成 1 bit 「需要我繼續嗎？」「要做嗎？」「OK 嗎？」這類 yes/no 問句、看似最簡單其實是五維 collapse 的極致形態：1 bit 編碼掉「改 / 延後 / 疊加 / 分批 / 反問」五種合法回應。本卡是 #74-#79 系列在「最常見、最隱形」變種的特化卡。
- 卡片系統的迭代浮現：原子卡 → meta-卡 → reference 三層展開 知識卡片系統不是一次寫成、是 dialogue → 原子卡 → meta-卡 → reference 的迭代浮現。每一輪迭代解決上一輪的 over-fit / under-fit、串連分散的卡片、抽出 meta-原則、最後沉澱成可直接套用的 reference 文件。本卡是 cards-skills 系統設計的 process-level 元原則。
- 字面攔截 vs 行為精煉：驗證手段跟錯誤層次的對齊 驗證手段必須跟錯誤層次對齊：字面錯誤（typo / syntax / 缺欄位）用 hook / lint / CI 攔截；行為錯誤（思考偏差 / 判斷錯位 / collapse 反模式）用 multi-pass spiral 收斂。強行用 hook 蓋行為錯誤 = 給出 false confidence、反而比沒保護危險。本卡是 #72 結構性對策在「驗證粒度」維度的 ceiling — 不是所有錯誤都該被攔截。
- 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 在「命名」場景的特化。
- Methodology 的 multi-pass 該升級為 pillar 層：核心結構才會被執行 任何「教做事方法」的 methodology / SKILL / playbook、應該把 multi-pass refinement 放在 pillar / 核心原則層、不是放在末尾「附帶提醒」段。Pillar 層 = 結構性必跑、appendix 層 = 看心情選擇 = 永遠不跑。本卡是 #82 行為驗證 + #72 結構性對策在「方法論設計本身」這一層的展現。
- 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 五策略矩陣可疊加使用。
- 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」的取捨抽象化、跨領域適用。
- 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。
- Dataset 規模改變什麼可行：「需要 index」依 scale 而定 工程師習慣以「production scale」為預設、自動假設「O(N) scan 不可行、需要 index」。但小 dataset 內、O(N) 甚至 O(N²) 都 trivial、不該過度工程。本卡列具體 threshold（< 1MB / < 10MB / < 100MB / > 1GB）對應的可行操作、跟「猜測 production scale 過度設計」的反模式對照。本卡是 #43 最小必要範圍在「規模假設」維度的展現。
- 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 在「使用者訊號層」的整合。
- 升級 trigger 的量化設計：「不夠就升 Y」需要明確的「不夠」指標 「先做 L1、不夠時升 L2、再不夠升 L3」這個分批 ship 順序看似合理、但「不夠」沒量化就會 #72 結構性跳過 — 永遠覺得「再觀察一下」、永遠不升級。本卡定升級 trigger 的量化設計：閾值、觀測窗口、決策週期、自動 vs 人工觸發。預設是寫 L1 ship 時就同步定 L2 升級的 trigger 條件、不是 ship 後才想。
- 視覺手段對齊錯誤層次：CSS / emoji 修不到語意 / 邏輯問題 修視覺問題的工具（CSS、emoji、顏色、排版）只能擋視覺層、不能修語意 / 邏輯層。把語意 / 邏輯問題當成視覺問題修 = 蓋住症狀根因不動 + false confidence、跟 #82 用 hook 蓋行為錯誤同骨。三層優先序：邏輯 → 語意 → 視覺、修法從深層往淺層走、不從症狀往回推。本卡是 #82 在「呈現層」的具體實例、是 #83 multi-pass review 缺的 vertical 軸。
- URL slug 必須顯式定義為 fact：跨工具 identifier 用單一定義源 URL slug 在 Hugo 預設下從 title 自動推導、在 mdtools lint 下從檔名讀、在跨檔連結時又要寫第三個值 — 一個 identifier 散落在三個推導鏈、典型 SSoT 違反。當多個工具共用一個 identifier、推導不一致 = silent broken link。修法：把 slug 從 derivation（runtime 推導）升級成 fact（frontmatter 顯式定義）、檔名 / 連結都基於這個 fact。本卡是 #44 在 toolchain integration 情境的具體實例、是 #82 字面 vs 行為在 identifier 維度的展現。
- 正向改寫要保留對照論據、不能空降結論 把「X、不是 Y」改成正向陳述時、若直接刪除「不是 Y」會讓結論失去推理依據、變成空降斷言。對照論據（Y 是讀者直覺會想到的替代方案）跟結論（X）是同一個推理單元、抽掉一半就不成立。正向改寫的合法做法是補解釋、改成對照表、或保留 Y 當對比錨點 — 直接拿掉是 worst。
- Multi-pass review 的 scope 要蓋『同類風險區』、不是『改動區』 做 multi-pass review 時、預設用『我這次改過的檔』當 scope 是便利選擇；但同一原則違反通常分布在整個 corpus、改動區只是冰山一角。Scope 該由『同類風險的內容範圍』決定 — 跑某條原則的 pass、就要掃所有適用該原則的檔、不是只掃我自己改過的。改動區 scope 是 #67 在 review 流程的具體展現、會讓 multi-pass 退化成 self-edit pass。
- 適用範圍要展開成 file enumeration、口語描述不夠 原則的『適用範圍』寫成口語描述（『所有教學文件的論證段落』）時、執行 review 的人要當場推導『具體哪些檔屬於這個範圍』、推導步驟容易漏；改寫成 enumerated file list（具體列出 file paths）就能避免 enumeration 不完整。Enumerate 的合法形式是『可被 grep / find 重現的具體 file 集合』、不是『口語類型描述』。本卡是 #95 的下游具體化、跟 #82 互補：enumerate 是字面層、enumeration completeness 是行為層判準。
- Metadata surface 要納入寫作 review 範圍 寫作 review 的 surface 包含正文與 metadata surface：title、description、frontmatter、heading、link label、MOC 索引條。正文通過 positive wording 或 multi-pass review 只代表 body surface 收斂；讀者入口與索引入口也要跑同一套 frame，才能讓文章在第一眼、搜尋與跨篇路由上維持同一個概念錨點。
- 素材庫比例要支撐主情境的反向驗證 當文章只展示少量主情境時，素材庫需要保留更多 field cases 或 source cards 來支撐反向驗證、壓力變體與後續擴寫。合理比例是主文章情境 4-5 個、來源素材約 2-3 倍，讓每個主情境背後至少有 2-3 個來源可回查。
- 資安教學的審查標準要對應風險不對稱 一般教學寫不清楚、讀者學不到、損失停在學習端；資安教學寫不清楚、讀者照做後在系統上產生破口、損失轉嫁到生產端。兩者風險不對稱、審查嚴格度應該對應下游實作代價、不是讀者讀懂程度。資安內容的 audit bar 預設要拉到「讀者會 implement」、不是「讀者會 read」、否則所有寫作便利選擇（含糊敘述、省略邊界、引用而不驗證版本）都會 silent 變成實作端破口。
- False sense of security 是資安寫作的主要失敗模式 資安教學內容的失敗模式不是「讀者學不到」、是「讀者以為學到了並照做、實際還有破口」。讀者實作後沒警覺 = 後續驗證、修補、事件偵測都不會被觸發、破口在生產系統長期 silent 累積。識別 false sense of security 句子的判準：讀者讀完後會說「我做了 X 防護所以安全」、卻無法回答「對什麼 threat 安全 / 什麼 deployment 條件 / 什麼前提失效」。
- Threat model 明確性：「防什麼」與「不防什麼」必須對稱 資安 mitigation 的論述要對稱寫「防什麼 threat」+「不防什麼 threat」。只寫前者、讀者會自行 universal 詮釋（防所有相關攻擊）、實際只擋作者腦中 subset、是 false sense of security 的主要產地。對稱論述不是讓文章變負面、是讓 mitigation 的 scope qualifier 顯式化、讓讀者能驗證實作覆蓋邊界。
- Mitigation 對位：防護對應到具體 threat 的驗證 資安寫作裡 mitigation 寫得乾淨不代表對到 threat、必須讓「mitigation X → 防 threat Y」的對應鏈可被反向驗證。常見失效模式：mitigation 攔的是 threat 的 surface artifact、不是 mechanism；mitigation 跟 threat 在不同抽象層；mitigation 假設 threat 已被上層擋掉但上層沒擋。對位驗證的 audit 模板：每個 mitigation 列出「設計攔的 threat」+「驗證 mechanism」+「失效訊號」三欄、缺一即 false sense of security 產地。
- Mitigation 的 context-dependence：deployment 條件改變有效性 同一個資安 mitigation 在不同 deployment / runtime / scale / config 條件下、有效性差異很大、甚至完全失效。寫作時把 mitigation 描述成 universal（「使用 HTTPS 保護傳輸」「JWT 用簽章驗身分」）會跳過 context、讀者實作時用單一條件詮釋、deployment 條件不對時 mitigation silent 失效。每個 mitigation 必須附帶「成立條件」+「失效條件」+「deployment 變數列表」。
- Security 標準引用的時效性與精確度 資安 citation 跟一般技術引用不同——best practice 時效短（MD5 / SHA-1 / bcrypt 100k / TLS 1.0 都曾是 best practice）、原文常被引用扭曲（conditional → unconditional drift）、版本不標 reader 會套用過時 spec。citation 同時涵蓋外部標準（OWASP / RFC / NIST / CIS）跟內部 citation（knowledge-cards / 跨章引用作為 control-of-record）；後者因無版本號 anchor 反而更易 silent drift / broken。每條 citation 必須附：版本 / 年份、引用句意可回溯、deprecated / superseded 標記、強度參數對應 actor 能力的 review trigger（外部）/ last-checked + sync owner（內部）。
- Audit recommendation 層級：accept / minor / major / 教錯不可保留 資安 audit 的產出不該是「OK / 不 OK」二選、要分層給 ship 決策用：accept（無 weakness）/ minor revise（補 boundary 級小改）/ major revise（結構性 false sense、需重寫）/ withdraw（教錯主動誤導、必須移除或全換）。前三層對應學術 peer review、第四層是資安 audit 特有——當內容會 silent 把 reader 帶向破口時、保留是淨負面、不存在「先 ship 後改」的選項。
- 用 Next-action frame 取代 Disclaimer：把 prohibition 翻成 actionable chain 當 audit / risk 識別 reader 不該做 X、寫作回應若停在 disclaimer 段（告訴 reader 不要 X）、整段自然產出 negative phrasing（不是 / ≠ / 不要）、即使逐句翻正向句法仍是 disclaimer。Reframe 成 next-action 段（告訴 reader 沿 chain 做 Y / Z）整段自然 positive、不需 contrast。Frame 選擇是 #94 正向改寫的上游問題——逐句正向化處理不到 frame 層、reframe 整段才會根治。
- 術語翻譯要保留原文錨點 翻譯術語時、中文名稱負責降低閱讀門檻，原文名稱負責鎖定概念邊界。只留中文會把 reader 帶進中文詞的日常歧義，只留英文會提高閱讀成本；中文後接英文括號是技術文章的穩定折衷。
- 中文壓縮術語要保留完整名詞頭 中文技術寫作可以壓縮長詞，但不能省到只剩形容詞或單字修飾。像「多步驟 perplexity 盲」這類詞少了完整名詞頭，讀者無法判斷是在說盲點、盲區、盲測或失明比喻。壓縮後仍要能獨立回答「這是什麼」。
- 術語翻譯要保留概念角色 術語翻譯不能只追求中文好讀，還要保留原詞在論證中的概念角色。Steelman 若翻成「最強版本測試」，reader 會以為它是一個檢查動作；但在決策語境裡，它更核心的責任是把反方論點重建成最強版本。
- 設計檢討用當下三軸論證、不依賴 hindsight 本卡提倡用「當下成本對稱條件下選了限制更高的選項」當設計缺陷的判定方式、避免 hindsight 論述把需求演化誤判成設計缺陷。當下三軸論證（成本對稱性 / 可逆性 / 領域先驗）讓判斷不依賴結局發生、且歸因偏向工具預設與制度而非個人預見性。
- 口語化修辭在判斷工具型段落會稀釋技術精度 技術文章的「判斷工具型段落」（讀者用來判斷自己 case 的論述）用「一輩子」「碰巧能用」「立刻撞牆」「沒事」這類口語修辭、會稀釋精度。修法是把口語修辭翻譯回技術屬性語言。但 hook / 引言 / narrative 段落用口語仍然合理——這是情境化的取捨、不是精度永遠優於可讀性。
- 地區用語對齊：寫作前先確定讀者的中文語料 繁中 vs 簡中的用詞差異不只是字形（屏 / 螢幕、視頻 / 影片）、更是技術術語跟業務情境的精度差。寫作前要先確定讀者的中文語料、避免用對方語料中不存在或意思偏移的詞。常見漂移：硬體（屏 / 螢幕）、檔案系統（文件 / 檔案）、概念詞（默認 / 預設）、修辭詞（質量 / 品質）、混雜情境的英文中文比例。
- 商業邏輯論述要 self-contained：不依賴 code 才能被理解 技術文章在「不放 code 的段落」仍然要 self-contained——商業邏輯論述不能預設讀者已經看過 code、用「那個 payload 第二段」「剛才的變數」這類 reference 等於把理解門檻轉嫁給讀者去翻 code。修法是把 reference 翻譯成「用名詞 / 角色 / 條件描述」的 self-contained 句子、即使讀者跳過所有 code block 也能理解論述。
- Multi-pass review 的 frame 顆粒度盲點：抽象規則 → 具體訊號的轉譯不完整 Multi-pass review 跑了 4 輪、字句層問題（口語修辭 / 地區用語 / 依賴 code / 廢話前綴）仍漏 catch——揭露 frame 顆粒度盲點：抽象規則（如「機會成本語氣」「正向陳述」「最重要的話優先說」）沒被轉譯成具體訊號（如 grep keyword bank：「一輩子 / 碰巧 / 撞牆 / 下次 X 時 / 不是 A 而是 B」）。修法是把每條規則展開成可 grep 的 keyword bank、加 reader simulation 輪、加 self-criticism 輪。
- 案例引用深度跟著 case 類型走 skeleton / medium / rich case 各有不同承接深度；誤判類型 → 編造數字 / taxonomy（over-extrapolation）或漏掉 case 揭露的 mechanism（under-citation）；引用前先看 case 行數 + 內容密度判類型、決定該寫『揭露 X 方向』還是『揭露 N 個機制』還是『揭露具體數字 / 設計』
- 引用案例要分觀察層 / 判讀層、強化詞是錯位訊號 引用案例（特別是 rich case）時、case 內容分兩層：觀察層（具體 fact）跟判讀層（作者推論）；兩層在章節引用時要分層標明、避免把作者判讀升級成 case fact；強化詞（才是 / 必須 / 一定 / 關鍵是）通常是錯位訊號、保留 case 原文的條件性表述（取決於 / 核心瓶頸 / 主要驅動）
- 跨多個 case 合成的 frame 必須標為章節合成、非 case 原文 當段落把多個 case 的失效訊號抽象為更高層 frame（如『跨工具回查壓力』『平台責任切分』）、要 explicit 標為『本章合成、非 case 原文』；否則章節 derive 會被讀者當成 case fact、回查 case 時發現章節說的『揭露』實際是章節抽象、不是 case 原文框架
- Standard-driven 取代 Case-driven 適用 standard framework 比 case 庫成熟的領域 並非所有領域都該走 case-driven。判斷該用哪種策略看四維度：議題穩定度 / case 公開度 / standard 成熟度 / 維護半衰期。LLM 安全屬 standard-driven 領域（OWASP LLM Top 10 + NIST AI RMF 已成型、case 半衰期 6 個月）；分散式系統 / 安全控制面屬 case-driven 領域（case 公開充分、半衰期 5+ 年）。誤套會導致 case 庫過早建構或 case 過時
- 章節已有 routing skeleton 走補強段、不空白擴章 章節結構分兩類：空白章節（threat scope / 問題節點表都待補）vs routing layer 章節（已有完整結構、case 庫缺位用 standard 引用承接）。擴章策略要對應結構——空白章節走 case-driven 大幅擴章；routing layer 章節走補強段（在現有結構內補 mechanism 深化）；誤判結構會引發 frame 重複展開或章節失衡
- 案例引用三段式段落結構：概念定義 → case 引用 → 通用展開 Case 引用段落要走三段式結構：(1) 段首概念定義句先寫『該概念是什麼、承擔什麼責任』、(2) 第二位置 case 引用、(3) 通用工程知識展開；段首被 case 引用取代是 06 模組最大宗 systemic 違規（11/12 段都犯）；本卡跟 #115（引用深度）/ #116（內部分層）/ #117（跨 case 合成）正交、處理段落結構順序
- Agent team context 隔離設計：用不同 instance 換 frame、平行 background 保護主 context Multi-pass review 跨輪 frame（#83）跟跨 reviewer instance 隔離（本卡）是兩個 axis：#83 是同一 reviewer 換輪次 frame、本卡是不同 reviewer instance 各自獨立 background 跑；context 隔離設計讓主 context 只接精煉摘要、節省 ~80% token、跟同 reviewer 多輪 catch 同類錯（#114）形成互補解法
- Cadence 同質化是模板的隱形維度 規範定義「模板」時通常只指內容欄位（規模對照、tripwire、失敗模式），忽略句型骨架 / 段首語 / 段末收尾語 / 表格前導句 / 過渡詞同樣是模板的一種；批量寫作時最易讓 cadence 同質化、單篇看起來都合規、連讀多篇才浮現預期化；51 vendor 都用「四件事 → 任一缺失就是 X 邊界的待補項目」是案例；自檢要 grep 首句 / 段末句 / 表格前導句、不是只看欄位
- 多重硬規範同時生效會把 cadence 推向便利解 當 N 個硬規範同時 enforce（11 章節結構 + 表格深化 + sweet spot 行數 + lint 規則）、找到一個「都通過」的 framing 後、批量寫作會把這個 framing 複製到所有檔案；cadence 同質化不是違規、是「合規最佳解」的副作用；對策是把 framing 多樣性也納入硬規範、或拉開 constraint 讓多個 framing 都有合規路徑；是 #67 在「批量寫作」的具體機制展現
- Emergence-class 違規規則化不了、要 stage 0 變體規劃 + stage 內抽樣兩層 違規分三類（字面 / 結構 / emergence）、enforcement 時機要對應違規類型；字面違規（emoji / 裸 URL）可 regex hook 在 pre-commit 攔、結構違規（章節缺失 / frontmatter）可 linter 攔、emergence 違規（cadence 同質化 / 跨檔語氣漂移）規則化不了、需要 *stage 0 變體規劃（主動設計）* + *stage 內抽樣（被動監測）* 兩層；checkpoint 只是監測工具、若 stage 0 沒準備 variant、被動抽樣不會自動發現 collapse；補 #82 字面 vs 行為的「時機」軸
- Collapse 是隱形預設：多維空間被壓成單格的三類典型 決策對話、決策呈現、批量輸出三個 surface 都有同一個 pattern — 高維選擇空間預設被 collapse 到 1-2 個窄格、且這個 collapse 因為「便利 / 合規 / 簡潔」被當成中性預設、不被覺察；#80 是 decision surface 上的極致 collapse、#79 是 dialogue 五維 collapse、#123 是 output framing 在 constraint 下 collapse；三者共骨：*某個高自由度空間被便利驅動 reduce 到最少格子*；對策不是去除 collapse、是讓 collapse 變顯性、由設計者決定要 collapse 哪一維、不是預設全 collapse
- 寫作 review 是多軸完整性、不是單軸深度 寫作 review 的完整性不是單一軸越做越深、是多軸交集都對齊；#83 frame 軸 + #121 instance 軸 + #97 surface 軸 + #95 scope 軸 + #122 cadence 軸 + #124 timing 軸 + #114 granularity 軸、七軸正交、缺任一軸都會 systematic miss；review 設計時要 enumerate 七軸覆蓋狀況、不是只跑一兩個維度做深；是 #79 五維決策對話在 review 工具設計的姊妹卡
- 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* 才能決定結構、跳過會套錯模板
- 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」結構
- 公開案例量是 vendor 社群活躍度 signal Vendor 選型時、公開 customer engineering case 的累積量是社群活躍度與長期可維護性的信號、不只是「案例庫不完整」的偶然現象
- 教材目標先於決策框架 教材的核心目標是讓讀者學會某個領域的心智模型、操作語意與演進路徑；服務能力、風險、成本與決策是教學中的必要概念框架。當決策框架取代教材目標，文章會變成選型分析或治理文件，讀者知道怎麼判斷，卻仍缺少領域學習路線。
- 教材完整性要用讀者旅程驗證 教材完整性要用讀者旅程驗證；章節數、案例數或 vendor 覆蓋度只能判斷素材量。成熟教材要能回答不同讀者從哪裡開始、按什麼順序讀、讀完能做什麼。LLM 與 Go 目錄顯示，讀者旅程、學習梯度與主題導讀是教學設計完成度的核心訊號。
- 貫穿式案例是服務教材的教學骨架 服務型教材需要一條可重播的貫穿式案例，把資料庫、快取、queue、觀測、部署、可靠性、資安、事故與容量串成同一個服務演進路徑。沒有貫穿式案例時，章節會各自正確但讀者難以理解能力之間如何交接。
- 服務頁教材合約 服務頁是一篇能獨立教會讀者某個服務能力的教材，產品資訊與選型摘要只是教材材料。成熟服務頁要達到單篇技術教材的討論細節與漸進教學，但章節結構要依分類責任、服務對象與使用情境設計。
- Sibling Coverage Asymmetry Blindspot：Priority 評估漏掉的「對稱性維度」 當批量 A 跟批量 B 是 sibling（同類 vendor / 同類角色）、A 後寫超過 B、心智模型容易 collapse 到「A 是 reference / B 是 baseline」、忽略 *B 才應該 ≥ A coverage* 的對稱性 priority。Case：MySQL 18 篇 / PG 11 篇後、推薦下一步把 PG 排除、列 DynamoDB / Aurora / SQLite 等「新領域擴張」、user 自己 catch 才發現 PG 還沒對齊。機制：sequential point-in-time coverage 評估 vs cross-sectional sibling symmetry 評估、後者預設不在 priority 列表維度。修法：priority candidate list 必須跑 sibling symmetry audit。
- Sibling Vendor Cross-Link 雙向性 Audit：寫 Vendor Batch 結束必跑 當寫 sibling vendor batch（A vs B）、cross-link 容易單向 — A 提 B 多次、B 沒回提 A、形成 navigation asymmetry。Case：MySQL 18 篇對 PG sibling cross-link 9 條、PG 對 MySQL cross-link 0 條。機制：寫第二個 batch 時 reference 第一個 batch 是自然行為、但 reverse direction 必須主動補。修法：vendor batch 結束跑 bidirectional link audit、`A → B` 跟 `B → A` 對比、缺一邊就補。
- Vendor Feature 時間敏感性：Claim Verification 必跑、寫作日期必標 寫 vendor article 時、feature limitation claim（『不支援 X』『最多 Y』『預設 Z』）有時間敏感性 — vendor 持續演進、寫作後 N 個月可能 invalidate 整段 audit 邏輯。Case：PlanetScale FK 不支援是 2022 年的事實、2023 末 Vitess 18 加 FK 支援、寫作時若不 verify、Phase 1 audit「FK audit + 全 drop」整段過時。機制：LLM training cutoff vs vendor changelog 速度差、且 LLM 預設不標 claim 的時間性。修法：每篇 vendor article 標 *Last verified* date、limitation claim 必要時加 *as of N* 註、claim 反轉 invalidates 整段 audit 時必須重寫不是修補。
- Cross-Reviewer Convergence：多 Reviewer 收斂的 finding 比單 Reviewer flag 信號強 Multi-reviewer audit（4-reviewer / N-reviewer parallel）後、finding priority 不該是 *N 個 reviewer 報告平均合併*、應該按 *跨 reviewer convergence* 加權 — 兩個獨立 reviewer 從不同 axis 各自發現同一 finding 是 *信號收斂*、比單 reviewer flag 信號強 5-10x。Case：MySQL 17 篇 4-reviewer audit、Reviewer A（寫作規範）跟 Reviewer B（跨檔一致性）獨立 flag 同一 finding『4 篇 migration playbook 缺 weight + banner』、是跨軸 convergence、是最 high-priority fix。機制：N 個獨立 axis 隨機 hit 同一 finding 的機率隨 N 增加而 exponential decline、convergence 排除噪音、是 signal-to-noise 的最高比訊號。修法：multi-reviewer audit 後做 *cross-reviewer matrix*、convergence column 自動標 priority bump。
- 新增頂層 content 資料夾要同步首頁 _index.md 入口 Hugo 不會 auto-list 頂層資料夾、首頁的模組清單是 content/_index.md 的手動 curated markdown。新增 content/<module>/ 後若沒同步加入口、模組在首頁完全不可發現；讀者只能靠搜尋或直接打 URL 才進得去。本卡把『新增頂層資料夾 + 首頁入口』綁成同 commit 的雙生動作、避免下次再漏。是 #44 SSoT 在『首頁清單』維度 + #97 metadata surface 在『上層索引』維度的具體案例。
- WRAP Widen Options 容易塌成稻草人 framing、要改 evidence weight 結構 WRAP 框架的 Widen Options 段在案例寫作中容易塌成「列爛選項 → 打掉 → 留正解」的修辭結構、變成稻草人 setup。問題不在框架本身、在於寫作時把 Widen Options → Reality Test 當作全文 narrative 主軸。修法是把 Widen Options 從「對抗稻草人」改成「並陳合理因果鏈用 evidence 配重」、Reality Test 從 binary verdict 改成 weight assessment + Falsifier。是 #125 Collapse 在 WRAP 寫作 surface 的具體 instance、#79 多軸決策的姊妹卡。
- WRAP 是寫作者的內部工具、不是文章章節結構 WRAP 框架（Anchor Check / Step 0 / Widen Options / Reality Test / Attain Distance / Prepare to be Wrong / Tripwire）是寫作者背後做 hypothesis 探索與認知偏誤防護的內部工具。當把這些 process 標籤暴露成文章章節標題、讀者會踩三個壞 effect：預設讀者認知、塞滿 meta dialogue、同論點重複預告。修法是把 WRAP 工作內嵌進教學 narrative、章節順序服從教學流程。是 #140 WRAP Widen Options 稻草人的上位原則、跟 #125 Collapse 同骨。
- 文章主體要對齊標題承諾、WRAP 內部分析不該喧賓奪主 文章標題對讀者做了承諾、文章主體必須對齊這個承諾。WRAP 內部分析（Widen Options + Reality Test 含 prior 引用 + evidence weight）即使方法論做得好、如果不是標題承諾的內容、就不該佔文章主體—屬於 scope mismatch、跟 process metadata 暴露（#141）的議題分開。附帶議題：當 WRAP 內部分析喧賓奪主、為了支撐 prior 容易引入沒實際出處的 source citation；把 WRAP 內部分析從主體移除、hallucination 風險自然降低。是 #141 的姊妹卡—#141 處理章節標題 surface、本卡處理章節內容 scope。
- 外部分析文章要先拆成事實、作者判讀、本文推導 把外部分析師文章轉成教學型商業分析時、原文不是可直接搬進正文的 case fact。寫作者要先把材料拆成三層：可驗證事實、原作者判讀、本文推導。三層混寫會讓分析師 frame 被讀者誤當事實、也會讓本文自己的結論失去可回溯性。修法是先做 source layering、再決定哪些內容進事件段、哪些內容只作為 hypothesis prior、哪些內容要標為本文合成。
- 跨領域分析要先定位讀者層級、再決定術語密度 把商業分析寫給工程背景讀者時、不能繼承原分析文章的 VC / founder / industry insider 讀者假設。跨領域寫作要先定位來源文章與目標讀者的層級差，再決定術語密度、因果鏈步長與例子粒度。若直接沿用高密度商業語言，文章看似專業、但讀者只能記名詞，無法複製判讀。
- 外部分析改寫的交付物是可遷移框架、不是風格轉換 把其他分析師文章交給 AI 改寫時、任務目標不能停在語氣、段落與措辭符合本站風格。教學型商業分析的交付物是讀者可帶到下一個事件使用的判讀框架。若只做風格轉換，文章會像摘要或二次評論；若做框架轉換，文章會把事件拆成訊號、機制、風險、預警與下一步路由。
- 案例庫不對齊章節主題時用反向追問取代強掛 當案例庫主軸跟章節主題不在同一維度時、引用框架要從『正向掛入』切換到『反向追問』；強掛 case 的根因是『想填滿案例段』的模板配額、而非『想讓讀者看到證據』；反向追問把案例庫的限制當 first-class 訊息傳給讀者、case 變成『沒做 X 的後果』的反證、不是 X 的示範；reviewer 第一輪 fact-check 就能抓出強掛、修正成本高；判讀徵兆是引用句寫不出 case 具體段落 / 多個 case 句型雷同 / 章節主題跟 case 庫主軸不同維度
- 規範化跟自審是兩種認知任務、立規範當下無法保護同批稿件 把反模式抽象成規範卡、跟在自己稿件辨識該反模式的局部實例、是兩種不同認知任務；前者用『歸納共同特徵』的視角、後者用『局部 pattern matching』的視角；用相同概念詞、走不同神經路徑；案例：#146 卡描述「看 X 如何 Y」是反模式、同 batch 5 篇章節仍有 11 處該句型未被作者察覺；修法是規範化當下立刻把規範轉成 grep keyword、對同 batch 稿件主動 sweep；不修則 #122 主題語意 attractor 跟 #124 emergence 違規會在同 batch 內持續累積
- 跨輪 review 停止訊號是 frame 涵蓋、不是 finding 數遞減 判斷「該不該再來一輪 review」的訊號是『frame 軸是否還有未動』、不是『上一輪 finding 變少』；多輪 review 的 ROI 不是 monotonically decreasing、而是 frame 切換的質性轉換 — Round N 用新 frame 通常仍會抓出 substantial finding、但內容從 surface compliance 往深層 structural issue 走；停止訊號是「下一輪可用的新 frame 已經想不出來」、不是 finding 數遞減；本卡填補 #114 / #126 / #147 沒覆蓋的「何時夠了」判讀缺口
- 字句層 review：keyword bank 命中是候選、不是判決 跑了字句層 grep keyword bank、命中『不是 A 而是 B』、卻把它判成『可接受的反例對照』放行；違規由讀者 catch。揭露 keyword bank 的第二層盲點：偵測（grep 命中）跟判定（這個命中是不是違規）是兩個認知步驟、reviewer 容易把命中合理化成合規而放行。判定準則：否定句構若在『建立核心概念』就改正向、只有在『明示反例段落』才保留。另有一類贅語（訴諸群體『很多人卡在』）連關鍵詞都沒有、keyword bank 結構上抓不到、要靠 reader-simulation 語意 pass。
- 教材用中性陳述、不對讀者喊話 教材的 register 是中性陳述概念、不是對讀者說話。三種對讀者喊話的形式 —— 安撫情緒（很多人卡在）、第二人稱代入（你天天寫）、祈使控制閱讀（先讀懂 / 別搞混）—— 表面不同、共同違反是把讀者當成要管理的對話對象、而非把概念講清楚。問題不在精度（「你天天寫的 int count」精度完全正確）、在 stance。修法是換成中性陳述（常見的 int count）或描述性名詞標題（簽章的型別與名字拆解）。邊界：hook / narrative 段落的輕度第二人稱可幫讀者進入、不一律禁。
- 教材給技術理由、不替方案下品質評價 教材該陳述「為什麼這樣設計」，不對方案下品質評價。自評誇飾（教科書級 / 堪稱經典 / 完美契合 / 漂亮地解決）讀起來像作者在誇自己方案、傳遞的是滿意度而非概念，且品質評價會頂替掉真正的技術理由 —— 寫了「X 是教科書級的適配」就少寫了「X 為什麼適配」。修法是把評價換成機制 / 條件。邊界：帶判讀條件的適配性陳述（三條件齊備時 HOF 比列舉更省）是判準、不是誇飾，保留。
- 教材把設計選擇講成選擇、不講成必然或天性 本質主義 / 必然性框架（天生 / 本質就是 / 必然 / 唯一）把一個設計選擇講成自然法則、抹掉設計能動性，讓讀者以為沒得選。它是『機會成本語氣 vs 絕對主義』違反的一個 subtype —— 不是命令式絕對（應該做 X）、而是必然性絕對（X 本來就這樣）、更隱形。sharp feature 是常局部牴觸作者自己在別處的條件性立場。修法是把必然框架還原成條件性：X 在『選了某前提』之後才以此形式成立。邊界：物理 / 法律 / 合規事實可講必然。
- Review 漏抓先分 design gap 與 execution gap、再決定改框架還是改執行 Review 漏抓某類問題時，有兩個不同成因：design gap（框架根本沒有對應 frame）跟 execution gap（框架有 frame、但 reviewer 沒跑）。修法相反 —— design gap 要改框架（補 frame / keyword）、execution gap 要改執行（真的跑完該跑的輪）。診斷前先分清：把 execution gap 誤判成 design gap 會 framework bloat（一直加 frame 卻沒解決偷跑子集）、把 design gap 誤判成 execution gap 會永遠漏同類。常見陷阱是『加 keyword』感覺像進步、但對沒跑的輪毫無幫助。
- 教材的『重點 / 總結』段是內容發散的訊號、該重組正文不該補丁 教材尾端的『重點』『一句話總結』段、若功能是重述前面已講過的內容、就是正文組織不佳的補丁。讀者需要回頭被提醒、代表概念在正文裡散掉了 —— 該做的是重拆正文段落、把概念在它該出現的位置一次講清、而不是另開總結段替發散的正文善後。判準：刪掉總結段後正文若仍站得住、證明總結本就冗餘；若站不住、是正文要重組、不是總結要補。處理總結段內容時先分『提醒 vs 概念』—— 純提醒（養成習慣 / 回頭確認）刪、有概念價值的（為何這樣設計）併回它本該所屬的正文位置。
- 引用章節用語意標題、不用位置編號：編號是結構排列的 derivation、會隨版本漂移 跨段落、跨檔引用結構單位（章節 / 階段 / 條列項）時、引用語意標題（副標題）、不引用位置編號（Stage 3、第 5 章、第 3 點）。編號是「目前結構排列」的 derivation、不是 fact；結構重排時編號全部位移、引用點不會報錯、而是 silent 指向錯的內容 — 比 broken link 更難偵測。標題的存在意義就是承載可被引用的語意。是 #44 SSoT 在結構引用維度的實例、#93 identifier-as-fact 家族的 sibling、#84 命名承載語意的引用面延伸。
- 集合命名用角色、不內嵌數量：「核心七問」的七是成員數的 derivation、加一問就全面失真 「核心七問」「成長六階段」「四大支柱」這類名稱把成員數量烤進名字裡 — 數量是集合當前成員的 derivation、不是集合的語意身分；成員增減時名稱失真、且名稱是被複製最多次的字串、缺陷隨每次引用繁殖。修法：命名只承載角色與層級（核心問題 / 次要問題 / 撞牆階段）、數量讓清單自己呈現。本卡是 #155 的命名端 sibling（#155 修引用端、本卡讓「語意標題是穩定錨」的前提真正成立）、#44 SSoT 在名稱內容的實例、#84 命名檢驗的數量維度。
- 語意錨用單一字串、同義雙名讓引用修復退回人腦對應 引用錨在語意標題之後、語意名稱本身要是單一字串。同一個結構單位有兩個同義名稱（標題寫「決策記錄 + scaffold 建議」、引用寫「決策收斂階段」）時、語意引用的兩個核心收益同時失效：grep 要掃兩套 pattern 才完整（漏配置一個就漏一半引用點）、重排時的引用修復回到人腦對應。是 #155 引用端、#156 命名端之後的第三塊：命名唯一性。
- 決策表兩列同時命中且結論相反：缺的是一個上游區分維度 判讀表 / 決策表的兩列規則被同一個真實案例同時命中、且指向相反結論時、問題通常出在表外：案例承載著兩種身分、而表缺少把身分拆開的上游維度 — 修法是補前置澄清問、把維度抬到表之前；拆不出身分的矛盾才是規則真衝突、回表內改規則。偵測方法是用真實案例 dry-run、不是逐列檢查 — 單列都正確的表仍可能整體矛盾。
- 入口分流要放在詞彙牆之前、門外讀者要在門外就拿到岔路 一個模組為「還沒進門的讀者」補了專屬章節、但模組入口頁的開頭全是門內讀者的詞彙、分流句埋在數十行後 — 目標讀者在抵達分流點之前就跳出了。分流的位置要依「最外圈讀者的存活範圍」決定：他讀得懂的區域有多長、分流就要出現在多早。內容寫得再友善、入口斷路就等於沒寫。
- 跨 surface 同主題內容要重新語境化、不是搬運：逐字相同句是未語境化的訊號 同一個原則要同時存在於兩個 surface（教材章節與 agent 協議、blog 卡與 skill 卡）時、規範說「各寫一份、語境化在各 surface 內」— 語境化的可操作判準是：句子要跟著該 surface 的讀者與用途改寫、兩邊逐字相同的句子是未語境化的候選訊號、命中後逐處判讀。逐字搬運讓兩份內容形成沒人宣告的隱性同源、改一邊另一邊 silent 漂移、且兩邊都沒有為自己的讀者最佳化。
- 摘要壓縮可以丟細節、不可以改模態 description、索引 hook、目錄註解這些壓縮層在濃縮規則時、最容易丟失的是約束的模態 — 「可延後、但不可沉默」是帶條件出口的設計、壓成「不可跳過」變成絕對禁令。模態失真比內容遺漏更糟：讀者從壓縮層建立的預期跟本體矛盾、規則的彈性設計（出口、條件、記錄義務）被摘要抹掉。壓縮丟細節是本職、丟模態是失真 — 判準是讀者只依摘要行動、會不會做出本體不要求、或錯過本體允許的事。
- 引用卡片用被引卡自己的分類詞彙：改寫對方的 taxonomy 是隱性錯引 宣告「本卡是 X 卡在某維度的延伸」時、描述 X 卡的詞彙要用 X 卡自己的分類體系。被引卡把 link label 歸在 navigation surface、引用方寫成「metadata surface 的一種」— 關係精神成立、詞彙錯位：讀者循連結過去、發現被引卡的分類表跟引用句對不上、引用的可信度連帶整張卡的可信度一起折損。引用前重讀被引卡的分類段、用它的詞彙描述它。
- 多階段流程的 artifact 欄位契約：下游宣稱的輸入要能從上游產出推導、推導規則要明文 多階段流程裡、下游階段宣稱「以上游的 X 為輸入」時、X 需要的每個欄位要嘛直接存在於上游的產出格式、要嘛有明文的推導規則。上游表七欄、下游要求的「失敗語意」欄不在其中也沒有推導說明 — 執行者只能自由心證、每次推得不一樣、漏標的欄位剛好是下游分支的開關。檢查方法是逐欄走查：把下游輸入格式的每一欄、對到上游產出格式的欄或一條明文推導。
- 知識載體責任分配：rules、agents、skills 各該裝什麼 AI 開發框架的知識會堆積在多種載體（rules / pm-rules / agents / skills / methodologies 等），每種載體的載入時機與受眾不同。本篇記錄從『一切塞 CLAUDE.md』到『受眾 x 形態二軸地圖』的演進歷程，與『代理人定義 = 人格與授權、skill = 可重複流程』的核心判定；載體錯置的代價是 token 污染或知識失傳，且規則互相矛盾時有執法者的一方必勝
- register 違規：偵測可機械化、判定要靠文體異源的眼睛 寫作規範的違規分兩類：形式違規（emoji / 編號 / broken link）可完全機械判定、該進工具鏈；register / 品味違規（概念前置 / 否定起手 / 喊話 / 誇飾）的判定有不可消除的品味核心。「不是 X、而是 Y」的陷阱是偵測可機械化（grep 抓得到句型）偽裝成判定可機械化、誘導無限投入更精緻的判定方法（grep → 概念位置 → 行為測試）、但判定始終在品味側、始終放水。更深一層：產出這類違規的 LLM 跟審查它的 LLM 共享文體直覺、同源自審對 register 違規有結構上限、加再多輪次都跨不過。結構解是引入文體異源的視角（人類冷讀 / reader-simulation / 對抗文體 reviewer）、並接受 100% 自動 catch 不可能。
- 重點優先陳述是跨語言的資訊結構原則、不是中文句型問題 正向陳述優先的本質是資訊結構效率：讀者拿到核心概念的認知步驟越少越好。「不是 X、而是 Y」表達能力差、是因為它讓讀者先處理一個被否定的錯誤理解 X 才拿到正確的 Y、重點後置多繞一步。這個缺陷跨語言成立——英文 not X but Y、日文 X ではなく Y 同樣高頻、換語言不打破（證偽過的反例假設）。判別線是「核心概念在不在最前」、統一了 #94（重點先行合法）與 #149（重點後置違規）、且可操作。LLM 系統性放水的根因是高頻偏置（把語料高頻句型評為表達好、高頻不等於資訊結構優、跨語言）。主解是強制執行重點位置判準、#165 的異源視角降為補充。
- 修法是新違規的來源、且常引入同類變體 修法（改寫違規句、補 lint 規則、改 pattern）這個動作本身會引入新違規、而且引入的常是同一類問題的變體——修「不是 X、而是 Y」就暴露「不是 X — 是 Y」、補一個 pattern 就漏下一個變體。所以 review 的 scope 要涵蓋修法後的產物、不只原始內容；停止判斷不能停在「修完這批」、因為修法本身產生新一批。同類變體靠判準（重點位置）收斂、不靠窮舉 pattern；補 pattern 永遠追不上變體（打地鼠）。
- 多輪審查要有冷讀者 frame：知情 reviewer 看不見行話洩漏 多輪審查模擬讀者時要分兩種：知情讀者（讀完全部、走旅程）與冷讀者（經搜尋或直連落在單篇、零脈絡）。知情 reviewer 會自動腦補脈絡，結構性看不見洩漏撰寫者預設前提的行話。原子 / Zettelkasten / glossary 等可被直連抵達的內容，必須額外跑冷讀 frame。
- 原子筆記要有向上的議題入口：讀者要知道為何讀這張、何時會撞到 承載知識的原子筆記不是字典條目。每張卡（或其上層）要回答「你在討論什麼議題、撞到什麼問題，才需要這個知識」——從情境進入，而非從定義進入。做法是建『議題 hub』上層筆記討論問題、再分流到術語卡，術語卡頂部回指議題。
- Description 是未來自己的 recall trigger、不是文章摘要 文章的 description 欄位要讓未來的自己在掃列表時判斷「我現在遇到的問題，該不該回來讀這篇」——像 skill 的 description 讓系統決定何時載入一樣。摘要式 description 只回答「這篇在講什麼」，recall trigger 回答「你在什麼情境下需要這篇」。
- 列舉與數字殘留在定義型文件會製造維護債務 定義型文件（規則、規格、常駐名單）中的冗餘列舉（A-G）和描述性數字（9 個函式、428 行）是撰寫過程中的推理殘留——作者先算出範圍再寫定義，但最終文件只需要定義本身。列舉讓每次擴充都要回頭更新引用處，數字讓每次重構都要校準計數，兩者都是維護成本但不增加閱讀價值。判斷標準：如果拿掉列舉或數字，讀者理解不受影響 → 刪除。
- 讀者是缺經驗的專業人士、不是外行人 技術教材的讀者定位應該是「在這個領域缺乏經驗的專業人士」，不是「完全不懂的外行人」。寫法是補足經驗缺口、不是從零科普。宣導式語氣（跑得好好的、你可能不知道）預設讀者無能，實際上會降低教材的可信度。
- 跨專業溝通用情境遞進、不用比喻堆疊 向非本領域的專業人士解釋技術議題時，減少術語並從簡單情境遞進到複雜情境，比堆疊比喻有效。比喻傳遞形狀但不傳遞嚴重性；情境遞進讓對方用自己熟悉的決策框架（成本、風險、時間）消化資訊。
- 技術教材要內嵌管理層可彙報的資訊 技術文章的讀者不只要知道怎麼做，還要能向上彙報為什麼做、花多久、花多少。成本量級、時程估算、進度指標與需簽核的決策點應該嵌在技術段落旁邊，而非集中在另一篇溝通指南裡。
- 多輪審查缺 outside-in 讀者 frame：六個系統性盲點 review 框架的所有 frame 從已寫的內容出發（inside-out），缺從讀者完整需求出發的 frame（outside-in）。六個盲點全部由使用者而非 reviewer 發現：宣導語氣、管理層資訊缺失、接手情境遺漏、工具指引缺失、深度不拆分、讀者定位未預設。
- 操作指引的「怎麼做」要帶環境專屬的工具路徑 操作型教材說「拍下現況」「匯出資料庫」「建立備份」時，不同執行環境（container / VM / 共享主機）的工具路徑完全不同。只寫動作不寫工具，讀者知道該做什麼但做不到。這個缺口在 fact-check 和 steelman 審查裡結構性隱形，因為動作本身在邏輯層是正確的。
- 跨 surface 鏡像的連結轉換 mapping 要窮盡、不能靠猜 skill 鏡像從 .claude/skills/ 複製到 content/skills/ 時，references/principles/ 的相對連結要轉成 /report/ 的真實路徑。mapping table 不完整會讓 CI 反覆 broken link，每次修一批漏一批。窮盡 mapping 的方法是列出所有 principle 檔案再逐一找對應 report 卡，不是靠 slug 精確匹配碰運氣。
- 先建 report 卡再進 skill、不是先改 skill 再補 report report 卡是原則的 SSoT（有情境、根因、理想做法），skill 是 report 的操作化引用。先有 report 才有 skill 引用的依據。反過來做會讓 skill 裡的規則缺乏可追溯的根據，且 report 容易被跳過。
- 常識是相對於讀者背景的、不是作者背景的 知識卡的建卡判準不能用「這個夠不夠常見」——對 PHP 工程師是常識的 .htaccess，對 Node.js 工程師完全陌生；對後端工程師是常識的 DNS TTL，對前端工程師需要解釋。建卡看的是目標讀者群裡最不熟悉的那個人能不能理解，不是作者自己覺得夠不夠普遍。
- 一篇文章只承擔一種功能：SOP 跟 retrospective 混寫兩邊都做不好 文章同時塞操作步驟（SOP）和批次驗證紀錄（retrospective）時，機器讀者找不到可執行的步驟、人類讀者不知道哪段是給自己看的。
- Log 時間真空是 silent hang 訊號、happy log 是 anti-signal 非互動 process（CI / cron / container init）的最後一行 log 是成功訊息、到被 cancel 之間有大段時間無輸出時回來。判讀靠訊息時序的真空、不是最後一行的成功訊息。
- Report 卡的論述基礎記結論和 evidence 來源、不記檢討過程 report 卡的論述基礎與限制段寫「從哪來、evidence 邊界是什麼」，不寫「怎麼發起的、用了什麼工具分析」。過程是作者的工作紀錄、結論才是讀者需要的判讀前提。
- 多輪審查至少三輪是硬底線 多輪審查跑完 Round 2 想收手時回來讀 — Round 3 的 steelman/outbound frame 在每次實測都找出 10+ 項、問要不要跑等於問要不要跑一定有產出的審查
- 三輪審查的檢討收穫 — 工具 opinion 文章的寫作品質演進 一篇 work-log 經過三輪多視角審查（8 frame、33 findings），從 B+ 提升到 A+。記錄每輪抓到什麼、為什麼前一輪漏抓、以及哪些寫作 pattern 會在 AI 輔助寫作中反覆出現。
- 文章語氣校正：恐嚇式 hook 與技術分享的邊界 「可能正在你的工具中靜默發生」是恐嚇語氣，「從一個版本錯置的經驗出發」是分享語氣。兩者的差別在於把讀者放在什麼位置——被警告的對象，還是同行的分享者。
- 文章範圍漂移：從 CLI 工具到工具設計的泛化過程 一篇文章初稿聚焦在 CLI 工具的 opinion 設計，經三輪審查和作者回饋後逐步泛化到所有工具設計。記錄範圍擴展的決策點和需要同步調整的位置（title、hook、原則段、checklist、對照表）。
- 主題偏移：內部系統知識洩漏到面向讀者的論述 「規則檔和 memory 系統也能傳遞教訓」是正確的技術描述，但在討論「工具應該有 opinion」的文章中偏離了主題。讀者不需要知道作者的內部系統架構，他們需要的是可遷移的工具設計原則。
- 信號不是承認 — 技術寫作中的歸因語氣 「都是承認工具沒做到位的信號」把客觀的觀測訊號包裝成主觀的責任歸因。工程上，信號是提醒，不是定罪。語氣偏差會讓讀者從「可以改善」的正向心態轉為「做錯了要承認」的防禦心態。
- 讀者不需要知道 — 刪除比解釋更尊重讀者 「整理目的」blockquote 告訴讀者這篇文章的寫作動機和邊界。但讀者不需要知道作者為什麼寫這篇文章——他們需要知道讀完能帶走什麼。meta 資訊（寫作動機、邊界聲明、脈絡解釋）服務的是作者的組織需求，不是讀者的閱讀需求。
#3cx
#429
#5w1h
#a11y
#ab-test
#abac
#abuse
#abuse case
#access-control
#access-key
#access-management
#access-pattern
#access-revocation
#accessibility
#ack-deadline
#acl
#acm
#acme
#active-active
#adb
#admin endpoint
#adoption
#aerospace
#agent
#agent-architecture
#agent-team
#agent派發
#aggregation
#ai-agent
#ai-governance
#ai-writing
#aider
#air-gapped
#ai代理人
#ai協作
#ai協作心得
#akamas
#alacritty
#alarm
#alb
#alert runbook
#alert-fatigue
#alerting
#alignment
#amd
#amplitude
#analytics
#android
#anonymization
#ansi
#anti-pattern
#anti-patterns
#aof
#apfs
#api
#api-contract
#api-design
#api-key
#apm
#app
#app-link
#apple-silicon
#application
#applications
#arch
#arch-linux
#architecture
#aria
#artifact
#artifact provenance
#artifacts
#ascii
#assertion
#ast
#async
#asyncio
#atexit
#atlas
#atlassian
#att&ck
#att&ck evaluations
#attack-surface
#attention
#attribution
#audience-awareness
#audience-positioning
#audit
#audit log
#audit-dimension
#auditable loop
#aurora
#aurora-dsql
#auth0
#authentication
#authorization
#auto-intercept
#auto-recovery
#auto-scaling
#automation
#autovacuum
#avro
#aws
#aws-acm
#aws-elasticache
#aws-iam
#aws-iam-identity-center
#aws-kms
#aws-s3
#aws-secrets-manager
#aws-sqs
#aws-sso
#aws-waf
#axis-candidate
#azure
#azure-key-vault
#azure-rbac
#baas
#backend
#backfill
#backpressure
#backup
#backward-compatible
#baseline
#bash
#basics
#batch
#batch-writing
#bdd
#bdr
#bear cub
#bearer-token
#behavior testing
#behavioral-detection
#benchmark
#best-practices
#bigquery
#binary
#bind-address
#binlog
#biometric
#blast radius
#blindspot
#blog
#blog-config
#blog心得
#blog維護
#blue team
#boot
#bootstrap
#bottleneck
#boundary
#branch-protection
#brewfile
#broker
#broot
#browser
#btop
#bubbleup
#buffer
#buffering
#bulkhead
#burst-traffic
#bus
#business
#business-analysis
#business-case
#business-model
#buy-vs-build
#c-extension
#ca
#cache
#cache invalidation
#caelestia
#caffeine
#canary
#capability
#capability-upgrade
#capacity
#capacity-mode
#capacity-planning
#capital
#cardinality
#cards-skills
#case-analysis
#case-driven
#case-first
#case-first-workflow
#case-study
#cassandra
#catppuccin
#cd
#cdc
#cdn
#cert-manager
#cffi
#chain-of-thought
#change healthcare
#change-feed
#change-streams
#changelog
#channel
#chaos
#chaos engineering
#chapter-structure
#chart
#checklist
#checkout
#checkov
#checkpoint
#chezmoi
#chronicle
#ci
#ci-cd
#ci/cd
#cidr
#cilium-tetragon
#circuit-breaker
#cisa
#citation
#citrix bleed
#citus
#class
#classification
#claude
#claude code
#clean architecture
#cli
#client
#client-server
#client-side
#clock-drift
#cloud
#cloud-cost
#cloud-data-policy
#cloud-iam
#cloud-llm
#cloud-logging
#cloud-managed
#cloud-monitoring
#cloud-security
#cloud-sql
#cloudflare
#cloudflare-access
#cloudflare-waf
#cloudhealth
#cloudhsm
#cloudtrail
#cloudwatch
#cluster
#cnapp
#cockroach-cloud
#cockroachdb
#code-generation
#code-quality
#code-smell
#codex
#coding
#coding-agent
#cognitive-load
#cohort
#collaboration
#collaborative-filtering
#collapse
#collection-strategy
#collector
#comfyui
#commercial
#communication
#comparison
#completeness
#compliance
#compositional-writing
#compositor
#compute
#concurrency
#conditional-write
#config rollout
#conflict-resolution
#conftest
#connection
#connection-pool
#connection-pooling
#consensus
#consistency
#consolidation
#constants
#constrained-decoding
#constraint-design
#consul
#consumer
#consumer-group
#consumer-lag
#consumption
#container
#container-scan
#containment
#content-based
#content-design
#context
#context-engineering
#context-management
#context-window
#continue-dev
#contract-test
#control failure
#control handoff
#control map
#control mapping
#control pattern
#control plane
#control validation
#convention
#conversion
#copywriting
#coroutine
#correlation id
#cors
#cosmosdb
#cost
#cost-governance
#cost-management
#cost-model
#cost-optimization
#cost-thinking
#courses
#coverage
#cpu-offload
#cpython
#cqrs
#crashlytics
#credential
#credential-rotation
#cross-cloud
#cross-link
#cross-module
#cross-platform
#cross-vendor
#crowdstrike-falcon-cs
#csf
#cspm
#css
#ctypes
#cuda
#customer-identity
#d1
#d3fend
#dart
#dashboard
#data classification
#data exfiltration
#data flow
#data inconsistency
#data lifecycle
#data plane
#data-architecture
#data-boundary
#data-consistency
#data-control
#data-engineering
#data-integrity
#data-minimization
#data-pipeline
#data-protection
#data-quality
#data-repair
#data-residency
#data-security
#data-shape
#data-types
#data-warehouse
#database
#datadog
#datadog-security
#dax
#db-document
#db-kv
#db-oltp
#dblab
#ddd
#ddl
#ddos
#dead-code
#dead-letter-topic
#deadlock
#debezium
#debounce
#debug
#debuggability
#debugging
#decision
#decision dialogue
#decision log
#decision-tree
#decoding
#decorator
#dedup
#deep-article
#deep-link
#default-design
#defender pressure
#defense
#defense vocabulary
#definition
#degradation
#degraded-mode
#deletion evidence
#delivery
#delivery-mode-selection
#delta
#denormalization
#dependabot
#dependency
#dependency-injection
#deployment
#deployment-platform
#descriptor
#design
#design-pattern
#design-patterns
#design-tradeoff
#desktop
#desktop-environment
#detection
#detection coverage
#detection engineering
#detection-rule
#devcontainer
#developer
#development-environment
#devops
#diagnosis
#diagnostic endpoint
#diffusion
#digest
#disaster-recovery
#discrete-gpu
#disk
#disk-space
#distributed
#distributed-counter
#distributed-lock
#distributed-sql
#distributed-systems
#dlp
#dlq
#dns
#docker
#docker-swarm
#document
#document-model
#document-store
#documentation
#dom
#domain設計
#dotfile
#downtime
#dr
#dragonflydb
#draining
#drawer
#drift
#drop-in
#drop-off
#dry
#dsl
#duplicate delivery
#durability
#dynamic-credential
#dynamodb
#e2e
#ebpf
#ecs
#edge
#edge exposure
#edge-cache
#editor
#edr
#eks
#elastic-cloud
#elastic-security
#elastic-stack
#elasticache
#embedded
#embedding
#emulator
#encryption
#enforcement-design
#entra-id
#entry-point
#environment
#error
#error-handling
#error-message
#error-recovery
#error-storm
#error-tracking
#escape
#etcd
#eval
#evals
#evaluation
#event
#event-classification
#event-contract
#event-delivery
#event-design
#event-driven
#event-enumeration
#event-format
#event-loop
#event-peak
#eviction
#evidence
#evidence package
#evolution
#exactly-once
#exception
#execution
#exercise design
#expectation
#explain
#exponential-backoff
#export
#extension
#external-consistency
#failover
#failure patterns
#failure-mode
#falco
#fallback
#fallback-design
#false confidence
#false-alarm
#false-negative
#false-positive
#false-trigger
#fargate
#fastly
#fastly-ngwaf
#fault-tolerance
#fde
#feature-flag
#feature-tier
#federation
#federation trust
#field cases
#file-manager
#filter
#fine-tuning
#fingerprint
#finops
#firebase
#firestore
#fixture
#flaky
#flaky test
#flash-sale-spike
#fleet
#flow-control
#flush
#flutter
#font
#fontconfig
#form
#foundations
#frame-coverage
#framework
#framing
#free-threading
#freezed
#freshness
#frontend
#frontend-with-playwright
#frontmatter
#ftp
#full-stack
#full-text-search
#function
#function-calling
#funnel
#fuse.js
#fuzzing
#fzf
#ga4
#game day
#gate
#gate-fallback
#gatekeeper
#gatling
#gc
#gcp
#gdpr
#gemma
#generics
#geoserver
#getter
#getx
#gguf
#ghas
#gil
#gis
#git
#gitguardian
#github
#github-actions
#github-advanced-security
#gitleaks
#gitui
#global
#global-database
#global-edge
#global-sql
#global-tables
#gnuplot
#go
#go-advanced
#goaccess
#goldmark
#google-cloud-iam
#google-cloud-kms
#google-dlp
#google-pubsub
#google-secret-manager
#google-security-operations
#googlesql
#goreplay
#gorouter
#goroutine
#governance
#gpu
#gql
#graceful-shutdown
#gradle
#grafana
#grafana-cloud
#grafana-oncall
#grammar
#grep
#group-replication
#grouping
#grype
#gsi
#gsm
#gtid
#gtk
#gtm
#gui
#ha
#handover
#hands-on
#happy-path
#harbor
#hardware
#harlequin
#harness
#hashicorp
#hashicorp-vault
#hatch
#health
#health-check
#heatwave
#helpdesk
#hig
#high-availability
#high-cardinality
#high-frequency-write
#higher-order-function
#hlc
#homebrew
#honeycomb
#hook
#hook系統
#horizontal-scaling
#hot-partition
#hsm
#htap
#htop
#http
#https
#hugo
#human-ai-collaboration
#human-in-the-loop
#hypothesis-testing
#hyprland
#hyprlock
#i18n
#iac
#iac-scan
#iam
#ide
#ide-integration
#idempotency
#identifier
#identity
#idle timeout
#ilm
#image
#ime
#immuta
#impact scope
#implementation
#import
#imports
#improvement
#in-context-learning
#incident
#incident cases
#incident decision log
#incident evidence
#incident learning
#incident severity
#incident workflow
#incident-response
#index
#inference
#inference-optimization
#inference-server
#information architecture
#information-protection
#information-theory
#infra
#infrastructure
#ingestion
#inheritance
#innodb
#innodb-cluster
#input
#install
#installation
#installer
#instruction-following
#instrumentation
#integration
#integration-test
#intel
#interface
#interleaved-tables
#internal endpoint
#invalidation
#io-threads
#ios
#iredis
#isolate
#isolation
#isr
#ivanti
#javascript
#jenkins
#jetstream
#jmeter
#journalctl
#js
#json
#json-schema
#jsonb
#jsonl
#judgment
#k6
#k9s
#kafka
#kando
#kaskade
#kent beck
#key
#keyboard
#keycloak
#keydb
#kitty
#kms
#knowledge
#knowledge gardening
#knowledge routing
#knowledge-card
#knowledge-cards
#knowledge-work
#kubernetes
#kv
#kv-cache
#kyverno
#lacework
#lambda
#language-design
#laravel
#late
#latency
#layout
#lazygit
#lazysql
#leaf-node
#lectures
#legacy
#letsencrypt
#library
#lifecycle
#linear-algebra
#linearizability
#lint
#linux
#litestream
#liveness
#llama-cpp
#llm
#llm-as-judge
#lm-studio
#load balancer contract
#load shedding
#load-balancer
#load-balancing
#load-test
#load-testing
#local-first
#local-llm
#local-llm-services
#local-vs-cloud
#locality
#lock
#locking
#locust
#log
#log-compaction
#log-pipeline
#log-schema
#logging
#logical-decoding
#logical-replication
#logs
#loki
#long-context
#long-term-storage
#lora
#loss
#low-latency-sustained
#lsi
#lsp
#lua
#m-trends
#mac
#macos
#major-upgrade
#mako
#managed
#managed-service
#management plane
#mandiant
#markdown
#market-dynamics
#marketing
#mass exploitation
#material-design
#materials
#math
#math-foundations
#maturity
#maturity model
#maxwell
#mcp
#mdm
#memcached
#memory
#memory-budget
#mental-model
#mermaid
#mesh-vpn
#message-queue
#meta-commentary
#metaclass
#metadata
#metadata-lock
#metaprogramming
#methodology
#methodology-selection
#metric
#metrics
#mfa
#mft
#mgm
#microservice
#microsoft-purview
#middleware
#migration
#migration-playbook
#mimir
#mindset
#minisearch
#mitigation
#mitre
#mixpanel
#ml-detection
#mlx
#moat
#mobile
#mock
#model-architecture
#model-behavior
#model-family
#model-selection
#model-trust
#module
#modules
#moe
#mongodb
#mongodb-api
#monitoring
#monorepo
#mosh
#motivation
#moveit
#mq-stream
#msk
#mtls
#mtp
#mttr
#multi-account
#multi-agent
#multi-axis
#multi-cluster
#multi-dc
#multi-gpu
#multi-master
#multi-model
#multi-pass
#multi-region
#multi-round-review
#multi-source
#multi-tenant
#multicore
#multilingual
#multimedia
#multimodal
#multiplexer
#multiprocessing
#mutationobserver
#mvcc
#mysql
#naming
#nat
#nats
#navigation
#neovim
#network
#network-exposure
#network-partition
#networking
#neural-network
#new-relic
#nexus
#nginx
#ngxtop
#nist
#nix
#node
#noise
#non-technical
#nosql
#notes
#ntp
#numerical-precision
#nvidia
#observability
#offline
#oidc
#okta
#olap
#ollama
#oltp
#on-call
#onboarding
#online-ddl
#oomkill
#oop
#opa
#open-source
#open-webui
#opentelemetry
#opentofu
#operational-hybrid
#operations
#opinionated-software
#ops-loop
#optimization
#optimizer
#orchestration
#orchestrator
#ordering-key
#organization
#organizations
#os
#oss
#otlp
#outbox
#over-match
#override
#owasp
#ownership
#paas
#package
#package-management
#package-manager
#packaging
#pacman
#page-shield
#pagefind
#palo-alto
#pam
#pane
#paradigm
#paradigm-shift
#parallel
#parallel-dispatch
#parca
#parser
#partition
#partition-key
#partitioning
#path
#pathlib
#patroni
#pattern
#peak-estimation
#peak-event
#pel
#performance
#permission
#persistence
#pg-partman
#pgbouncer
#pgcli
#pgvector
#phased-translation
#philosophy
#php
#pii
#pipeline
#piper
#pitr
#pki
#planetscale
#planning
#platform
#playbook
#playwright
#plotext
#poetry
#policy control
#policy-as-code
#pooler
#pos
#post-incident review
#postgis
#postgresql
#postgresql-dialect
#posts
#pprof
#pragma
#pre-commit
#precision
#predictable-peak
#predictive-scaling
#presence
#pretraining
#preview
#principles
#priority
#prisma-cloud
#privacera
#privacy
#probability
#probe
#problem cards
#process
#process-writing
#production
#production-validation
#professional sources
#profiling
#prometheus
#prompt-cache
#prompt-engineering
#prompt-injection
#prompting
#promql
#property-graph
#protocol
#protocol-integration
#provenance
#provisioning
#proxy
#proxysql
#pub-sub
#push
#push-pop
#push-pull
#pyo3
#pyproject
#pyroscope
#python
#python-advanced
#qlora
#quality
#quantization
#query
#query-boundary
#query-optimization
#queue
#quickshell
#quickstart
#quorum
#quorum-queue
#quota
#qwen
#rabbitmq
#raft
#rag
#rainfrog
#ram
#ranger
#ransomware
#rate-limit
#rate-limiting
#rba
#rdb
#rds
#rds-proxy
#reachability
#read-preference
#read-replica
#read-write
#readability
#reader-experience
#reader-first
#readiness
#reading
#realtime
#reasoning
#rebalance
#recall
#recommendation
#reconciliation
#recording-rules
#recovery
#red-team
#redaction
#redis
#redis-compatibility
#redis-streams
#redundancy
#refactor
#refactoring
#registry
#rego
#regulated
#release
#release freeze
#release gate
#release governance
#release-tracking
#reliability
#remote
#remote-access
#remote-config
#remote-write
#replay
#replica
#replication
#replication-slot
#report
#repository-adapter
#representativeness
#reproducibility
#required-checks
#requirement-protocol
#requirements
#rerun
#reserved-instance
#resharding
#residency
#resilience
#resiliency matrix
#resource
#resource-limit
#resource-planning
#resource-pool
#response routing
#responsive design
#retention
#retrieval
#retrofit
#retrospective
#retry
#retry-loop
#reverse-proxy
#review
#review-design
#review-process
#review-timing
#review機制
#rfm
#rhythm
#rice
#ripgrep
#risk
#risk acceptance
#risk governance
#risk input
#risk routing
#rls
#roblox
#rocm
#roi
#rollback
#rollback rehearsal
#rollback strategy
#rollout
#root-cause
#root-cause-analysis
#rotation
#route53
#router
#routing
#rpo
#rsync
#rto
#ru-sizing
#rule-codification
#rule-engine
#rum
#runbook
#runtime
#runtime config
#runtime-detection
#runzonedguarded
#rust
#s3
#saas
#safety
#sampling
#sanctum
#sans
#sast
#saturation
#sbom
#sca
#scaffold
#scale
#scaling
#scenario
#schema
#schema-design
#schema-diff
#schema-evolution
#schema-migration
#schema-registry
#scope
#scope-management
#scp
#screen-state
#screen-state-test
#screenshot
#sdk
#sdk-design
#search
#secret
#secret-management
#secret-scanning
#secrets
#security
#security control
#security design
#security materials
#security operations
#security references
#security testing
#security-group
#security-rules
#segmentation
#select
#selector
#self-hosted
#self-review
#semantics
#semver
#sensitive-data
#sensor
#sentinel
#sentry
#serializable
#server
#serverless
#service design
#service discovery
#service registry
#service-locator
#service-mesh
#service-selection
#service-worker
#session
#session invalidation
#session-recording
#session-replay
#session-token
#setup
#severity
#shard-key
#sharded
#sharding
#shared controls
#shared-storage
#shell
#shortcode
#siem
#sigma
#signal
#signal quality
#signing
#signing key
#simulation
#simulator
#single-table-design
#skill
#skills
#slab-allocator
#sliding-window
#slo
#slow-log
#snapshot
#snapshot-listener
#snowflake
#snyk
#soar
#sociable unit tests
#social engineering
#source
#source-of-truth
#spa
#spanner
#spanner-graph
#spatial
#specification
#speculative-decoding
#speech-to-text
#spiffe
#spire
#split-brain
#splunk
#spot-instance
#spurious-failure
#spurious-warning
#sql
#sql-api
#sql-features
#sqlite
#sre
#ssh
#ssot
#stable-diffusion
#stakeholder
#stakeholder mapping
#stanford-cs230
#state
#state-machine
#state-management
#state-matrix
#stateful
#stateless
#static stability
#static-site
#statistics
#status page
#statusline
#stdlib
#steady state
#sticky session
#storage
#stored-procedure
#storm-0558
#stow
#strategy
#stream
#streaming-replication
#streams
#struct
#structured-output
#subnet
#supercluster
#supply-chain
#support workflow
#surge
#survival-goals
#sustained-growth
#svelte
#syft
#synapse-link
#sync
#systemd
#tab-bar
#table-locality
#tabletop
#tagging
#tailscale
#tailscale-ssh
#takeover
#tdd
#tdd流程
#teaching-structure
#team
#technical-writing
#telemetry
#telemetry-pipeline
#teleport
#template-abuse
#tempo
#termgraph
#terminal
#terminology
#terraform
#test
#test-data
#test-design
#test-time-compute
#testcontainers
#testing
#tflint
#tfsec
#theme
#theoretical-foundations
#theory
#threading
#threat intelligence
#threat model
#threat-informed defense
#threat-modeling
#throughput
#ticket
#ticket整合
#ticket管理
#ticket系統
#ticket追蹤
#tier
#tiered-storage
#tig
#til
#tiling
#time-machine
#time-series
#timeout
#timescaledb
#timeseries
#timestamp
#timezone
#tls
#tmux
#toc
#toil
#token
#token revocation
#token scope
#token-bucket
#tokenization
#tone
#tool-design
#tool-use
#tooling
#tools
#topic-drift
#topology
#touch
#traceability
#tracing
#tradeoffs
#traffic
#traffic-management
#traffic-mirroring
#traffic-replay
#training
#transaction
#transformer
#transition
#translation
#transport
#triage
#trigger
#tripwire
#trivy
#troubleshooting
#truetime
#ttl
#tts
#tty
#ttyd
#tui
#tuning
#tunnel
#turso
#two-tier
#type-a
#type-b
#type-c
#type-e
#type-f
#type-hints
#type-i-error
#type-ii-error
#type-system
#typedef
#typing
#uefi
#ui
#ui-test
#unit-economics
#unittest
#universal-link
#update
#upgrade
#uptime
#usql
#utm
#ux
#ux-design
#vacuum
#validation
#valkey
#valuenotifier
#vantage
#variants
#vault
#vector-database
#vector-search
#vegeta
#vendor
#vendor-article
#vendor-mapping
#vendor-selection
#verification
#version-management
#version-upgrade
#versioning
#vertical-saas
#vertical-slice
#viewmodel
#visibility-timeout
#vision
#visual
#visual-regression
#vitess
#vlm
#vm
#vpc
#vram
#vscode
#vulnerability response
#waf
#wal
#wal-archive
#waybar
#wayland
#web
#websocket
#wezterm
#whisper
#widget
#widget-test
#window-manager
#windows
#wiz
#wofi
#work-log
#workflow
#workload
#workload-identity
#worklog
#wrap
#wrap-decision
#write-back
#write-sharding
#writing
#writing-methodology
#writing-spec
#writing-workflow
#x11
#xclaim
#xz utils
#yabai
#yagni
#yaml
#yazi
#yozefu
#zellij
#zero-trust
#zettelkasten
#zone
#zsh
#ztna
#並行分析
#並行評估
#事件處理
#事件驅動
#事後檢討
#事故圍堵
#事故後檢討
#事故案例
#事故決策紀錄
#事故等級
#任務拆分
#任務派發
#任務管理
#供應鏈
#供應鏈完整性
#依賴方向
#停機
#健康檢查
#備份刪除
#允許清單
#內容分類
#內部端點
#全局分析
#全方位評估
#函式設計
#分層架構
#利害關係人地圖
#前端開發
#前置知識卡片
#功能旗標
#卡片盒筆記
#原則
#原子任務
#可靠性
#吞吐量
#告警處置手冊
#命名規範
#品質改善
#品質標準
#品質檢查
#品質管理
#商業分析
#問題覺察
#問題評估
#單元測試
#單字
#回滾演練
#回滾策略
#國際化
#圖表
#地區化
#執行期設定
#外部組件
#多視角分析
#契約
#字源
#學習筆記
#完成定義
#容器
#容錯切換
#寫作
#寫作方法論
#寫作規範
#專案管理
#對話協議
#導航
#就緒檢查
#工作日誌
#工作流
#工作流程
#工作準則
#工具
#工具技巧
#工具設計
#工具評估
#工具鏈
#工程實踐
#工程方法論
#工程筆記
#平均修復時間
#建議追蹤
#影響半徑
#影響範圍
#復原時間目標
#復原點目標
#快取失效策略
#技術債務
#技術寫作
#技術文件
#技術選型
#抽象層
#拉丁文
#持續改善
#指標
#授權
#排空
#探針
#搜尋
#效率工具
#敏捷
#敏捷開發
#教學
#教材結構
#教材設計
#整合測試
#文件撰寫
#文件系統
#文件規範
#文件設計
#文檔架構
#方法論
#會話失效
#服務發現
#服務註冊
#架構升級
#架構合規
#架構設計
#框架設計
#機密管理
#權杖撤銷
#決策呈現
#決策框架
#決策樹
#決策記錄
#治理例外
#流程
#流程圖
#流程設計
#測試
#測試驅動
#測試驅動開發
#溝通
#漸進式遷移
#版本企劃
#物件導向設計
#狀態機
#狀態頁
#發布
#發布凍結
#發布關卡
#知識傳遞
#知識卡
#知識卡片
#知識基礎建設
#知識管理
#程式品質
#程式碼品質
#程式碼審查
#程式碼操作
#程式碼設計
#程式設計
#稽核日誌
#穩態
#管理平面
#管理端點
#系統化開發
#系統思考
#系統遷移
#素材庫
#統計
#經驗分享
#經驗收集
#聯邦信任
#背壓控制
#自動化
#自檢機制
#英文單字
#處置手冊
#術語
#訊息管理
#訊號偵測
#訊號關聯
#設定發布
#設計驅動
#診斷端點
#註解規範
#認知負擔
#語意搜尋
#證據包
#議題hub
#讀者旅程
#負載削峰
#負載平衡協議
#負載平衡器
#資安
#資安治理
#資安演練
#資料不一致
#資料保護
#資料分級
#資料生命週期
#資源限制
#資訊架構
#跨語言開發
#跨領域
#身分驗證
#軟體架構
#速率限制
#逾時
#選型訪談
#重構
#重複手動工作
#重複投遞
#重評估觸發器
#錯誤處理
#錯誤預防
#鍵盤
#開發原則
#開發工具
#開發流程
#開發策略
#閒置逾時
#降級
#除錯
#階段管理
#雜項
#需求澄清
#需求管理
#靜態網站
#響應式設計
#風險評估
#首頁
#驗收
#驗收條件
#驗收流程
#黏性會話