# 失败与重试

以同一操作恢复未知结果，按资源所有权执行 DETACH 清理。

## 正常阶段与失败占用

生命周期只有 `INSTALL`、`UPGRADE`、`CONFIGURE`、`DETACH`，每次操作经过
`BEFORE_RESOURCES` 和 `AFTER_RESOURCES`。业务逻辑按照操作类型和阶段执行。
请求和响应没有 `intent`；不再登记或调用独立的操作结束接口。

网络超时可能发生在实际写入之后。安装、升级和配置操作保存失败或未知结果，停止后续阶段并保留占用。卸载按下述平台清理边界处理。
重试使用同一 `operationId + stage` 和同一 `executionSequence`；内部派发记录变化不产生新业务操作。
插件返回既有业务结果和获授权属性，不重复创建租户、不猜测完成状态。

## 所有者写入顺序

`executionSequence` 是 Runtime 提供的正整数操作顺序；插件不能按 UUID、时间戳或自身计数器重新推断顺序。
所有者把顺序校验、业务写入和业务回执放在同一数据库事务或具有相同隔离保证的操作中。
同一安装资源只接受当前操作的相同动作重试，较旧操作的迟到请求不得继续修改业务状态。
后台缓存、凭据刷新和调度器也必须服从实际业务记录的当前状态。

## DETACH 串行接管

失败的安装、升级或配置可以由 DETACH 在 Runtime 的同一互斥边界内接管。
清理范围包含当前实际资源及失败操作可能已创建的中间资源。被接管的操作不能重试、写回输出或提交完成。
所有者保留顺序记录，即使此前没有创建业务实例，也能拒绝迟到的首次创建请求；不得为清理伪造业务租户。

DETACH 的平台资源清理失败时仍保留占用，并按同一操作续跑。平台清理全部完成后即可提交卸载并释放占用；外部业务插件的失败或未知结果单独保留，继续按原操作及原阶段重试，不伪造插件成功。原多 Bundle 计划中的其他操作保留冻结身份；
原计划不能重新创建已被 DETACH 接管的参与者。

业务插件清理只作用于自己拥有的业务实例及关联。共享业务数据、其他安装的资源和执行历史遵守各自 Owner 的保留规则。
历史归属缺失时，先由 Owner 根据权威记录迁移；不能按工作区或 Module 模糊匹配后批量删除。

## Runtime 内部提交

安装、升级和配置需要资源与插件正常阶段完成；卸载需要平台资源清理完成。Runtime 在自身事务内提交安装结果、保存事件并释放占用。
插件无需实现额外结束通知。模块 Token 的签发与使用属于系统插件和 ACS，属性读写使用通用插件机制。Runtime 不调用 ACS 处理模块 Token，不保存安装凭据清单，也不以凭据清理作为安装或卸载完成条件。

## Runtime 停止和删除

停止 Runtime 只暂停新的入口与定时执行，保留 Bundle 安装、Timer 定义、凭据与业务资源。已发出的业务请求可能仍在执行；停止不代表回滚这些请求。恢复运行后，保留的排期继续生效。

删除 Runtime 先停止执行，再按依赖顺序卸载所有 Bundle。平台清理失败时 Runtime 保留为停止状态，继续重试；最后的删除事务再次核对没有活动安装，防止并发新安装被遗漏。业务插件的旧清理可以在 Runtime 删除后继续，它只拥有原安装的清理身份，不能读取新安装属性或回写新安装。