"Decision"
- Mock 邊界判斷決策表
什麼時候 mock 夠用、什麼時候需要真實服務 — 從 API 層 / 協議層 / 環境層的斷裂點判斷 mock 的適用範圍
- 自架 vs 商業的判斷決策表
使用者數、網路範圍、功能需求、合規要求四個維度判斷該自架還是用商業方案
- 輸入機制決策表
Keyboard type / submit model / IME policy / special keys 四個維度的決策框架 — 每個維度都是設計決策，影響 UI layout 和 protocol
- 判斷原則：什麼時候需要 protocol integration test
從服務架構特徵判斷是否需要 protocol integration test 的決策流程 — 協議複雜度、mock 寬鬆度、失敗靜默度三個維度
- 成本判斷表
什麼時候值得寫 protocol integration test、什麼時候用 contract test 或實機測試替代 — 根據服務啟動成本和協議複雜度判斷
- 整合式 Shell vs 手動拼裝：實測足跡、失敗半徑與選型判準
在整合式桌面 shell（如 Caelestia）與手動拼裝 waybar+wofi+mako 之間選型、需要實測的資源足跡、失敗半徑與配色一致性數據來判斷時回來讀
- Aurora PG/MySQL vs Aurora DSQL 取捨：何時 single-region managed 夠用、何時跨到 distributed
Aurora DSQL 不是 Aurora 的升級版而是不同 paradigm；本文聚焦『standard Aurora（single-region managed SQL）什麼時候夠用、什麼時候需要跨到 active-active distributed』的升級門檻決策，切分『怎麼遷』（migrate-to-aurora-dsql）與『DSQL vs Spanner vs CockroachDB 三方選型』（decision-tree）兩個既有 SSoT
- 「現在不決定」是合法選項：context 不足時延後決策
被問到時不一定要立刻答 — 「先補 context、回頭再決」是合法選項、卻常被當「拖延」忽略。LLM / agent 預設「問了就要立刻答」是錯誤前提：使用者有權延後到 context 補齊、推薦時應主動標出「也可選『先 X 再回來決』」。本卡是 #58 篩選三問、#74 決策呈現的時間軸延伸。
- 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 後改」的選項。