把 88 页论文读懂：时空可组合性到底证明了什么

传统模块系统擅长静态组合：编译时知道有哪些模块，启动时把它们连好。插件化平台更困难，因为组件会在运行中安装、卸载、替换，依赖也会出现和消失。时间问题是：组件离开时，它造成的影响能否撤销；空间问题是：环境变化后，依赖它的组件能否自动进入正确状态。

论文把这两个方向称为 spatiotemporal composability。它不是泛泛谈“模块化很好”，而是试图给运行时组合一个可以推理的核心：环境变换附带 inverse，组件对环境的需求被表达为 coeffect，Context 追踪两者。

对非科班读者，第一遍不需要追每个符号。先抓住作者的论证链：现实问题 → 抽象机制 → 形式语义 → 性质 → 工程映射 → 案例。看清链条后，公式是为了约束歧义，而不是为了展示难度。

Effect 描述计算对外部世界的影响：写状态、注册监听、发出事件。论文关心的是 revertible effect——变换不仅产生新环境，还携带一个能把受控环境带回去的 inverse。运行时记录这些 inverse，形成时间维度的撤销链。

Coeffect 则从相反方向描述上下文需求。一个组件不是简单地“导入某个模块”，而是声明只有在特定服务和条件出现时才能工作。环境改变后，系统重新判断需求是否满足，于是组件可以 active、pending 或 neutral。

统一 Context 的意义，是让“我对环境做了什么”和“环境必须给我什么”不再属于两套互不相识的框架。代价是运行时要承担更多追踪、调度和一致性责任，插件作者也必须诚实地描述依赖与 inverse。

Preservation 可以先理解为：系统走了一步后，原本成立的结构约束仍然成立。Progress 关心：一个合法状态要么已经完成，要么还能继续走，而不是无缘无故卡死。Confluence 关心：不同合法调度顺序是否能汇合到等价结果，从而降低动态依赖变化带来的不确定性。

读这些性质时必须同时看前提。模型通常会抽象掉网络分区、恶意代码、外部系统、错误的 disposer 和版本欺骗。证明的是形式系统内的性质，不是生产环境里所有风险的总保证。

创始人不必自己重做证明，但要学会问：这个结论在什么模型里成立？现实系统增加了哪些模型外变量？作者展示的是 soundness、liveness、性能，还是只展示案例可行？这套问题能显著提升你读任何技术论文的判断力。

论文以 Koishi 生态作为长期案例，展示大量插件如何在统一 Context 下组合。这是很强的工程证据：机制不是只存在于小样例中。但案例集中在一个生态、语言和宿主模型，不能直接推导企业多租户隔离、供应链可信或跨 Runtime 一致性。

作者也保留了重要开放项：inverse 的正确性依赖实现者，依赖版本与类型兼容仍需进一步工作，语言级代理不是安全沙箱，自演化 Harness 更多是未来方向而不是已完成实证。

因此，我们对 LumiClaw 的推论应被明确标为 interpretation：借鉴 Context/lease/disposition 模式；不把 Cordis 本身提升为 Core 业务对象；不让动态插件直接获得企业宿主权限；不把论文性质包装成生产安全认证。