production-audit

生产审计

检查发布范围并指出生产环境风险，评估应用是否可以安全发布。

约定

输入：

• 仓库、分支、PR、候选版本或已部署的 URL
• 可选的发布关键流程、测试账号、环境说明或 CI 运行记录

输出：

• 附带评分和证据的发布/阻止建议
• 阻止项、高价值修复、缺失证据和后续操作
• 具体的文件、命令、CI 或 URL 引用

创建/修改：

• 审计模式下不创建或修改任何内容
• 仅在明确请求时进行后续修复

外部副作用：

• 只读本地命令和已授权的 HTTP/浏览器检查
• 默认不上传源代码、不执行破坏性迁移、不写入生产环境，也不运行扫描器

需要确认：

• 执行需要凭据的生产操作、使用远程扫描器、部署、迁移、数据变更或影响用户的测试之前

委派给：

• security-audit 处理应用安全问题
• deploy-app 或 deployment-composer 处理发布流程
• release 对 trunk SHA 进行门禁检查并创建发布
• playwright-e2e-init 补充缺失的发布关键浏览器覆盖；test-runner 运行现有测试

适用场景

• 用户询问“这能用于生产吗？”“生产环境中会出什么问题？”“准备好发布了吗？”“审计这个版本”或“我们漏了什么？”
• 临近发布、演示、客户推广或投资者演示。
• CI 全部通过，但仍需审查生产风险。
• 高风险 PR 已合并，或已升级依赖项。
• 需要对已部署的预发布或预览 URL 进行就绪检查。

这不是合规、法律、财务、医疗或安全认证——仅用于工程发布分诊。

证据顺序

先检查成本较低的本地证据：

git status --short --branch
git log --oneline --decorate -20
git diff --stat origin/main...HEAD

然后检查实际存在的部分：

• 软件包脚本、构建命令、CI 工作流和发布脚本
• API 路由、身份验证中间件、webhook、工作进程、cron 作业和队列
• 迁移、种子数据、回填、回滚说明和数据访问策略
• 环境变量文档和启动验证
• 支付、电子邮件、存储、AI 和外部提供商边界
• 可观测性、日志、健康检查、仪表板和告警负责人
• 发布关键用户路径的 E2E 或冒烟测试覆盖
• 检查范围包含已部署 URL 时，对该 URL 进行检查

不要仅因 CI 全部通过就认定发布状态良好。

风险维度

安全与身份验证

• 敏感路由是否在服务端受到保护？
• 授权检查是否考虑租户，并在数据访问附近实施？
• 客户端包、日志、示例和已提交文件中是否没有密钥？
• 上传、CORS、CSRF、速率限制和输入验证是否适当？
• Agent 或 AI 功能是否将不可信内容与特权工具隔离？

数据完整性

• 迁移能否安全地向前执行？
• 对于影响较大的变更，是否有回滚、恢复或备份途径？
• 破坏性回填是否分阶段执行且具备幂等性？
• 写入操作、作业和 webhook 的重试是否安全？
• 沙盒、预发布和生产环境的架构是否符合代码假设？

支付与 Webhook

• 是否在信任负载字段之前验证 webhook 签名？
• 对于重复投递，履行处理程序是否具有幂等性？
• 是否处理乱序和重放事件？
• 测试凭据和正式凭据是否分开？
• 提供商故障后，面向客户显示的账单状态能否恢复？

运维

• 能否按照文档中的命令，从干净的代码检出状态启动应用？
• 必需的环境变量是否已命名并在启动时验证？
• 是否有健康检查可以确认依赖项可访问？
• 日志是否有用，同时不会泄露密钥或个人数据？
• 是否有清晰的部署、回滚和事故负责人途径？

用户体验

• 发布关键路径是否覆盖桌面端和移动端？
• 加载、空数据、错误和权限不足状态是否易于使用？
• 表单能否处理无效输入、缓慢请求和重复提交？
• 关键操作失败时，是否有恢复或支持途径？

评分

使用评分来强制确定优先级：

评分	结论
0-49	阻塞：修复阻塞项之前不得发布
50-69	有风险：仅限内部 Beta 或小范围推出
70-84	可发布，但需注意：负责人接受明确列出的风险后即可发布
85-100	强：根据现有证据，没有明显的发布阻塞项

如果存在以下任一情况，最高评分为 69：

• 敏感数据缺少身份验证或授权
• 支付或履约 Webhook 不具备幂等性
• 必需的迁移无法安全运行
• 密钥暴露在客户端包、日志或已提交的文件中
• 高影响发布没有回滚或恢复路径

如果 CI 未通过，或未对发布关键路径进行端到端测试，最高评分为 84。

输出格式

以一句话开头：

Production audit: 76/100, launchable with caveats, with webhook idempotency and rollback docs as the two risks to fix before public launch.

然后列出：

• 阻塞项：部署前必须修复的问题
• 高价值修复项：按影响排序的后续改进
• 已检查的证据：已检查的文件、命令、CI、URL 或 PR
• 缺失的证据：哪些信息会改变信心
• 下一步行动：一个具体的修复或验证步骤

如果没有发现阻塞项，仍需说明证据范围。

反模式

• 将未固定版本的远程扫描器作为默认审计方式运行。
• 未经明确批准，就将私有源代码、密钥、客户数据或拓扑信息上传到外部。
• 给出评分却不说明依据的证据。
• 将暂存环境的冒烟测试当作数据迁移安全的证明。
• 以泛泛的总结收尾，而不是提出下一项具体的发布行动。