今天的 Workaround，明天的 Architecture：補償凝固命題

摘要

前五篇已依序建立軟體表觀完好、補償性完好、宣告架構與有效架構分離、Big Ball of Mud 的生存架構，以及技術債／架構侵蝕／歷史殘留的區分。這些命題共同導向一個尚未被完整回答的問題：

一個原本只是 temporary workaround、compatibility shim、manual step、shadow system 或 compensating control 的機制，究竟在什麼條件下會從「暫時支架」轉化成「不能隨意移除的真正架構」？

本文提出「補償凝固命題（Compensation Solidification Proposition）」。補償凝固不是單純指一個 workaround 存在很久，而是指補償機制在反覆使用、跨角色協調、外部依賴、隱性契約、操作常規與治理承認的作用下，逐步取得架構性地位，使其移除將改變系統的有效能力、契約、工作流或穩定性。

形式上，若補償 $C$ 在時間 $t$ 只是對某一缺口 $G$ 的局部修補：

C_t \rightarrow G_t

但隨著時間推進，出現：

\operatorname{Dependents}(C_t)\uparrow

\operatorname{RemovalCost}(C_t)\uparrow

\operatorname{ContractSurface}(C_t)\uparrow

則可能發生：

\boxed{ C_t \rightarrow A_{t+1} }

亦即補償開始成為有效架構的一部分。

本文綜合 workaround、organizational routines、shadow IT、enterprise-system misfit、Hyrum’s Law、compensating controls 與 security workaround 等相鄰研究，提出「補償凝固階梯」「架構重量」「凝固指數」「去凝固條件」與「替代先於移除」原則。本文並指出：補償凝固不必然是負面事件。有些補償應被淘汰，有些應被正式吸收為架構，有些則應維持為明確、可觀測、可退出的韌性機制。

對 Dynamic MSSP/FPL 而言，這意味著架構治理不能只問：

「這是 workaround 嗎？」

而必須進一步判斷：

它目前只是 workaround，還是已經成為 effective architecture？

**關鍵詞：**補償凝固、workaround、implicit interface、Hyrum’s Law、organizational routines、shadow IT、compensating controls、有效架構、Dynamic MSSP、FPL

1. Temporary 往往是軟體工程裡最危險的形容詞

許多大型系統裡都有這類註解：

TEMPORARY
TODO remove after migration
compatibility only
workaround for issue #1827
delete after client v2 sunset

工程師的預期是：

C(t_0)

只會短暫存在。

但幾年後：

TODO remove after migration

還在。

而且它旁邊已經長出了：

新 API；
新 consumer；
新 monitoring；
新部署程序；
新 migration；
新 exception；
新文件；
新客服 SOP。

此時最大的錯誤是仍然把它理解成：

「一個忘記刪掉的小 workaround。」

因為真正發生的可能是：

C_{\text{temporary}} \rightarrow C_{\text{repeated}} \rightarrow C_{\text{depended}} \rightarrow C_{\text{structural}}

也就是：

它已經凝固了。

2. 存在很久，不等於凝固

首先必須區分：

Persistence

與：

Solidification

一個 workaround 可以存在十年，但從未被任何其他東西依賴。

例如：

rare emergency script

只有在極特殊事件才使用，而且可被完全替換。

它的：

T_{\text{age}}

很高，

但：

D_{\text{dependent}}

很低。

反過來，一個剛出現三個月的 compatibility behavior，可能已經被上百個 consumer 使用。

因此：

\boxed{ \text{Age} \neq \text{Solidification} }

補償凝固的核心不是「存在多久」，而是：

它是否已經改變其他結構的行為與假設。

3. Workaround 的持續存在需要協調

Davison、Wong、Ou 與 Alter 對跨國企業系統 workaround 的研究提供了一個非常重要的線索。

當 global enterprise system 不符合 local reality 時，員工創造了不符合 corporate IT policy 的 workaround，但這些 workaround 仍然使 essential activities 得以完成，並創造企業與客戶價值。

