系统整体性的维护等价于理论 T 的一致性维护，系统整体性的崩溃等价于理论 T 的矛盾推导。DS-TUI 与 omp 分别代表了两种不同的一致性保证策略——编译时证明与运行时检测——而二者共同面对的根本挑战是：当系统以分布式、模块化、开放的方式组织理论时，没有任何全局的”理论检查器”能够保证整体的一致性。
系统的整体性质并非各子系统性质的简单加和。设系统 $S$ 的子系统集合为 {$S₁, …, Sₙ$}，每个子系统 $Sᵢ$ 对应一个理论 $Tᵢ$。系统的整体行为由合并理论 $T_{union} = ⋃ Tᵢ$ 描述。整体性条件的三个层次可表述为：
整体性条件（WC-1）：合并理论 $T_{union}$必须是一致的——不存在公式 φ 使得 $T_{union} ⊢ φ$ 且 $T_{union} ⊢ ¬φ$。在经典一阶逻辑中，不一致的理论推出任意公式——这是”系统整体崩溃”的模型论对应。
整体性条件（WC-2）：如果子系统之间存在共享符号 $Σ_{shared} = Σ(Tᵢ) ∩ Σ(Tⱼ) ≠ ∅$，则 $Tᵢ$ 与 $Tⱼ$ 在共享符号上的解释必须一致。这在软件工程中对应接口契约——两个模块共享的接口类型、函数签名必须语义一致。
整体性条件（WC-3）：存在在任意单独 $Tᵢ$ 中不可表达的公式 $φ$，但在 $T_{union}$ 中 $φ$ 可被证明——即 $T_{union} ⊢ φ$ 但对所有 $i$，$Tᵢ ⊬ φ$。这正是”整体大于部分之和”的模型论解释：$φ$ 不是预先插入系统的，而是在多子系统相互作用中涌现出的行为规律。
经典模型论中的理论闭包是自足的：$Cn(T)$ 由 $T$ 的公理集完全决定。但对于开放的复杂巨系统，理论 $T$ 并非固定的——新子系统（MCP 服务器、技能、规则）会不断向 T 添加新公理：
$$ T_t = T_{core} ∪ (⋃_{s ∈ ActiveSkills(t)} T_s) ∪ (⋃_{r ∈ McpConnected(t)} T_r) $$
每个时间点 $t$ 维护一个不同的合并理论。整体性条件必须对每个 $T_t$ 成立——静态一致性被推向了动态一致性。系统必须有能力检测并响应合并理论的变化。这正是 DS-TUI 与 omp 在架构上的根本分歧所在。
DS-TUI 的策略极端而优雅：将所有公理在编译时固定。系统提示词 base.md（~264 行）通过 include_str!() 在编译时嵌入。工具签名通过 ToolSpec trait 在编译时确定。配置模型通过 ConfigToml 在编译时类型检查。
在模型论语境中这意味着：合并理论 $T_{DS}$ 的公理集在编译时完全确定。不存在运行时添加公理的路径。Rust 编译器的作用不仅是翻译——它充当了理论一致性的证明器：