[Kiran01bm]

destructiveOp now decides every operation shape in statement.OpKinds() explicitly, a test fails when a shape has no decision, and a shape outside the decided set is treated as destructive.

Why

The imperative destructive gate (RF-10) and desired-state admission both rest on destructiveOp, and SAFETY.md notes the core has no backstop for it: a wrong "not destructive" lets a drop commit unacknowledged. Its default: return false meant a new operation shape added to the parser was non-destructive unless its author remembered this switch. With statement.OpKinds() available, the decision can be required for every shape instead.

What

• destructiveOp moves from planner.go to pkg/planner/destructive.go and delegates to classifyDestructive, which names all 24 shapes: the four drops destructive, the other twenty not. An unnamed shape is reported unclassified and treated as destructive.
• TestEveryOpKindIsClassifiedForDestructiveness walks statement.OpKinds(), fails on any shape without a decision, and pins the destructive set to DROP COLUMN, DROP CONSTRAINT, DROP INDEX, DROP NOT NULL.
• TestAnUnclassifiedOpKindIsTreatedAsDestructive pins the fail-closed default.
• RF-10's Enforced line names both tests.

No verdict changes for any statement today: every existing shape keeps its answer.

Before / after

A later change teaches the parser ALTER TABLE orders DROP POLICY orders_tenant as a new shape, OpDropPolicy, and forgets destructiveOp.

Before                                        After

destructiveOp(OpDropPolicy)                   classifyDestructive(OpDropPolicy)
  → falls to default: not destructive           → not named: unclassified
migrate --alter 'ALTER TABLE orders           TestEveryOpKindIsClassifiedForDestructiveness
  DROP POLICY orders_tenant'                    fails in CI: "op kind 24 ("DROP POLICY")
  → destructive gate sees nothing to            has no destructiveness decision"
    acknowledge and runs it                   and if it shipped anyway, destructiveOp
                                                says destructive, so the gate refuses it
                                                without --allow-destructive

🤖 Generated with Amp (Claude Opus 4.6)

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	⚠️ Failed 2026-10-28T03:27:31.447032Z We couldn’t complete this review. Comment @codex review to try again.	838bc2a	Draft marked ready

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.

[JashLal]

🤖 Adversarial correctness review by Jash's AI agent at 838bc2ad20e870ad8518864fe10d3aef9e365bd0.

Verdict: the inspected delta preserves existing classifications and treats an undecided operation as destructive by default. No actionable defect found. The same four drop kinds remain destructive, and the other twenty kinds are explicitly classified as non-destructive. The default returns (true, false) and the production wrapper preserves the conservative result. The new tests check inventory coverage, the exact destructive set, and the runtime fallback. No tests were deleted or weakened.

All 16 reported checks succeeded, including PostgreSQL 14–18, build and unit tests; the separate automated Codex review reported usage exhaustion. The required OpKinds() addition from #270 is merged. Exact-head repository instructions, surrounding planner/statement code and review threads were unavailable because API requests failed connecting to api.github.com, so inventory completeness and both admission paths were not independently verified. No local build or tests ran.

Generated by Codex.

[JashLal]

🤖 OSS adoption ease: current operation classifications are preserved, with no new configuration required. The conservative default makes future operation additions safer for callers who have not acknowledged destructive changes.

SchemaBot integration: the inspected change retains existing classification behavior and does not change the visible API. No product finding established; verification of both admission paths against their exact-head implementations remains incomplete because surrounding-source reads were unavailable.

Generated by Codex.

[JashLal]

🤖 Approving on Jash's behalf after the review at 838bc2a. No actionable defect found in the full diff; the required OpKinds addition is merged. Exact-head surrounding source and review threads were unavailable, and no local build or tests ran. Approval does not certify those unverified paths. Generated by Codex.