更重要的是：

workaround 的 coordination 對其 persistence 至關重要。

這意味著 workaround 並不是只靠「某個人偷偷做」才能存在。

它可能逐步經歷：

個人知道
→ 團隊知道
→ 團隊協調
→ 跨角色配合
→ 固定交接
→ 固定輸入輸出

一旦如此，補償就開始形成：

\text{Relation Structure}

而「關係結構」正是架構的核心材料。

4. Organizational Routines：補償可以改變正常工作

organizational-routines 研究對 workaround 的另一個重要觀察是：

個人 workaround 不只影響本人，也可能影響其他員工的活動，進而改變組織層級的工作常規。

因此：

C_i

原本只是個人行為，

但如果：

C_i \rightarrow R_j \rightarrow R_k \rightarrow R_{\text{org}}

其中 $R$ 表示 routine，

那麼 workaround 已經從：

Local Adaptation

變成：

Organizational Routine

此時即使資訊系統本身沒有改：

S_{\text{software}}(t_0) = S_{\text{software}}(t_1)

有效系統仍然可能已改變：

S_{\text{effective}}(t_0) \neq S_{\text{effective}}(t_1)

因為人類層架構變了。

5. Hyrum’s Law：行為一旦被依賴，就形成隱性介面

補償凝固在純軟體世界中也有非常清楚的對應。

Hyrum’s Law 指出：

當 API 使用者足夠多時，不論正式 contract 承諾什麼，所有可觀察行為最終都可能被某個 consumer 依賴。

形式上：

C_{\text{formal}} \subseteq C_{\text{effective}}

而：

C_{\text{implicit}} = C_{\text{effective}} - C_{\text{formal}}

其中：

C_{\text{implicit}}

就是隱性契約。

假設一個 workaround 改變：

response order；
latency；
error string；
retry timing；
output format；
null behavior；
migration sequencing。

如果外部 consumer 開始依賴這些行為：

\operatorname{Dependency}(C)\uparrow

則原本只是 workaround 的實作細節，已經開始形成：

Implicit Interface

這就是補償凝固最典型的軟體路徑之一。

6. Shadow IT：workaround 甚至可以長成新的子系統

Shadow IT 提供另一種更直觀的凝固方式。

當正式系統無法滿足需求時：

Official System
    ↓
   gap
    ↓
Excel / SaaS / Script / Database

最初可能只是：

「先這樣處理一下。」

但若：

多人共用；
有固定資料；
有權限；
有流程；
有版本；
有報表；
有交接；
有 downstream consumer；

那麼：

C_{\text{shadow}}

已經具備大量 subsystem 特徵。

因此：

\text{Shadow IT} \subseteq A_{\text{effective}}

可能成立，

即使：

\text{Shadow IT} \not\subseteq A_{\text{declared}}

這就是前一篇「架構殘差」的一個具體來源。

7. 補償凝固的正式定義

本文將補償凝固定義為：

原本為填補局部缺口而存在的補償機制，在反覆使用、協調、依賴、契約形成與運行整合的作用下，逐步取得不可忽略的架構性功能，使其移除會顯著改變系統有效行為的過程。

令補償為：

C

若在時間 $t$ ：

\exists X: X \overset{e}{\rightarrow} C

其中：

\overset{e}{\rightarrow}

表示有效依賴，

並且移除 $C$ 造成：

\Delta I_o < 0

或：

\Delta F_v < 0

或破壞有效契約：

\Delta K_e \neq 0

則 $C$ 已經具有：

Architectural Weight

即架構重量。

8. 架構重量不是二元值

一個補償不是突然從：

workaround = true

跳成：

architecture = true

更合理的是定義：

W_A(C,t)

表示補償 $C$ 在時間 $t$ 的架構重量。

可概念化為：

W_A = f( P, D, K, R, C_s, O, S )

其中：

