RunProof可证工程

本文用两份登录实现做对照实验：旧实现行为测试全绿，但契约测试失败、扫描命中 1 high；新实现契约测试通过，目标规则清零。

本地扫描器接进 GitHub Actions 后，真正的问题变成权限、失败后的 SARIF 上传、首次接入是否阻断，以及扫描结果和 CI 策略如何分层。文章用实际工作流拆解这三个隐藏假设。

一个真实三节点 Go KV 项目被扫描出 100 条结果，其中 `ruby-rce` 79 条、`sql-concat` 13 条、路径规则 8 条。

文章用可控的 `FakeDb` 记录 `cursor.execute` 收到的 SQL 和参数，补一条参数化契约测试，并讨论占位符差异、ORM 场景、契约测试的选取范围和修复后的重新验证。

本文用 code-audit-cli 的 baseline 做实验：历史问题写入基线后放行，新增 SQL 拼接时 new_total=1、退出码变为 1，CI 立即拦截；修复新增问题后恢复通过。文章还

本文给出一条参数化契约测试，直接检查 cursor.execute 实际收到的 SQL 和参数，并用 code-audit-cli 定位 sql-concat High。

绑定行号能提高可核查性，却不能保证模型理解代码；AI 更适合提取证据，最终判定应由规则、扫描器或人完成。

这篇文章不争论“哪个 AI 更强”，而是拆开生成、审查和证据复核三个环节，说明为什么“AI 自审通过”不能直接等于代码安全，以及人工应该怎样核对 AI 的审查结论。

三节点 Raft KV 看起来能跑之后，最容易翻车的不是选举，而是重启重放、旧 Leader 读取和持久化失败静默。文章记录这三个真实问题及修复方向。