Convex 后端上线就绪审计：多路检查汇总为可复现评分与修…

需要对 Convex 项目做上线前全面审计，并将鉴权、代码评审、运行时建议、日志洞察合并为一份可执行修复报告时使用。

适用场景

解决思路

1. 以 findings bus（specs/finding.schema.json）为基础做纯组合，运行各审计 capability，把输出归一化为一份报告（specs/finding-report.schema.json），计算可审计分数，并因为每条 finding 都带 fixCapability 而给出优先级明确的待办清单，而不是四份独立报告。
2. 用 deploy-guard 对目标进行分类（local-anonymous / dev / preview / prod）并公布分类结果。
3. 检测可评估对象：是否存在 convex/ 目录、有流量的已部署 deployment、auth 基础；跳过前置条件不满足的 pass，并说明哪些被跳过（跳过的 pass 不等于通过）。
4. 运行 convex-authz：做 authz 扫描（identity-from-arg、missing ownership、PII leak、parent-ref-on-write），对代码始终可运行。
5. 运行 convex-reviewer：检查 validators、indexes-not-filter、idiom、error handling，对代码始终可运行。
6. 运行 convex-advisor：获取 live read-limit / OCC 证据；仅当存在有流量的 deployment 时运行，否则记录 'skipped: no traffic'。
7. 运行 convex-insights：从日志中获取最近失败；仅当存在 deployment 时运行。
8. 并发运行相互独立的 pass；每个 pass 只返回 findings，不返回 fixes。
9. 归一化并去重：把所有 findings 收集到一份报告，将每个 finding 的 identity 字段设为规范化 function/table key（例如 messages:list），使同一函数无论由 code-locus 还是 deployment-locus 报告都使用同一 identity；同一缺陷从两个 locus 观察到时，通过 bus 的 (class, identity) 去重合并为一条，不在评分中重复计数。
10. 去重时保留置信度更高的来源；不要静默丢弃任何内容；报错或被跳过的 pass 要作为已声明的覆盖缺口，而不是干净结果。
11. 可审计评分：从 100 开始；按严重度对每个 CONFIRMED finding 扣分（high −15、med −5、low −1），最低为 0；打印确切公式和按 class 的分解，使分数可复现。
12. plausible-only findings 仅列为候选，不改变分数（evidence-not-vibes）。
13. 没有 deployment/流量时，报告 code-only 分数并明确说明。
14. 报告：先给分数，再按严重度排列 findings，每条包含 evidence、locus、fixCapability 和一行修复说明；按 blockers（high）/ should-fix（med）/ nice-to-have（low）分组。
15. 在报告末尾给出有序修复计划：下一步运行哪个 capability、按什么顺序（authz/data-loss 优先，然后 perf/scale，然后 idiom/observability）。
16. 按请求分派：对用户接受的每个 finding，调用其 fixCapability（convex-authz、convex-reviewer 的 fixers、schema 变更用 migrate-rehearse、组件替换用 suggest）。
17. 修复后重新运行受影响的 pass，并展示分数变化；就绪分数只有在修复后确实变化时才有意义。
18. 不要声称比实际运行更多的覆盖：报告头部列出哪些 pass 运行过、哪些被跳过及原因。
19. code-only 运行得到的绿色分数只是 'code looks ready'，不是 'production-verified'。
20. 组合而不是重新实现：运行已有 audit capabilities 并聚合其 bus findings，绝不在内联重新推导 authz 或 perf 检查。
21. 评分只统计 CONFIRMED findings，按严重度计算，并打印公式；plausible findings 是候选，不改变数字。
22. 去重前把每个 finding 的 locus 规范化为 function/table identity（映射 deployment functionId ↔ code file:line），使同一缺陷从两个 locus 看到时合并为一条且不重复计分；保留更高置信度来源；不要静默丢弃。
23. 每条 finding 都携带其 fixCapability；报告以有序修复计划结束（data-loss/authz 优先，然后 scale，然后 idiom/observability）。
24. 修复后重新运行受影响的 pass 并展示分数变化；修复后不动的就绪数字是表演。
25. 绝不声称超过实际运行的范围：头部列出 ran/skipped passes；code-only 运行只产生并明确标注 code-only 分数。
26. 这是 read + aggregate + dispatch pass；实际修复在 fixer capabilities 中进行，并受其自身的 consent/deploy-target 规则约束。

适用边界 · 注意事项

• 不适用于非 Convex 项目或没有 Convex 审计/修复能力的环境。
• 没有已部署 deployment 或流量时，不能得到生产验证分数，只能得到 code-only 分数。
• 该技能本身不修复问题；用户未接受 finding 或缺少对应 fixCapability 时不要承诺修复。