综合设备交付
让产品可以复现

14.1.1 对象和使用场景

系统合同的第一原则是先写清对象，再写清边界。这里的对象不是一句‘设备’，而是某个板卡、SoC、传感器、执行器、固件版本、分区、服务和用户动作的组合；边界则包括电源、时钟、存储、网络、温度、权限、工具链和资料版本。需求工程把人与设备之间的承诺变成可执行条目只有当对象、输入、机制、输出、时间窗口和验收人同时出现时，‘可用’才是可以重复检查的工程判断。若缺少其中一项，读者只能复述概念，不能在自己的环境中重放结果。

14.1.2 shall 句子与验收指标

系统合同要把抽象目标拆成可观察的断言。例如‘启动快’应改成‘在指定板卡、指定冷启动条件下，从复位释放到服务 readiness 的 p95 不超过某个窗口，串口和时间戳均被保存’；‘更新安全’应改成‘候选镜像来自允许来源、签名和兼容性检查通过、首次健康检查失败会回到已知可启动版本’。需求编号、验收方法、样本和版本每个断言都要有证据类型、生成命令、版本身份和不能推出的结论。

PYTHON · REQUIREMENT GATE复制
from delivery_model import Requirement, requirement_ok

req = Requirement('REQ-BOOT-01', '冷启动进入服务', 'ready_ms', 2500, 'serial+timestamp')
print(requirement_ok(req, 1840))

主机检查指标与阈值；冷启动时钟、串口、电源和真实服务仍需目标机证据。

YAML · CONTRACT SHAPE复制
id: REQ-BOOT-01
metric: ready_ms
limit: 2500
evidence: serial+timestamp
scope: board-rev-b

字段是合同形状；单位、采样窗口、板卡和版本必须按项目确认。

14.1.3 时间、功耗与资源预算

把机制和结果分开是交付记录的关键。机制描述系统为什么可能达到结果：启动阶段如何交接、接口如何编码、服务如何依赖、数据如何落盘、密钥如何验证、失败如何恢复；结果描述这一次观测到了什么。一个主机状态机、一个 QEMU smoke 或一个 CI 绿灯可以验证机制的某一部分，但不能替代真实 GPIO 电平、DDR 初始化、Flash 掉电、射频质量、热边界和量产密钥的证据。

14.1.4 需求来源、假设与未知

证据应形成从输入到结论的可追溯路径：需求编号指向设计决策，设计决策指向源码/配置，源码/配置指向构建产物，产物指向测试记录，测试记录指向版本与设备身份。需求编号、验收方法、样本和版本记录中至少要有采集时间、工具版本、工作负载、样本窗口、失败样例和保留期限。这样审查者可以重算指标，也可以发现某一句结论其实跨越了没有执行的目标机步骤。

14.1.5 追踪矩阵与变更影响

风险管理不是把所有异常都归为‘偶发’。先描述触发条件，再判断影响、发生可能性和可探测性，最后指定预防、检测、降级和恢复动作。指标缺失会把隐患推到现场如果风险没有负责人、门禁或停止条件，它就只是备注；如果只有风险分数没有现场动作，分数也不能让设备回到安全态。对执行器、电源、网络凭据和更新槽位，默认动作应优先保护人身、数据和旧版本可启动性。

14.1.6 风险、降级与安全态

主机练习可以从一个小的确定性模型开始：解析 manifest，检查字段，计算摘要，推进状态机，注入超时、截断、重复、缺失和版本不兼容，然后断言系统拒绝危险输入并保留原因。练习的价值不在于假装模拟了芯片，而在于让读者先把输入、输出、错误码和证据格式固定下来。合同也适用于协议、CI 和现场运维迁移到目标板时，要把模型通过的字段与仍需测量的硬件事实逐项对照，不能把‘脚本通过’改写成‘产品通过’。

14.1.7 验收样本与统计窗口

交付包应让另一个人从干净目录开始，而不是依赖作者电脑里的缓存和记忆。README 要说明 Python 版本、安装命令、测试命令、预期输出、可选工具、目标机前置条件和恢复方式；manifest 要列出版本、来源、摘要、许可证和兼容性；evidence 要保存实际运行记录和未执行项。对外发布前再检查压缩包内容、相对路径、可执行权限、换行符和秘密是否被误打包。