$P$ ：Persistence，持續性；
$D$ ：Dependency，依賴量；
$K$ ：Criticality，關鍵性；
$R$ ：Removal Cost，移除成本；
$C_s$ ：Contract Surface，契約表面；
$O$ ：Operational Integration，操作整合；
$S$ ：Substitutability，可替換性。

其中：

S\uparrow \Rightarrow W_A\downarrow

通常成立。

如果一個 workaround 可在五分鐘內被完全替換，

它的架構重量自然較低。

9. 補償凝固階梯

本文提出六階段模型：

C_0 \rightarrow C_1 \rightarrow C_2 \rightarrow C_3 \rightarrow C_4 \rightarrow C_5

$C_0$ ：Transient Workaround

一次性補償。

例如：

手工重跑一次

沒有持續依賴。

$C_1$ ：Repeated Workaround

相同補償反覆發生。

每週都需要重跑

此時：

\operatorname{Frequency}(C)\uparrow

但仍可能只有一人知道。

$C_2$ ：Coordinated Compensation

其他人開始配合。

例如：

客服先標記
→ 財務匯出
→ 工程師跑 script
→ 財務確認

workaround 開始形成流程。

$C_3$ ：Dependent Compensation

其他模組、流程或人開始依賴它。

\operatorname{Dependents}(C)>0

此時它已經不能被視為孤立補丁。

$C_4$ ：Implicit Contract

外部或內部 consumer 對補償產生穩定期待。

例如：

一定在凌晨 2 點完成；
一定保持某排序；
一定輸出某欄位；
一定由人工核准；
一定會 retry 三次。

此時：

C \rightarrow K_{\text{implicit}}

$C_5$ ：Effective Architecture

補償已經成為：

A_e

的一部分。

即使 architecture document 沒承認它：

C\notin A_d

仍然可能：

C\in A_e

這就是補償凝固完成。

10. 凝固不是只有「變正式」

一個常見誤解是：

workaround 被寫進文件後才算架構。

不對。

文件化只是：

F_{\text{formalization}}

其中一個維度。

一個完全 undocumented 的人工流程也可能：

W_A\gg0

如果：

每天都跑；
沒有它訂單無法完成；
三個部門依賴；
客戶結果依賴；
停止後會造成錯帳。

所以：

\boxed{ \text{Formalization} \neq \text{Architectural Existence} }

這正是「有效架構」概念存在的必要性。

11. 補償凝固的四條主要路徑

目前可以整理成四條典型路徑。

11.1 Workaround → Routine

\text{Individual Workaround} \rightarrow \text{Coordination} \rightarrow \text{Organizational Routine}

主要發生在人類與操作層。

11.2 Implementation Detail → Implicit Contract

\text{Observable Behavior} \rightarrow \text{Consumer Dependence} \rightarrow \text{Implicit Interface}

Hyrum’s Law 是核心對照。

11.3 Temporary Control → Governance Structure

例如 NIST 所稱 compensating control。

原本：

baseline control 無法採用，先用替代控制。

若替代控制長期被正式評估、審核、稽核與依賴，

它可能：

C_{\text{temporary}} \rightarrow C_{\text{governed}}

最後成為正式治理架構。

因此補償凝固不一定是失敗。

它也可能是：

系統找到比原始方案更合適的長期結構。

11.4 Shadow Tool → Effective Subsystem

\text{Spreadsheet} \rightarrow \text{Shared Spreadsheet} \rightarrow \text{Workflow} \rightarrow \text{Shadow Database} \rightarrow \text{Operational Subsystem}

這在 enterprise environment 尤其常見。

12. 凝固的正向版本：補償可能是架構發現機制

這是一個非常重要的反轉。

假設正式系統：

A_d

無法處理某種 local reality。

員工反覆產生：

C

而且 $C$ ：

穩定有效；
被多人採用；
解決相同缺口；
不斷創造價值。

那麼：

C

不一定代表：

「人們一直違規。」

它可能代表：

正式架構漏掉了一個真實需求。

因此補償凝固可以被當成：

Architecture Discovery Signal

即：

