pythia-apply

应用 PL/SQL 更改

开始时宣布：“正在使用 pythia-apply——我会先预览更改。”

**阶段：**询问 → 执行 — 预览结果会先传达并获得批准，然后才会打开唯一的写入入口

Oracle 中的 DDL 会自行提交，因此 pythia 在写入前创建的快照就是唯一的撤销手段——而对于 DML，连快照都没有。这个技能就是用来利用它的。

铁律

NO WRITE THE DEVELOPER HAS NOT SEEN AND APPROVED

每次写入都适用：新建对象、修复、还原、批量运行。没有“很简单”这种例外——一行更改就可能使十二个依赖对象失效。

Agent 有四种操作被禁止，而 pythia 会强制执行这四项（CLI 在没有终端时会拒绝；预工具钩子会阻止最后一项）：

• --yes — 这是开发者的标志，绝不能由你使用。
• 伪造批准。pythia approve <token> 是开发者在控制台使用的命令；Agent 不能运行它。你应当提出请求（第 3 步）：只有开发者亲自作出答复，才会生成授权。
• 将 pythia policy set <group> 设置为任何更宽松的策略，以及执行 pythia autopilot on — 这些属于开发者的决定；把准确的命令交给开发者，让他们自行运行。
• 绕过关卡写入 — 使用 sqlplus、SQLcl run-sql 或驱动脚本。

你可以执行的一项操作是：--confirm — 但只能在开发者回复“批准”或在控制台批准之后。 例外：有效的 autopilot 租约（pythia-autopilot）已获开发者批准——此时 pythia apply <file> 会自行应用租约涵盖的语句，预览会说明 autopilot: applying under lease，或解释无法应用的原因。

更改无法通过 apply 执行的情况

如果由 DBA 或发布流程执行，或者策略拒绝了该组：预览仍会为当前版本留下回滚脚本，位于 .pythia/journal/<entry>/restore.sql（pythia history <OBJECT>）。请明确指出。

工作流

**第 1 步之前：**如果此对话中还没有针对该对象的独立影响分析，请先运行 pythia-impact——apply 的 impact: 行只是确认一个你已经知道的数字。

1. 预览。pythia apply <file> 不会写入任何内容：它会创建快照、计算影响、打印差异、警告、Lint 结果和确认令牌。

2. **原样转述预览内容。**差异、impact: 行、每条 ! 警告，都必须与打印内容完全一致。开发者批准的是他们看到的内容，而不是你的转述。

3. 请求批准——优先使用第一个可行的渠道，不要询问下一个渠道：

   • Claude Code：AskUserQuestion——使用它自己的对话框，所有客户端都会显示。pythia approve --card <token> 会打印卡片；问题文本必须是卡片内容，不得包含其他内容——前面不能加任何字，后面也不能翻译。钩子会对比问题与卡片，若两者不同则不会生成任何内容。说明写在选项描述中。标题为 pythia；选项必须正好是 Approve / Reject；每次调用最多四个令牌；绝不能填写 answers。如果钩子以 Reject 之外的任何原因表示该回答不算数，请直接转到下一个渠道。
   • 然后使用 pythia_approve 工具（MCP；Codex 从此处开始），并提供令牌：这是 pythia 自己的卡片。如果它表示客户端未显示卡片，请继续使用下一个渠道。
   • **最后：**转述 pythia approve <token>，供开发者在终端中运行。 任何不是 Approve 的回答都不算批准：停止操作，并询问需要修改什么。

4. **应用更改：**运行 pythia 打印的 then the agent: 行，必须完全照抄。此处出现两种拒绝都属正常，且都不代表故障：

   • “no developer approval is on file”——回答不是 Approve，或者钩子尚未安装。说明情况并等待；重试不会生成批准记录。
   • “the confirmation token does not match”——自预览后，文件或数据库已发生变化。返回第 1 步，绝不要“重试”；如果对象已在 pythia 之外发生变化，新的预览会自行发出警告。

