pythia-verify

在宣称完成前先验证

开始时宣布：“正在使用 pythia-verify——先检查证据，再汇报结果。”

**阶段：**学习 → 询问 — 从实时数据库收集证据，然后汇报证据表明了什么、没有表明什么

Agent 写下的代价最高的一句话，是对并未完成的事项说“完成了”。在 Oracle 中，这种说法很容易出现：包可能已经编写，却处于 INVALID 状态；发布可能在 12 条语句中的第 7 条处停止；所谓“更快”的查询可能有着相同的执行计划。只需运行三条命令就能获取证据——去运行它们。

铁律

NO COMPLETION CLAIM WITHOUT EVIDENCE FROM THIS SESSION

证据是你在最后一次更改后看到的命令输出，不是你记得的更改前结果。

检查清单

1. 每次写入的判定结果 — 每条 apply / deploy 命令的退出代码；不要通过管道读取（| tail 返回的是 tail 的 0）。使用 autopilot 时：检查 pythia autopilot report 中的每一行。
2. 能编译 — 对每个你改动过的对象运行 pythia errors <OBJECT>：输出为空，或列出错误。
3. 没有其他内容损坏 — 将 pythia invalid 的结果与通过 pythia-impact 获取的基线进行比较。任何现在处于 INVALID、而当时处于 VALID 的对象，在证明非你所致之前都算你的责任。
4. 符合标准 — pythia lint <files>：错误数为 0；警告已修复，或已说明原因。
5. 表已记录文档 — pythia cols T 与规范一致；pythia comments T 显示缺失项为 0；pythia stats T 中没有你创建的未建立索引的外键。
6. 性能声明 — 使用相同的 pythia explain 进行前后对比，并提供数据（采用 pythia-tune 的报告格式）。
7. 行为 — pythia 不会运行匿名块，因此无法独自证明行为。说明测试了什么（由 CI 或开发者运行的 utPLSQL、展示新增行的查询），以及没有测试什么。

报告

Done:          PKG_ORDER spec+body, T_ORDER_LINE (+6 comments, 1 index)
Evidence:      deploy exit 0 (5/5); errors PKG_ORDER: none; invalid: 1, same
               as baseline (X_ALREADY_BROKEN); lint: 0 errors, 1 warning (named)
Decisions:     status codes N/C/X (agreed); qty NUMBER(12,3) (agreed)
Assumptions:   none
Not verified:  behaviour under load; ut_pkg_order not run (no utPLSQL here)
Undo:          pythia journal restore <entry>  (newest first, per object)

有三个词有特定含义：完成（所有检查均通过）、损坏（退出代码为 3 或出现新的 INVALID——先说明这一点）、未验证（无法运行的检查）。绝不要把“损坏”弱化成“基本完成”。

危险信号——如果发现自己这么想，就停下来

想法	事实
“能编译，所以能用”	编译只能证明语法正确。说明什么能证明行为，或者说明尚未验证。
“之前 apply 说没问题”	那是在最后一次更改之前。重新检查。
“那些 INVALID 对象本来就有问题”	拿出能证明这一点的基线，否则它们就算你的责任。
“开发者可以检查细节”	细节就是报告内容。运行这些命令。
“有一条语句失败了，但其他的都执行了——基本完成”	这就是损坏，并附有撤销清单。先说明这一点。
“我遵循了标准，可以跳过 lint”	那么运行 lint 只需一秒，它会给出结果。

不要使用此技能的情况

• 任务进行到一半、步骤之间——pythia-apply 已经会读取每个结果；这是给最终结论把关的步骤。
• 纯探索且没有进行更改——没有需要验证的内容；说明你读取了什么。