C_{\text{persistent}} \rightarrow \text{Possible Missing Capability}

這對 Dynamic MSSP 極重要。

13. 凝固的負向版本：臨時缺陷被依賴後變得難以修復

另一方向當然存在。

一個 bad workaround：

return empty list instead of raising error

原本只是為了避免 crash。

後來：

Client A
Client B
Client C

全部開始依賴：

empty list means retry later

此時：

\text{Bug-like Behavior} \rightarrow \text{Implicit Contract}

如果現在「修正」成正規 exception：

\text{Fix} \rightarrow \text{Break Consumers}

這就是：

Pathological Solidification

即：

不良行為因依賴形成而取得架構重量。

因此：

\text{Bad Origin}

不代表：

\text{Easy Removal}

14. 凝固指數

為了後續 Dynamic MSSP 的機器判斷，本文提出概念性的：

Solidification Index

記為：

\Gamma_C(t)

可由以下維度構成：

\Gamma_C = \alpha P + \beta D + \gamma K + \delta R + \epsilon C_s + \zeta O - \eta S

其中：

$P$ ：持續性；
$D$ ：依賴程度；
$K$ ：關鍵性；
$R$ ：移除成本；
$C_s$ ：契約表面；
$O$ ：操作整合程度；
$S$ ：可替換性。

注意：

這不是已驗證量表。

它是一個研究骨架。

目的不是假裝：

\Gamma_C=0.73

就具有普世客觀意義，

而是迫使架構治理系統回答：

為什麼我們認為它已經凝固？

15. 一個更強的判定：反事實移除測試

最有價值的判定可能不是年齡，也不是程式碼大小。

而是：

Counterfactual Removal Test

問：

如果明天把 $C$ 完全移除，什麼會失效？

形式上：

S^{-C}

表示移除補償 $C$ 後的系統。

若：

I_o(S^{-C}) \ll I_o(S)

或：

F_v(S^{-C}) \ll F_v(S)

或有大量：

\operatorname{BrokenDependents}(C)

則 $C$ 已具有高度架構重量。

這比：

「它是不是 workaround？」

更重要。

16. 替代先於移除原則

前幾篇已經得到：

\text{Remove Compensation} \rightarrow \text{Expose Latent Failure}

的可能性。

本文將它正式收斂成：

Replacement-Before-Removal Principle

若 $C$ 已承擔責任：

R(C)

則安全移除需要：

\exists X: R(X)\supseteq R(C)

並且：

\operatorname{Dependents}(C) \rightarrow X

已完成遷移。

因此：

\boxed{ \text{Retire}(C) \text{ only after } \text{Transfer}(R(C)) }

這對 AI 自動重構尤其重要。

17. 去凝固不是刪除，而是解除依賴

真正的：

De-solidification

不是：

delete workaround

而是：

識別責任
→ 找出依賴
→ 建立替代
→ 遷移 consumer
→ 觀察 residual usage
→ 降低架構重量
→ 最後移除

形式上：

\operatorname{Dependents}(C,t)\downarrow

W_A(C,t)\downarrow

直到：

W_A(C,t)\approx0

這時才真正安全退出。

18. 補償凝固與歷史殘留的差別

上一篇定義：

H = \text{Historical Residue}

這與補償凝固非常接近，但不相同。

歷史殘留強調：

過去留下來。

補償凝固強調：

留下來後被新的結構依賴。

因此：

H \not\Rightarrow \text{Solidified}

例如完全沒人用的 deprecated field 是 residue，但未凝固。

反過來：

\text{Solidified Compensation}

幾乎必然具有某種當前依賴。

所以凝固關注的是：

Current Structural Dependence

而不只是歷史來源。

19. 補償凝固與技術債的差別

同樣：

D \neq \Gamma_C

某個 compensation 可以是 technical debt，

也可以完全不是。

例如：

Case A：健康凝固

temporary compensating control 經風險評估證明比 baseline 更適合，最後成為正式長期控制。

它：

\Gamma_C\uparrow