14.1.8 本节交付：系统合同卡

复盘时采用单变量改变：保留上一份输入、产物、日志和设备身份，只替换一个条件，例如更换候选版本、缩短超时、断开网络或模拟掉电。比较最后成功阶段、错误分类、状态迁移和恢复动作，才能说明因果。不要同时换 bootloader、内核、rootfs、供电、配置和测试板；那样即使现象改变，也无法知道是哪一个条件造成改变。最后把未知项、停止条件和下一步实验写入交付记录。

14.2.1 系统分解与资源所有权

软硬件协同的第一原则是先写清对象，再写清边界。这里的对象不是一句‘设备’，而是某个板卡、SoC、传感器、执行器、固件版本、分区、服务和用户动作的组合；边界则包括电源、时钟、存储、网络、温度、权限、工具链和资料版本。接口的每一列都既有逻辑语义也有物理前置条件只有当对象、输入、机制、输出、时间窗口和验收人同时出现时，‘可用’才是可以重复检查的工程判断。若缺少其中一项，读者只能复述概念，不能在自己的环境中重放结果。

14.2.2 引脚复用与电气合同

系统合同要把抽象目标拆成可观察的断言。例如‘启动快’应改成‘在指定板卡、指定冷启动条件下，从复位释放到服务 readiness 的 p95 不超过某个窗口，串口和时间戳均被保存’；‘更新安全’应改成‘候选镜像来自允许来源、签名和兼容性检查通过、首次健康检查失败会回到已知可启动版本’。原理图、BOM、波形和版本矩阵每个断言都要有证据类型、生成命令、版本身份和不能推出的结论。

PYTHON · INTERFACE DIGEST复制
from delivery_model import interface_digest

fields = {'board': 'rev-b', 'i2c': '400kHz', 'vdd': '3.3V'}
print(interface_digest(fields))

主机确认接口清单稳定；电平、波形、时钟抖动和器件容差仍需目标机测量。

C · RESOURCE OWNER复制
typedef struct {
    const char *owner;
    unsigned long base;
    unsigned irq;
} resource_owner_t;

/* board revision and electrical limits stay in the BSP contract */

结构展示资源所有权；地址、IRQ、引脚和电气限制必须来自当前板卡资料。

14.2.3 时钟、复位与电源时序

把机制和结果分开是交付记录的关键。机制描述系统为什么可能达到结果：启动阶段如何交接、接口如何编码、服务如何依赖、数据如何落盘、密钥如何验证、失败如何恢复；结果描述这一次观测到了什么。一个主机状态机、一个 QEMU smoke 或一个 CI 绿灯可以验证机制的某一部分，但不能替代真实 GPIO 电平、DDR 初始化、Flash 掉电、射频质量、热边界和量产密钥的证据。

14.2.4 存储、内存与带宽预算

证据应形成从输入到结论的可追溯路径：需求编号指向设计决策，设计决策指向源码/配置，源码/配置指向构建产物，产物指向测试记录，测试记录指向版本与设备身份。原理图、BOM、波形和版本矩阵记录中至少要有采集时间、工具版本、工作负载、样本窗口、失败样例和保留期限。这样审查者可以重算指标，也可以发现某一句结论其实跨越了没有执行的目标机步骤。

14.2.5 总线拓扑与协议版本

风险管理不是把所有异常都归为‘偶发’。先描述触发条件，再判断影响、发生可能性和可探测性，最后指定预防、检测、降级和恢复动作。错误边界会在量产后变成返工如果风险没有负责人、门禁或停止条件，它就只是备注；如果只有风险分数没有现场动作，分数也不能让设备回到安全态。对执行器、电源、网络凭据和更新槽位，默认动作应优先保护人身、数据和旧版本可启动性。

14.2.6 BSP、HAL 与驱动边界

