Verify air-conditioning catalog provenance and installed view joins against current RUTAP book

Sub-tickets

Activity

• wi-cli-venus created · 4w ago
• wi-cli-venus assigned · 4w ago
  db02-mba-l-cc / db
• wi-cli-venus parentChanged · 4w ago
  parent=MOVILBA-481
• wi-cli-venus assigned · 3w ago
  db04-mba-l-ca
• db04-mba-l-ca progress · 3w ago
  db04-mba-l-ca 2026-09-24 04:05 -03 — Status sweep limitation: The two-catalog union for carroceria_aire_acondicionado_id and its current use denominator were not recomputed through v_opciones; no schema change or closure. BWI show and recent events were read; status unchanged and no DB write.
• db04-mba-l-ca blocked · 3w ago
  db04-mba-l-ca 2026-09-24 04:13 -03 — coder03-mba-l-cc must approve the resolver design for carrocerias.carroceria_aire_acondicionado_id and the downstream COALESCE joins: one stored option ID can refer to general.respuesta_binaria or carroceria.aire_acondicionado, so a single qualified catalog pair loses the other branch. Before that design call, the DB lane must verify the authoritative pair for actual source rows against the approved current book and refresh the historical zero-use denominator; matching label text is insufficient. No DB/view write.
• db04-mba-l-ca unblocked · 3w ago
  db04-mba-l-ca 2026-09-24 04:27 -03 — Correcting my premature block. coder03-mba-l-cc clarified in hub DM 2026-09-24 04:09 ART that 483 is DB/source work, not a design decision awaiting him. The DB lane must verify the two-catalog mapping against the pinned current book and recompute the live-use denominator before proposing a resolver. Prior blockedReason was an inference and is withdrawn; no DB/view write.
• db04-mba-l-ca titleChanged · 3w ago
  Verify air-conditioning catalog provenance and installed view joins against current RUTAP book
• db04-mba-l-ca descriptionChanged · 3w ago
  was: HALLAZGO de db02-mba-l-cc el 2026-09-18 en el censo de MOVILBA-481 (docs/reference/movilba-481-opciones-view-join-census.md, landeado en v5.5.240). carrocerias.carroceria_aire_acondicionado_id resuelve contra DOS catalogos vivos a la vez en PROD: ('general','respuesta_binaria') y ('carroceria','aire_acondicionado'). Es la MISMA forma que clase_licencia_id en el noveno sitio de MOVILBA-308: una columna, dos catalogos reales, asi que calificar con un par suelto no arregla nada - VACIA las filas del otro catalogo en vez de mostrar una etiqueta ajena. El par correcto es la UNION y NO ESTA ESTABLECIDO todavia. POR QUE ES P1 Y NO P0, medido por db02: la fila de carrocerias que cae en el catalogo minoritario no la referencia NINGUN vehiculo en PROD - denominador CERO. O sea que hoy no hay ninguna pantalla mostrando nada de esto. No se parece a MOVILBA-482, que si es dato vivo en pantalla. Pero el par sigue sin establecerse y basta con que a un vehiculo se le asigne esa carroceria para que pase a ser visible, asi que no se cierra por tener denominador vacio. CUIDADO AL ESTABLECER EL PAR, leccion de 482 y de MOVILBA-366: las dos lecturas dicen SI, o sea que el texto no distingue cual es la copia buena. NO establecer el par por coincidencia de texto. Verificar contra el libro cual corresponde, igual que en 482 se resolvio mirando lo que la capa derivada del libro ya decia y no el match E5/E3. ADEMAS, y es parte del mismo arreglo: v_vehiculos_detalle y v_vehiculos_export arman COALESCE(periodo_veh.aire_acondicionado_id, ca.carroceria_aire_acondicionado_id) y unen ESE resultado a opciones con un solo LEFT JOIN sin calificar. Las dos ramas del COALESCE resuelven distinto -la primera solo contra general.respuesta_binaria, la segunda contra dos-, asi que el JOIN final tiene que cubrir la union de AMBAS, no el par de una rama sola.
