Process content 的 diff dimension audit 原本 5 維 — schema / operational / paradigm / components / application change — 漏了 data topology 這軸。Topology 是 資料在 cluster / partition / region 之間的分佈拓樸、跟既有 5 維任一個都不對等：

Data topology 是 資料分佈 層級的概念 — 跟資料結構（schema）、運維機制（operational）、抽象模型（paradigm）、組件數量（components）、application code 改動量（application change）並列為第 6 軸；topology 變動時其他 5 維可能完全不變、但 資料在 cluster / partition / region 之間的擺放方式 改變、需要獨立的結構處理。

擴 audit 到 6 維、新增 Type F「Topology re-layout」 結構對映 topology 高差異 的 process content。

Topology 的 5 個 sub-dimension

不同 source/target 配對對 topology 的影響不同、用 5 sub-dimension 描述具體變化：

任一 sub-dimension 變動就構成 topology layout 變動；多個 sub-dimension 同時變更（如「sharding strategy + region distribution 同時改」）是 complex topology migration、結構複雜度高。

為什麼 topology 不能塞進既有 5 維

Reviewer 質疑：為什麼不直接歸進 operational 或 paradigm？三個拒絕理由：

1. Schema 不變但 topology 變：PostgreSQL partition strategy 改（monthly → daily）— schema 完全相同、partition boundary 重劃；歸 Schema 維度錯位
2. Operational stack 不變但 topology 變：Redis cluster 加 node 重分 slot — Sentinel / monitoring / backup 不變、純粹是 slot mapping 重劃；歸 Operational 維度太寬
3. Paradigm 不變但 topology 變：Cassandra 從 single DC 加到 multi-DC — 同 distributed DB paradigm、co-location / replication topology 變；歸 Paradigm 維度誤導
4. Components 不變但 topology 變：Kafka topic re-partition（10 partitions → 100）— 同 1 個 cluster、partition count 變；歸 Components 維度錯位

Topology 是 獨立的問題軸、5 維 audit 漏掉時會誤判結構。

觸發 Type F 的情境

多數 Type F 場景是 同 vendor — 跟 #127 Type A-E 預設「跨 vendor」對應、Type F 是 同 vendor 內 topology 重劃。

6 維 audit decision rule（updated）

擴 audit 到 6 維後、type 對映規則更新：

主導維度判讀的優先序也擴張：Schema > Paradigm > Operational > Topology > Components。Topology 在 schema / paradigm / operational 之後、components 之前 — 因為 topology 對讀者 conceptual impact 通常比 components 拆分大、但比 schema / paradigm 小。

Type F「Topology re-layout」結構 anatomy

從 Redis cluster re-sharding 抽出的標準形態：

11. 為什麼 re-layout（4-N 種 driver）
22. 結構 differentiator（re-layout 不是 migration）
33. Pre-layout analysis（current topology audit / hot key / slot 分佈）
44. Re-layout 機制（slot migration / partition split / shard rebalance）
55. Execution flow（per-step、含 rollback boundary）
66. Production 故障演練
77. Capacity / cost
88. 整合 / 下一步

7-9 章節、200-260 行。三個 新元素 是 Type F 的核心承擔：

• Pre-layout analysis 段：在執行前列出當前 topology（slot 分佈 / hot key / replica lag / partition imbalance）、決定 re-layout 的範圍跟順序；缺這段、後續執行階段沒 baseline 可比、failure 偵測延遲
• Re-layout 機制段：解釋 vendor 的 slot migration / partition split / shard rebalance protocol —讀者要理解 vendor 內部機制才能預估 latency / locking / atomicity 邊界
• Execution flow per-step + rollback boundary：跟 Type A 的 phased 對照、Type F per-step 粒度更細（單 slot migration vs 整個 phase）、每 step 都要明示 能否回退、回退時資料狀態

跟 Type B 對照、Type F 多了「topology audit」段、Step-by-step 比 Type B 細（per-step 不是 per-cutover）；跟 Type A phased 對照、Type F 多數情境不需要 schema translation / parallel run / cleanup phase（source / target 同 cluster）；但 multi-region rollout 子情境例外、仍需 parallel run（兩 region 同跑後切流量）— 此時 Type F + Type A parallel run 段組合應用、見「多重歸類」規則。