主机练习可以从一个小的确定性模型开始：解析 manifest，检查字段，计算摘要，推进状态机，注入超时、截断、重复、缺失和版本不兼容，然后断言系统拒绝危险输入并保留原因。练习的价值不在于假装模拟了芯片，而在于让读者先把输入、输出、错误码和证据格式固定下来。协同合同也适用于云端 API 和模块化系统迁移到目标板时，要把模型通过的字段与仍需测量的硬件事实逐项对照，不能把‘脚本通过’改写成‘产品通过’。

14.2.7 板卡改版与兼容矩阵

交付包应让另一个人从干净目录开始，而不是依赖作者电脑里的缓存和记忆。README 要说明 Python 版本、安装命令、测试命令、预期输出、可选工具、目标机前置条件和恢复方式；manifest 要列出版本、来源、摘要、许可证和兼容性；evidence 要保存实际运行记录和未执行项。对外发布前再检查压缩包内容、相对路径、可执行权限、换行符和秘密是否被误打包。

14.2.8 本节交付：协同接口卡

复盘时采用单变量改变：保留上一份输入、产物、日志和设备身份，只替换一个条件，例如更换候选版本、缩短超时、断开网络或模拟掉电。比较最后成功阶段、错误分类、状态迁移和恢复动作，才能说明因果。不要同时换 bootloader、内核、rootfs、供电、配置和测试板；那样即使现象改变，也无法知道是哪一个条件造成改变。最后把未知项、停止条件和下一步实验写入交付记录。

14.3.1 数据字典和单位

端到端集成的第一原则是先写清对象，再写清边界。这里的对象不是一句‘设备’，而是某个板卡、SoC、传感器、执行器、固件版本、分区、服务和用户动作的组合；边界则包括电源、时钟、存储、网络、温度、权限、工具链和资料版本。完整业务链的正确性来自跨层不变量而不是某个函数返回值只有当对象、输入、机制、输出、时间窗口和验收人同时出现时，‘可用’才是可以重复检查的工程判断。若缺少其中一项，读者只能复述概念，不能在自己的环境中重放结果。

14.3.2 时间戳、序列与关联 ID

系统合同要把抽象目标拆成可观察的断言。例如‘启动快’应改成‘在指定板卡、指定冷启动条件下，从复位释放到服务 readiness 的 p95 不超过某个窗口，串口和时间戳均被保存’；‘更新安全’应改成‘候选镜像来自允许来源、签名和兼容性检查通过、首次健康检查失败会回到已知可启动版本’。帧、状态、关联 ID 和输出测量每个断言都要有证据类型、生成命令、版本身份和不能推出的结论。

PYTHON · STATE REPLAY复制
from delivery_model import transition

state = 'READY'
for event in ('SENSOR_SAMPLE', 'NETWORK_LOST', 'RECOVERED'):
    state = transition(state, event)
print(state)

主机重放状态和故障；传感器噪声、总线仲裁和执行器动作仍需目标机。

JSON · EVENT FRAME复制
{"schema":"device.event.v1","seq":42,"kind":"sample","unit":"degC","value":23.5,"correlation_id":"job-7"}

帧示例固定字段与单位；端序、CRC、链路时序和真实数据质量要在设备上验收。

14.3.3 状态机与不变量

把机制和结果分开是交付记录的关键。机制描述系统为什么可能达到结果：启动阶段如何交接、接口如何编码、服务如何依赖、数据如何落盘、密钥如何验证、失败如何恢复；结果描述这一次观测到了什么。一个主机状态机、一个 QEMU smoke 或一个 CI 绿灯可以验证机制的某一部分，但不能替代真实 GPIO 电平、DDR 初始化、Flash 掉电、射频质量、热边界和量产密钥的证据。

14.3.4 队列、背压与丢弃策略

证据应形成从输入到结论的可追溯路径：需求编号指向设计决策，设计决策指向源码/配置，源码/配置指向构建产物，产物指向测试记录，测试记录指向版本与设备身份。帧、状态、关联 ID 和输出测量记录中至少要有采集时间、工具版本、工作负载、样本窗口、失败样例和保留期限。这样审查者可以重算指标，也可以发现某一句结论其实跨越了没有执行的目标机步骤。

14.3.5 超时、重试与幂等

