決策依據

Mock 夠用的場景

Test 驗證的行為完全在程式碼內部 — 函式邏輯、狀態機轉換、資料轉換、錯誤處理分支。這些行為不依賴外部服務的協議細節，mock 提供的 API 層模擬已經足夠。

判斷問題：如果把 mock 替換成真實服務，test 的斷言結果會不會改變？ 如果不會改變，mock 夠用。

例：ConnectionManager 收到 error 後是否正確切換到 error 狀態 — 不管 error 來自 mock 還是真實 WebSocket，狀態機邏輯相同。Mock 夠用。

Mock 不夠的場景

Test 要驗證的行為涉及外部服務的協議行為 — frame type 差異、認證流程、編碼格式、逾時行為。Mock 的 API 層模擬跳過了這些行為，test 通過不代表真實互動也通過。

判斷問題：Mock 跳過了外部服務的哪些步驟？這些步驟的行為是否影響 test 要驗證的結果？ 如果是，需要 protocol integration test（testing 模組三）。

例：sendData() 發送鍵盤輸入 — mock 的 sink.add(dynamic) 接受任何型別，但真實 IOWebSocketChannel 對 String 和 Uint8List 產生不同 frame type。Mock 不夠。

決策表

灰色地帶的判斷

有些 test 介於「mock 夠用」和「mock 不夠」之間。例如驗證「連線失敗時顯示 error 訊息」— 觸發失敗的方式可以是 mock 回傳 error（驗證顯示邏輯），也可以是真實服務拒絕連線（驗證真實失敗場景的處理）。

灰色地帶的判斷策略是：用 mock test 驗證「收到 error 後的處理邏輯」，用 protocol integration test 驗證「真實服務在什麼情況下回傳 error」。兩層 test 各自回答不同問題，不互相替代（testing 模組一 三層定義）。

Mock 邊界確定後，另一個影響 test 有效性的因素是測試資料的代表性 — 測試輸入能否反映真實環境。Mock 遮蔽的結構性原因在 testing 模組一 Mock 遮蔽機制分析中完整展開，判定需要真實服務後的成本評估見 testing 模組三 成本判斷表。

四個判斷維度

使用者數

自架方案的成本和使用者數幾乎無關（JSONL + grep 處理 1 個和 100 個使用者的成本差異很小）。商業方案按事件量或使用者數計費，使用者數增長直接推高費用。

經驗估算：使用者數在百人以下時，自架的總成本（開發 + 維護 + 硬體）通常低於商業方案的年費（以典型商業方案年費 $300-$600 和自架的開發維護時間估算）。使用者數在千人以上時，自架需要投入的基礎設施維護（高可用、擴容、備份）成本上升，商業方案的規模經濟開始有優勢。具體的交叉點取決於選用的 vendor 定價（Sentry Developer plan 免費額度 5000 events/月、PostHog 免費到 1M events/月）和自架的維護時間成本。

兩者之間是灰色地帶 — 取決於功能需求和團隊能力。

網路範圍

使用者和 collector 是否在同一個網路內。

同一網路（自用工具、內部工具）：自架方案直接 HTTP POST 到本機或內網 endpoint，不需要 DNS、TLS 憑證、CDN。成本極低。

外部網路（公開 app、SaaS）：自架方案需要處理公網暴露、DDoS 防護、TLS 憑證管理、高可用（多區域部署）。商業方案把這些基礎設施問題內化了。

功能需求

自架方案的功能上限是開發者願意投入的工程量。grep + jq 能做基礎查詢和 funnel 分析（模組八 自架 funnel）。Dashboard、告警、session replay、A/B test 分群每個功能都是數週到數月的開發量。

商業方案的功能開箱即用。如果需求包含 session replay、A/B test dashboard、自動 issue 分群，商業方案的功能完成度遠高於自架。

合規要求

資料必須存放在特定地區（GDPR data residency）或不能離開公司網路（金融、醫療）。

自架：資料完全在自己的基礎設施上，資料位置由自己控制。適合最嚴格的合規要求。

商業方案：資料存放在 vendor 的基礎設施上。部分 vendor 提供 data residency 選項（Sentry 的 EU hosting、Datadog 的 EU region），但仍然是第三方持有資料。

決策表

四個維度中三個以上指向同一方向 → 選那個方向。兩兩對半 → 從自架開始（成本低、可逆），需求增長後再評估切換。

決策表指向商業方案後，Sentry 深入和 Firebase 套件分別展開兩個主流方案的架構和能力邊界。決策表指向自架時，模組四 Collector 設計提供從 HTTP endpoint 到 rule engine 的完整實作藍圖。Server-side 的可觀測性（OTLP、Prometheus、Grafana）見 Backend 模組四 可觀測性。

中間路線

