Safe Haven 自动拒绝三规则，重复哈希版本号和包名不匹配直接拦下

三条自动拒绝规则

Safe Haven 的扫描管线有三个硬性拒绝条件。任何一个触发，提交直接进入 rejected 状态，跳过 pending_review 和手动审核。

这三个规则是安全底线——防住的是最常见的提交错误和恶意提交：

1. APK SHA-256 重复

每个 APK 计算一次 SHA-256。如果数据库里已经有同包名应用的某个 live 版本记录了完全相同的哈希 → 拒绝。

这个规则防的是：

• 开发者不小心把同一个 APK 上传了两次
• 同步时拉到了已经收过的版本
• 有人用完全相同的 APK 文件反复提交（垃圾行为）

SHA-256 是"碰撞概率可以忽略"的强哈希——两个不同文件产生相同哈希的概率接近零。所以这个规则误判的可能性极低。

2. versionCode 重复

从 APK manifest 里真实提取 versionCode（安卓的内部版本号，整数，必须单调递增）。如果这个值和同包名下任何一个 live 版本的 versionCode 一样 → 拒绝。

这个规则防的是：

• 开发者提交新版本但忘了在 manifest 里递增 versionCode
• 同步时拉到了已经收过的版本（比如上游仓库没更新 versionCode 就重打包了）
• 有人故意覆盖已有的版本记录

注意：这里比对的是 versionCode（整数），不是 versionName（字符串）。两个版本的 versionName 可以不同但 versionCode 相同（不推荐但常见），这种情况也会被拒绝——因为安卓系统认为 versionCode 才是"版本先后"的唯一判断依据。

3. 包名不匹配

扫描管线从 APK manifest 里提取真实包名（applicationId，比如 com.colourswift.safehaven），和应用条目数据库里记录的包名比对。不一样 → 拒绝。

这个规则防的是：

• 社区投稿时包名还是临时占位符（{owner}-{repo} 格式），但扫描管线提取到了真实包名 → 应该自动覆盖而不是拒绝。这个情况其实不会触发拒绝——扫描管线有 manifest reconciliation 逻辑，会在扫描时把占位符替换成真实包名。
• 开发者选错应用条目上传（把 A 应用的 APK 上传到了 B 应用的条目下）
• 恶意提交（包名对不上说明整个条目和 APK 对不上）

自动拒绝和手动拒绝的区别

自动拒绝（三个规则）和手动拒绝（管理员操作）是两条不同的拒绝路径：

manifest reconciliation：不是拒绝而是修正

扫描管线有一个智能逻辑叫 manifest reconciliation——在扫描过程中，从 APK manifest 里提取真实的 versionCode、versionName、包名，然后：

• 如果 versionCode 和开发者声明的不一致 → 用 manifest 的覆盖（不拒绝，自动修正）
• 如果包名是临时占位符 → 用 manifest 的真实包名替换（不拒绝，自动修正）
• 如果 manifest 的 versionCode 和已有的 live 版本重复 → 进入 rejected（这就是规则 2 的触发场景）

所以开发者提交时 versionCode 填错了没关系——扫描管线会自己修正。但如果修正后的 versionCode 和已有的撞了，才会触发拒绝。

拒绝后怎么办

rejected 是终态。开发者需要：

1. 查看拒绝原因（应用条目会记录哪个规则触发了）
2. 修正问题：换一个 versionCode、确认包名正确、不要重复上传
3. 重新提交

管理员也可以手动干预——把 rejected 状态改回 pending_scan 或强制改成 live（Admin Secret 权限）。但每个强制操作都会被记录到审计日志，包含：操作者、旧状态、新状态、操作时间、理由。

为什么要做自动拒绝

三个自动拒绝规则的设计理念是：明确错误 → 机器可判定 → 不需要等人审核。

Safe Haven 故意不在这些规则上留模糊空间——"我觉得这个可能是重复的"不行，必须是"SHA-256 完全一致"才拒绝。这样管理员不需要介入这些低价值的拒绝案例，节省精力处理真正需要人工判断的扫描结果（比如 VX-TITANIUM 引擎检出可疑载荷但不确定是不是误报）。