风险管理不是把所有异常都归为‘偶发’。先描述触发条件，再判断影响、发生可能性和可探测性，最后指定预防、检测、降级和恢复动作。跨层丢失上下文会让定位变慢如果风险没有负责人、门禁或停止条件，它就只是备注；如果只有风险分数没有现场动作，分数也不能让设备回到安全态。对执行器、电源、网络凭据和更新槽位，默认动作应优先保护人身、数据和旧版本可启动性。

14.3.6 部分失败与降级模式

主机练习可以从一个小的确定性模型开始：解析 manifest，检查字段，计算摘要，推进状态机，注入超时、截断、重复、缺失和版本不兼容，然后断言系统拒绝危险输入并保留原因。练习的价值不在于假装模拟了芯片，而在于让读者先把输入、输出、错误码和证据格式固定下来。端到端方法可迁移到任何事件驱动系统迁移到目标板时，要把模型通过的字段与仍需测量的硬件事实逐项对照，不能把‘脚本通过’改写成‘产品通过’。

14.3.7 端到端延迟与质量指标

交付包应让另一个人从干净目录开始，而不是依赖作者电脑里的缓存和记忆。README 要说明 Python 版本、安装命令、测试命令、预期输出、可选工具、目标机前置条件和恢复方式；manifest 要列出版本、来源、摘要、许可证和兼容性；evidence 要保存实际运行记录和未执行项。对外发布前再检查压缩包内容、相对路径、可执行权限、换行符和秘密是否被误打包。

14.3.8 本节交付：集成场景卡

复盘时采用单变量改变：保留上一份输入、产物、日志和设备身份，只替换一个条件，例如更换候选版本、缩短超时、断开网络或模拟掉电。比较最后成功阶段、错误分类、状态迁移和恢复动作，才能说明因果。不要同时换 bootloader、内核、rootfs、供电、配置和测试板；那样即使现象改变，也无法知道是哪一个条件造成改变。最后把未知项、停止条件和下一步实验写入交付记录。

14.4.1 验证与确认的区别

验证与确认的第一原则是先写清对象，再写清边界。这里的对象不是一句‘设备’，而是某个板卡、SoC、传感器、执行器、固件版本、分区、服务和用户动作的组合；边界则包括电源、时钟、存储、网络、温度、权限、工具链和资料版本。分层测试让每个问题在最便宜且最有解释力的层被发现只有当对象、输入、机制、输出、时间窗口和验收人同时出现时，‘可用’才是可以重复检查的工程判断。若缺少其中一项，读者只能复述概念，不能在自己的环境中重放结果。

14.4.2 测试金字塔与门禁顺序

系统合同要把抽象目标拆成可观察的断言。例如‘启动快’应改成‘在指定板卡、指定冷启动条件下，从复位释放到服务 readiness 的 p95 不超过某个窗口，串口和时间戳均被保存’；‘更新安全’应改成‘候选镜像来自允许来源、签名和兼容性检查通过、首次健康检查失败会回到已知可启动版本’。测试命令、种子、设备身份和边界每个断言都要有证据类型、生成命令、版本身份和不能推出的结论。

PYTHON · TEST MATRIX复制
from delivery_model import test_verdict

print(test_verdict(100, 101, tolerance=2))
print(test_verdict(100, 105, tolerance=2))

主机验证判定逻辑；仪器精度、负载、温度和目标机重复性仍需补证。

SHELL · CLEAN RUN复制
python -m venv .venv
python -m pip install --upgrade pip
python run_all_tests.py
python -m pip check

命令适用于实验包主机路径；不代表交叉工具链、QEMU 或板卡已经可用。

14.4.3 边界、性质与黄金样本

把机制和结果分开是交付记录的关键。机制描述系统为什么可能达到结果：启动阶段如何交接、接口如何编码、服务如何依赖、数据如何落盘、密钥如何验证、失败如何恢复；结果描述这一次观测到了什么。一个主机状态机、一个 QEMU smoke 或一个 CI 绿灯可以验证机制的某一部分，但不能替代真实 GPIO 电平、DDR 初始化、Flash 掉电、射频质量、热边界和量产密钥的证据。

14.4.4 QEMU、仿真与 HIL 边界

