跨 X process content（migration / upgrade / rollout / 演練 / playbook）的結構不是 universal、由 source 跟 target 之間的 差異維度組合 決定。固定套「6-phase playbook」「6-section deep article」會在 結構錯位 的場景失效。

實證：6 種 migration / process type 產出 6 種不同結構：

6 種結構是 常見 type、不是窮盡分類；source / target 配對可能同時屬多 type（多軸 High）、或不屬任一 type（6 維皆 Medium）— 處理規則見「多重歸類跟 tie-breaking」段。本卡前身是「最大差異維度決定結構」+ 5 維 audit、Redis re-sharding dogfood 揭露 data topology 是漏掉的第 6 維、Type F 是對應的第 6 type；本卡擴張為 6 維 audit + 6 type。

為什麼 universal phased 模板會失效

寫第一篇 migration playbook 時自然會想：「6 phase 是 migration 的標準結構吧」 — 套到 drop-in compatible migration 後發現 80% phase 不需要、文章變成「為了 phase 而 phase」；套到 paradigm shift 後發現 phased 假設 線性收斂、實際是 永遠混合架構、phased 模板強迫一個 不存在 的「cleanup phase」。

Universal phased 失效的三個機制：

1. Schema 差不顯著時、phased 多數 phase 變空白：drop-in compatible（如 Redis → DragonflyDB）的「Schema translation phase」內容空、強寫變廢話
2. Operational 差是主軸時、phased 把 operational redesign 壓進「phase 1」變太薄：PostgreSQL → Aurora 的 operational model 重設計 是核心、不該壓在一個 phase
3. Paradigm 差時、phased 假設 source 完全消失：Kafka ↔ NATS 是 永遠共存、phased cleanup phase 假設不存在

→ 結構必須跟差異維度對位、不能反向假設。

Diff dimension audit：寫作前的必要 step

寫 process content 前先做 audit、列出 source 跟 target 在 6 個維度的差異程度：

主導差異維度對映常見 type：

• Schema = High（其他 Low） → Type A phased rule translation
• Operational = High（其他 Low） → Type C operational redesign hybrid
• Paradigm = High → Type E partial + 混合架構
• Components = High（一站式 → multi-tool） → Type D parallel streams
• Topology = High（其他 Low） → Type F topology re-layout（見 #128）
• 全 Low → Type B drop-in、6-section + audit prefix

第 6 維 Data topology 是後續從 Redis cluster re-sharding dogfood 浮現補位、見 #128 Data topology 是 process content 的第 6 audit 維度；本卡原為 5 維 audit、被第二輪 batch evidence 揭露盲點後擴張為 6 維。

多重歸類跟 tie-breaking

實際 source / target 配對 很少 完美對映單一 type；常見情境跟處理規則：

關鍵原則：主導維度決定主結構、其他高維度獨立加段、不強迫單一 type 標籤。Backlog 的「Type A/D 混合」「Type B/D 混合」標示是 維度組合 的簡記、不是承認 5 type 互斥失效；下表多重歸類處理規則才是正式判讀。

6 type 是 axis-aligned simplification、非窮盡

本卡 6 type 來自兩輪 migration playbook 的 dogfood 觀察（第一輪 5 篇 → Type A-E、第二輪 Redis cluster re-sharding → Type F）、是 已浮現的 type、不是 涵蓋所有 migration 的完備分類。已知漏類至少 3 種：

未來累積更多 migration playbook 後、可能浮現第 7-9 type（identity / consistency / residency 候選 — 對應 #128 跟 self-aware limitation update 揭露的候選軸）、或對 6 type 重構。本卡的 type 集合是 open、不是 closed。

6 種結構的 anatomy

**「結構 differentiator」**是本系列引入的概念：每篇 process content 在開頭加一段、明示這篇用什麼結構、跟其他同 category content 的結構差異在哪。功能類似 type signature — 讓讀者一開始就知道接下來的章節組織方式、避免套錯預期。例：drop-in migration 的「結構 differentiator」段會說「跟 phased migration 對照、本篇是 6-section + audit、不是 6-phase」。