但不必然：

D\uparrow

Case B：債性凝固

shortcut 被大量依賴，每次修改都增加成本。

此時：

\Gamma_C\uparrow

同時：

D\uparrow

20. 補償凝固與架構侵蝕的差別

凝固也不必然等於 erosion。

如果：

A_d

及時更新，把經驗證有效的補償納入正式架構：

C\in A_d

那麼：

\Gamma_C\uparrow

但：

E

可能下降。

反之，如果補償大量凝固但架構文件完全不更新：

A_d \neq A_e

差距擴大，

則：

E\uparrow

可能成立。

因此補償凝固描述的是：

依賴與結構化。

architecture erosion 描述的是：

偏離與退化。

21. Dynamic MSSP：Compensation 必須是一等物件

由此，Dynamic MSSP 不應只建模 module。

還需要：

compensation:
  id: legacy_empty_response_behavior

  origin:
    type: workaround
    introduced_at: 2022-04-17
    reason: "avoid client crash during partial outage"

  role:
    declared: temporary
    effective: compatibility_contract

  solidification:
    persistence: high
    dependents: 37
    criticality: high
    removal_cost: high
    substitutability: low
    contract_surface:
      - response_shape
      - retry_semantics

  evidence:
    - runtime_trace
    - client_repository_search
    - incident_history
    - support_ticket

  recommendation:
    action: migrate_before_remove
    confidence: 0.91

此時 MSSP 的工作不是：

TEMPORARY TOO OLD → ERROR

而是：

Temporary 已經變成什麼？

22. AI 的任務：發現依賴，而不是猜作者本意

補償凝固非常適合 AI 輔助，因為依賴證據可能散落在：

code；
API usage；
tests；
git；
issue；
runbook；
ticket；
chat；
runtime；
metrics；
incident history。

AI 可以提出：

H_C = \text{Solidification Hypothesis}

但必須附：

E_C = \text{Evidence Set}

以及：

q_C = \text{Confidence}

因此：

\text{AI} \rightarrow (H_C,E_C,q_C)

而不是：

\text{AI} \rightarrow \text{Delete}

23. AI 時代會讓補償凝固更快

這也是 2026 年後尤其需要注意的問題。

Agentic development 會降低：

C_{\text{implementation}}

也就是建立：

script；
adapter；
agent；
workflow；
integration；

的成本。

因此：

V_{\text{workaround creation}}\uparrow

可能導致：

N_{\text{workarounds}}\uparrow

更重要的是，AI 可以在數小時內把一個 workaround：

script

擴張成：

service
+ API
+ UI
+ database
+ agent

所以：

T_{\text{solidification}} \downarrow

即補償凝固時間可能顯著縮短。

這也是為什麼 AI-native architecture governance 不能只靠半年一次 architecture review。

24. 從 Shadow IT 到 Shadow AI

2026 年企業已經開始面對：

Shadow AI

也就是員工在正式治理外使用：

external AI；
autonomous agent；
vibe-coded app；
automation；
personal workflow。

這比傳統 Shadow IT 更容易快速形成有效子系統。

一個人今天做：

AI summarizer

下週可能：

整個團隊用

下個月：

另一流程依賴輸出

於是：

C_{\text{shadow-ai}} \rightarrow A_e

的速度可能比傳統 spreadsheet 快得多。

因此「補償凝固」在 AI 時代不是邊緣現象，而可能成為常態架構形成機制。

25. 三種治理結果：吸收、替換、保留

當 Dynamic MSSP 發現：

\Gamma_C

很高時，

不代表唯一動作是刪除。

至少有三種結果。

25.1 Absorb

補償被證明合理。

則：

C \rightarrow A_d

正式納入架構。

25.2 Replace

補償有效，但成本／風險太高。

則：

C \rightarrow X

先建立替代再遷移。

25.3 Preserve

補償本身就是合理韌性或 emergency mechanism。

則保留，但要求：

ownership；
observability；
test；
activation condition；
exit condition；
review。

