chore(lookup): lookupOptions.campo is the authored value-code column (shipped)

Sub-tickets

Activity

• wi-cli-venus created · 2026-07-06
• wi-cli-venus assigned · 2026-07-19
  coder-venus-cc
• wi-cli-venus statusChanged · 2026-07-19
  status=todo
• wi-cli-venus spec · 2026-07-19
  Widened per Elazar 2026-07-19 EVO-67 fallout: (1) add authored codigo column on lookupOptions, backfill tipoDocumento+sexo; (2) migrate practicas.pacienteSexo off label-verbatim text storage to FK-or-code (1610 live rows, Class-A). db-venus-cc survey confirmed pacienteSexo is the ONLY label-verbatim column in schema; documentoType x2 is lesser ad-hoc-code issue; everything else clean FK. Also surfaced orphaned 'ticketStatus' lookup group (5 unreferenced rows) as separate small cleanup. Plan doc required before any DDL.
• wi-cli-venus note · 5w ago
  ROW STATE vs PROD STATE, MEASURED 2026-09-11 AS agent_db_venus_cc, READ-ONLY - flagging a possible stale row, not closing it. This row is not mine and the disposition call is not mine. THE REMAP IS APPLIED IN PRODUCTION. public.pacientes.sexo holds F 1440, M 899, XN 21 and public.practicas."pacienteSexo" holds F 1881, M 1184, XN 21. Zero label-verbatim values ('Femenino', 'Masculino', 'Otro / No especificado') survive in either column. Phase 2 as described in pm/venus-155-sexo-code-migration-design.md is done, and the two _venus155_*_sexo_backup snapshots documented under VENUS-403 (pushed 5e255f8) are its rollback source. THE TITLE MAY BE WHY THE ROW LOOKS OPEN. It says 'explicit valor/codigo column on lookupOptions'. There is no column named valor or codigo - public.lookupOptions is (id, grupo, campo, nombre, descripcion, params, orden, activo, createdAt, createdBy, updatedBy, updatedAt), and IS the code column the design doc settled on and the one the live values now key against. So the deliverable exists under a name the title did not anticipate. That is a row-title question, not a schema gap, and reading the title alone would send someone to add a redundant column. WHAT IS GENUINELY NOT DONE: Phase 3, the optional resolver/CHECK hardening. The live columns are still plain text with NO enum type and NO check constraint - format_type returns text on both and pg_constraint contype='c' returns only the two dni-or-hc checks. The design doc calls Phase 3 deferrable and not required for correctness, and it is not signed off, which is exactly why VENUS-403's comment says the backups are not unconditionally droppable. If this row is being kept open FOR Phase 3, say so on it, because right now the row reads as if the migration itself were pending. NO ACTION TAKEN, no DDL, no status change.
• wi-cli-venus note · 5w ago
  AMENDMENT - THE NOTE ABOVE IS MANGLED, READ THIS ONE INSTEAD. I wrote that note with backticks inside a double-quoted shell argument, so bash ran the backtick content as a command (line 9: campo: command not found) and substituted the empty result. The sentence naming the code column lost the column name. Same defect class as the gitpush backtick hazard already on record; the fix is to pass the body from a file rather than inline it. Nothing about the measurement changed - only the rendering of it. Full corrected text: ROW STATE vs PROD STATE, measured 2026-09-11 as agent_db_venus_cc, read-only. Flagging a possible stale row, not closing it. This row is not mine and the disposition call is not mine. THE REMAP IS APPLIED IN PRODUCTION. public.pacientes.sexo holds F 1440, M 899, XN 21 and public.practicas."pacienteSexo" holds F 1881, M 1184, XN 21. Zero label-verbatim values (Femenino, Masculino, "Otro / No especificado") survive in either column. Phase 2 as described in pm/venus-155-sexo-code-migration-design.md is done, and the two _venus155_*_sexo_backup snapshots documented under VENUS-403 (pushed 5e255f8) are its rollback source. THE TITLE MAY BE WHY THE ROW LOOKS OPEN. It says "explicit valor/codigo column on lookupOptions". There is no column named valor and none named codigo. public.lookupOptions is (id, grupo, campo, nombre, descripcion, params, orden, activo, createdAt, createdBy, updatedBy, updatedAt), and CAMPO is the code column - the one the design doc settled on and the one the live F/M/XN values key against. So the deliverable exists under a name the title did not anticipate. That is a row-title question, not a schema gap, and reading the title alone would send someone to add a redundant column. WHAT IS GENUINELY NOT DONE: Phase 3, the optional resolver/CHECK hardening. The live columns are still plain text with no enum type and no check constraint - format_type returns text on both, and pg_constraint contype='c' on those two tables returns only the two dni-or-hc checks. The design doc calls Phase 3 deferrable and not required for correctness, and it is not signed off, which is exactly why VENUS-403's catalog comment says the backups are not unconditionally droppable. If this row is being held open FOR Phase 3, say so on it, because as written the row reads as if the migration itself were pending. NO ACTION TAKEN. No DDL, no status change.
• wi-cli-venus assigned · 4w ago
  unassigned
• wi-cli-venus statusChanged · 4w ago
  Unassigned and moved to backlog by pmmaster-evolutiva-cc 2026-09-12. The assigned agent did not exist: coder-venus-cc, db-venus-cc, coder-pluto-cc and db-pluto-cc are all absent from the hub roster and have no tmux pane, and venus and pluto currently have no staffed coder or db lane at all. A todo or inProgress row against an absent assignee reads as staffed-and-underway and is neither, so the status was a lie about this row rather than a claim about the work. The work itself is untouched and the priority is unchanged. Cause of the cluster, and it is a fleet-wide pattern rather than a bookkeeping slip: five auto-succession call sites plus resolvePm can leave a row pointing at an agent that has been deregistered, and nothing reconciles an assignee against the roster afterwards. Filed context: 178 rows across these four names, of which 23 carried a non-backlog status. Restaffing venus and pluto is Elazars decision, not a reassignment I can make.
• pmmaster-evolutiva-cc assigned · 1w ago
  db-venus-cc
• db-venus-cc titleChanged · 1w ago
  chore(lookup): lookupOptions.campo is the authored value-code column (shipped)
• db-venus-cc completed · 1w ago
  Shipped under lookupOptions.campo (not a new valor/codigo column, title named the wrong thing). Live-verified 2026-10-06: pacientes.sexo + practicas.pacienteSexo hold only F/M/XN codes, zero label-verbatim survivors. Phase 3 (CHECK/enum hardening) split to its own row - pmmaster ruling.