遞歸閉包積木組合語言：折疊、展開、引用與再封裝

Recursive Closure Block Composition Language: Collapse, Expansion, Reference, and Re-encapsulation

系列名稱： 遞歸自適應積木組合語言（Recursive Adaptive Block Composition Language, RABCL）
系列編號： EML-RABCL-2026-04
作者： Neo.K（許筌崴）with Aletheia（GPT）
機構： EveMissLab／一言諾科技有限公司
版本： v0.1 基礎理論稿
日期： 2026 年 7 月 30 日
文件定位： 積木語言閉包、結構嵌套、定義／實例分離、引用語義、折疊／展開、版本與再封裝

摘要

前述 RABCL 文件已建立三個基礎：第一，工作流可以在受約束條件下升格為新的高階積木；第二，封裝前必須經過局部靜止、快照、分析、驗證與原子提交；第三，積木不能被簡化成無狀態純函數，而應被描述為具有邊界、端口、契約、狀態、副作用、權限與證據輸出的可契約呼叫單元。

然而，若要使這些積木真正構成一種語言，仍需回答更基本的問題：封裝後的大積木如何再次進入畫布？同一積木在不同位置出現時，是複製、引用還是實例化？展開後修改內部結構，會不會同步改變所有使用者？積木可以包含積木，但能否包含自身？多層封裝如何避免無限展開？版本更新後，既有工作流應追蹤最新版本、固定舊版本，還是建立相容性分支？

本文提出 RABCL 的受約束遞歸閉包模型。令合法積木定義集合為 $\mathfrak B$ ，合法組合關係為 $\operatorname{ComposeOK}$ ，則閉包條件不是無條件的：

B_1,\ldots,B_n\in\mathfrak B \land \operatorname{ComposeOK}(B_1,\ldots,B_n) \Longrightarrow \operatorname{Pack}(B_1,\ldots,B_n)\in\mathfrak B.

這種閉包同時要求型別、契約、效果、權限、版本與治理條件成立。積木的外觀可以被折疊為單一節點，但其權威結構仍保存為可尋址的定義圖；折疊與展開只是同一權威對象的不同投影。本文進一步區分四個核心對象：積木定義、積木版本、積木實例與積木引用。其中定義描述「它是什麼」，版本描述「哪一個不可變修訂」，實例描述「在本次工作流中具有何種狀態」，引用則描述「此處如何找到並約束該定義或版本」。

本文也區分三種不同的遞歸：結構遞歸、執行遞歸與演化遞歸。結構遞歸允許積木包含其他積木；執行遞歸涉及積木在運行時直接或間接呼叫自己；演化遞歸則是 AEREC 對積木實現進行多代生成、驗證與選擇。三者必須分別受控，不能因「積木可嵌套」便推論所有執行遞歸都安全，也不能因版本持續演化便宣稱形成無限計算。

本文最終建立折疊、展開、引用、實例化、內聯、分叉、升版與再封裝八個基本操作，以及回環一致性、邊界保存、無隱藏捕獲、版本可重現、引用可解析與權威單一性六項核心不變量。由此，工作流不再只是被動保存的圖，而能形成一個持續增長、可引用、可驗證、可回滾且可再次組合的局部語言。

關鍵詞： 遞歸閉包、積木語言、工作流、折疊、展開、引用、實例、內容定址、版本、再封裝、RABCL

0. 問題定位

RABCL 的第四個核心問題不是「畫布能不能把幾個節點框起來」，而是：

一個已封裝積木如何成為下一層組合的合法語言基元，同時保留可展開、可修改、可追溯與可回滾的能力？

若缺少明確語義，產品容易落入下列混亂：

折疊只是 UI 隱藏，展開後卻找不到原始結構；
拖入兩個同名積木，修改其中一個卻意外改動另一個；
工作流保存了「最新版本」的模糊指標，日後無法重現；
內部節點被直接複製，導致相同實現散落多份並逐漸漂移；
積木包含積木後，除錯器每次都遞歸展開全部層級；
自我引用與結構嵌套被混為一談，形成不可停止的執行；
AI 為了最佳化而修改共用定義，卻未取得所有使用者同意；
視覺圖、執行圖、版本圖與來源圖各自維護，逐漸形成多份真相。