上表是「完全自架 vs 專業監控 SaaS」的兩端。中間還有兩條路徑 — 用 BaaS（Supabase + Vercel）搭出託管版 collector，或用 PaaS（Railway / Fly.io）跑自架 collector 原始碼但不管 server。APP 上線初期用免費方案零成本起步、保留自訂 schema 彈性是常見的起步策略。完整的四條路徑比較、架構差異、免費方案限額和遷移路線見部署光譜。

四個決策維度

Keyboard type：顯示哪種鍵盤

Keyboard type 決定使用者按下輸入框時出現什麼鍵盤。數字鍵盤、email 鍵盤、URL 鍵盤、一般文字鍵盤 — 每種鍵盤的按鍵配置和自動行為不同。

選擇判斷依據是「使用者要輸入什麼內容」。email 地址用 email 鍵盤（有 @ 鍵），電話號碼用數字鍵盤，密碼或 CLI 指令用 visiblePassword 型別（避免自動校正和建議）。

app_tunnel 的 terminal 輸入框用 TextInputType.visiblePassword — 因為 CLI 指令包含路徑分隔符、flag 縮寫等非自然語言內容，一般文字鍵盤會嘗試自動校正 ls -la 或 /usr/bin/ 成其他東西（U.C3）。

Submit model：怎麼送出輸入

Submit model 決定使用者輸入的內容何時傳送給系統。兩個基本選項：整行送出（使用者按 Enter/Send 後一次傳送整行）和逐字元送出（每個按鍵即時傳送）。

這個決策直接影響通訊協議設計（本章合成，UF-8 Derive）。整行送出代表每次傳送一個完整指令字串（ls -la\n），server 端按行處理。逐字元送出代表每個按鍵產生一個 WebSocket frame（l、s、 、-、l、a），server 端需要處理單字元輸入，包括 Tab 補全和 Ctrl+C 這類立即回應的操作。

app_tunnel 選擇整行送出（onSubmitted），代表 Tab 補全在 client 端無法觸發（因為 Tab 不會單獨送出），但實作成本較低且協議設計較簡單。逐字元送出支援 Tab 補全和命令編輯，但 protocol 複雜度顯著提高。

IME policy：輸入法的行為控制

IME（Input Method Editor）policy 控制手機輸入法的自動行為：自動校正、建議列、個人化學習。每個行為在某些輸入場景是幫助，在另一些場景是干擾或安全風險。

三個控制項各自有獨立的影響：

• autocorrect：自動校正把輸入替換成字典中的詞。CLI 指令和路徑不是自然語言，自動校正會破壞輸入內容。
• enableSuggestions：建議列在鍵盤上方顯示候選詞。在 terminal 場景中建議列遮擋畫面底部的終端機輸出。
• enableIMEPersonalizedLearning：IME 從使用者輸入中學習新詞，跨 app 適用。CLI 輸入可能包含密碼和路徑 — 這是安全問題，見 安全敏感輸入框的 IME 控制 checklist。

Special keys：特殊按鍵的處理

手機鍵盤沒有桌面鍵盤的 Esc、Tab、Ctrl、方向鍵。如果應用需要這些按鍵，必須自建 UI 元件提供。

app_tunnel 用底部工具列提供 Esc/Tab/Ctrl/方向鍵。這個工具列的設計（按鈕大小、排列、長按行為）是 UX 決策，不是實作細節。

決策表作為設計產物

四個維度的決策應該在功能規格中以表格形式記錄，讓 code review 時可以逐項對照實作是否符合規格。

app_tunnel 的六個 TextField 參數全是 W2 hotfix 事後補上的，沒有一個是事前規劃。每個參數都有 gotcha — 漏掉 enableIMEPersonalizedLearning: false 就是安全漏洞，漏掉 autocorrect: false 就是 UX 問題。事先決策並記錄在規格中，code review 時逐項勾選，比事後逐一發現問題的成本低。

四個維度在不同場景下的具體決策各有不同。CLI 場景的特殊需求見 Terminal app 輸入設計，安全敏感欄位的 IME 控制逐項列在 IME 安全 checklist。Submit model 的選擇（整行 vs 逐字元）直接影響通訊協議的設計 — 這個交叉影響在 testing 模組三 協議整合測試中從 test 的角度分析。

三個判斷維度

維度一：協議複雜度

程式碼和外部服務之間的協議是否存在 API 層無法描述的語意？

HTTP REST API 的協議複雜度相對低：request body 是 JSON、response body 是 JSON、status code 有明確語意。Mock 一個 REST endpoint（回傳固定 JSON）和真實 endpoint 的行為差異主要在效能和邊界案例，核心語意差距小。

WebSocket 協議的複雜度較高：連線握手、frame type（text / binary / ping / pong / close）、分片（fragmentation）、壓縮擴展（permessage-deflate）、子協議協商 — 這些語意在 API 層（sink.add(dynamic)）是不可見的。gRPC 的 streaming、deadline propagation、metadata header 也有類似特徵。

判斷問題：API 簽名是否隱藏了協議層的行為分支？ 如果 API 用 dynamic、Object、Any 等寬泛型別接受輸入，而協議層對不同輸入有不同處理方式，這就是需要 protocol integration test 的訊號。

