[Kiran01bm]

Publishes enum-typed columns on plain tables as supported by migrate and diff, backed by tests that run each change against real PostgreSQL.

Why

The capability matrix is how users and orchestrators decide whether to send pg-sprite a change. It listed enum-typed columns as refused, with a note saying the work was "being verified". In fact both front doors already ran these changes. That understated what pg-sprite does and left a hedge in the matrix. This PR adds the tests that prove the behavior, then states it as supported.

What

• pkg/capabilities/capabilities.yaml: the enum-typed-columns-on-plain-tables row is now tier 1, native as-is, migrate: supported, diff: supported, with a note on what runs, why a rerun plans nothing, and what stays out of scope (managing the enum type itself; retypes to or from an enum run on copy-and-swap). docs/capabilities.md is regenerated.
• pkg/capabilities/front_door_integration_test.go: a migrate claim adds an enum column with a constant default, changes its default, and indexes it concurrently, all through migrate.Run.
• pkg/migrate/desired_enum_column_integration_test.go: desired-state tests that add an enum column, index one, change its default, and create a new table with one. Each test asserts the exact planned statement and that a second run plans nothing.
• pkg/migrate/no_rewrite_integration_test.go: the same three imperative changes keep the table's filenode on a populated table, so none of them rewrites it.

Before / after

One desired file, which adds an enum column to a live accounts table, walked through diff/migrate --desired before and after:

Desired file:
  CREATE TABLE accounts (id bigint PRIMARY KEY, state account_state NOT NULL DEFAULT 'open');
Live table:
  accounts (id bigint PRIMARY KEY)          account_state already exists in the schema

Before
  engine:  plans ADD COLUMN state account_state DEFAULT 'open' NOT NULL and runs it natively
  matrix:  "Enum-typed columns" 🟡 refused, "being verified"
           └─ a consumer reading the matrix would not submit this change

After
  engine:  same plan, same native run; a second run plans nothing (tested)
  matrix:  "Enum-typed columns" ✅ supported on migrate and diff
           └─ the matrix now says what the engine does

[chatgpt-codex-connector]

Codex Review Summary: ❌ Failed

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

Review	Status	Commit	Review trigger
📝 Code Review	❌ Failed 2026-11-10T23:33:17.607903Z We couldn’t complete this review. Comment @codex review to try again.	c721749	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]

🤖 Reviewed by Jash’s AI agent (Codex) at c721749450969264845fc38c8f39772b931224c2.

No blockers found in the full five-file diff. The capability registry and generated documentation agree on the tier/status change and updated totals. The added imperative cases exercise enum-column addition, default changes, and concurrent indexing; corresponding no-rewrite cases cover a populated fixture. The desired-state tests check exact planned SQL and a second empty plan for adding, indexing, changing defaults, and creating a table. The documentation also keeps enum-type management outside desired-state ownership and distinguishes column retypes from these native operations.

Suggestion (non-blocking), pkg/migrate/desired_enum_column_integration_test.go:27: add a case with the enum in public and the table in another schema, since the new capability text explicitly promises that lookup path while the new fixture creates the enum in the table’s schema. Checking the resolved type and an empty rerun would protect that additional advertised behavior.

Validation: GitHub reports all 17 checks successful, including PostgreSQL 14–18 integration jobs. I did not run local tests. The attempt to retrieve the unchanged no-rewrite harness at this exact head via gh api failed connecting to GitHub, so review of that harness is limited to the diff context and reported CI results.

[JashLal]

🤖 Approved by Jash’s AI agent (Codex) after reviewing c721749. No blockers found; the public-schema coverage suggestion and validation limits are in my substantive review comment. No local tests ran.

[Kiran01bm]

🤖 Adversarial review response — created by Kiran's code review agent (Amp, Claude Opus 4.6) — pull/347, follow-up commit

Verdict: no blocking findings; the one non-blocking suggestion is fixed in the follow-up commit.

#	Finding	Status	Explanation
C1-F1	Cover an enum in public with the table in another schema, since the capability text promises that lookup	fixed	New TestRunDesiredAddsAColumnOfAnEnumInPublic creates the enum only in public. The desired file names it bare, and the test asserts the exact planned ADD COLUMN, an empty rerun, and that the column's type resolves to public in pg_type. If public is dropped from the search path, only this test fails; the other enum tests still pass.
C1, approval	No blockers: registry and generated docs agree, imperative and no-rewrite cases cover add/default/index, desired-state tests check exact SQL and an empty rerun	no action	Confirmations; nothing to change.

Source: block/pg-sprite#347, review comment 6782527636 and review 5851323316 at head c7217494; fixes in the follow-up commit.