证据应形成从输入到结论的可追溯路径：需求编号指向设计决策，设计决策指向源码/配置，源码/配置指向构建产物，产物指向测试记录，测试记录指向版本与设备身份。测试命令、种子、设备身份和边界记录中至少要有采集时间、工具版本、工作负载、样本窗口、失败样例和保留期限。这样审查者可以重算指标，也可以发现某一句结论其实跨越了没有执行的目标机步骤。

14.4.5 故障注入和可恢复性

风险管理不是把所有异常都归为‘偶发’。先描述触发条件，再判断影响、发生可能性和可探测性，最后指定预防、检测、降级和恢复动作。错层验证会制造虚假的信心如果风险没有负责人、门禁或停止条件，它就只是备注；如果只有风险分数没有现场动作，分数也不能让设备回到安全态。对执行器、电源、网络凭据和更新槽位，默认动作应优先保护人身、数据和旧版本可启动性。

14.4.6 重复性、随机种子与 flaky

主机练习可以从一个小的确定性模型开始：解析 manifest，检查字段，计算摘要，推进状态机，注入超时、截断、重复、缺失和版本不兼容，然后断言系统拒绝危险输入并保留原因。练习的价值不在于假装模拟了芯片，而在于让读者先把输入、输出、错误码和证据格式固定下来。分层门禁同样适用于数据管道和服务发布迁移到目标板时，要把模型通过的字段与仍需测量的硬件事实逐项对照，不能把‘脚本通过’改写成‘产品通过’。

14.4.7 覆盖率、指标和停止条件

交付包应让另一个人从干净目录开始，而不是依赖作者电脑里的缓存和记忆。README 要说明 Python 版本、安装命令、测试命令、预期输出、可选工具、目标机前置条件和恢复方式；manifest 要列出版本、来源、摘要、许可证和兼容性；evidence 要保存实际运行记录和未执行项。对外发布前再检查压缩包内容、相对路径、可执行权限、换行符和秘密是否被误打包。

14.4.8 本节交付：分层验证卡

复盘时采用单变量改变：保留上一份输入、产物、日志和设备身份，只替换一个条件，例如更换候选版本、缩短超时、断开网络或模拟掉电。比较最后成功阶段、错误分类、状态迁移和恢复动作，才能说明因果。不要同时换 bootloader、内核、rootfs、供电、配置和测试板；那样即使现象改变，也无法知道是哪一个条件造成改变。最后把未知项、停止条件和下一步实验写入交付记录。

14.5.1 依赖、来源与版本锁定

安全与供应链的第一原则是先写清对象，再写清边界。这里的对象不是一句‘设备’，而是某个板卡、SoC、传感器、执行器、固件版本、分区、服务和用户动作的组合；边界则包括电源、时钟、存储、网络、温度、权限、工具链和资料版本。每个产物都需要可追踪身份和可撤销的信任关系只有当对象、输入、机制、输出、时间窗口和验收人同时出现时，‘可用’才是可以重复检查的工程判断。若缺少其中一项，读者只能复述概念，不能在自己的环境中重放结果。

14.5.2 SBOM 与许可证证据

系统合同要把抽象目标拆成可观察的断言。例如‘启动快’应改成‘在指定板卡、指定冷启动条件下，从复位释放到服务 readiness 的 p95 不超过某个窗口，串口和时间戳均被保存’；‘更新安全’应改成‘候选镜像来自允许来源、签名和兼容性检查通过、首次健康检查失败会回到已知可启动版本’。SBOM、来源摘要、签名和密钥角色每个断言都要有证据类型、生成命令、版本身份和不能推出的结论。

PYTHON · SBOM CHECK复制
from delivery_model import sbom_entry, sbom_ok

entries = [sbom_entry('demo', '1.0.0', 'MIT', 'https://example.invalid/demo')]
print(sbom_ok(entries))

主机检查来源、版本和许可证字段；签名、密钥注入和调试锁需要目标机/工厂证据。

JSON · RELEASE IDENTITY复制
{"version":"14.0.0","source_commit":"abc123","sbom":"SPDX-2.3","signature":"detached.sig","rollback_index":7}