注意 anatomy 列 8 row 是 規範形態、不是強制機械對映 — 實作上「結構 differentiator」+「pre-layout analysis」段可 inline 到開頭 audit 段（如 Redis cluster re-sharding 的「Source = Target，但 topology 重劃」段內聯處理）、實作 H2 數可能比 anatomy 列 row 少 1-2 個。

Production 反模式

跟其他抽象層原則的關係

判讀徵兆

核心：5 維 audit 漏 topology 是初始框架的盲點；topology 是 資料分佈 而非 資料結構 / 元件 / 抽象、需要獨立 audit 軸。Type F「Topology re-layout」對映 topology = High 的 process content、跟 Type A-E 並列；多軸 High 配對按 #127 多重歸類規則處理。

Self-aware limitation：本卡的 6 個未解結構性質疑

第二輪 4-reviewer audit 揭露 6 項結構性 issue、本卡選擇 meta-acknowledgment（記錄）而非 substantive restructure（重寫）— 跟 #127 self-aware limitation spirit 一致：

1. 6 維仍可能漏類：reviewer 提 identity / authorization / consistency / transactional / data residency 三軸候選；本卡確認 6 維是 current best understanding、不是窮盡；下一輪 batch 跑前優先驗證這些候選軸是否真的獨立
2. Type F 跟 Type B 結構重疊度高：anatomy 8 row 中 6 row 跟 Type B 對齊、實質差異在「pre-layout analysis + re-layout 機制」兩段；可能下次 evolution 是 Type B 的 variant 而非並列 type；保留現狀因為「同 cluster」邊界對讀者區分有用
3. 「不需要 parallel run」claim 部分不成立：multi-region rollout 子情境仍需 parallel run（兩 region 同跑然後切流量）— anatomy 已加註此例外、跟「多重歸類」規則組合應用
4. 主導維度優先序是 audience-dependent heuristic：DBA 視角 Topology 可能 > Operational、application developer 視角 Schema > Paradigm；當前 Schema > Paradigm > Operational > Topology > Components 預設是「跨 audience 平均」、非 universal；reviewer 識別此 stipulation 性質
5. 「topology 不能塞進既有 5 維」拒絕理由的窄定義依賴：4 個拒絕點都靠 narrow 既有 5 維定義成立；換個合理定義（如「component = 任何 cluster-internal primitive、包含 partition」）topology 跟 components 邊界會 collapse；保留現狀因為當前定義對寫作判讀有用
6. 既有 5 篇 playbook 沒 retroactive audit：6 維框架 retroactively 對既有 Type A-E 文章未重審；Splunk → Elastic / Datadog → Grafana / Postgres → Aurora 按 6 維可能變 multi-axis；這是已知 silent grandfathering、不是清白「擴張」

下一輪 batch trigger：

• 寫 1-2 篇 Type F dogfood 驗證 anatomy 通用性（Cassandra re-balance / PG partition redesign 是候選）
• 若浮現 Type F 跟 Type B 結構真同構、考慮降級為 variant
• 若浮現 identity / consistency / residency 真的獨立軸、再擴 audit 到 7 維
• 既有 5 篇 retroactive audit 在累積到 10+ migration playbook 後做、單獨成 retrospective report

Update（2026-05-19 第三輪 migration batch 後）：4 條 tripwire 全驗證

第三輪 migration batch（5 篇）執行了上述 4 條 trigger、各自結果：

3 軸候選驗證 detail：

• Identity axis：Vault → AWS Secrets Manager 45% 工作量在 identity model 對位（Vault token vs IAM principal）、不歸 schema / operational / application change；驗證 identity 可獨立發生 + 帶獨立工作量
• Consistency axis：DynamoDB strong → eventual 85% 工作量在 per-call-site contract review、不歸 paradigm / application change；驗證 consistency 可獨立發生 + 帶獨立工作量
• Residency axis：GDPR multi-region 40% 工作量在 compliance（DPIA / evidence collection / DPO sign-off）、reverse-constrain topology + operational + application；驗證 residency 不只是 driver、是 cross-cutting constraint