因此，本篇不只定義一種畫布操作，而是建立 RABCL 的語言物件模型。

1. 從「大方塊」到語言基元

1.1 大方塊不是像素區域

一個真正的高階積木不能以畫布座標或矩形框作為本體。畫布上的方塊只是投影：

\Pi_{\mathrm{canvas}}(B) = \text{可視化節點}.

積木本體應是權威結構中的可尋址物件：

B = (I,C,\partial,P^\ast,D,V,G,H).

其中：

$I$ ：身分與命名資訊；
$C$ ：外部契約；
$\partial$ ：端口、狀態、效果與權限邊界；
$P^\ast$ ：權威中介表示；
$D$ ：依賴與內部成員；
$V$ ：版本與相容性；
$G$ ：治理與存取政策；
$H$ ：來源、歷史與證據。

方塊可以改變顏色、位置、縮放或是否展開，但這些視覺操作不應自動改變 $B$ 的語義。

1.2 語言基元的最低資格

一個物件要成為 RABCL 的語言基元，至少應滿足：

\operatorname{Primitive}(B) = \operatorname{Named}(B) \land \operatorname{Addressable}(B) \land \operatorname{Contracted}(B) \land \operatorname{Callable}(B) \land \operatorname{Composable}(B) \land \operatorname{Inspectable}(B).

也就是它必須：

可命名；
可穩定尋址；
有明確契約；
能被 Runtime 呼叫；
能與其他積木合法組合；
能在需要時檢查其內部與來源。

只具備「可拖曳」或「可重用」仍不足以成為完整語言基元。

2. 四個不可混淆的核心對象

2.1 積木定義

積木定義描述一個相對穩定的語義身分：

\mathsf{BlockDef} = (\text{name},\text{namespace},\text{contract family},\text{governance}).

例如：

eml.media/GenerateValidatedAsset

它回答的是「這是什麼能力」，而不是「目前哪一版實現」或「此次呼叫的狀態」。

2.2 積木版本

版本是某個積木定義的一次不可變修訂：

B^{(v)} = \operatorname{Revision}(\mathsf{BlockDef},v).

版本應固定：

契約；
權威結構；
依賴鎖定；
驗證證據；
建構與執行需求；
內容指紋。

一旦發布，版本內容不得就地覆寫。任何語義或實現改動都形成新版本或候選分支。

2.3 積木實例

實例是積木版本在某張工作流中的具體出現：

\iota_k = \operatorname{Instantiate} (B^{(v)},\theta_k,S_k,L_k).

其中：

$\theta_k$ ：該實例的配置；
$S_k$ ：該實例的局部狀態；
$L_k$ ：該實例在工作流中的局部連線。

同一版本可以有多個實例：

\iota_1\neq\iota_2, \qquad \operatorname{Def}(\iota_1) = \operatorname{Def}(\iota_2).

兩個實例共享定義與版本，但不必共享運行狀態。

2.4 積木引用

引用不是積木本身，而是找到積木的規則：

\rho = (\text{target},\text{version constraint},\text{resolution policy}).

常見引用可分為：

精確版本引用：固定到 $B^{(1.2.3)}$ ；
內容引用：固定到某一內容雜湊；
相容範圍引用：接受一組契約相容版本；
符號引用：例如 stable、approved、latest-tested；
本地分支引用：指向工作區內尚未發布的候選版本。

引用解析後才得到可執行版本：

\operatorname{Resolve}(\rho,\mathcal R_t) = B^{(v)},

其中 $\mathcal R_t$ 是時間 $t$ 的註冊表與政策狀態。

3. 定義圖與實例圖的分離

3.1 為何需要兩張圖

RABCL 至少需要區分：

G_D=(V_D,E_D),

以及：

G_I=(V_I,E_I).

其中：

$G_D$ ：積木定義與版本之間的依賴圖；
$G_I$ ：某次工作流中的積木實例與資料／控制連線圖。

若不區分兩者，使用者刪除畫布實例可能誤刪全域定義；修改定義則可能被誤解成只調整單一節點。

3.2 定義圖的基本要求

定義圖應保存：

積木版本依賴哪些版本；
依賴是內嵌、動態載入還是能力需求；
契約與版本約束；
來源與驗證鏈；
是否存在循環依賴。

在最小 MVP 中，定義依賴圖應優先限制為有向無環圖：