manifest 记录身份关系；真正的信任根、计数器和撤销策略须按产品安全架构验证。

14.5.3 哈希、签名与信任根

把机制和结果分开是交付记录的关键。机制描述系统为什么可能达到结果：启动阶段如何交接、接口如何编码、服务如何依赖、数据如何落盘、密钥如何验证、失败如何恢复；结果描述这一次观测到了什么。一个主机状态机、一个 QEMU smoke 或一个 CI 绿灯可以验证机制的某一部分，但不能替代真实 GPIO 电平、DDR 初始化、Flash 掉电、射频质量、热边界和量产密钥的证据。

14.5.4 安全启动和测量启动

证据应形成从输入到结论的可追溯路径：需求编号指向设计决策，设计决策指向源码/配置，源码/配置指向构建产物，产物指向测试记录，测试记录指向版本与设备身份。SBOM、来源摘要、签名和密钥角色记录中至少要有采集时间、工具版本、工作负载、样本窗口、失败样例和保留期限。这样审查者可以重算指标，也可以发现某一句结论其实跨越了没有执行的目标机步骤。

14.5.5 密钥角色、注入和轮换

风险管理不是把所有异常都归为‘偶发’。先描述触发条件，再判断影响、发生可能性和可探测性，最后指定预防、检测、降级和恢复动作。信任链断点会让修复变成紧急返厂如果风险没有负责人、门禁或停止条件，它就只是备注；如果只有风险分数没有现场动作，分数也不能让设备回到安全态。对执行器、电源、网络凭据和更新槽位，默认动作应优先保护人身、数据和旧版本可启动性。

14.5.6 调试口、权限和最小暴露

主机练习可以从一个小的确定性模型开始：解析 manifest，检查字段，计算摘要，推进状态机，注入超时、截断、重复、缺失和版本不兼容，然后断言系统拒绝危险输入并保留原因。练习的价值不在于假装模拟了芯片，而在于让读者先把输入、输出、错误码和证据格式固定下来。供应链治理也适用于网站和实验包迁移到目标板时，要把模型通过的字段与仍需测量的硬件事实逐项对照，不能把‘脚本通过’改写成‘产品通过’。

14.5.7 漏洞、撤销与回滚保护

交付包应让另一个人从干净目录开始，而不是依赖作者电脑里的缓存和记忆。README 要说明 Python 版本、安装命令、测试命令、预期输出、可选工具、目标机前置条件和恢复方式；manifest 要列出版本、来源、摘要、许可证和兼容性；evidence 要保存实际运行记录和未执行项。对外发布前再检查压缩包内容、相对路径、可执行权限、换行符和秘密是否被误打包。

14.5.8 本节交付：供应链安全卡

复盘时采用单变量改变：保留上一份输入、产物、日志和设备身份，只替换一个条件，例如更换候选版本、缩短超时、断开网络或模拟掉电。比较最后成功阶段、错误分类、状态迁移和恢复动作，才能说明因果。不要同时换 bootloader、内核、rootfs、供电、配置和测试板；那样即使现象改变，也无法知道是哪一个条件造成改变。最后把未知项、停止条件和下一步实验写入交付记录。

14.6.1 发布角色与环境

发布与现场的第一原则是先写清对象，再写清边界。这里的对象不是一句‘设备’，而是某个板卡、SoC、传感器、执行器、固件版本、分区、服务和用户动作的组合；边界则包括电源、时钟、存储、网络、温度、权限、工具链和资料版本。发布是一项跨角色的操作合同而不是一个文件名只有当对象、输入、机制、输出、时间窗口和验收人同时出现时，‘可用’才是可以重复检查的工程判断。若缺少其中一项，读者只能复述概念，不能在自己的环境中重放结果。

14.6.2 manifest、版本和包结构

系统合同要把抽象目标拆成可观察的断言。例如‘启动快’应改成‘在指定板卡、指定冷启动条件下，从复位释放到服务 readiness 的 p95 不超过某个窗口，串口和时间戳均被保存’；‘更新安全’应改成‘候选镜像来自允许来源、签名和兼容性检查通过、首次健康检查失败会回到已知可启动版本’。manifest、烧录、健康、回滚和支持记录每个断言都要有证据类型、生成命令、版本身份和不能推出的结论。