新浮現議題（不在原 tripwire 內）：

• Residency 是 cross-cutting constraint vs 獨立軸：reviewer 把 residency 歸為 driver、實證上是 cross-cutting constraint — 反向約束其他維度 + 帶獨立合規工作量；可能需要 constraint layer 概念跟 axis 並列
• Type F sub-type 浮現：multi-region rollout 跟 cluster re-sharding 是不同 sub-type；前者需 parallel run、後者不需；anatomy 在 sub-type 之間有差異

當批量 A 跟批量 B 是 sibling（同類 vendor / 同類角色 / 應有對等 coverage）、但 A 後寫卻超過 B、心智模型容易 collapse 到「A 是 reference template / B 是 baseline」的角色分配、忽略 B 才該 ≥ A coverage 的對稱性 priority。Priority 列表往往跳過 B、列其他「新領域擴張」選項。

問題不在 推某個 vendor、在 priority 評估維度漏掉 sibling symmetry。

Case：MySQL 18 篇 vs PG 11 篇後的 priority 列表

時間線：

1. PG 11 篇先寫完（autovacuum-tuning / declarative-partitioning / patroni-ha / pgbouncer-config / pitr-wal-archiving / logical-replication-debezium + 5 migration playbook）
2. MySQL 從 0 開始、user 要求「第一個示範服務、儘量都寫」、寫到 17 篇 deep article + migration playbook + 既有 migrate-to-postgresql = 18 篇 / 5715 行
3. 推薦下一步 priority 時、列「DynamoDB / Aurora / SQLite / MongoDB / CockroachDB / Spanner / Cosmos DB」、PG 不在列表
4. User 問：「為什麼這裡列的選項沒有 PG？我們做完了嗎？」

實際盤點：

• PG 11 篇 vs MySQL 18 篇、PG 缺 7 個 MySQL sibling deep article（replication-topology / online-schema-change-tools / query-optimization / lock-contention / vitess-sharding 對應 Citus / group-replication 對應 BDR / modern-sql-features 反向視角）
• PG 還缺 4 個 PG-only 議題（JSONB deep dive / Extension ecosystem / Full-text search / Replication slot management）

User 直覺 catch 到 coverage asymmetry、但我 priority 列表沒提供這個視角。

機制：為什麼會忽略

至少 5 個 priority bias 共同貢獻：

1. 「先存在就 mature」隱性假設

PG 11 篇先存在 → 直覺映射「PG 已 mature」。沒做 cross-sectional 對比：

• PG 11 篇 vs MySQL 18 篇、絕對量比較
• 議題覆蓋對應：MySQL 有哪些 deep article、PG 對應的是否都有

「11 篇」這個絕對數字 看起來合理、但跟 MySQL 18 篇對比後 結構性不足。心智模型把「合理」當成「mature」、跳過了相對性 audit。

2. 「新領域擴張」優於「既有領域對齊」的 progress bias

Priority 列表時、DynamoDB / Aurora / SQLite 等 vendor 看起來進度感強 — 從 0 推到 N、新領域擴張。PG 補齊看起來 重複勞動 — 從 11 推到 18、改善舊領域。

實際上：

• 新領域擴張 增加 surface area、但不改善既有結構
• 既有領域對齊 修補 baseline、是 reference template 成立的前提

當 baseline 跟 reference template 不對稱時、後者作為 示範服務 的價值打折扣 — 「MySQL 怎麼寫 vendor article」沒法 fully 套到 PG、因為 PG 本身不對稱。

3. Priority 評估維度漏 sibling symmetry

我用的 priority 評估維度：

• T1 vs T2 vendor 分類
• 領域重要度
• 已有量
• 新領域 vs 既有領域

漏掉的維度：

• Sibling vendor 對稱性（A 跟 B 同類、A 寫完後 B coverage 是否對齊）
• Reference template 跟 baseline 的關係（後寫的 reference template 應 ≤ baseline）

「Sibling 對稱性」這個維度不在預設 priority 評估清單、就被自動忽略。

4. Reference template vs Baseline 角色混淆

