passed=false 里混着六种结果

当前系统里同时存在两套结果语言。

任务记录可以写 success、partial、failure 或 unknown；案例入库只接受前三种，因为尚未确认结果的任务不能被包装成可复用经验。自动验证记录却只剩一个不能为空的 passed 布尔值。

这个差异会改变重试、统计和审计含义。测试断言失败、命令没有启动、执行超时、人工尚未验收和主动跳过，最终都可能落成同一个 false。

一个 false 目前可能代表什么

前两项已经取得否定结论；后四项只是没有通过当前验证流程。把它们放进同一个失败分母，会同时破坏重试策略和趋势解释。

当前人工路径还会先写入一条 passed=false 记录，再通过额外更新写入最终结论。已有实现能够完成这个流程，但直接触达底层数据库，没有形成正式存储接口、状态转换约束和审计事件。

一次覆盖更新能告诉我们“现在是什么”，不一定保留“怎样从待验变成通过”。

状态、方法和任务结果必须分开

至少需要三个正交维度：

verification_status:
  passed | failed | unverified | timed_out | infra_error

verification_method:
  auto_test | auto_lint | auto_typecheck | manual | skip

task_outcome:
  success | partial | failure | unknown

这是从现有缺口推出的设计模型，不是已经完成的数据库迁移。

failed 只表示验证完整执行并得到否定结论。manual 与 skip 描述证据来源，不应自动成为失败状态。任务 outcome 则需要由一组证据收敛，不能被任意一条验证记录直接覆盖。

这也解释了为什么一个类型检查通过不能代表页面行为正确，一次超时也不能直接判定修复失败。验证记录回答“这项检查发生了什么”，任务 outcome 回答“整个任务最后处于什么状态”。

把结果来源从模型自报移向外部检查，是《我删掉了一套数学上正确、工程上无效的学习闭环》完成的第一步。本文处理的是下一层：外部结果仍然需要保留状态语义。

指标的分母由状态决定

即使状态拆开，一个总通过率仍可能误导。test、lint、typecheck 和人工验收检查不同层级，样本选择也不相同。

至少应该分别观察：

• 各验证方法的样本量与结果；
• timed_out 和 infra_error 的数量；
• 等待人工确认的积压；
• 最终 task outcome 的分布。

趋势变化时，先判断是代码质量变化、验证方法占比变化，还是基础设施异常增加。某个时间窗口没有足够自动验证时，显示 N/A 比把 manual、skip 或未知记录填进分母更诚实。

当前材料不足以确认现有 30 天面板是否已经按这些口径聚合。能够确认的风险是：如果直接聚合全部 passed，上述状态就会被压成同一种失败。

测试数量本身怎样形成证据范围，由《四十项测试的证据账本》继续处理。

旧数据不能整齐地自动回填

历史 passed=false 如果缺少退出码、超时标记、验证方法和更新轨迹，就无法可靠区分：

• 人工否决；
• 人工尚未处理；
• 主动跳过；
• 基础设施错误；
• 真实测试失败。

自动命令退出码为零且没有超时，可以确定性映射为 passed；明确断言或 lint 非零，可以映射为 failed。无法恢复语义的记录应保留为 unverified，不能为了得到整齐统计而改写成 failure。

迁移前需要先按验证方法、退出码、超时与详情字段盘点，再补几类状态转换测试：manual 与 skip 不进入失败分母，timeout 与断言失败保持不同状态，人工复核保留前后轨迹，unknown 任务不能关闭为可召回案例。

这些是迁移设计，不是当前已经通过的测试结果。

布尔值丢掉的是过程

继续判断现有指标是否受到污染，还需要验证表 schema、少量脱敏记录、人工更新路径和面板聚合查询。缺少这些材料时，能够成立的结论是“当前状态模型不足以保证指标正确”，不是“当前面板已经算错”。

验证系统的目标也不是尽快给出 true 或 false，而是保留执行过什么、得到什么结论、依据来自哪里，以及整个任务最终处于什么状态。