Type A：Phased translation（schema 差為主）

1Phase 0 audit → Phase 1 schema 對位 → Phase 2 translation
2→ Phase 3 parallel run → Phase 4 cutover → Phase 5 cleanup

特徵：

• 線性 流程、phase 之間有 dependency
• 每 phase 有獨立 回退邊界
• Schema translation 是工作量主軸（4-12 週）

適用：Splunk → Elastic / Datadog APM → New Relic / MySQL → Postgres

Type B：6-section + audit prefix（drop-in compatible）

1為什麼遷 → 結構 differentiator → 相容性 audit
2→ Step-by-step cutover → 故障演練 → Capacity → 整合

特徵：

• 接近 deep article 6-section
• 多一段 相容性 audit（在 cutover 前列出風險點）
• 不需要 phased、單次 cutover

適用：Redis → DragonflyDB / OpenJDK → Adoptium / MariaDB → MySQL（部分版本）

Type C：Operational redesign hybrid

1為什麼遷 → 結構 differentiator → Operational redesign 對位
2→ 4-phase operational migration（Phase 0 audit + 3 active phase）→ Drop-in cutover → 故障演練 → Capacity → 整合

特徵：

• application code 不變、operational model 全換
• operational 表格對位 是內容主軸
• Cutover 本身簡單（protocol 相容）、operational 準備複雜

適用：PostgreSQL → Aurora / Self-managed Redis → ElastiCache / Self-managed Kafka → MSK

Type D：Parallel streams（multi-tool 拆分）

1為什麼遷 → 五個責任、五個 component → 5 parallel migration stream
2→ Stream-level audit / deploy / dual-ship / cutover → 故障演練 → Capacity → 整合

特徵：

• source 一站式、target N 個專責 component
• 每個 stream 獨立 audit / deploy / cutover、stream 間少 dependency
• 整體不是線性、是 staggered parallel

適用：Datadog → Grafana Stack / Splunk → Elastic + Tines + PagerDuty / Atlassian Suite → 各 specialized tool

Type E：Partial + 混合架構（paradigm shift）

1「不是 migration、是 paradigm 重設計」→ Paradigm 對位
2→ 什麼情境真的能換 → Application 重設計 → 部分 stream cutover → 長期混合架構

特徵：

• 不存在「complete migration」、是 按 use case 拆分 + 共存
• application 模式重設計（不是 SDK 換）
• 混合架構是 long-term default

適用：Kafka ↔ NATS / REST → gRPC / SQL → NoSQL / VM → Serverless

Type F：Topology re-layout（data topology = High）

1為什麼 re-layout → 結構 differentiator（re-layout 不是 migration）
2→ Pre-layout analysis（topology audit）→ Re-layout 機制
3→ Execution flow（per-step + rollback boundary）
4→ 故障演練 → Capacity / cost → 整合

特徵：

• Source / target 多數是 同 cluster 不同 state、不是跨 vendor
• 主軸是 topology audit + 重劃機制、不是 schema translation / paradigm shift
• Pre-layout analysis（識別 hot key / 當前 distribution）是 Type F 的核心 audit 段
• Execution flow per-step、含 rollback boundary

適用：Redis cluster re-sharding / PostgreSQL partition redesign / Kafka topic re-partitioning / Cassandra keyspace re-balance / 加 region / multi-master rollout

詳細 audit dimension 跟 sub-dimension 見 #128 Data topology 是 process content 的第 6 audit 維度。

跟 deep article methodology 的關係

Deep article methodology 的 6-section structure（問題情境 → 概念 → 配置 → 演練 → 容量 → 整合）是 single feature implementation 的模板、不是 cross-vendor process 的模板。Migration playbook 是 新 content category、需要自己的 methodology。

