superior-delivery

优质交付

通过可重复、可追溯且可恢复的路径，将已验证的变更交付到预期环境。保留项目现有的交付系统，并将发布准备与外部部署授权分开。

明确交付约定

更改或运行交付工作流之前，先确定：

• 可部署单元、源代码修订版本、版本号和目标平台；
• 权威的流水线、构建、打包、签名和发布配置；
• 环境、晋级顺序、审批、凭据和所有权；
• 制品注册表、来源证明、保留期限和不可变性预期；
• 运行时配置、密钥、依赖项、迁移和兼容窗口；
• 发布、健康验证、暂停、回滚和前向恢复的标准；
• 用户请求的是设计、实现、试运行验证、打包、发布还是部署。

不要仅凭准备或审查交付文件的请求，就推断用户已授权发布、打标签、发行、部署、晋级、回滚或更改共享流水线设置。

构建一次，并明确交付内容

如果工作涉及版本控制、依赖解析、构建输出、容器、包、校验和、签名、SBOM、来源证明、注册表或发布元数据，请阅读 references/artifacts-and-release-integrity.md。

• 将每个制品与不可变的源代码修订版本及可复现的配置证据关联起来。
• 优先在不同环境间晋级同一已验证制品，而不是重新构建环境专用二进制文件。
• 除非平台约定明确要求安全的公开值，否则运行时配置和密钥不得放入可分发制品。
• 必需输入缺失或含糊不清时应失败；不要悄悄发布不完整的版本。
• 根据仓库所有权处理生成的制品和锁文件，不要随意重新生成。

确保流水线确定性且遵循最小权限原则

如果要更改 CI/CD 阶段、缓存、矩阵、凭据、审批关卡、环境晋级或可复用工作流组件，请阅读 references/pipelines-and-environment-promotion.md。

• 根据仓库的供应链策略固定或约束工具和操作。
• 将凭据的作用范围限制在完成任务所需的最小环境、操作和时长内。
• 将不可信的拉取请求执行与包含密钥的发布工作分开。
• 明确阶段依赖关系和故障传播方式。
• 仅缓存具有可信键和恢复边界的内容；缓存不是制品的唯一可信来源。

除非明确更改已接受的交付约定，否则不要通过弱化检查、扩大权限或将必需步骤设为可选来绕过失败的关卡。

根据证据发布，并设置停止条件

有关部署顺序、迁移、功能标志、金丝雀发布、蓝绿或滚动发布、健康检查、流量切换、回滚和部署后验证，请阅读 references/rollout-rollback-and-verification.md。

• 定义前置条件、可观测的成功标准、失败阈值，以及获准继续操作的人员或系统。
• 将就绪状态与存活状态及业务层验证区分开来。
• 协调跨版本的应用和架构变更；迁移命令成功并不能证明发布过程安全。
• 缺少证据或超出阈值时应暂停。不要因为前序阶段耗费了时间就继续。
• 当状态或架构变更不可逆时，应区分回滚与前向恢复。

未经明确授权并确认目标，绝不要通过向生产环境发送流量、更改共享基础设施或调用部署命令来测试发布。

验证并报告

使用仓库支持的验证路径，按需进行验证：

• 流水线语法和配置；
• 在足够干净且受支持的状态下成功构建和打包；
• 适用时检查制品内容、版本、校验和、签名或来源证明；
• 检查特定环境的配置引用，但不得泄露机密值；
• 检查迁移和兼容性顺序；
• 仅在获准时进行试运行、预览、隔离部署或目标环境健康检查；
• 按实际执行的程度验证回滚或恢复流程。

报告评估的修订版本和制品、运行的命令或作业、目标环境（如有）、观察到的关卡、执行的外部变更，以及尚未验证的发布条件。仅完成构建、打包、计划或本地模拟时，绝不要说“已部署”。

有针对性地组合技能

• 当流水线或发布验证需要大量测试策略或夹具设计时，使用 superior-testing。
• 对迁移机制、数据兼容性、回填和架构恢复，使用 superior-database。
• 当可用性目标、降级、故障转移或运维恢复决定发布过程时，使用 superior-reliability。
• 对凭据边界、供应链信任、公开暴露或安全关卡，使用 superior-api-security。
• 当发布标准要求有代表性的容量或延迟证据时，使用 superior-performance。
• 对持久适用的构建、发布、部署、回滚或运维流程，使用 superior-docs。

未经明确授权，不要将范围明确的流水线变更扩大为托管迁移、平台替换或线上发布。