LumiClaw 的企业扩展内核：该吸收什么，不该复制什么
学完你会：形成一套适合 LumiClaw 的扩展对象、作用域、UI slot 与责任边界。
共享可升级的 Foundation，不强迫所有客户共享数据、Runtime 与凭据。
Lumi 应吸收生命周期局部性、依赖响应和组件可观察性，但用自己的 ExtensionDefinition、Provider、Grant、Lease 与 Receipt 承载企业治理。
先稳定用户主对象
插件可以无限增长，用户心智模型不能无限增长。
Lumi 的主对象应稳定为 Engagement、Task、Run、Artifact、Acceptance 和 Knowledge。AI Position、Runtime、Pack/Skill、Plugin 是完成工作的能力，不是取代工作的对象。
根导航保持少而稳定：Home/Attention、Engagements、Search/Command；进入 Engagement 后再看 Overview、Work、Runs、Deliverables、Knowledge、Configure。插件贡献 command、attention provider、tab、task section、renderer、knowledge source/view、settings panel 等语义 slot。
这种 IA 类似 Obsidian 的关键不是视觉，而是“核心工作空间 + 可组合能力 + 用户长期资产”。不同客户可拥有完全不同的 Pack 和主题，却仍使用同一套工作事实与导航语法。
六个核心扩展对象
Definition 说是什么，Provider 说谁提供，Consumer 说谁需要，Grant 说谁批准，Lease 说正在使用，Receipt 说发生了什么。
ExtensionDefinition 描述 kind、capability、版本、输入输出、side-effect class、UI slot 和数据边界；ExtensionProvider 绑定实际 artifact/Runtime/Adapter；ExtensionConsumer 来自 Pack、TaskSpec 或 workspace；PermissionGrant 记录授权；ResourceLease 绑定具体作用域与生命周期；Enforcement/DispositionReceipt 记录真实执行和释放。
这比一个万能 plugin manifest 更复杂，却能回答企业最关心的问题：是谁请求、谁批准、运行了哪些 bytes、在哪个范围生效、用到了什么权限、停止后是否清理。
Cordis 可以作为某些 Provider 内部实现，但 Core 合同不依赖 Cordis API。这样未来切换语言、进程模型或 Harness 时，企业治理不需要重写。
Extension Control Center 应该先只读
先让系统可理解，再让管理员操作；先看清来源和风险，再开放 mutation。
只读 Control Center 展示 installed/admitted/active/healthy/upgrade_pending，来源层级、版本与闭包、配置摘要、声明能力、请求权限、批准权限、实际 enforcement、最后验证时间和 rollback availability。
Harness 内部插件只作为某个 Runtime 的折叠组件报告，不提升成 Lumi Extension。来源 unknown、版本缺失或健康过期时应如实显示。用户可以从 Task/Artifact 追溯到实际 Provider，但不能从组件行直接任意 install 或 enable。
当只读模型稳定后，mutation 才按风险分阶段开放：低风险设置、审核扩展启停、签名升级、灰度与 previous-good rollback。
什么坚决不进入 Core
客户品牌、业务文案、具体流程与第三方内部状态，必须留在正确层。
无名初的品牌主题、见心、账号人格、运营节奏和客户数据属于 Overlay；内容版本、审片、排期等跨客户领域能力属于 Content Operations Pack；Harness plugin rows、session 内部状态属于 Runtime。
Core 只拥有通用 Task/Run/Artifact/Acceptance/Knowledge、权限、证据与扩展合同。若把每个客户业务页面和每个 Runtime 内部概念都回灌 Core，底座会成为所有项目的瓶颈。
判断标准不是“这个功能重要不重要”，而是它是否跨客户稳定复用、是否需要成为系统权威、数据责任由谁承担、升级是否必须与 Foundation 同步。
你真正要带走的，不只是技术解释
切换身份，看看这项技术会怎样改变战略、产品、工程和长期运营。
底座的价值是让客户差异更快交付，而不是把所有客户需求收进同一个版本。
四张可以带走的卡片
主对象稳定，能力可扩展
企业扩展需要 Definition/Provider/Grant/Lease/Receipt
Control Center 先只读
客户语义不进入 Core
无名初特有的账号人格和运营节奏最适合放在哪一层？
把理解变成自己的语言
试着写下：这项机制能解决什么、不能解决什么，以及它会怎样影响你的产品判断。内容只保存在当前浏览器。