app_tunnel 的 sink.add(dynamic) 就是這個模式 — API 簽名不區分 String 和 Uint8List，但協議層對兩者產生不同的 frame type（T.C1）。

維度二：Mock 寬鬆度

Mock 的行為是否比真實服務更寬容？

Mock 通常是「最小可用」的實作 — 能讓 test 通過就好。這意味著 mock 的行為往往比真實服務寬鬆：不檢查認證、不限制速率、不要求特定順序、不區分輸入格式。

寬鬆本身不是問題，但寬鬆程度和真實服務的差距決定了 mock 遮蔽的風險大小。判斷問題：Mock 跳過了真實服務的哪些步驟？每個被跳過的步驟在業務上是否關鍵？

app_tunnel 的 FakeWebSocketChannel 跳過了 auth handshake — ready 立即完成不需認證。Auth handshake 在業務上是關鍵步驟（沒有認證，ttyd 不推送資料），mock 跳過這一步讓「功能根本沒實作」變得不可見（T.C2）。

逐項列出 mock 跳過的步驟是一個實用的 audit 方法。寫出「FakeWebSocketChannel 和 IOWebSocketChannel 的行為差異清單」，每一個差異點就是潛在的遮蔽風險。

維度三：失敗靜默度

外部服務收到非預期輸入時，回應是明確的錯誤還是靜默忽略？

如果外部服務對錯誤輸入回傳 HTTP 400 或斷線，問題在實機測試時會快速浮現 — 程式碼進入 error 狀態，開發者看到明確的錯誤訊息。但如果外部服務靜默忽略，問題表現為「連線成功但沒有回應」，debug 方向可能完全錯誤。

ttyd 收到 binary frame 時靜默忽略，不回傳錯誤碼也不斷線。這讓問題的表現從「frame type 錯誤」變成「終端機無回應」，開發者的 debug 方向是「為什麼 terminal 沒反應」而非「為什麼 frame type 不對」。

判斷問題：外部服務是否有靜默忽略的行為？ 如果有，protocol integration test 的價值更高 — 因為即使在實機測試階段，靜默忽略也會增加 debug 成本。

決策流程

以下流程不追求完備覆蓋所有情境，而是提供一個起點，根據上述三個維度的組合判斷 protocol integration test 的必要性。

協議複雜度高（API 層和協議層有語意斷裂）： 需要 protocol integration test。即使 mock 寬鬆度低、失敗回報明確，語意斷裂本身就是 mock 結構性無法覆蓋的盲區。

協議複雜度低，但 mock 寬鬆度高（mock 跳過業務關鍵步驟）： 需要 protocol integration test。Mock 跳過的步驟越多，「功能缺失不可見」的風險越大。

協議複雜度低，mock 寬鬆度低： 依失敗靜默度判斷。如果外部服務靜默忽略錯誤，protocol integration test 有較高價值；如果錯誤回報明確，可以依賴實機測試階段的 error 來發現問題。

成本極低的情境： 當外部服務可以在 test 環境輕鬆啟動時（自用工具 server+client 同機、Docker 一行啟動的 open source service），protocol integration test 的成本門檻大幅降低，三個維度中任何一個有疑慮就值得寫。

下一步路由

• 想實作 protocol integration test → 模組三：協議整合測試
• 理解 mock 遮蔽的結構性原因 → Mock 遮蔽機制分析
• 反模式：試圖用更多 mock test 補救 → 反模式：用 mock 數量彌補 mock 盲區

服務啟動成本

服務啟動成本決定了 protocol integration test 的執行成本 — test 跑一次要多久、CI 中佔多少時間。

極低成本（同機單程序）

Server 是一個本機程序，Process.start 一行啟動，不需要 Docker、不需要網路、不需要設定檔。啟動到 ready 不到 2 秒。

app_tunnel 的 ttyd 就是這個場景。ttyd bash 在本機啟動，WebSocket 服務立即可用。整個 protocol integration test suite 的額外成本約 10-15 秒（包含啟動、健康檢查、5 個 test 各 2 秒）（本章合成，TF-8 Derive）。

在這個成本等級下，protocol integration test 幾乎沒有理由不寫。

低成本（Docker 單容器）

Server 用 Docker 容器啟動，需要 pull image（首次或更新時），啟動到 ready 約 5-30 秒。Redis、PostgreSQL、Elasticsearch 等 open source 服務屬於這個等級。

CI 中用 image cache 可以把 pull 時間降到接近零。但容器啟動時間仍比原生程序長。整個 protocol integration test suite 的額外成本約 30-60 秒。

在這個成本等級下，如果協議有任何複雜度（見下方），protocol integration test 值得寫。

中等成本（多容器堆疊）

Server 依賴多個服務（app server + database + cache + message queue），需要 Docker Compose 管理。啟動到所有服務 ready 約 30-120 秒。