所以：

\text{Solidified} \not\Rightarrow \text{Remove}

26. 命題 6：補償凝固命題

本文正式提出系列第六命題：

補償凝固命題

對補償機制 $C$ ，若其在系統演化中持續形成新的依賴、操作常規與隱性契約，使移除 $C$ 會顯著破壞系統有效能力，則 $C$ 將由補償機制逐步轉化為有效架構構成：

\boxed{ C_t \rightarrow A_{t+1} }

其核心判斷不是：

\text{Age}(C)

而是：

\boxed{ \operatorname{Dependence} + \operatorname{Criticality} + \operatorname{Contract} + \operatorname{RemovalCost} }

並可用架構重量：

W_A(C,t)

與凝固指數：

\Gamma_C(t)

進行概念性描述。

27. 更強版本：架構本身可以由 workaround 生成

這個命題最後其實會得到一個比預期更強的推論。

一般想像：

\text{Architecture} \rightarrow \text{Implementation} \rightarrow \text{Operations}

但真實系統也可能反向：

\text{Workaround} \rightarrow \text{Routine} \rightarrow \text{Dependency} \rightarrow \text{Contract} \rightarrow \text{Architecture}

因此：

\boxed{ \text{Architecture Formation} \text{ can be bottom-up} }

這正是 Dynamic MSSP 必須比靜態架構語言更動態的原因。

28. 結論：今天的例外，可能是明天的本體

本文從一句工程世界非常熟悉的話開始：

「這只是 temporary workaround。」

但系統演化告訴我們：

temporary 不是本體屬性。

它只是一個當下意圖。

真正決定未來地位的是：

是否被反覆使用；
是否被協調；
是否被依賴；
是否形成隱性契約；
是否被操作流程吸收；
是否存在可替代方案；
移除後是否破壞有效系統。

所以：

\boxed{ \text{Temporary Intent} \nRightarrow \text{Temporary Existence} }

而：

\boxed{ \text{Repeated Compensation} + \text{Dependency} + \text{Contract Formation} \rightarrow \text{Architectural Solidification} }

最終：

\boxed{ C_t\rightarrow A_{t+1} }

因此，真正危險的不是：

workaround 存在。

而是：

workaround 已經成為架構，但我們仍然假裝它只是 workaround。

同樣地，真正的機會也在這裡：

某些反覆有效的 workaround，可能是在告訴我們原本架構漏掉了真實世界。

Dynamic MSSP 的責任因此不只是抓違規。

它還要辨認：

哪些違規正在腐蝕架構？

哪些 workaround 應該被淘汰？

哪些補償已經變成不可忽略的有效架構？

哪些甚至應該被正式吸收到下一版架構中？

下一篇將接著處理另一個問題。

假設我們成功重構、清理、集中或替換了一個補償：

複雜度真的消失了嗎？

還是只是從一個位置移到了另一個位置？

〈修好真的比較簡單嗎？複雜度轉移與重構悖論〉

將正式研究：

\operatorname{Complexity}_{t} \rightarrow \operatorname{Complexity}_{t+1}

以及：

\text{Repair} \not\Rightarrow \text{Total Complexity Reduction}

參考文獻