\operatorname{DAG}(G_D)=\top.

這不是宣稱所有合法軟體架構都必須無環，而是為了讓初版的建構、版本解析、快取、展開與垃圾回收保持可控。

3.3 實例圖可以具有執行循環

工作流本身可能含有：

重試；
迴圈；
回饋；
狀態機轉移；
事件等待；
遞歸呼叫。

因此 $G_I$ 不必是 DAG。但循環必須具有明確的控制語義：

\operatorname{Cycle}(G_I) \Longrightarrow \operatorname{Guarded} \lor \operatorname{Bounded} \lor \operatorname{ExternallyTerminated}.

換言之，結構上出現回邊不等於錯誤，但不能只靠一條視覺連線隱含無限循環。

4. 折疊與展開

4.1 折疊不是刪除

折疊操作為：

\mathsf{Collapse}: (P^\ast,\sigma) \rightarrow (\Pi_B,\sigma'),

其中：

$P^\ast$ ：權威結構；
$\sigma$ ：原操作狀態；
$\Pi_B$ ：單一積木投影；
$\sigma'$ ：保存折疊資訊後的操作狀態。

折疊只改變視圖與操作粒度，不應刪除內部結構，也不應將所有內部節點序列化成無法再解析的黑盒字串。

4.2 展開是受控投影

展開操作為：

\mathsf{Expand}(B^{(v)},d,m) \rightarrow \Pi_{d,m}(P^\ast),

其中：

$d$ ：展開深度；
$m$ ：展開模式。

模式至少包括：

唯讀展開：檢查內部但不可修改；
實例展開：查看該實例的配置與狀態；
候選分支展開：建立可編輯草稿；
除錯展開：顯示 Trace、狀態與效果；
來源展開：查看版本、依賴與證據。

因此，展開不等於取得共用定義的直接寫入權。

4.3 往返一致性

若沒有修改，積木經展開與重新折疊後應保持語義一致：

\mathsf{Collapse} (\mathsf{Expand}(B^{(v)})) \equiv_C B^{(v)}.

其中 $\equiv_C$ 表示相對於外部契約 $C$ 的一致，而不要求畫布座標、折疊狀態或註解完全相同。

4.4 有損與無損展開

某些積木可能只有：

外部契約；
已編譯工件；
來源摘要；
不完整或受保護的內部表示。

因此應標示：

\operatorname{Expandability}(B) \in \{ \text{full}, \text{partial}, \text{opaque} \}.

只有 full 積木能保證完整往返；partial 可展開到允許的抽象層；opaque 則只能顯示契約與證據，不能假裝可還原全部內部。

5. 引用、複製與實例化

5.1 拖入畫布預設應是實例化

當使用者將既有積木拖入畫布時，預設操作應是：

\operatorname{Drag}(B^{(v)}) \Rightarrow \operatorname{Instantiate}(B^{(v)}),

而不是複製整份積木定義。

這可避免每次使用都產生一份逐漸漂移的內部副本。

5.2 複製實例

複製實例表示：

\operatorname{CloneInstance}(\iota_1) = \iota_2,

並滿足：

\operatorname{Version}(\iota_1) = \operatorname{Version}(\iota_2).

配置可以選擇複製，運行狀態通常不應默認複製，尤其是：

憑證；
鎖；
長期任務游標；
交易狀態；
外部資源所有權。

5.3 分叉定義

若使用者希望改造積木內部並保留獨立演化路徑，應執行：

\operatorname{ForkDef} (B^{(v)},N') = \widetilde B^{(0.1.0)}.

新定義保留來源：

\operatorname{Origin}(\widetilde B) = B^{(v)},

但具有新的命名空間、治理權與版本序列。

5.4 內聯

內聯操作將引用的積木版本展開並嵌入當前候選圖：

\operatorname{Inline}(\rho) \rightarrow P^\ast_{\mathrm{embedded}}.

內聯後，該結構不再自動追蹤原積木更新。這適合：

需要深度修改；
要消除 Runtime 呼叫邊界；
要產生獨立、可離線部署的工件；
需要將依賴固定進封裝內。

但內聯會提高重複、漂移與安全修補遺漏風險，因此必須保存來源指紋。

5.5 引用優先、複製例外

RABCL 的預設原則應是：

\boxed{ \text{Reference by default, copy only by explicit intent.} }

中文可表述為：預設引用，明確分叉；預設實例化，不默認複製定義。

6. 三種遞歸必須分離

6.1 結構遞歸

結構遞歸表示積木可以包含積木：

B_k = \operatorname{Pack} (B_1,\ldots,B_n).

這是 RABCL 最基本的高階組合能力。

只要每層封裝都有有限權威表示，結構深度雖可增長，任何具體版本仍是有限物件：

\forall B^{(v)}, \quad |P^\ast(B^{(v)})|<\infty.

6.2 執行遞歸

執行遞歸表示積木在 Runtime 直接或間接呼叫自身：

B\rightarrow B,

或：

B_1\rightarrow B_2\rightarrow\cdots\rightarrow B_1.

這與結構嵌套不同。執行遞歸必須具備：

終止條件；
深度或資源預算；
重入政策；
狀態隔離；
取消與逾時；
Trace 關聯。

最低安全要求可表示為：

\operatorname{RecursiveCall}(B) \Longrightarrow \operatorname{Budget}(B)<\infty \lor \operatorname{ExternalStop}(B).

6.3 演化遞歸

演化遞歸表示 AEREC 對積木實現進行多代變換：

B^{(v,0)} \rightarrow B^{(v,1)} \rightarrow \cdots \rightarrow B^{(v,n)}.

它不是積木在同一次執行中呼叫自身，而是版本或候選實現的跨代生成。

演化遞歸需要：

契約錨定；
每代證據；
選擇函數；
負知識；
停止準則；
回滾路徑。

6.4 三者的正交表示

可以定義積木的遞歸向量：

\mathbf r(B) = (r_s,r_x,r_e),

其中：

$r_s$ ：結構遞歸深度；
$r_x$ ：執行遞歸特性；
$r_e$ ：演化代數或演化深度。

一個積木可以具有深層結構嵌套，卻完全沒有執行遞歸；也可以結構很簡單，卻在 Runtime 中執行遞歸演算法。這三者不能再以單一「遞歸」標籤混合描述。

7. 受約束遞歸閉包

7.1 閉包算子

令合法積木集合為 $\mathfrak B$ ，封裝算子為：

\mathcal P: \mathfrak B^n \times \mathcal W \times \mathcal Q \rightarrow \mathfrak B\cup\{\bot\},

其中：

$\mathcal W$ ：連線與工作流結構；
$\mathcal Q$ ：契約、權限、版本與治理條件；
$\bot$ ：封裝失敗或拒絕。

只有當：

\operatorname{TypeOK} \land \operatorname{ContractOK} \land \operatorname{EffectOK} \land \operatorname{PermissionOK} \land \operatorname{VersionOK} \land \operatorname{GovernanceOK}

全部成立，才有：

\mathcal P(B_1,\ldots,B_n;\mathcal W,\mathcal Q) \in \mathfrak B.

7.2 相對閉包

閉包永遠相對於某個環境與政策：

\mathfrak B_{\Gamma,P,t}.

同一組積木可能在開發環境可合法組合，在生產環境卻因權限、資料區域或模型政策而不可部署。

因此：

\operatorname{Closed} (\mathfrak B_{\Gamma_1,P_1}) \not\Rightarrow \operatorname{Closed} (\mathfrak B_{\Gamma_2,P_2}).

RABCL 的閉包不是宇宙性的代數閉包，而是工程與治理條件下的可組合閉包。

7.3 封裝不保證純化

將多個有副作用積木封裝成大積木，不會自動消除副作用：

\mathcal E (\operatorname{Pack}(B_1,\ldots,B_n)) \supseteq \bigcup_{i=1}^{n}\mathcal E(B_i) - \mathcal E_{\mathrm{internalized}}.

只有已被封裝內部完全吸收、不再外顯的效果，才可從外部契約中隱藏。網路存取、檔案寫入、付費 API、資料庫交易與人工審批仍須顯式保留。

8. 八個基本語言操作

RABCL v0.1 的語言操作可先固定為八個：

8.1 `collapse`

將展開工作流投影為單一積木節點，不改變權威語義。

8.2 `expand`

按深度、權限與模式查看積木內部。

8.3 `reference`

建立對積木定義或版本的受約束引用。

8.4 `instantiate`

在工作流中建立具有局部配置與狀態的積木實例。

8.5 `inline`

將引用版本內嵌至候選結構，切斷自動升版關係。

8.6 `fork`

從既有版本建立新的獨立積木定義與演化線。

8.7 `revise`

對同一積木定義建立新版本，不覆寫舊版本。

8.8 `repack`

將已修改或重新組合的候選圖，經 EQB、契約推斷與驗證後，再次提交為積木版本。

可以用簡化語法表示：

block eml.media/GenerateValidatedAsset@1.0.0 {
  import image.source@1
  import model.generate@2
  import quality.validate@1

  export generateValidatedAsset

  compose {
    source -> generate -> validate
    validate.reject -> generate.retry
    validate.accept -> output
  }
}

這段語法的重點不在具體字面格式，而是明示：

使用的是哪些積木與版本；
哪些能力被導入；
哪些接口被導出；
內部如何連線；
哪些內部能力被封裝後不再外露。

9. 身分、版本與內容定址

9.1 四層識別

RABCL 不應只使用一個 id 欄位承擔所有語義。至少需要：

I(B) = (I_{\mathrm{def}},I_{\mathrm{ver}},I_{\mathrm{content}},I_{\mathrm{inst}}).

其中：

$I_{\mathrm{def}}$ ：積木定義身分；
$I_{\mathrm{ver}}$ ：語義版本身分；
$I_{\mathrm{content}}$ ：不可變內容指紋；
$I_{\mathrm{inst}}$ ：工作流實例身分。

9.2 內容指紋

可定義：

I_{\mathrm{content}} = H ( P^\ast, C, D_{\mathrm{locked}}, Q_{\mathrm{build}} ),

其中：

$H$ ：密碼雜湊；
$P^\ast$ ：規範化權威表示；
$C$ ：契約；
$D_{\mathrm{locked}}$ ：鎖定依賴；
$Q_{\mathrm{build}}$ ：會影響工件的建構條件。

相同內容應得到相同內容識別；內容一旦改變，指紋必須改變。

9.3 符號引用與不可變內容分離

stable、approved、latest-tested 等符號引用可以移動，但其所指向的內容版本不可變：

\operatorname{Ref}_{t_1}(\texttt{stable}) =B^{(1.2)},

\operatorname{Ref}_{t_2}(\texttt{stable}) =B^{(1.3)}.

工作流發布時，應將符號引用解析並鎖定：

\operatorname{Lock}(\rho_{\mathrm{symbolic}}) = (I_{\mathrm{ver}},I_{\mathrm{content}}).

如此才能兼顧易用的名稱與可重現的執行。

9.4 依賴閉包指紋

積木的可重現性不只取決於自身內容，也取決於完整依賴閉包：

H_{\mathrm{closure}}(B) = H \left( I_{\mathrm{content}}(B), \{H_{\mathrm{closure}}(D_i)\} \right).

這允許系統判斷兩個表面相同的積木是否實際依賴不同模型、工具或 Runtime。

10. 版本相容性不是只看版本號

10.1 契約指紋

對外契約可產生規範化指紋：

H_C(B) = H ( \operatorname{Normalize}(C_B) ).

版本更新時，系統比較：

輸入是否擴張或收縮；
輸出是否改型；
新增或刪除哪些效果；
權限是否升級；
錯誤集合是否改變；
狀態遷移是否相容；
資源上限是否改變。

10.2 相容關係

可定義：

B^{(v_2)} \preceq_C B^{(v_1)},

表示 $v_2$ 可在所有依賴 $v_1$ 契約的合法位置安全替換 $v_1$ 。

這比「主版本號沒變，所以應該相容」更精確。

10.3 自動升版條件

只有在：

\operatorname{ContractCompatible} \land \operatorname{EffectNonEscalating} \land \operatorname{PermissionNonEscalating} \land \operatorname{TestsPass} \land \operatorname{PolicyAllows}

成立時，系統才可建議或自動進行版本替換。

若新增網路、檔案、付費服務或更高資料權限，即使輸入輸出型別未變，也不應視為無害的小版本更新。

11. 再封裝的正式程序

11.1 再封裝不是保存按鈕

當積木被展開並修改後，不能直接覆寫原版本。正確程序為：

B^{(v)} \xrightarrow{\mathsf{Expand}} P^\ast_v \xrightarrow{\mathsf{Edit}} \widetilde P \xrightarrow{\mathsf{EQB}} \widetilde P_q \xrightarrow{\mathsf{Infer+Validate}} \widetilde B \xrightarrow{\mathsf{Commit}} B^{(v+1)}.

11.2 變更分類

再封裝前應判定：

\Delta = (\Delta_C,\Delta_E,\Delta_P,\Delta_S,\Delta_D,\Delta_I),

其中：

$\Delta_C$ ：契約變更；
$\Delta_E$ ：效果變更；
$\Delta_P$ ：權限變更；
$\Delta_S$ ：狀態模型變更；
$\Delta_D$ ：依賴變更；
$\Delta_I$ ：內部實現變更。

若只有 $\Delta_I$ 且外部契約與效果不變，可形成實現修訂或 AEREC 候選。若 $\Delta_C$ 、 $\Delta_E$ 或 $\Delta_P$ 發生不相容改動，則必須形成新語義版本，甚至新積木定義。

11.3 再封裝輸出

一次成功再封裝至少產生：

新版本清單；
新權威結構；
契約與效果差異；
鎖定依賴；
測試與驗證報告；
遷移建議；
回滾目標；
內容與閉包指紋。

12. 六項核心不變量

12.1 往返不變量

無修改的展開與折疊應保持契約語義：

\mathsf{Collapse} (\mathsf{Expand}(B)) \equiv_C B.

12.2 邊界保存不變量

折疊後所有外部可觀測的輸入、輸出、狀態、效果、錯誤與權限必須仍可由積木邊界表達：

\operatorname{Obs}_{\mathrm{external}} (P^\ast) = \operatorname{Obs}_{\mathrm{external}} (B).

12.3 無隱藏捕獲不變量

封裝不得偷偷捕獲畫布外變數、未宣告工具、環境祕密或全域狀態：

\operatorname{FreeDeps}(P^\ast) \subseteq \operatorname{DeclaredImports}(B).

12.4 版本可重現不變量

精確版本與內容指紋應解析到同一不可變結構：

\operatorname{Resolve} (I_{\mathrm{ver}},I_{\mathrm{content}}) =P^\ast.

12.5 引用可解析不變量

所有可發布工作流中的引用都必須能在部署前解析，或被明確標示為由 Runtime／Host 提供的能力：

\forall \rho\in R, \quad \operatorname{Resolved}(\rho) \lor \operatorname{HostProvided}(\rho).

12.6 權威單一性不變量

畫布、文字 DSL、狀態機視圖、執行計畫與除錯視圖只能是投影：

\Pi_1(P^\ast), \Pi_2(P^\ast), \ldots, \Pi_n(P^\ast).

不能各自成為獨立真相來源。

13. AI 在遞歸組合語言中的角色

13.1 AI 可以提出的操作

AI 可協助：

辨識可封裝子圖；
建議積木名稱與命名空間；
推斷端口與契約；
判斷引用或內聯較合適；
偵測重複積木與可共用定義；
生成折疊後摘要；
比較版本與契約差異；
建議分叉、升版或保持鎖定；
推斷最佳展開深度；
發現循環依賴與隱藏捕獲；
生成再封裝候選。

13.2 AI 不應單獨決定的操作

AI 不應在無政策與驗證條件下：

修改共用積木的已發布版本；
將符號引用自動升級到權限更高版本；
把引用悄悄改成內聯；
複製機密狀態到新實例；
將不可逆副作用隱藏進封裝；
自動解除依賴鎖定；
將執行循環誤判為結構嵌套；
無限制展開或遞歸執行。

13.3 提案與提交分離

AI 生成的操作先形成提案：

\widetilde O = \operatorname{Propose}_{AI} (O,P^\ast,C,Q).

只有在驗證與政策通過後：

\operatorname{Commit}(\widetilde O) =O'.

這延續 RABCL 前三篇的基本原則：AI 可以提出結構，但不能跳過權威提交與治理邊界。

14. 與現有元件與內容定址思想的關係

WebAssembly Component Model 已展示一個重要工程事實：具有機器可讀 import／export 介面的元件，可以被組合為新的元件；組合後，已被滿足的依賴可成為內部實現細節，而未滿足的依賴繼續暴露為新元件的 import。其元件也可以嵌套其他元件，並透過介面檢查判定組合是否成立。RABCL 接受這種「介面驅動組合後仍為同類元件」的方向，但把範圍擴大到視覺工作流、狀態、效果、權限、來源、AI 推斷與可逆展開。

Git 的物件與引用機制則說明了不可變內容與可移動名稱可以分離：內容物件由內容定址，符號引用則提供人類可讀、可更新的入口。IPFS 的 Merkle DAG 也展示內容識別與圖形關係可以共同形成可驗證的物件結構。RABCL 不需要複製 Git 或 IPFS 的全部架構，但可借用兩個原則：

已發布積木版本應具有不可變內容指紋；
stable、approved 等可移動名稱只能是引用，不能把其當成可重現版本本身。

因此，RABCL 的積木可以同時具有語義名稱、版本名稱、內容指紋與工作流實例識別，而不再把所有身分壓縮到一個可變 ID。

15. 常見失敗模式

15.1 展開即修改共用定義

使用者只是為了查看內部而展開，卻因拖動節點直接改變所有引用者。解法是唯讀展開與候選分支分離。

15.2 拖入即複製

每次使用積木都複製全部內部內容，造成修補與升版無法同步。解法是預設實例化與引用，只有明確內聯或分叉才複製結構。

15.3 `latest` 污染可重現性

工作流只保存 latest，數週後重跑得到不同結果。解法是編輯期可使用符號引用，提交與部署時必須解析為精確版本與內容指紋。

15.4 版本號相容假象

僅依賴主次版本號，忽略新增權限、副作用或資料外流。解法是加入契約、效果與權限差異檢查。

15.5 結構遞歸誤當執行遞歸

積木包含自己的舊版本或同族元件，不代表 Runtime 必須無限自我呼叫。解法是分離定義依賴圖與實例執行圖。

15.6 無限制全展開

除錯器展開所有子積木與依賴，造成認知與計算爆炸。解法是深度限制、按需載入與摘要視圖。

15.7 隱藏能力捕獲

封裝後積木表面只有一個輸入輸出，內部卻偷偷使用網路、檔案、祕密或付費模型。解法是自由依賴掃描與能力 import 顯式化。

15.8 自我引用版本環

新版本依賴符號 stable，而 stable 又更新指向新版本自身，形成解析循環。解法是發布時鎖定不可變版本，禁止內容閉包中的未解析自指符號。

16. MVP 前置資料結構

本篇仍不開始實作，但可以先鎖定最小資料物件：

block_definition:
  id: eml.media/GenerateValidatedAsset
  title: Generate Validated Asset
  namespace: eml.media

block_version:
  version: 1.0.0
  content_hash: sha256:...
  contract_hash: sha256:...
  closure_hash: sha256:...
  authority_ir: cair://objects/...
  expandability: full

imports:
  - ref: eml.media/ImageSource@1.1.0
    content_hash: sha256:...
    mode: reference
  - ref: eml.model/GenerateImage@2.0.3
    content_hash: sha256:...
    mode: reference

exports:
  - interface: generate-validated-asset

instances:
  state_policy: isolated
  config_schema: schema://...

recursion:
  structural_depth: 2
  runtime_recursion: guarded
  max_call_depth: 8

provenance:
  parent_version: null
  source_workflow: workflow://...
  validation_certificate: cert://...

MVP 的初始限制可以是：

定義依賴圖必須為 DAG；
不支援直接自我依賴；
執行循環必須使用顯式迴圈或狀態機節點；
發布版本不可變；
拖入預設建立實例；
編輯共用積木必須建立候選分支；
部署時鎖定精確版本與內容指紋；
展開深度預設為一層；
只有 full 積木支援完整往返編輯；
opaque 積木僅顯示契約、來源與證書。

17. 主要命題

命題一：同類組合命題

合法積木在組合條件成立時，封裝結果仍是合法積木，而不是另一種不可再組合的特殊物件。

命題二：定義／實例分離命題

積木定義與工作流實例必須具有不同身分、版本與狀態生命週期。

命題三：折疊非刪除命題

折疊只改變投影與操作粒度，不得破壞權威內部結構與來源鏈。

命題四：展開非寫入命題

查看積木內部不等於取得修改已發布共用定義的權限。

命題五：引用優先命題

積木重用應預設透過引用與實例化完成；複製定義、內聯與分叉必須是明確操作。

命題六：不可變版本命題

已發布積木版本與其內容指紋不得就地覆寫，任何改動都形成新候選或新版本。

命題七：遞歸分離命題

結構遞歸、執行遞歸與演化遞歸是三種不同機制，必須分別建模與治理。

命題八：相對閉包命題

RABCL 的閉包只在型別、契約、效果、權限、版本、環境與治理條件下成立。

命題九：再封裝事務命題

展開後的修改不能直接覆寫權威版本，必須重新經過靜止、差異分析、驗證與原子提交。

命題十：局部語言增長命題

每次成功封裝都可為命名空間增加新的語言基元，但新基元必須納入引用、版本、來源與相容性治理。

18. 理論邊界

本文不主張：

所有工作流都能形成合法積木；
所有積木都可完整展開為原始碼；
結構嵌套可無限免費展開；
內容雜湊本身能證明語義正確；
版本號可以取代契約與效果驗證；
自我引用天然安全；
遞歸封裝突破圖靈可計算性；
局部語言增長等同模型獲得自主主權；
AI 可以在無審核下修改共用積木與生產依賴；
初版 MVP 應支援任意循環依賴與跨組織自動升版。

本文只主張：

\boxed{ \begin{aligned} &\text{工作流可被封裝成積木；}\\ &\text{積木可作為下一層工作流的合法成員；}\\ &\text{合法組合可再次封裝成同類高階積木；}\\ &\text{此過程必須由明確的定義、版本、實例、引用與治理語義約束。} \end{aligned} }

19. 結論

RABCL 所謂的「積木組合語言」不能只停留在視覺上把幾個節點框成一個大方塊。真正的語言化要求：大方塊必須成為可命名、可尋址、可契約、可版本化、可實例化、可展開、可引用、可再次封裝的一級計算物件。

其基本循環為：

\boxed{ \text{積木引用} \rightarrow \text{工作流實例化} \rightarrow \text{合法組合} \rightarrow \text{封裝} \rightarrow \text{新積木版本} \rightarrow \text{再次引用} }

而其雙向操作為：

\boxed{ \text{展開態} \rightleftarrows \text{封裝態} }

其遞歸性則不是無條件的「任何東西都能包任何東西」，而是：

\boxed{ \text{有限權威結構} + \text{顯式接口} + \text{鎖定依賴} + \text{受控引用} + \text{可驗證再封裝} = \text{受約束遞歸閉包} }

一旦這些概念成立，工作流工具就不再只是固定節點庫的使用介面。人類與 AI 可以在實際工作中，把已完成、已驗證的計算結構提升為新的語言基元，再用這些新基元構造更高階工作流。語言因此不再只由平台開發者預先寫死，而能在可治理、可追溯與可回滾的前提下，隨使用過程逐步增長。

下一篇將處理這些積木如何同時存在於格子語言操作表面、CAIR 權威結構、MSSP 描述索引與 RDR 執行派發之中，並避免四個層次各自維護一份互相漂移的系統真相。

參考資料

Bytecode Alliance, WebAssembly Component Model — Components. https://component-model.bytecodealliance.org/design/components.html
Bytecode Alliance, WebAssembly Component Model — Composing Components. https://component-model.bytecodealliance.org/composing-and-distributing/composing.html
Bytecode Alliance, WebAssembly Component Model — Interfaces. https://component-model.bytecodealliance.org/design/interfaces.html
Bytecode Alliance, WebAssembly Component Model — Worlds. https://component-model.bytecodealliance.org/design/worlds.html
Git Project, Pro Git — Git Objects. https://git-scm.com/book/en/v2/Git-Internals-Git-Objects
Git Project, Pro Git — Git References. https://git-scm.com/book/en/v2/Git-Internals-Git-References
IPFS Docs, Merkle Directed Acyclic Graphs. https://docs.ipfs.tech/concepts/merkle-dag/
IPFS Docs, Content Identifiers. https://docs.ipfs.tech/concepts/content-addressing/

04_遞歸閉包積木組合語言_折疊展開引用與再封裝_v0.1