企业扩展协议：从声明、授权到执行与留证

Definition 声明 capability、输入输出 schema、side-effect class、支持的 repo mode、UI contribution 和所需 permission。Consumer 说明哪个 Pack/Task 在什么目的和 scope 下请求。平台用 Policy 与人类决策产生 Grant。

Capability 和 Permission 不能共用一个字符串数组。图像生成能力可能需要网络与 Provider secret；Artifact Renderer 只需要读取特定 Artifact。把两者压成“image”会让最小授权无法实现。

Admission 还要检查 artifact/closure、配置、模型能力、compatibility matrix、secret ownership、sandbox completeness 和交互批准通道。任何 required fact unknown 时，策略应 fail closed，而不是猜测默认值。

TaskSpec 可以引用 logical capability key 与期望版本，服务端解析为 opaque binding id，并在 Run 创建时冻结 ExecutionBindingSnapshot。这样业务合同不依赖本地 Provider id，历史 Run 也不会随当前配置改变。

Event ledger 保存 source sequence/cursor 与 Lumi append sequence，prev digest 形成链；payload 有分类和 redaction version；unknown schema 进入 opaque diagnostic。状态机区分 starting、running、idle、degraded、outcome_unknown、terminated。

对于外部动作，使用 canonical idempotency key 和 terminal lifecycle。响应丢失时可以用相同 key 查询或重放，不得创建第二个业务动作。

ArtifactRevision 保存成果的不可变版本，Evidence 记录生成来源、引用、工具与运行身份。Acceptance 可以 changes_requested、accepted 或 rejected，并绑定精确 revision 与 actor authority。新的重做产生新 Run 与新 revision，不覆盖旧历史。

通过验收的成果可以被人类提升为 Knowledge 或 Skill，但提升是显式动作，不是因为模型回答看起来不错就自动发生。知识需要来源、版本、访问权限和失效条件。

这套分离让平台可以更换 Harness、模型或插件，同时保持业务历史可解释；也让审计者回答“谁在什么信息和权限下接受了哪个版本”。

发布身份使用 immutable SHA/release、签名 manifest、capability negotiation 和 compatibility matrix。普通 deprecation 至少跨多个已发布 minor 给出窗口；breaking removal 需要显式 major Gate。

升级前对比 capability、permission、schema 和 data migration；在 candidate channel 演练 backup/restore 与 rollback；升级后记录实际 ReleaseIdentity 和验证 receipt。previous-good 必须包含完整 closure 与配置，不能只是旧版本号。

扩展退出时，disposer 清理宿主资源，DispositionReceipt 记录结果；业务数据保留、迁移或归档遵循独立 retention 合同。被卸载的插件不能让历史 Artifact 变得无法解释。