工作空间里的应用能跑，往往依赖很多默认条件：工具已经连接，模型已经配置，目录里还有以前试验留下的文件。复制目录能把页面交过去，却不一定交付了可维护的应用。
我把发布包、部署与运行数据拆开。别人收到的应是可识别的应用版本，目标环境自行绑定资源，用户数据不跟着应用更新被覆盖。
交付清单说明应用依赖什么
{
"version": "1.0",
"entry": "web",
"requiredTools": ["read-metrics"],
"configuration": ["business-scope"],
"credentialSlots": ["business-access"]
}这是示意声明，不是某个产品的标准接口。它表达入口、所需工具、配置与凭证槽位。接收方缺什么，要能从检查结果直接看到，而不是启动以后反复试。
依赖不能只写显示名称。名字相同的工具在不同环境中可能有不同参数和行为，发布记录需要明确引用、兼容约束与当次解析结果。
源码、指令、工具声明与入口配置都参与发布摘要。只固定页面代码、让提示词一直变化，同样无法解释一次运行采用了什么。
构建环境不直接承载用户运行
试验文件、未完成修改和构建对话属于开发过程，运行实例服务用户。调试动作不能直接改动用户正在使用的版本。
只读发布包保存应用定义，部署记录保存环境绑定与当前版本，用户会话、业务文件和产出保存在独立存储。更新切换应用引用，不删除这些持久状态。
凭证由目标环境按自己的权限提供。包里只声明槽位，不能把构建者的真实密钥和范围复制过去。秘密值也不进入差异预览与诊断日志。
安装过程有候选状态
- 校验包摘要、格式与兼容约束。
- 收集目标环境参数并绑定凭证引用。
- 创建候选实例，探测依赖与执行能力。
- 使用目标普通身份完成最小业务检查。
- 切换当前部署引用，记录生效版本。
- 保留上一部署、检查证据与候选失败原因。
候选失败不接默认流量。连接检查只说明服务可达，工具列表可读不能代替实际查询可用。测试写入使用明确标记并清理，不能拿构建者的高权限替用户证明功能正常。
回退范围由数据变化决定
切换后有问题，可以恢复上一部署引用，再核对新版本已经写过什么。涉及不可逆迁移时，切回源码不等于完整恢复。
第一版尽量使用兼容增加字段的方式，等旧版本不再使用后清理。必须迁移的变更，发布计划列出执行范围、恢复限制与所需备份，不把它混在普通版本替换中。
部署记录至少关联 releaseDigest、bindingRevision、runtimeGeneration 与状态，用户实例明确引用部署版本。配置变了、运行环境重建了，仍能查出是哪一层。
交付验收发生在接收方环境
普通用户访问、无权限、依赖缺失和外部失败都要覆盖，结果与可处理的错误分别检查。包安装完成、运行启动与业务任务可用是不同结论。
在目标环境重复安装同一版本，不重复创建受管资源；更新保留用户数据，失败候选不接流量，回退后仍能解释之前发生的操作。应用离开原工作空间后继续遵守这些规则，才是一份完整交付。