寫 vendor article 時、哪個是 baseline、哪個是 reference template 的心智模型可能反轉：

• 直覺：「先寫的 = baseline、後寫的 = reference / extension」
• 真實：「baseline 應 ≥ reference template coverage、不該倒過來」

MySQL 18 篇是 user-driven 要求 — user 明說「第一個示範服務、儘量都寫」。所以 MySQL 寫得多不是錯。但 PG 沒對齊到同水準 才是漏掉的紀律。

當 MySQL 寫到 reference template 規模、PG 還在 11 篇、心智模型容易 collapse 到「MySQL 是新 baseline、PG 是 legacy partial」、其實是 baseline 應該升級到 reference template 水準。

5. Sequential vs cross-sectional coverage 評估

寫作過程是 sequential —寫 MySQL 17 篇是一段時間、寫完看 git diff stat 確認進度、然後 priority 下一步。Coverage 評估是 point-in-time 的：

• Point-in-time（sequential）：「我這 batch 寫了多少」
• Cross-sectional（symmetric）：「我寫的這個跟 sibling 是否對齊」

寫 MySQL 第 17 篇時 self-cross-check：「PG 對應有沒有？」是 cross-sectional 行為、不是預設行為。

Priority 列表階段沒回頭跑 cross-sectional audit、就把 PG 排除。

修法

1. Priority candidate list 必須跑 sibling symmetry audit

提 priority 列表時、強制 cross-check：

• 列出該批量影響的 sibling vendor / sibling role
• 對比每個 sibling 的 coverage（篇數 + 議題覆蓋 mapping）
• 若有 asymmetry、把「補齊 sibling」加進 priority 列表 跟新領域並列

2. Vendors/_index「內容覆蓋進度」表加對稱性視角

當前內容覆蓋進度只列「已寫 / 未寫」、不列 sibling 之間相對進度。改善：

• 加 「跟 sibling 對應」欄：每個 article 標 sibling vendor 是否有對應
• 加 總計篇數 + sibling 對比 欄：直觀看到 asymmetry

3. 「先 mature baseline、再擴張」紀律

寫 vendor batch 時、紀律：

• 確認 baseline vendor 對齊到 reference template 水準、再推下一個 vendor
• 例外：user 明確要求先擴張某 vendor 時、加註 baseline 待對齊 為 known limitation

4. Audit dimension list 加 Coverage symmetry

跟 Data Topology as Audit Dimension 同型 —audit 維度可擴張。把 sibling coverage symmetry 加進 priority audit 維度：

• 既有維度：T1 / 領域 / 已有量 / 新 vs 既有
• 新增維度：sibling 對稱性（A 跟 B 同類時、coverage 對齊度）

跟既有原則的關係

• Data Topology as Audit Dimension：本卡是 priority 評估維度漏一個、同型但不同 axis
• Collapse is Implicit Default：priority 評估 collapse 到「新領域擴張」維度、是其變體
• Multi-Pass Review Frame Granularity Blindspot：multi-pass review 漏 catch 的同型、但本卡是 priority assessment 漏 catch、不是 review 漏 catch

反向驗證

不該誤用本卡：

• Sibling vendor 對稱性 不等於 每個 vendor 都該寫到同篇數。MySQL 18 篇對 PG 合理（兩大 SQL OLTP baseline），但 SQLite / DynamoDB / Spanner 各 18 篇不合理（領域窄 / niche audience）
• 對稱性 audit 是 對 baseline / reference template 雙方適用、不是擴張到所有 sibling
• 真正 niche vendor（如 Spanner / Cosmos DB 對小團隊）可以 明確 backlog 標記 minimum coverage、不必對齊 baseline

觸發再評估

未來累積到以下情境、本卡應重新 review：

• 寫第二個 baseline pair（02 cache Redis vs Memcached / 03 queue Kafka vs NATS 等）時、是否同樣踩 asymmetry blindspot
• 多 reviewer audit 是否能 catch coverage asymmetry（4-reviewer 沒設計這軸、之後 batch 可加 reviewer E coverage symmetry）
• Sibling 對稱性 audit 進工具化（vendors/_index 自動產 asymmetry warning）後是否解決