Protocol integration test 的執行成本顯著上升。適合在 CI 的獨立 stage 跑（和 unit test 分開），避免拖慢 fast feedback loop。

高成本（外部服務 / SaaS）

Server 是外部 SaaS（Stripe API、AWS S3、第三方 OAuth provider），無法本地啟動。Test 需要打到 sandbox environment，有速率限制和網路延遲。

在這個成本等級下，consumer-driven contract test 可能比 protocol integration test 更實用 — 用 contract 定義期望的 request/response，在本地驗證 client 端行為，不需要每次都打到外部服務。

協議複雜度

協議複雜度決定了 mock 遮蔽的風險大小 — 風險越大，protocol integration test 的價值越高。

高複雜度：WebSocket（frame type、handshake、子協議）、gRPC（streaming、deadline、metadata）、MQTT（QoS level、retain、will message）。API 簽名隱藏了協議層的行為分支，mock 結構性地無法覆蓋。

中複雜度：HTTP REST API（多種 status code、error body 格式、認證流程、分頁）。核心語意（JSON request/response）差距小，但 edge case（error response 格式、header 要求）仍可能被 mock 遮蔽。

低複雜度：本地 IPC（Unix socket、named pipe）、標準格式的檔案讀寫。協議行為簡單，mock 和真實行為差距小。

判斷矩陣

「可選」代表 protocol integration test 有價值但不是必要 — 實機測試階段的手動驗證可能足夠。「實機測試替代」代表成本太高或收益太低，依賴實機測試階段的人工驗證。

成本和複雜度的評估結果決定了要建什麼等級的 test 基礎設施。Protocol integration test 定義提供這一層 test 的精確邊界，testing 模組一的判斷原則從 mock 遮蔽角度補充另一個判斷維度。決定要建之後，CI 中的服務 fixture 管理處理啟動和停止真實服務的工程問題。

這裡的數據來自一次 VM 實測：先手動拼裝一套 waybar + wofi + mako + hyprlock，再換成 Caelestia，量兩者的安裝大小、記憶體、config 結構與失敗行為。

資源足跡：差約一個數量級

整合式 shell 把整個桌面畫在一個程式裡，這個程式通常是重量級的 UI runtime。Caelestia 建在 Quickshell（Qt6/QML）上，實測安裝足跡如下：

差距的來源是 Quickshell 這個 UI 框架——那 213 MB 是 quickshell 套件本身的安裝大小（一個建在 Qt6 上的 QML shell runtime），不是 Caelestia 的功能程式碼；而且 Qt6 的函式庫（qt6-declarative、qt6-base 等）還是它之上的額外相依，沒算進這 213 MB。手動拼裝的 waybar、wofi、mako 都是輕量的 wlroots/GTK 程式，加起來還不到 5 MB。

這一軸在資源受限的機器上才會咬人：舊筆電、記憶體小的 VPS、或你本來就想把桌面壓到最輕。在一台記憶體充裕的桌機上，400 MB 對 60 MB 的差別多半感覺不到；在一台 2 GB RAM 的機器上，這就是「桌面吃掉五分之一記憶體」跟「幾乎不佔」的差別。

失敗半徑：單點 vs 各自獨立

整合式 shell 把狀態列、通知、鎖屏、啟動器畫在同一個程式裡，所以這個程式崩潰時，這些東西會一起消失。手動拼裝的每個元件是獨立行程，一個崩掉不影響其他——mako（通知）崩了，waybar（狀態列）還在。

這不只是理論。這次 VM 實測就撞到一個具體案例：Caelestia 的鎖屏是由 Quickshell 主程式畫的，當這個持鎖的程式被中止時，Hyprland 依 ext-session-lock 協議保持鎖定並顯示「lockscreen app died」的死局——狀態列、通知、鎖屏因為同源，一個環節出事就連帶整個桌面 UI。手動拼裝的 hyprlock 是獨立的鎖屏程式，它崩潰同樣會觸發那個死局，但你的狀態列與通知不會跟著沒。

這一軸在穩定性敏感或無人值守的場景最關鍵。跑長時間無人盯著的任務時，「一個元件崩掉只損失那個元件」的隔離性，比「全部整合在一起」的一致性更值錢——因為沒人在旁邊立刻重啟。

配色一致性：最容易被低估的一軸

讓整個桌面配色一致，是整合式與手動拼裝差別最大、卻最常被忽略的地方。整合式 shell 因為所有元件在同一個程式裡，天生共用一套配色——Caelestia 的 dynamic scheme 從桌布抽一組 Material-3 palette，狀態列、通知、鎖屏、dashboard 全部同時套用，換張桌布整套 UI 跟著變。

手動拼裝要達到同樣的一致，得自己解決一個跨程式的問題：每個元件用不同的設定格式與主題引擎，它們之間不會自動共享顏色。這次手動拼裝那套時就撞到這點——waybar 的 GTK CSS 引擎讀不到 Hyprland 的 $ 顏色變數，結果 waybar 的 style.css 裡得手抄一份跟 Hyprland colors.conf 相同的 hex 色碼。換一次配色，就要在 waybar CSS、wofi CSS、mako config、hyprland colors 好幾個地方各改一遍。

