三级证据口径
当前有效能力矩阵中有 135 条 feature 带明确真机版本记录。计数按目标矩阵条目统计，不把一个源特征跨目标合并；它不等于当前具备 hash 锚定工件、可供审核关联的条目数，后者还要通过更严格的完整性门禁。
| 级别 | 进入条件 | 能证明 | 仍需确认 |
|---|---|---|---|
| 真机已验 | 目标 feature 条目记录公开产品版本与实测边界。 | 代表性 SQL 在该版本与模式下得到记录中的结果。 | 客户参数、数据分布、驱动、完整业务链路，以及历史记录是否具备当前 hash 锚点。 |
| 公开文档 | 结论来自目标厂商公开资料，来源可追溯。 | 文档声明的语法或能力边界。 | 版本补丁差异、现场组合条件与运行语义，建议 PoC 复核。 |
| 待真机核验 | 没有当前目标条目的明确版本实测，也没有足够文档证据。 | 规则已识别到需要处置的源端特征。 | 目标端支持度与改写结论，必须补证后再定。 |
真机核验如何形成证据
当前批次的验证从规则正例或人工 fixture 出发，执行计划、目标身份和结果分类共同绑定到离线工件。新的矩阵升级只接收经过复核的当前锚点；历史版本记录不会自动冒充这类工件。
- 确定来源从规则 examples 或专用 fixture 重建源 SQL，保留规则 ID 与 feature。
- 绑定环境记录公开产品、版本与兼容模式，环境错误不产生能力结论。
- 分类结果区分 pass、reject、probe_error 与 skip，失败和未覆盖不会静默消失。
- 人工接纳核对完整性、语义深度和建议内容后，才把证据锚定到能力矩阵。
边界：代表性 SQL 通过不等于任意 SQL 都兼容，语法通过不等于业务语义等价，真机证据也不等于 AI 生成的改写已经得到验证。
为什么保留“待评估”
数据库迁移的未知项通常来自版本、模式、参数、扩展或业务上下文差异。把未知标出来，会降低置信度并进入后续 PoC 清单；把未知藏起来，只会把验证成本推迟到上线窗口。
因此，待真机核验不是缺失提示的装饰，而是处置台账的一种正式状态。补到可复核证据后，状态才能升级。