构建、发布、运维与退役

库、CLI、静态网站、研究产物和线上服务有不同的交付/恢复责任。发布标准按实际发行和运行模型裁剪。

构建与发布

构建使用项目真实锁文件和受信输入。普通贡献检查与持有部署密钥的发布任务分开；不可信 PR 不得访问生产凭据、广泛 runner/socket 权限。

可追溯构建物应关联源码版本/commit；支持时记录不可变 digest 或校验值。条件允许时将已验收的同一工件提升到不同环境，而不是从相同源码反复构建并假设结果相同。

发布记录按需要说明范围、版本/commit、工件、兼容性、秘密/config 引用、实际检查、数据变更和回退/前向修复。开发镜像和生产运行镜像用途不同，分别记录构建边界。

跨仓库发布应写明已验证的组件版本/commit 集合、提供方与消费者升级顺序、局部发布失败的恢复方式。若没有实现 feature flag、canary 或自动回滚，不应写成已有能力。PR 合并、CI 通过、镜像构建、服务启动、用户流程验收和发布成功不是同一件事。

明确运行平台、负责人、配置来源、秘密、外部依赖、启动/停止/恢复命令。需要时区分 liveness、readiness、依赖可用性和用户流程验收；探针不迁移 schema、不修改客户数据。

结构化日志应脱敏并可关联请求；指标标签保持有界，避免把用户/租户 ID 当无限指标维度。告警对应可执行决策、响应责任和升级路径。持久数据记录备份所有者、保留、访问、实际恢复方法和业务所需恢复目标。备份任务成功并不证明数据能恢复。

Runbook 按实际依赖说明过期凭据、队列毒消息、存储空间不足、服务降级和部分发布失败。人工事故沟通需由明确负责人发起；文档本身不授权代理人代替用户发外部消息。

依赖升级、弃用窗口、已知风险、运行手册过期和资源预算要有责任人。测试、监控和漏洞扫描覆盖不同问题，任何单项都不能证明系统整体正确。

退役前确认消费者、继任方案/支持期限、通知和迁移窗口、数据导出/删除/留存、服务/域名停用、凭据撤销和保留记录。不要仅因仓库不活跃就删除仓库、停在线上服务、撤销凭据或清理客户数据。