解這個手工問題的標準做法，是加一層模板工具（matugen、pywal、wallust 之類）：從一張桌布或一套色票，自動生成每個元件的設定檔（例如 matugen/templates/rofi-colors.rasi 就是給 rofi 用的顏色模板）。這等於是手動重建 Caelestia 內建的那套 dynamic theming pipeline。所以配色一致這件事的真正取捨是：Caelestia 開箱就有「換桌布全套跟著變」，手動拼裝要嘛手抄 hex、要嘛自己搭一條 templating pipeline。

config 結構

配色一致的差別，也反映在 config 的形狀上。Caelestia 的使用者設定集中在一個 shell.json（實測約 24 行就涵蓋狀態列、通知、idle 行為）。手動拼裝的設定散在各元件目錄、各用各的格式：waybar 的 config.jsonc + style.css、wofi 的 config + style.css、mako 的 config、hypr 的數個 .conf。集中的好處是好懂好改；散開的好處是每個元件可以獨立替換（把 waybar 換成 ironbar 不影響其他），代價是你要管更多檔案、更多格式。

選型判準

沒有一種在所有軸上都贏。依你的情境對照：

重新評估的訊號（tripwire）

選了之後，出現這些訊號時值得回頭重新評估：

• 選了整合式，卻發現一直在跟它的設計決策對抗（想改的結構它不讓你改）——你要的其實是手動拼裝的自由度。
• 選了手動拼裝，卻發現配色維護（每次改色手抄多個檔案）吃掉大量時間——該加 templating 工具，或重新考慮整合式。
• 記憶體壓力浮現（整合式的 Qt runtime 在小機器上排擠其他程式）——往手動拼裝退。
• 整合式的一次更新靜默破壞了你的自訂設定（Caelestia README 明言 config 可能無預警變動）——評估這層快速移動的依賴值不值得。

下一步

• 整合式 shell 的概念定位、跟 AGS/Eww 的比較、三個 repo 的分工，見 Caelestia 總覽。
• 手動拼裝那幾個元件（狀態列、啟動器、通知）各自怎麼配置，見 桌面 Shell 元件。
• 配色系統本身（不管哪條路線）怎麼設計，見 配色系統、鎖屏與 GTK 主題。

這篇的足跡數字（安裝 230 MB vs 4.5 MB、RSS ~400 MB vs ~60 MB）與 lock-died 失敗案例，來自一次在 Apple Silicon UTM VM 上實際跑過兩種桌面棧的量測。

本文是 Aurora family 內的決策取捨文章。聚焦 standard Aurora（Aurora PostgreSQL / MySQL，single-region managed SQL） 跟 Aurora DSQL（active-active distributed SQL） 之間的升級門檻判斷。兩個既有 SSoT 不在本篇重複：「PG → DSQL 怎麼遷」見 migrate-to-aurora-dsql；「DSQL vs Spanner vs CockroachDB 三方 distributed SQL 選型」見 aurora-dsql-spanner-decision-tree。本篇只回答「standard Aurora 夠不夠、要不要跨過去」。

多數團隊不需要 Aurora DSQL。Aurora PostgreSQL / MySQL 已經是 managed SQL、storage / compute 分離、跨 AZ 高可用、read replica 擴讀——絕大多數 OLTP workload 在這層就解決了。Aurora DSQL 是 2024-12 re:Invent preview、2025-05 GA 的 不同 paradigm 產品：PG wire-compatible 但底層是 active-active distributed、OCC + snapshot isolation、multi-region strong consistency。它解的是 standard Aurora 解不了 的特定問題，代價是放棄一部分 PostgreSQL 相容性與交易自由度。要不要跨過去，看 workload 是否真的撞到 standard Aurora 的結構上限。

時間錨點：Aurora DSQL 2024-12 preview、2025-05 GA。vendor 能力持續演進、實際決策前以 AWS docs 當前狀態為準。

核心差異：single-writer vs active-active

兩者的根本差異在寫入架構：

standard Aurora 的 storage 層雖然分散，compute 寫入仍是 single writer——這是它的結構上限。DSQL 把寫入也分散，代價是 SQL 相容性縮窄（PG 子集、extension 缺位）與交易語意改變（OCC，衝突要 application retry）。

該跨到 DSQL 的訊號

只有撞到 standard Aurora 結構上限的特定需求，才值得跨 paradigm：

• global write（多 region 都要低延遲寫入）：standard Aurora 跨 region 只有非同步副本、寫入要回到單一 writer region；真正需要多 region active-active 寫入 → DSQL
• single-writer 寫入上限撞牆：寫入量大到單一 writer instance（即使最大 instance class）撐不住、且無法用 sharding 簡單解 → DSQL 的水平寫入擴展
• region resiliency（單 region 失效仍要可寫）：standard Aurora 的跨 region failover 有 RPO/RTO 與寫入中斷；要求單 region 失效時其他 region 仍持續接受寫入 → DSQL active-active
• operational zero-touch：不想管 instance / failover / 容量 → DSQL serverless 模型（但這單項不足以跨 paradigm、要搭配上面的結構需求）

