MiniCordis：从零实现一个插件化 Runtime
接着 Cordis 从零开始教程往前走一步，换一个角度看这个框架是怎么实现的：从空的 Context 出发，一步步长出 Service Registry、Plugin、Effect、Scope、Event、依赖生命周期、失败隔离和 Child Context，把“能力会被安装、撤销、依赖、恢复、隔离”的插件化 Runtime 模型从零实现一遍，最后再拼回一个完整场景验证这套模型是否闭合。
MiniCordis：从零实现一个插件化 Runtime
接着 Cordis 从零开始教程往前走一步，换一个角度看这个框架是怎么实现的——不复刻 Cordis，而是做一个简化版 MiniCordis，一步步实现关键 feature，理解这些 Runtime 结构为什么会长成现在这样。
第一篇：从空的 Context 到最小 Service Registry
在谈 Plugin、Event 和依赖之前，一个最小 Runtime 至少应该先拥有什么——从一个完全没有行为的 Context 开始，逐步补上“注册能力”“读取能力”“移除能力”这几件最基本的事情。
第二篇：从直接 provide 到 Plugin、Effect 和 Scope
当 Runtime 已经能保存能力以后，谁来安装这些能力，谁来撤销这些能力，以及撤销时为什么不能一锅端——把安装逻辑抽成 Plugin，把撤销绑进 effect，再用 Scope 隔离每个 Plugin 的边界。
第三篇：为什么 Event Listener 本身也是一种 Runtime Effect
当两个 Plugin 不应该直接互相认识，但其中一个又需要感知另一个做了什么时，Runtime 该怎么组织它们——Event 不是外挂的子系统，而是可以直接复用 effect 和 scope 机制的一种特殊情况。
第四篇：从一次性依赖检查到响应式依赖生命周期
当一个 Plugin 依赖的能力可能在运行过程中出现、消失和恢复时，Runtime 应该如何持续维护它的激活状态——从一次性的 require 检查，走到能长期追踪依赖关系的 inject。
第五篇：失败隔离与 Child Context
当 Runtime 进入更真实的运行环境以后，为什么仅仅有安装、撤销、事件和依赖系统还不够——一个 Plugin 出错为什么不能拖垮整个系统，以及为什么最终需要的不是一个 Context，而是一棵可以继承与隔离的 Context 树。
第六篇：把所有机制重新拼回一个完整场景
前面一路建立起来的容器、Plugin、Effect、Event、依赖生命周期、失败隔离和 Child Context，放在一起以后到底能不能支撑一个像 HelloCordis 那样的真实小场景。