Davison, R. M., Wong, L. H. M., Ou, C. X. J., & Alter, S. (2021). The Coordination of Workarounds: Insights from Responses to Misfits Between Local Realities and a Mandated Global Enterprise System. Information & Management, 58(8), 103530. https://doi.org/10.1016/j.im.2021.103530
Wolf, V., & Beverungen, D. (2019). Conceptualizing the Impact of Workarounds – An Organizational Routines' Perspective. ECIS 2019 Research-in-Progress Papers.
Wibisono, A., Sammon, D., & Heavin, C. (2022). Opening the Workaround Black Box: An Organisational Routines Perspective. Journal of Decision Systems. https://doi.org/10.1080/12460125.2022.2073647
Malaurent, J., & Karanasios, S. (2020). Learning from Workaround Practices: The Challenge of Enterprise System Implementations in Multinational Corporations. Information Systems Journal, 30, 639–663. https://doi.org/10.1111/isj.12272
Wright, H. Hyrum’s Law. https://www.hyrumslaw.com/
Harrand, N., Benelallam, A., Soto-Valero, C., Bettega, F., Barais, O., & Baudry, B. (2019). API Beauty Is in the Eye of the Clients: 2.2 Million Maven Dependencies Reveal the Spectrum of Client-API Usages. arXiv:1908.09757.
Shaikh, A. (2021). Shadow-IT System as a Workaround: A Theoretical Review. MENACIS2021.
White, M. S. (2023). Workarounds and Shadow IT – Balancing Innovation and Risk. Business Information Review, 40(3), 114–122.
NIST. Special Publication 800-63-4: Identify Compensating Controls. https://pages.nist.gov/800-63-4/sp800-63.html
Huang, Z., D'Angelo, M., Miyani, D., & Lie, D. (2017). Talos: Neutralizing Vulnerabilities with Security Workarounds for Rapid Response. arXiv:1711.00795.
Neo.K / EveMissLab. 《表觀完好系統》系列第 1–5 篇，以及 MSSP / FPL 既有架構研究。

今天的 Workaround，明天的 Architecture：補償凝固命題

摘要

1. Temporary 往往是軟體工程裡最危險的形容詞

2. 存在很久，不等於凝固

Persistence

Solidification

3. Workaround 的持續存在需要協調

4. Organizational Routines：補償可以改變正常工作

Local Adaptation

Organizational Routine

5. Hyrum’s Law：行為一旦被依賴，就形成隱性介面

Implicit Interface

6. Shadow IT：workaround 甚至可以長成新的子系統

7. 補償凝固的正式定義

Architectural Weight

8. 架構重量不是二元值

9. 補償凝固階梯

C0C_0C0​ ：Transient Workaround

C1C_1C1​ ：Repeated Workaround

C2C_2C2​ ：Coordinated Compensation

C3C_3C3​ ：Dependent Compensation

C4C_4C4​ ：Implicit Contract

C5C_5C5​ ：Effective Architecture

10. 凝固不是只有「變正式」

11. 補償凝固的四條主要路徑

11.1 Workaround → Routine

11.2 Implementation Detail → Implicit Contract

11.3 Temporary Control → Governance Structure

11.4 Shadow Tool → Effective Subsystem

12. 凝固的正向版本：補償可能是架構發現機制

Architecture Discovery Signal

13. 凝固的負向版本：臨時缺陷被依賴後變得難以修復

Pathological Solidification

14. 凝固指數

Solidification Index

15. 一個更強的判定：反事實移除測試

Counterfactual Removal Test

16. 替代先於移除原則

Replacement-Before-Removal Principle

17. 去凝固不是刪除，而是解除依賴

De-solidification

18. 補償凝固與歷史殘留的差別

Current Structural Dependence

19. 補償凝固與技術債的差別

Case A：健康凝固

Case B：債性凝固

20. 補償凝固與架構侵蝕的差別

21. Dynamic MSSP：Compensation 必須是一等物件

22. AI 的任務：發現依賴，而不是猜作者本意

23. AI 時代會讓補償凝固更快

24. 從 Shadow IT 到 Shadow AI

Shadow AI

25. 三種治理結果：吸收、替換、保留

25.1 Absorb

25.2 Replace

25.3 Preserve

26. 命題 6：補償凝固命題

補償凝固命題

27. 更強版本：架構本身可以由 workaround 生成

28. 結論：今天的例外，可能是明天的本體

〈修好真的比較簡單嗎？複雜度轉移與重構悖論〉

參考文獻

$C_0$ ：Transient Workaround

$C_1$ ：Repeated Workaround

$C_2$ ：Coordinated Compensation

$C_3$ ：Dependent Compensation

$C_4$ ：Implicit Contract

$C_5$ ：Effective Architecture