5. 读取退出码——它就是最终结果。绝不能通过管道读取： apply … | tail 返回的是 tail 的退出码，始终为 0。请直接运行命令，或使用 ${PIPESTATUS[0]}。

   退出码	含义	必须执行的操作
   0	已应用、编译通过、没有新增 INVALID 对象	报告完成，并提及还原 ID
   1	已拒绝（策略、分类、令牌过期）	转述打印出的原因及其解决方法；不要绕过限制
   3	已写入但已损坏——出现编译错误或其他对象现已变为 INVALID	见下文

6. **退出码为 3 时，绝不能报告成功。**明确说明更改已写入，但导致了问题；展示编译错误（行:列）和新增的 INVALID 对象，并提供 To undo: 命令。只有开发者看到此状态后，才允许继续修复。

还原

pythia journal restore <id> 本身也是一次写入：同样遵循上述六个步骤，并且必须经过批准。如果还原的对象之前并不存在，这意味着执行 DROP——策略会根据 structural: deny 拒绝该操作，这是正确行为。

多条语句

脚本、发布操作或包含注释的表：使用 pythia-deploy——为每条语句生成一次预览，获取一次批准，按顺序运行，并在首次出现退出码 3 时停止。开发者说“别再问我”时，应请求使用 pythia-autopilot，绝不能据此跳过审批关卡。

绝不绕过写入流程

不能使用 SQLcl MCP run-sql、sqlplus 或驱动脚本：这些方式都没有快照、预览、验证和日志记录。拒绝信息是提供给开发者的信息，不是需要绕过的障碍。

回滚是真的吗？请如实说明

分组	回滚是真的吗？
plsql_source	是——完全可以。 可以从 ALL_SOURCE 恢复源代码。
comments	是。 每次写入前都会快照保存之前的注释。
data_dml	不可以。 提交后只剩 Flashback Query 可用，而且仅在撤销保留期内有效。重新验证会在写入前检查行集；这不等于撤销。
structural	几乎不可以。 DROP COLUMN 是永久操作；被删除的表可能还在 Recycle Bin 中。
grants	可以，但必须手动操作。
session	不需要。

绝不要承诺“我们总能回滚”——这只对第一行成立；笼统地这么说，会在风险最高时误导开发者。

data_dml 会针对其行进行重新验证：预览和 approve 会显示受影响的行数和最多十行记录；如果行集发生变化，--confirm 会拒绝执行。 MERGE 以及任何无法衡量的操作都会被拒绝，而不是靠猜测处理。

危险信号——如果发现自己有以下想法，请停下来

想法	实际情况
“改动很小，跳过预览吧”	小改动也会使依赖项失效。请先预览。
“开发者之前批准过类似的内容”	批准针对每次预览，而非每个主题。请再次询问。
“退出码是 3，但我的部分已编译——就报告完成吧”	有内容出了问题。那就不算完成。
“令牌过期了，我直接换新的吧”	内容已经改变。开发者必须看到新的预览。
“apply 拒绝了；run-sql 会接受的”	拒绝说明产品正在正常工作。请如实转达。
“我悄悄恢复一下，收拾自己的失误”	恢复操作也是写入。必须遵循同样的关卡，并保持同样的可见性。
“我把输出传给 tail 后，$? 显示 0”	那是 tail 的 0。请查看 pythia 自己的输出，或检查未经过管道时的退出码。
“我自己运行 approve，先把这事办通”	这是开发者的操作。控制台中的 approve 会拒绝你；钩子只会根据开发者的答复生成令牌。绕过流程正是这个关卡要阻止的行为。
“我在卡片周围加一行自己的话”	添加任何文字都会使卡片失效。说明应写在选项描述中——或者使用 pythia_approve 工具。
“Lint 报了问题，但代码能编译”	错误必须在预览提交给开发者之前修复；自动驾驶模式不会将其合入。

何时不应使用此技能

• 阅读 → pythia-explore。评估影响范围 → pythia-impact（预览用于确认，不用于发现）。多条语句 → pythia-deploy。

示例中写作 pythia ...；每条 pythia 输出都会打印本项目实际使用的后续操作格式——请优先直接粘贴这些内容。