• db04-mba-l-ca descriptionChanged · 3w ago
  was: Historical finding (2026-09-18, MOVILBA-481): carrocerias.carroceria_aire_acondicionado_id appeared to point at both general.respuesta_binaria and carroceria.aire_acondicionado; proposed qualification of joins had no established pair. This historical premise must not be presented as current state. Read-only remeasurement by db04-mba-l-ca on 2026-09-24 found that every non-null carrocerias.carroceria_aire_acondicionado_id in installed DEV and PROD is option 126, the live carroceria.aire_acondicionado/SI row; none points to general.respuesta_binaria. The latest imported RUTAP snapshot in each base carries 5,528 rows; raw book Aire_acondicionado values Si/SI/si/No resolve in rutap.vehiculo_historial_normalizado to 126/127, both carroceria.aire_acondicionado. The pinned corrected 2026-09-19 workbook has those same 5,528 source rows, and the top-level 2026-09-23 workbook has 5,534, with the same four label spellings. A query following the installed export resolver's COALESCE over live public.vehiculos finds PROD 2,411/2,411 with effective option 126 or 127, zero general-catalog IDs; DEV 2,423/2,430 with effective 126 or 127 and seven NULL (test data), zero general-catalog IDs. These are current data measurements, not a proof of future catalog enforcement. Installed view shape differs: DEV v_vehiculos_detalle and both bases' v_vehiculos_export use COALESCE(periodo_veh.aire_acondicionado_id, ca.carroceria_aire_acondicionado_id); PROD v_vehiculos_detalle uses ca.carroceria_aire_acondicionado_id directly. All inspected joins currently resolve by option ID without catalog qualification. Remaining DB work: determine whether a catalog-qualified constraint/join is still needed for future writes, and reconcile the DEV/PROD detail-view difference with its owning migration; do not implement a two-catalog UNION on the historical premise alone. No DDL or data write in this measurement.
• db04-mba-l-ca descriptionChanged · 3w ago
  was: Historical finding (2026-09-18, MOVILBA-481): carrocerias.carroceria_aire_acondicionado_id appeared to point at both general.respuesta_binaria and carroceria.aire_acondicionado; proposed qualification of joins had no established pair. This historical premise must not be presented as current state. Read-only remeasurement by db04-mba-l-ca on 2026-09-24 found that every non-null carrocerias.carroceria_aire_acondicionado_id in installed DEV and PROD is option 126, the live carroceria.aire_acondicionado/SI row; none points to general.respuesta_binaria. The latest imported RUTAP snapshot in each base carries 5,528 rows; raw book Aire_acondicionado values Si/SI/si/No resolve in rutap.vehiculo_historial_normalizado to 126/127, both carroceria.aire_acondicionado. The pinned corrected 2026-09-19 workbook has those same 5,528 source rows, and the top-level 2026-09-23 workbook has 5,534, with the same four label spellings. A query following the installed export resolver's COALESCE over live public.vehiculos finds PROD 2,413/2,413 with effective option 126 or 127, zero general-catalog IDs; DEV 2,424/2,431 with effective 126 or 127 and seven NULL (test data), zero general-catalog IDs. These are current data measurements, not a proof of future catalog enforcement. Installed view shape differs: DEV v_vehiculos_detalle and both bases' v_vehiculos_export use COALESCE(periodo_veh.aire_acondicionado_id, ca.carroceria_aire_acondicionado_id); PROD v_vehiculos_detalle uses ca.carroceria_aire_acondicionado_id directly. All inspected joins currently resolve by option ID without catalog qualification. Remaining DB work: determine whether a catalog-qualified constraint/join is still needed for future writes, and reconcile the DEV/PROD detail-view difference with its owning migration; do not implement a two-catalog UNION on the historical premise alone. No DDL or data write in this measurement.
• db04-mba-l-ca progress · 3w ago
  db04-mba-l-ca 2026-09-24 04:35 -03 — Source/catalog check complete, SELECT-only PROD movilba and DEV movilba_dev: GROUP BY c.carroceria_aire_acondicionado_id,o.grupo_nombre,o.campo_nombre over public.carrocerias LEFT JOIN opciones gives only non-null 126/carroceria/aire_acondicionado in both bases. GROUP BY h.raw_aire_acondicionado,h.aire_acondicionado_id,o.grupo_nombre,o.campo_nombre on max(rutap_snapshot_id) of rutap.vehiculo_historial_normalizado gives Si 5268, SI 200, si 4 -> 126; No 56 -> 127; identical in both. Workbook Base!T3:T5530 of SHA-pinned corrected 09-19 workbook gives same source distribution; top-level 09-23 gives Si 5274, SI 200, si 4, No 56. COALESCE join on installed v_vehiculos_hist_ultimo/current normalized period plus carrocerias for live vehiculos gives PROD 2413 effective 126/127 of 2413, DEV 2424 effective of 2431 with seven NULL; zero general.respuesta_binaria effective IDs. pg_get_viewdef confirms PROD v_vehiculos_detalle uses ca ID directly; DEV uses COALESCE; both export views use COALESCE. The earlier 04:13 block on coder approval is withdrawn. Historical two-catalog-data premise is not reproduced today; remaining future-write safeguard/view-drift question stays backlog, no DDL.
• db04-mba-l-ca progress · 3w ago
  db04-mba-l-ca 2026-09-24 04:28 -03 — Cross-reference MOVILBA-565: both track installed DEV/PROD view-body drift requiring coordinated migration design. This item: v_vehiculos_detalle aire_acondicionado_id uses COALESCE(periodo_veh, ca) in DEV but ca directly in PROD; future-write catalog safeguard remains separate work. MOVILBA-565: v_vehiculos_export expediente_alta/baja use periodo_veh in DEV but vdc in PROD. Reconcile both against intended source and installed objects before writing migration; notify coder03 before any migration. No DB change.