不該跨的訊號（standard Aurora 夠用）

以下情況跨 DSQL 是過度工程、且會付出相容性代價：

• single-region 夠用：寫入集中在一個 region、跨 region 只需要讀副本或 DR → standard Aurora
• 需要 PostgreSQL extension：依賴 PostGIS / pgvector / 特定 extension → DSQL 子集不支援、留 standard Aurora
• 複雜 / 長交易：依賴長交易、複雜多語句交易、特定 isolation 行為 → standard Aurora 的完整交易模型
• 寫入量 standard Aurora 撐得住：single writer 還有餘量 → 不必為「未來可能」預先跨 paradigm

9.C14 Standard Chartered 與 9.C4 DraftKings 是反向佐證：金融帳本 / 博彩這類高一致性、高關鍵 OLTP workload，在 standard Aurora 上就能同時拿到韌性與性能（DraftKings replication lag 降到 10-30ms 級、Standard Chartered 把韌性與性能當單一目標）。它們沒有跨到 distributed SQL——因為 single-region 強一致 + 跨 AZ 高可用已滿足需求。多數金融 OLTP 不需要 active-active multi-region write。

Scope warning：Standard Chartered / DraftKings 的 case 揭露其用 standard Aurora 達成韌性 + 性能（見 storage-architecture）；「它們不需要 DSQL」是本文基於其 single-region 強一致需求的推論、非 case 明文比較 DSQL。引用為「standard Aurora 已足夠多數高一致 OLTP」的訊號、不當 DSQL 對比的 case fact。

升級門檻決策流程

從需求判讀到路徑選擇的流程：

Step 1：確認是不是 global write 需求

寫入是否真的需要多 region 同時低延遲？還是只需要多 region 讀 + 單 region 寫？後者 standard Aurora（+ Global Database 讀副本）就解。

Step 2：確認 single-writer 是否真的撞牆

當前寫入量 vs 最大 instance class 上限、是否已嘗試過 read/write 分離、是否能用 application 層 sharding。撞牆才考慮 DSQL；沒撞牆是過早優化。

Step 3：檢查相容性代價

清點對 PG extension、長交易、特定 SQL 功能的依賴。依賴重 → DSQL 相容性子集會擋路、留 standard Aurora。

Step 4：若決定跨，走既有 SSoT

• 「PG → DSQL 怎麼遷」（protocol drop-in + paradigm shift、transaction retry 處理、extension 缺位）→ migrate-to-aurora-dsql
• 「DSQL vs Spanner vs CockroachDB 哪個 distributed SQL」→ aurora-dsql-spanner-decision-tree

Rollback boundary：跨 paradigm 是高成本決策——DSQL 子集相容性與 OCC 交易模型改變了 application 契約，回退到 standard Aurora 不是改 connection string 就好。決策前用一個非關鍵 workload 試點、確認相容性與 retry 行為，再擴大。

邊界與整合

為什麼這是「升級門檻」而非「遷移」

standard Aurora → DSQL 不是版本升級、是 paradigm 切換。Aurora PG/MySQL 用得好好的，不代表「升級到 DSQL 會更好」——多數情況會更差（失去 extension、交易要改、相容性縮窄）。只有 workload 真的需要 active-active multi-region write 或撞到 single-writer 上限，跨過去才划算。這跟「PostgreSQL major version upgrade」（同 paradigm、向後相容）是完全不同性質的決策。

Sibling 與 cross-link

• storage-architecture — standard Aurora 的 storage 分散但 compute single-writer 的結構上限根源
• global-database-multi-region — standard Aurora 的多 region 方案（非同步副本）、global write 需求前先確認這層夠不夠
• migrate-to-aurora-dsql — 決定跨之後的遷移 playbook（SSoT）
• aurora-dsql-spanner-decision-tree — 三方 distributed SQL 選型（SSoT）
• 替代路由：single-region 夠 → 留 standard Aurora；KV access pattern → DynamoDB
• 跟 Standard Chartered 9.C14 / DraftKings 9.C4 互引：高一致 OLTP 在 standard Aurora 已足夠的訊號

呈現決策時、預設選項清單應包含「現在不決定、先做 X 再回來」這一條 — 而且要主動標出、不是等使用者自己想到。

「立刻決定」與「拖延」之間有第三條路：結構性延後。延後有明確條件（例：等卡片補完、等 context 收斂、等下個 sprint），不是「再說啦」。沒主動給這個選項、使用者會被迫在 context 不足下做決策、產生品質低的選擇。

為什麼「立刻決定」是預設、卻常常錯

被問到時、對話的隱含壓力是「該答了」。這個壓力來自：