PYTHON · RELEASE GATE复制
from delivery_model import release_gate

print(release_gate(host_ok=True, target_ok=False, recovery_image=True, sbom_ok=True, known_limits=['RF not run']))

主机提醒门禁缺口；目标机、工厂烧录、断电恢复和现场 runbook 不能由模型伪造。

SHELL · PACKAGE CHECK复制
python run_all_tests.py
python -c "import json; print(json.load(open('examples/release_manifest.json'))['version'])"
python -m pip check

命令确认包能运行；版本、签名、设备身份和支持窗口仍要由发布流程补齐。

14.6.3 烧录、身份与工厂记录

把机制和结果分开是交付记录的关键。机制描述系统为什么可能达到结果：启动阶段如何交接、接口如何编码、服务如何依赖、数据如何落盘、密钥如何验证、失败如何恢复；结果描述这一次观测到了什么。一个主机状态机、一个 QEMU smoke 或一个 CI 绿灯可以验证机制的某一部分，但不能替代真实 GPIO 电平、DDR 初始化、Flash 掉电、射频质量、热边界和量产密钥的证据。

14.6.4 健康检查与升级窗口

证据应形成从输入到结论的可追溯路径：需求编号指向设计决策，设计决策指向源码/配置，源码/配置指向构建产物，产物指向测试记录，测试记录指向版本与设备身份。manifest、烧录、健康、回滚和支持记录记录中至少要有采集时间、工具版本、工作负载、样本窗口、失败样例和保留期限。这样审查者可以重算指标，也可以发现某一句结论其实跨越了没有执行的目标机步骤。

14.6.5 断电、网络中断与回滚

风险管理不是把所有异常都归为‘偶发’。先描述触发条件，再判断影响、发生可能性和可探测性，最后指定预防、检测、降级和恢复动作。不可恢复的升级会把软件错误变成硬件返修如果风险没有负责人、门禁或停止条件，它就只是备注；如果只有风险分数没有现场动作，分数也不能让设备回到安全态。对执行器、电源、网络凭据和更新槽位，默认动作应优先保护人身、数据和旧版本可启动性。

14.6.6 日志、指标与远程支持

主机练习可以从一个小的确定性模型开始：解析 manifest，检查字段，计算摘要，推进状态机，注入超时、截断、重复、缺失和版本不兼容，然后断言系统拒绝危险输入并保留原因。练习的价值不在于假装模拟了芯片，而在于让读者先把输入、输出、错误码和证据格式固定下来。发布卡可以迁移到任何需要长期维护的产品迁移到目标板时，要把模型通过的字段与仍需测量的硬件事实逐项对照，不能把‘脚本通过’改写成‘产品通过’。

14.6.7 支持周期、弃用与热修复

交付包应让另一个人从干净目录开始，而不是依赖作者电脑里的缓存和记忆。README 要说明 Python 版本、安装命令、测试命令、预期输出、可选工具、目标机前置条件和恢复方式；manifest 要列出版本、来源、摘要、许可证和兼容性；evidence 要保存实际运行记录和未执行项。对外发布前再检查压缩包内容、相对路径、可执行权限、换行符和秘密是否被误打包。

14.6.8 本节交付：产品发布卡

复盘时采用单变量改变：保留上一份输入、产物、日志和设备身份，只替换一个条件，例如更换候选版本、缩短超时、断开网络或模拟掉电。比较最后成功阶段、错误分类、状态迁移和恢复动作，才能说明因果。不要同时换 bootloader、内核、rootfs、供电、配置和测试板；那样即使现象改变，也无法知道是哪一个条件造成改变。最后把未知项、停止条件和下一步实验写入交付记录。

资料卡（访问日期：2026-09-05）：本章对照 NIST SSDF、SPDX、U-Boot、Yocto、Buildroot、Linux Kernel、systemd、RAUC 与 MCUboot 官方资料。主机模型不替代真实 SoC、DDR、驱动、电源、Flash、密钥、烧录、温度、网络和现场恢复证据。