---
docStatus: current
---

# 交付完整性与验收证据

在发布验收中关联精确 Bundle、后端制品、部署、插件协议与真实业务证据，保留独立安装边界。

Bundle 是业务资源定义的版本化交付单元。前端构建、独立后端程序、插件进程、数据库和第三方账号有各自的
所有者与生命周期。一个完整 Bundle JSON 不代表目标环境已经部署所有程序或配置所有业务入口。

## 交付闭包由谁证明

| 内容           | 权威来源                                         | 发布时记录什么                                   |
| ------------ | -------------------------------------------- | ----------------------------------------- |
| Bundle 与本包资源 | Bundle 精确版本、源码项目与各资源 Owner                   | 来源环境、Bundle 身份和精确版本、源码提交、完整资源及精确版本        |
| 编译期类型        | Module 不可变版本内闭合的类型合同                         | 所消费的精确 Type Definition 合同；不生成 Bundle 安装依赖 |
| 前端和后端        | 项目版本、BuildJob、Artifact、站点或 Hosted Service 部署 | 项目、精确程序版本、源码提交、制品身份、目标环境与成功部署记录           |
| 生命周期插件       | 插件目录与提供方程序版本                                 | 稳定 pluginId、生命周期和引用协议、精确程序版本及已验证入口；不记录凭据  |
| 平台能力         | 目标平台登记的资源 Owner、内容与执行协议                      | 本包实际需要的资源类型和合同，以及目标环境的执行验证证据              |
| 外部服务与绑定      | Module 显式属性配置、第三方账号与业务授权                     | 必要配置项名称、绑定目的、配置责任人和验收场景；Secret 仅记录受控引用    |

清单记录不可变交付引用及本次验收结果，不创建第二份部署目录、Runtime 库存或安装状态。
发布者负责核对是否遗漏程序、资源或业务前置条件；工具不能从空清单推断“没有外部要求”。

## 分别验收三个结果

1. **定义交付通过**：精确源码提交、资源版本、同包引用与插件资源授权通过校验。
2. **部署验证通过**：必要程序的精确制品已部署到声明的目标，迁移和 Endpoint 成功；Runtime Owner 返回预期资源。
3. **业务验收通过**：配置和授权完成，真实入口执行成功，结果符合预先声明的断言。

未知、失败、跳过或仍在执行的结果都不能标记通过。历史成功部署不代表当前 Environment 正在运行该版本；
应同时核对当前部署关联。Bundle 安装账不能替代资源 Owner 库存。报告只是采集时的证据，后续配置变更需重新验收。

## 发布阶段采集

先按本机分级帮助确认命令：

```bash
baijimu bundle version list --help
baijimu bundle manifest preflight --help
baijimu project version get --help
baijimu rust-build artifact get --help
baijimu hosted-service project deployments --help
baijimu hosted-service env list --help
baijimu lifecycle-plugin get --help
baijimu bundle resources --help
```

从真实目录取得身份并读取精确版本；不要使用展示名猜 ID、选择 latest 或拼接部署地址。
按[项目清单](/development/bundle-development/manifest/)执行结构验证和在线预检，正式创建版本仍重新校验准确提交。
独立后端的制品与部署分别按[后端验证](/development/backend-development/verification-and-troubleshooting/)回读。

[交付证据采集脚本](/examples/bundle-delivery/collect.py)通过官方 CLI 读取声明范围内的 Bundle 版本、
Hosted Service 项目版本和制品、当前部署、插件登记及 Owner 资源，生成脱敏 JSON 报告。它只执行只读查询，
不安装、不配置、不调用业务方法、不补授权，也不新增安装器前置探测。
使用前在自己的发布流程中列出完整交付范围；具体输入和退出状态见脚本的 `--help`。

业务验收由业务项目自身的测试执行，保存准确目标、源码与程序版本、执行时间、场景、预期断言和实际结果。
报告中的业务状态保持“待业务验收”，不能用查询成功或 HTTP 200 自动生成业务成功结论。

## 独立安装与功能前置条件

在不安装其他业务 Bundle 的 Runtime 中验证本包定义可以独立安装。声明的核心业务需要可重复执行的场景测试；
第三方服务自身的合法账号、API Key 或用户授权仍可作为该功能的必要配置。

跨 Bundle 集成另外验证未绑定、目标缺失、接口不匹配、权限拒绝、撤销、提供方升级与卸载；失败只影响相应功能。
可选提供方不进入安装依赖闭包，不导致安装排序、反向卸载阻断或自动安装。
平台不支持本包必要的资源类型或协议时应明确失败，不跳过未知资源，也不自动创建基础设施。

安装、绑定与调用的职责见[安装与资源绑定](/development/bundle-development/installation-and-binding/)。

## 插件注册证据的范围

采集规范为每个插件明确填写 `lifecycleProtocol`、`referenceProtocol`、`credentialsProtocol`、`bindingReadProtocol`、`inventoryProtocol` 和 `propertyWriteProtocol` 的准确 SemVer；版本以[权威协议规范](/development/lifecycle-plugin-development/reference-protocol/#协议选择与环境边界)与本次交付目标为准。
脚本逐项核对目录的 `bundleExecution.protocols`，旧 `protocolVersion` 格式、声明缺失或任一版本不符均失败，不做旧格式回退。
`registrationVerification: MATCHED_DECLARED_PROTOCOLS` 只证明目录声明相符。`programVerification`、`businessVerification` 仍为 `NOT_EXECUTED`；握手、生命周期配置、真实引用调用及轮换/撤销必须另行验收，不能用目录匹配结果替代。