• 對話節奏（沒答 = 流程卡住）
• 禮貌（不答 = 不尊重對方）
• LLM / agent 預設「使用者問就執行」（沒延後機制）
• 「快速決策 = 高效」的迷思

這四條都不必然成立、合在一起變成預設。實際上有的決策本來就不該現在做 — 缺資訊、缺驗證、缺其他關聯決策的結果。在這種情境下「立刻決定」= 在錯誤時點做、品質差、後續還要重做。

三類該延後的決策

類別 1：依賴未完成的 context

需要先讀某些 code / 跑某些測試 / 看某些資料才能判斷。例：

• 「該用 strategy A 還是 B」依賴 A/B 各自的 cost — 還沒量
• 「卡片 X 該寫成 pattern 還是原則」依賴知識庫整體形狀 — 還沒看
• 「ship D 還是先做 B/C」依賴 D 的實作風險 — 還沒展開

延後條件：補完 context 即可決。

類別 2：依賴尚未發生的事件

需要等某個外部事件（其他 PR merge、其他人決策、某個觀測週期結束）。例：

• 「這個 feature 要不要保留」依賴使用者使用率 — 等 telemetry
• 「該不該 refactor X」依賴 Y team 的 migration 進度
• 「flag 何時拔掉」依賴觀測期長度

延後條件：事件發生 / 觀測期到。

類別 3：依賴上層決策

某個下層決策還在等上層決策、現在做下層 = 為上層猜測、可能要重做。例：

• 「這個 module 該怎麼分」依賴整體架構方向 — 還在討論中
• 「DB schema 怎麼設計」依賴功能範圍是否擴張

延後條件：上層決策落地。

主動提供「不決定」選項的範本

呈現決策表時、加最後一個選項：

1| 選項 | 適配性 |
2|---|---|
3| A ⋯⋯ | ⋯⋯ |
4| B ⋯⋯ | ⋯⋯ |
5| C ⋯⋯ | ⋯⋯ |
6| **延後（補 X 再決）** | 不立刻決、先 ⋯⋯、回來時 context 完整 |
7
8我推薦 A、不過如果 ⋯⋯（某個 context 還沒展開）、我建議先延後、補完 X 再回來決。

關鍵：主動標出延後條件 — 「補完 X」是具體可執行的動作、不是「再說啦」。延後不是 escape hatch、是有明確 next step 的另一種決策。

反模式：把「不決定」當失敗

何時不該延後

四類共同：延後的成本 > 決策品質的收益。其他情境保留延後選項。

跟其他卡的關係

判讀徵兆

核心：對話中「答 / 不答」是二元的、決策中「決 / 延後 / 拒絕決」是三元的。把延後當合法選項主動提供、品質會比強迫立刻決更好。延後不是禮貌性給出口、是工程上對「context 不足」的正確反應。

資安 audit 的 recommendation 是 ship 決策、不是評語。 把每個 weakness trace 到具體 tier、輸出可被 build process / publish gate 引用——不該停在「這裡可改善」的軟性建議。四個 tier 是 monotonic decision shape：

第四層是資安 audit 跟一般學術 peer review 的關鍵差異——學術 reject 會給投稿者改寫機會、本 audit 的 withdraw 是「保留 = 增加生產系統 risk」的硬決策。跟 #76 incremental shipping criteria 反向：可逆內容可分批 ship 改善、不可逆 risk 內容不能。

情境

audit 報告若只給「找到 N 個問題」的 flat list、團隊收到後無法決策、最後常變成「慢慢改」、article ship 跟 audit 改善的 timeline 完全脫鉤。Tier 化的 recommendation 把 weakness 轉成決策訊號：

 1Flat list（沒層級）：
 2- 第 3 段沒寫 threat model boundary
 3- 第 5 段 mitigation 沒寫 mechanism
 4- 第 7 段引用 OWASP 沒標版本
 5- 第 9 段 bcrypt work factor = 10、針對 nation-state 弱
 6
 7決策結果：「都有問題、找時間改」、實際上幾個月不會動
 8
 9Tiered（分層）：
10- Withdraw: 第 9 段 bcrypt work factor 描述會直接讓 reader 用 weak setting、必須改寫或移除
11- Major revise: 第 5 段 defense theater、整段重寫 mechanism + 前提
12- Minor revise: 第 3 段補 threat model 對稱、第 7 段補 OWASP 版本
13
14決策結果：第 9 段必須現在改、第 5 段下個 sprint 改、第 3/7 段順手補

層級給的是「先做什麼 / 什麼擋 ship / 什麼可緩」的明確排序、不是改善優先序的軟建議。

理想做法

四 tier 判準

每個 weakness 套這個決策樹：

 1Q1：reader 照這段實作會不會主動產生破口？
 2  是 → Withdraw（不可保留）
 3  否 → Q2
 4
 5Q2：weakness 是結構性（多 dimension 同時失效）還是局部（單一 dimension 缺）？
 6  結構性 → Major revise
 7  局部 → Q3
 8
 9Q3：補完 weakness 的 cost 是「補一句 / 一表」還是「重寫一段」？
