V120: Document Creator Category → Type taxonomy migration

[timujinne]

V120 — Document Creator Category → Type taxonomy

Adds migration V120, the schema/DB foundation for the Document
Creator's Category → Type hierarchy (module-side work is a separate PR
on phoenix_kit_document_creator).

What V120 does

• Creates phoenix_kit_doc_categories and phoenix_kit_doc_types
  tables (UUIDv7 PKs, status soft-delete, position ordering).
• Adds nullable category_uuid / type_uuid FK columns to
  phoenix_kit_doc_templates and phoenix_kit_doc_documents
  (ON DELETE SET NULL); doc_types.category_uuid is
  ON DELETE CASCADE.
• Data migration: each distinct legacy template.category string
  becomes a Category row; templates/documents are repointed via FK;
  the legacy category string columns on templates and presets are
  dropped.
• Bumps @current_version to 120; idempotent up/down.

Notes

• Uses uuid_generate_v7() for data-migrated rows, per house
  convention (consistent with the schema's UUIDv7 autogenerate).
• No CHANGELOG.md / @version changes — maintainer-owned.

🤖 Generated with Claude Code

[timujinne]

PR #545 Review — V120: Document Creator Category → Type taxonomy migration

V120 adds the schema foundation for the Document Creator's Category → Type hierarchy: two new tables, nullable FK columns on templates/documents, a data migration of legacy category strings, and the @current_version bump. The migration is well-structured, idempotent in the common single-schema case, correctly restores the ⚡ LATEST marker (V119 had lost it), and touches no maintainer-owned files. Two correctness issues should be addressed before merge.

Critical

None.

Major

v120.ex:33, v120.ex:53 — uuid primary key has no default. Both create table blocks declare add(:uuid, :uuid, primary_key: true) with no column default. Every other Document Creator table (v86.ex:22,42,90, v117.ex:54,103) declares the PK as add(:uuid, :uuid, primary_key: true, default: fragment("uuid_generate_v7()")). The Ecto schemas use autogenerate: true so app-level inserts work, but any raw INSERT (including future migrations) hits a NOT NULL violation on uuid. The migration's own data-migration block sidesteps this by computing new_uuid := uuid_generate_v7() explicitly — proof the table has no DB-level default. Add default: fragment("uuid_generate_v7()") to both PK columns for consistency and safety.

v120.ex:62-79, v120.ex:89-95 — information_schema.columns guards omit table_schema. The DO $$ existence checks filter only on table_name/column_name. PhoenixKit supports multi-prefix (multi-tenant) installs — that is what the prefix parameter is for — and V110, V112, V116, V119 all qualify these guards with WHERE table_schema = '#{schema}'. Without that filter, in a multi-schema install the guard sees the column (or its absence) in any schema: the ADD COLUMN and the data-migration IF EXISTS (... column = 'category') block can be skipped or run for the wrong prefix, silently leaving a tenant un-migrated. Add a schema binding and include table_schema = '#{schema}' in all three guards.

Minor

Data migration uses initcap, spec specifies an explicit map. Spec §4 step 4 says "financial" → "Financial", "technical" → "Technical", others "capitalized". initcap(legacy) matches for those two, but a multi-word legacy value like legal review becomes Legal Review rather than Legal review. Harmless if legacy values are single-word; otherwise consider an explicit CASE. Non-blocking.

v120.ex (down) — category re-added as varchar(255), original was unbounded VARCHAR. V117 created the column as VARCHAR (no length) on both tables (v117.ex:40, v117.ex:106). Down-migrations are best-effort and 255 is ample, but for an exact reversal use unbounded varchar.

Nitpick

• postgres.ex V120 doc section mixes ### heading with #-prefixed comment lines, whereas V119/V118 use plain Markdown bullet lists under the heading. Cosmetic.
• The down/0 path relies on Postgres auto-dropping the V117 phoenix_kit_doc_templates_category_index when category is dropped — acceptable, though a strict reversal would restore that index.

---

VERDICT: REQUEST CHANGES — the two Major items are genuine correctness risks (the table_schema one breaks multi-prefix installs). Both are small, localized fixes.

🤖 Review generated with Claude Code

[timujinne]

Review fixes applied — 766f8f7c

Both Major items and both Minor items from the review are addressed:

• PK defaults — phoenix_kit_doc_categories / phoenix_kit_doc_types PKs now declare default: fragment("uuid_generate_v7()").
• Multi-prefix guards — a schema binding was added to up/0 and down/0; all five information_schema.columns checks now qualify on table_schema.
• Legacy mapping — initcap replaced with an explicit CASE (financial→Financial, technical→Technical, else first-letter-only).
• Rollback — down/0 re-adds category as unbounded varchar.

Re-reviewed and verified — mix compile clean. Verdict updated to APPROVE.

🤖 via Claude Code