supportTickets: add category+priority (lookup-backed) + vSupportTicketFull view
Fleet decision bs-mrtkq6rjomf (Elazar GO 2026-07-20). Class-A additive DDL, db-pluto lane, no gold-plating. supportTickets already has subject/createdAt/updatedAt/ticketNumber/soft-delete/threaded (PLUTO-563) — this leg adds ONLY: categoryOptionId + priorityOptionId FK->lookupOptions, seed grupos supportTicketCategory/supportTicketPriority, store VALUE-CODE not label, nullable + backfill category='general'/priority='normal', NO native enum, NO CHECK -> zero NOT NULL break. Then build view vSupportTicketFull (fleet-identical name, ratified in shared/md/evolutiva-db-views.md): one row per ticket, all standard cols resolved (ticketNumber, subject, category+priority labels via lookup, status label, creator display, createdAt/updatedAt/resolvedAt), soft-delete-filtered. Add fleet-registry row + pluto-commons pointer. Class-A: audit design-ping pre-apply + diff review pre-apply. Coder wires report-form pickers + /admin/soporte badges+triage filter AFTER column lands.
Questions
Activity
-
db-pluto-cc
-
dispatched db-pluto (DDL+view) + audit (Class-A pre-apply gate) + coder (UI follow-on), Elazar GO bs-mrtkq6rjomf
-
Storage correction (pm-venus ask + pluto schema check): categoryOptionId/priorityOptionId = uuid-FK -> lookupOptions(id), matching existing supportTickets.statusId uuid-FK pattern. NOT a value-code text column. Value-code lives on lookupOptions row; vSupportTicketFull resolves labels. Matches venus.
-
3/3 PM consensus (mars+venus+pluto): category/priority = uuid-FK per each app's entrenched style, NOT value-code. REQUIRED: migration + commons must log a DOCUMENTED per-app exception to §Lookup-Backed (deliberate: matches supportTickets.statusId, avoids mixed intra-table key style; strict compliance deferred to a separate cross-app convention-migration WI) so it doesn't read as 'the rule permits uuid' and drift.
-
STORAGE FINAL (supersedes the earlier uuid-FK + documented-exception events): value-code TEXT, per fleet 3-1 consensus (enamel+pluto+venus value-code; mars uuid). Reasoning: (a) a 2/3 PM vote can't authorize violating a HARD written rule (§Lookup-Backed 'never the row uuid') — follow or amend via process; (b) 'risky on live data' never applied to BRAND-NEW columns (zero legacy rows). categoryOptionId/priorityOptionId = value-code TEXT (store lookupOptions.campo), optional composite FK -> lookupOptions(grupo,campo); denormalized text allowed, no row uuid. NOW rule-compliant -> no exception note needed. Pre-existing statusId uuid-FK stays, addressed by a SEPARATE cross-app §Lookup-Backed convention-migration WI. db redrafting on value-code; raw-diff/apply gate unchanged.
-
Column names FINAL: categoryCode / priorityCode (TEXT value-code), NOT categoryOptionId/priorityOptionId — '...OptionId' misleads for a text code + re-invites uuid confusion; names are per-app-internal, not contract-locked (contract = view vSupportTicketFull + labels categoryValue/priorityValue). Integrity: no FK (17 grupos have duplicate campo, no global unique) → app-side active-option validation + grupo+campo-qualified view LEFT JOINs + terminal one-active-option assertions.
-
Category+priority classification shipped: reporter self-sets category (SupportFab+/soporte), admin triages category+priority on /admin/soporte (badges+filters+detail card). Value-code store/label-render, fail-closed active validation. SHA 19773229f v2.22.7, audit PASS, Class-A PTD clean.
-
Shipped a6a7733/v2.22.21 (Node RPC) + f64b89d mig-097 (DB lock-mode fix). audit-pluto-ca PASS a6a7733+f64b89d(097 scope): FOR NO KEY UPDATE up front closes the TOCTOU deadlock, lookup rows stay FOR SHARE, concurrency probe clean (no 40P01), caller signature/ACL/archive contract unchanged. PTD: deploy READY, live version-match, build clean, zero runtime errors 2h, tsc+193 tests green.