10  一句 / 一表 → Minor revise
11  重寫一段 → Major revise
12
13Q4：weakness 在容忍範圍（背景段 / 低 stakes 段、reader 不會直接照做）？
14  在 → Accept（可選 minor 但不要求）
15  不在 → 走 Q3

各 tier 的 fix 模式

Withdraw 的具體訊號

什麼狀態算 withdraw？四個訊號：

1. 過時 crypto / hashing primitive 沒 deprecation 標記：教 MD5 / SHA-1 / 弱 PBKDF2 但沒明示「這是過時、不要用」
2. 扭曲 citation 改變原文語意：把 OWASP conditional 引成 unconditional、或反向違反現行標準（NIST 的 password 定期更換 case）
3. 違反 current best practice 的步驟說明：教讀者主動關閉 mitigation（disable HSTS / CSP / SameSite）作為 workaround、沒明示「workaround 引入的新 risk」
4. Defense theater 例子當示範：用名稱層 mitigation 對位（rate limit「擋」brute force）作為步驟、reader 照做不擋實際 mechanism

四訊號的共通：reader 照做後實作會主動 worse than not having read。Withdraw 不是嚴格、是 risk-asymmetric（#99）下的必要決策。

Audit report 輸出格式

學術 peer review 的格式對應到本 audit：

 1# Audit Report: <章節 / 文章 title>
 2
 3## Summary
 4<1-2 句：主要 audit 結論 + 整體 tier>
 5
 6## Strengths
 7- <段 / dimension 跟其優點>
 8
 9## Weaknesses by dimension
10
11### Threat model（[#101](../threat-model-explicitness/)）
12- [Tier]: 段 N、[具體 weakness 描述]、[fix 建議]
13
14### Mitigation 對位（[#102](../mitigation-threat-alignment/)）
15- ...
16
17### Context-dependence（[#103](../mitigation-context-dependence/)）
18- ...
19
20### Citation（[#104](../security-citation-currency-and-precision/)）
21- ...
22
23## Blocking conditions
24<必須 fix 才能 ship 的 weakness 清單、按 tier 排序>
25
26## Recommendation
27<Accept / Minor revise / Major revise / Withdraw + 整體決策說明>

格式跟學術 peer review 同骨、欄位對應 audit dimension（#101-104）、輸出可直接餵 ship gate 工具。

沒這樣做的麻煩

Audit 變評語、改善 timeline 跟 ship 完全脫鉤

flat list 的 audit 給「找到問題」、team 把問題列入 backlog、backlog 永遠排不到上面（#72 高 ROI 無外部觸發會被結構性跳過）。tier 化讓 audit 從「評語」變「ship 決策 input」、跟 timeline 強耦合。

Withdraw-level 內容繼續 ship、生產系統 risk 持續累積

最危險的 case 是 audit 找到 withdraw-level weakness（過時 crypto、扭曲 citation）但用 minor / major 處置——讓內容繼續存在並擴散。教學擴散 = silent gap 集體放大（#100 false sense of security），withdraw 是 cut-off 訊號、不是嚴格、是必要。

各 tier 之間的決策邏輯模糊、reviewer 之間判準不一致

沒明確 tier 判準、不同 reviewer 對同一個 weakness 給不同建議——有人覺得「補一行就好」（minor）、有人覺得「整段重寫」（major）、有人覺得「移除」（withdraw）。決策不一致 = audit 失去結構性 value、退化成個人意見集合。tier 判準（決策樹四問題）讓判準可重現、跨 reviewer 收斂。

跟其他抽象層原則的關係

判讀徵兆

適用範圍與邊界

• 適用：資安內容 audit 的產出格式（章節 audit / 文章 audit / 跨章節 review）；任何「reader 照做後錯誤不可逆」的高 stakes 領域 audit（concurrency 正確性、distributed consistency、financial / medical 計算）
• 不適用：一般技術內容 audit（不需要 withdraw tier、accept / minor / major 三層即可）、研究探討文章的 review（學術 reject 跟 withdraw 語意不同）
• 邊界：「Withdraw」≠「全文重寫」——可以是「移除有問題的段 + 加 deprecation 標 + redirect 到 current best practice 段」、不必整篇重做；判別準則：「reader 看到這個處置版本後、會不會用過時 / 扭曲版本實作？」——不會 → withdraw 處置 OK、會 → 需要更深的處置（移除整段 / 整篇）
• 過度 tier 化反例：把每個段都評 tier、文章變評分表、reviewer 投資爆炸；tier 投資量級對應內容對 reader 實作的影響——核心 mitigation 段需 tier、background 段直接 accept 即可

本卡是資安 audit 系列（#99-105）的決策面收尾、把 #101-104 四個 dimension 的 weakness 統合成 ship 決策。後續對應的 skill reference（auditing-articles.md）會以本卡的 tier + report 格式為輸出模板。