pythia-verify

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Verifying Before Claiming Done

在声称完成前进行验证

Announce at start: "Using pythia-verify — checking the evidence before I report."

Phase: Learn → Ask — collect proof from the live database, then report what it shows and what it does not

The most expensive sentence an agent writes is "done" about something that is not. In Oracle it is easy to say: a package can be written and INVALID, a release can stop at statement 7 of 12, a "faster" query can have the same plan. The evidence is three commands away — run them.

开始时宣告： “正在使用 pythia-verify——在报告前检查证据。”

阶段： Learn → Ask — 从当前运行的数据库收集证据，然后报告它显示了什么以及没有显示什么

Agent 写下的最昂贵的一句话，就是对尚未完成的事情说“已完成”。在 Oracle 中很容易出现这种情况：package 可以已经写好但仍为 INVALID； release 可能执行到 12 条语句中的第 7 条就停止；“更快”的查询可能仍使用相同的 plan。获取证据只差三条命令——把它们运行一遍。

The Iron Law

铁律

NO COMPLETION CLAIM WITHOUT EVIDENCE FROM THIS SESSION

Evidence is command output you saw after the last change, not a result you remember from before it.

NO COMPLETION CLAIM WITHOUT EVIDENCE FROM THIS SESSION

证据必须是最后一次更改之后亲眼看到的命令输出，而不是凭记忆沿用的此前结果。

The Checklist

检查清单

Every write's verdict — the exit code of each
```
apply
```
/
```
deploy
```
, read unpiped (
```
| tail
```
returns tail's 0). Under autopilot:
```
pythia autopilot report
```
, every row.
It compiles —
```
pythia errors <OBJECT>
```
for every object you touched: empty, or the errors listed.
Nothing else broke —
```
pythia invalid
```
compared with the baseline you took in
```
pythia-impact
```
. Anything INVALID now that was VALID then is yours until proven otherwise.
It meets the standard —
```
pythia lint <files>
```
: zero errors; warnings fixed or named with a reason.
Tables are documented —
```
pythia cols T
```
matches the spec;
```
pythia comments T
```
says 0 missing;
```
pythia stats T
```
lists no unindexed foreign key you created.
Performance claims — the same
```
pythia explain
```
before and after, with the numbers (
```
pythia-tune
```
's report format).
Behaviour — pythia does not run anonymous blocks, so it cannot prove behaviour by itself. Say what was tested (utPLSQL by CI or the developer, a query that shows the new rows) and what was not.

每次写入的结论 — 每次
```
apply
```
/
```
deploy
```
的退出码，必须直接读取（不要接入管道；
```
| tail
```
返回的是 tail 的 0）。在 autopilot 下：运行
```
pythia autopilot report
```
，检查每一行。
能够编译 — 对每个涉及的对象运行
```
pythia errors <OBJECT>
```
：输出为空，或列出错误。
没有破坏其他内容 — 将
```
pythia invalid
```
与你在
```
pythia-impact
```
中取得的基线进行比较。现在为 INVALID、而基线中为 VALID 的任何对象，在有相反证据前都算作你造成的。
符合规范 — 运行
```
pythia lint <files>
```
：零个错误；警告已修复，或已说明其原因。
表已有文档 —
```
pythia cols T
```
与 spec 一致；
```
pythia comments T
```
显示缺少 0 项；
```
pythia stats T
```
没有列出你创建的任何未建索引的外键。
性能声明 — 对性能作出声明时，提供变更前后使用
```
pythia explain
```
获得的结果及其数字（采用
```
pythia-tune
```
的报告格式）。
行为 — pythia 不会运行 anonymous blocks，因此无法单独证明行为。说明测试了什么（由 CI 或开发者执行的 utPLSQL、显示新行的查询），以及哪些内容未测试。

The Report

报告

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)

Three words are reserved: done (every check passed), broken (exit 3 or new INVALID — say it first), not verified (a check you could not run). Never soften broken into "mostly done".

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)

以下三个词保留用于准确结论：done（所有检查均通过）、broken（退出码为 3 或出现新的 INVALID——应首先说明）、not verified（某项检查无法运行）。绝不要把 broken 软化成“基本完成”。

Red Flags — STOP if you catch yourself thinking

危险信号——发现以下想法时立即停止

Thought	Reality
"It compiled, so it works"	Compiling proves syntax. Say what proves behaviour, or say it is not verified.
"apply said ok earlier"	Earlier was before the last change. Check again.
"Those INVALID objects were already broken"	Show the baseline that proves it, or they are yours.
"The developer can check the details"	The details are the report. Run the commands.
"One statement failed but the rest landed — mostly done"	That is broken, with an undo list. Lead with it.
"I'll skip lint, I followed the standard"	Then lint costs one second and says so.

想法	实际情况
“编译通过了，所以它能工作”	编译只能证明语法正确。说明是什么证明行为，或者声明未验证。
“之前 apply 说 ok”	之前那次是在最后一次更改之前。重新检查。
“那些 INVALID 对象本来就坏了”	展示能够证明这一点的基线，否则就是你造成的。
“开发者可以检查细节”	细节正是报告的内容。运行这些命令。
“一条语句失败了，但其余都落库了——基本完成”	这属于 broken，并附上回滚清单。先说明这一点。
“我要跳过 lint，我遵循了规范”	那么 lint 只需一秒，而且会直接给出结果。

When NOT to use this skill

何时不应使用此 skill

Mid-task, between steps —
```
pythia-apply
```
already reads each result; this is the gate before the final word.
Pure exploration with no change made — there is nothing to verify; say what you read.

任务进行中、位于步骤之间 —
```
pythia-apply
```
已经会读取每个结果；本 skill 是给出最终结论前的关卡。
仅进行探索且没有做出任何更改 — 没有需要验证的内容；说明你读取了什么。