• coder03-mba-l-cc assigned · 2w ago
  db03-mba-l-cc
• db03-mba-l-cc note · 2w ago
  db03-mba-l-cc 2026-10-01, read-only PROD+DEV, re-measured after applying MOVILBA-584. LA PREMISA DE DOS CATALOGOS YA NO ES CIERTA, MEDIDO HOY: carroceria.aire_acondicionado (ids 126/127) NO EXISTE en la tabla opciones, ni en PROD ni en DEV - select id,... from opciones where id in (126,127) da 0 filas en las dos bases. El unico catalogo vivo para esta pregunta es general.respuesta_binaria (24 SI, 25 NO, 26 DESCONOCIDO, 27 NA). Hoy no hay segundo catalogo contra el que calificar: carrocerias.carroceria_aire_acondicionado_id resuelve 16/17 filas a general.respuesta_binaria en PROD (la 17a tiene el campo NULL, no una FK huerfana - verificado, 0 vehiculos vivos la referencian). Sobre vehiculos vivos: v_vehiculos_detalle.carroceria_aire_acondicionado_id (post-584, ya con el COALESCE periodo/carroceria) resuelve 2419/2419 a general.respuesta_binaria en PROD, mismo patron en DEV. O sea el JOIN sin calificar funciona hoy no por descuido sino porque solo hay un catalogo posible para resolver. Carroceria.piso SI sigue siendo catalogo unico y correcto (28 Bajo, 29 Medio, 30 Alto, 160 '3 Largo'), sin ambiguedad, nunca la tuvo. DOS SUPERFICIES con el mismo JOIN sin calificar a opciones para aire_acondicionado: public.v_vehiculos_detalle (linea 'op_ac', arreglada en 584 solo en la fuente del ID, el JOIN sigue sin calificar) y public.v_vehiculos_export (linea 'op_aire', mismo patron, COALESCE(periodo_veh.aire_acondicionado_id, ca.carroceria_aire_acondicionado_id) sin JOIN calificado). VEREDICTO: no hace falta una UNION de catalogos porque el segundo catalogo fue retirado (probablemente en el mismo esfuerzo de poda que MOVILBA-489/504, no investigado). El riesgo de MOVILBA-308 (un id que resuelve a etiqueta ajena) sigue latente si algun dia se crea una fila nueva en cualquier otro catalogo que reutilice los ids 24-27, pero HOY el join sin calificar no produce ningun error observable. Recomendacion para decidir, no DDL de mi parte: calificar los dos JOIN (grupo_nombre='general' AND campo_nombre='respuesta_binaria', mismo patron v_opciones que usa rutap-historial.ts) es un endurecimiento preventivo barato, no una correccion de un bug activo - decision de alcance/prioridad para coder03/Elazar, no bloqueante. NO EJERCITADO: no se busco si existe una tercera superficie ademas de las dos vistas; no se audito si algun codigo de aplicacion hace el mismo join sin calificar fuera de SQL de vista.
• coder03-mba-l-cc completed · 2w ago
  Premisa VENCIDA, medido por coder03-mba-l-cc 2026-10-01 en las dos bases, lectura sola, en acuerdo exacto con db03-mba-l-cc. El item existia por una ambiguedad de dos catalogos de aire acondicionado: hoy no hay dos. carroceria.aire_acondicionado -ids 126/127- NO EXISTE en public.opciones en PROD ni en DEV, ni vivo ni borrado, y no queda ninguna opcion viva con campo_nombre que contenga 'aire' en PROD. Lo unico vivo es general/respuesta_binaria 24 SI / 25 NO, que es el catalogo que la regla permanente de Elazar manda para todo campo Si/No, asi que el valor que sirve la vista no es ambiguo: es el correcto. Verificado contra el libro: cruzando la etiqueta de public.v_vehiculos_detalle contra el texto crudo raw_aire_acondicionado del periodo vigente, PROD 2419 filas con valor y 0 discrepancias, DEV 2406 y 0. El reparto en PROD es Si/SI/si -> SI 2372 y No -> NO 47. Sobre el endurecimiento preventivo que propuso db03 -calificar el JOIN por grupo y campo-: NO se hace, y la razon es que no compra nada. Los ids de opciones son unicos globalmente, asi que un join por id no puede traer la fila de otro catalogo; calificarlo solo convierte en NULL lo que hoy seria una etiqueta visiblemente equivocada, y una etiqueta equivocada se ve mientras un NULL se lee como dato ausente. Son dos vistas en dos bases de DDL para empeorar el modo de falla. Si alguien revive un catalogo dedicado de aire acondicionado, esto se reabre. SIN EJERCITAR: no se abrio la ficha ni el PDF en un navegador; lo verificado es la vista y el cruce contra el libro, no el render.