兩者關係：

• Single feature deep article：6-section、200-400 行、focused on how to implement / debug feature X
• Migration playbook：6 種 structure（依 diff dimension）、200-400 行 / 篇、focused on how to move from A to B
• 共同：問題情境 / 故障演練 / 容量 / 整合段；差異：中間「process / structure」段

寫前的 content category 判讀 是新方法論議題、不是 deep article methodology 涵蓋。

反模式

跟其他抽象層原則的關係

判讀徵兆

核心：Process content 的結構由 source / target 差異維度組合 決定、不是 universal phased / 6-section 模板。寫作前必須跑 6 維 diff dimension audit（schema / operational / paradigm / components / application change / data topology）、選對應主結構、其他高維度獨立加段；跳過 audit 會套錯模板、phase 變空白或 process 強行線性。

Self-aware limitation：本卡的 sample-driven over-fit 風險

本卡 5 type 來自 5 篇 migration playbook 的 dogfood 觀察、本身就是 N=5 sample 推導出 5 type taxonomy — 跟本卡批判的「universal phased 模板」「#122 cadence collapse」「#125 reduce 多維到單格」是 同骨錯誤。

本卡是 current best understanding、不是 已驗證的完備理論。Tripwire：

• 若下一輪 migration batch 浮現 無法歸進現有 5 type 的新 structure、應該擴充 type 集合而不是強行歸類
• 若同一 source/target 配對出現 結構翻轉（例 PostgreSQL → CockroachDB 在不同 application context 走不同主結構）、應該檢視 主導維度 規則是否需要動態化
• 若 type 數量擴張到 8+、應該評估是否該重構為 維度 × 維度 grid 而不是 type list

承認 limitation 本身是 dogfood — #122 cadence 同質化 講「natural attractor 不規劃就 collapse」、本卡的 5 type 就是 5 個 sample 的 natural attractor；不在卡內承認、就重複了 #125 隱形預設 的 collapse pattern。本段是 self-correction、不是 disclaimer。

Update（2026-05-19）：第二輪 migration batch 驗證 limitation

第二輪 migration batch（5 篇）跑完、self-aware limitation 三項預測得到驗證：

新發現（不在 self-aware limitation 預測內、需要後續處理）：

• 新 audit 維度浮現：re-sharding 揭露「data topology」是 5 維沒有的軸；audit 擴張為 6 維（加 topology 軸）已執行、見 #128 Data topology 是 process content 的第 6 audit 維度 + 本卡 audit table 新加 row 跟 Type F anatomy
• 「為什麼這篇不套」是漏類文章的好結構模板：major-version-upgrade 跟 cluster-resharding 都用這個 frame 開頭、明示跟 5 type 的邊界
• 「高維度獨立段」對照表自然在 multi-axis 文章浮現（cockroachdb 篇）— 應該升級為 multi-axis migration 的標準結構元素

Update（2026-05-19 第三輪 4-reviewer audit 後）：6 維擴張的未解結構性質疑

第三輪 audit 揭露本卡擴 6 維 + Type F 仍有 6 項未解結構性 issue。完整列表跟 acknowledgment 見 #128 Self-aware limitation 段、本卡這裡 cross-reference：

1. 6 維非窮盡：identity / consistency / residency 三軸候選
2. Type F 跟 Type B 結構重疊度高：實質差異只 2 段、可能下次 evolution 降為 Type B variant
3. 「不需要 parallel run」claim 部分不成立（multi-region rollout 例外）
4. 主導維度優先序是 audience-dependent heuristic、非 universal
5. 「topology 不能塞進既有 5 維」拒絕理由依賴 narrow 既有 5 維定義
6. 既有 5 篇 playbook 沒 retroactive audit（silent grandfathering）

本卡的 6 type / 6 維框架是 current best understanding、不是 final taxonomy；累積到 10+ migration playbook 後可能觸發 retroactive audit + framework restructure。

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 之間有差異