production-audit

name	production-audit
description	基于本地证据的生产就绪审计，适用于已发布应用、发布前评审、合并后检查和"生产环境会出什么问题？"的问题，无需将仓库数据发送到外部审计服务。
origin	community

生产审计

当用户询问应用是否准备好发布、生产环境可能出什么问题、或发布前必须修复什么时使用此技能。这是过时社区 production-audit 想法的安全重写：保留了有用的生产就绪视角，移除了未固定版本的外部执行和第三方数据共享。

何时使用

• 用户问"这是生产就绪的吗"、"生产环境会出什么问题"、"我们遗漏了什么"、"审计这个仓库"或"准备好发布了吗？"
• 一个功能已合并，需要部署前或合并后风险检查。
• 公开发布、演示、客户推广或投资者展示即将到来。
• CI 是绿色的但用户想要生产风险分析，不仅仅是测试状态。
• 有已部署的 URL、发布分支、PR 或当前检出可用于证据收集。

何时不使用

• 在积极实现期间，正确的视角是行级安全编码；先使用 security-review。
• 对于纯库、模板、仅文档仓库或脚手架，除非用户想要打包/发布就绪度而非应用就绪度。
• 当用户要求正式合规审计时。此技能是工程分诊，不是法律、财务、医疗或监管认证。
• 当唯一可用的证据是没有仓库、部署、CI 或运行时表面的产品想法时。

工作原理

从本地和用户授权的证据构建审计。不运行未固定版本的远程代码、不将仓库内容上传到第三方服务、不调用外部扫描器，除非用户明确批准该特定工具和数据流。

按此顺序：

1. 确立发布面。
2. 读取最近的变更和当前分支状态。
3. 检查仓库中实际存在的运行时、认证、数据、支付、后台任务、AI 和部署边界。
4. 检查 CI、测试、迁移、环境文档和回滚路径。
5. 产出包含具体修复的简短发布/阻塞建议。

证据检查清单

从廉价、本地的信号开始：

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

然后检查项目特定的表面：

• 包脚本、CI 工作流、发布脚本、Docker 文件和部署清单。
• API 路由、webhook、认证中间件、后台工作者、cron 任务和数据库迁移。
• 环境变量文档和启动检查。
• 可观测性钩子、错误报告、日志、健康检查和仪表板。
• 回滚、种子数据、迁移和回填指令。
• 最重要的用户路径的 E2E 覆盖。

如果已部署的 URL 在范围内，仅对该 URL 使用浏览器或 HTTP 检查，除非用户提供安全测试账户，否则避免凭证操作。

风险视角

安全和认证

• 公共路由、API 路由和管理路由是否清晰分离？
• 认证和授权是否在服务端强制执行？
• 密钥是否被排除在客户端包、日志、示例输出和已提交文件之外？
• 应用需要的地方是否存在速率限制、CSRF 保护、CORS 策略和上传验证？
• AI 或智能体表面是否防御了提示注入、工具滥用和不受信任内容流入特权操作？

数据完整性

• 迁移是否能干净地前向运行并有回滚或恢复计划？
• 破坏性迁移、回填和数据导入是否安全分阶段？
• 数据库策略、授权和服务角色边界是否与应用的租户模型匹配？
• 写入、任务和 webhook 处理程序的重试是否幂等？

支付和 Webhook

• 在解析受信任的负载字段之前是否验证了 webhook 签名？
• 每个支付、订阅或履行 webhook 是否幂等？
• 是否处理了重放、重复投递和乱序投递？
• 测试模式和实时模式凭据是否分离？

运维

• 应用能否使用文档化的命令从干净检出启动？
• 必需的环境变量是否已命名、验证和快速失败？
• 是否有证明依赖可达的健康检查？
• 部署、回滚和事件负责人路径是否已文档化？
• 日志是否有用而不泄露秘密或个人数据？

用户体验

• 发布关键路径是否在桌面和移动端覆盖？
• 表单在移动端是否可用，没有输入缩放、布局重叠或阻塞的提交状态？
• 加载、空、错误和权限拒绝状态是否告知用户发生了什么？
• 当关键操作失败时是否有支持或恢复路径？

评分

使用评分来强制优先级排序，而非暗示数学确定性。

区间	分数	含义
阻塞	0-49	在修复顶级风险之前不要发布
有风险	50-69	仅在小范围推广或内部测试后发布
有条件可发布	70-84	如果负责人接受列出的风险则发布
强健	85-100	从可用证据看没有明显的发布阻塞因素

如果以下任一为真，将分数上限设为 69：

• 敏感数据上缺少认证或授权。
• 支付或履行 webhook 非幂等。
• 必需的迁移无法安全运行。
• 密钥暴露在客户端包、日志或已提交文件中。
• 高影响发布没有回滚路径。

如果 CI 不是绿色或发布关键路径未端到端测试，将分数上限设为 84。

输出格式

以一句话开头：

生产审计：76/100，有条件可发布，webhook 幂等性和回滚文档是公开发布前需要修复的两个风险。

然后列出：

• 阻塞因素：部署前必须修复的项目。
• 高价值修复：如果用户想提高分数的下一个修复。
• 已检查证据：检查的文件、命令、CI、已部署 URL 或 PR。
• 缺失证据：如果提供会改变信心的内容。
• 下一步行动：一个具体的修复或验证步骤。

优点保持简短。用户要求的是就绪度，所以有用的答案是剩余风险和下一步行动。

示例

用户：

这个准备好发布了吗？

响应：

生产审计：68/100，有风险，因为 Stripe webhook 已验证但非幂等，且待处理迁移没有回滚说明。

阻塞因素：
- 在履行订单之前为 `checkout.session.completed` 添加幂等性。
- 编写并测试 `20260511_add_billing_state.sql` 的回滚路径。

高价值修复：
- 添加验证数据库和支付提供商可达性的健康检查。
- 为升级、webhook 履行和计费页面刷新添加一个 E2E 路径。

已检查证据：
- `api/stripe/webhook.ts`
- `db/migrations/20260511_add_billing_state.sql`
- 发布分支的 GitHub Actions 运行

下一步行动：要我优先修补 webhook 幂等性吗？

反模式

• 运行 npx <package>@latest 或远程扫描器作为默认审计路径。
• 在未经明确批准的情况下将源代码、秘密、客户数据或私有拓扑上传到外部审计服务。
• 在不命名已检查证据的情况下产出分数。
• 将绿色 CI 视为生产就绪。
• 以通用的"让我知道你想做什么"结束。

另见

• 技能：security-review
• 技能：deployment-patterns
• 技能：e2e-testing
• 技能：tdd-workflow
• 技能：verification-loop