Tres sitios comparan el estado contra la etiqueta en texto ('Baja'/'BAJA') en vez de valor_opcion: un typo corregido en el catalogo los rompe en silencio
Tres sitios comparan el estado del vehiculo contra la ETIQUETA en texto, no contra el id ni contra valor_opcion. Rompe la regla de catalogos de .claude/rules/catalogos.md y shared/md/movilba-commons.md:352, y rompe exactamente en el caso que Elazar nombro el 2026-09-03 al decidir que nunca se congela la etiqueta: si alguien corrige un typo en opciones.nombre_mostrable, estas comparaciones dejan de matchear en silencio y la pantalla cambia de comportamiento sin que nadie toque codigo. SITIOS (medidos sobre dev tip, worktree en dev/dev): - src/app/vehiculos/[id]/page.tsx:522 -> const isClosed = estadoLabel === 'Baja' || estadoLabel === 'BAJA'; - src/app/vehiculos/[id]/page.tsx:530-531 -> eslabon.estadoNombre === 'Alta' || eslabon.estadoNombre === 'ALTA' - src/components/ChoferExpedienteForm.tsx:32 -> alta: 'Alta' Que las dos primeras chequeen las dos grafias es la prueba de que ya se rompio una vez: alguien encontro que a veces llega 'Baja' y a veces 'BAJA' y en vez de dejar de comparar etiquetas agrego la segunda. Es el mismo error que la regla de Elazar sobre gatear por la forma VALIDA y nunca por la lista de formas malas conocidas: la tercera grafia gana. COMO SE ARREGLA: comparar por valor_opcion, que es la clave canonica en mayusculas y sin acentos y es lo que el catalogo garantiza estable, o por el id. El endpoint de dropdowns ya devuelve el campo valor justamente para esto - src/app/api/dropdowns/route.ts lo proyecta en siNo, estados, estadoColectivo, motivoTransferencia y motivoAsignacionLinea, y el comentario en la linea 205 dice literalmente 'La UI resuelve por ella y nunca por el id crudo ni por la etiqueta, que lleva acento y cambia sin avisar'. O sea el patron correcto ya existe en el repo y estos tres sitios no lo usan. VERIFICADO QUE NO ES EL BUG: el desplegable de Estado del formulario de agregar colectivo (src/app/vehiculos/agregar/colectivo/page.tsx:411-430) SI sale del catalogo - lee estadoColectivo del endpoint, que lee v_estado_colectivo, que es SELECT sobre opciones con grupo_nombre='vehiculo', campo_nombre='estado' y borrado_en IS NULL. DEV y PROD devuelven las mismas 3 filas (116 Alta, 117 Baja, 119 Mantenimiento) y TRANSFERENCIA (118) esta soft-deleteada desde 2025-10-13 y correctamente ausente. Ese formulario esta bien. NO EJERCITADO: no barri personas ni entidades buscando la misma forma; solo vehiculos y el componente de choferes que aparecio en el mismo grep.
Activity
-
was: Tres sitios comparan el estado del vehiculo contra la ETIQUETA en texto, no contra el id ni contra valor_opcion. Rompe la regla de catalogos de .claude/rules/catalogos.md y shared/md/movilba-commons.md:352, y rompe exactamente en el caso que Elazar nombro el 2026-09-03 al decidir que nunca se congela la etiqueta: si alguien corrige un typo en opciones.nombre_mostrable, estas comparaciones dejan de matchear en silencio y la pantalla cambia de comportamiento sin que nadie toque codigo. SITIOS (medidos sobre dev tip, worktree en dev/dev): - src/app/vehiculos/[id]/page.tsx:522 -> const isClosed = estadoLabel === 'Baja' || estadoLabel === 'BAJA'; - src/app/vehiculos/[id]/page.tsx:530-531 -> eslabon.estadoNombre === 'Alta' || eslabon.estadoNombre === 'ALTA' - src/components/ChoferExpedienteForm.tsx:32 -> alta: 'Alta' Que las dos primeras chequeen las dos grafias es la prueba de que ya se rompio una vez: alguien encontro que a veces llega 'Baja' y a veces 'BAJA' y en vez de dejar de comparar etiquetas agrego la segunda. Es el mismo error que la regla de Elazar sobre gatear por la forma VALIDA y nunca por la lista de formas malas conocidas: la tercera grafia gana. COMO SE ARREGLA: comparar por valor_opcion, que es la clave canonica en mayusculas y sin acentos y es lo que el catalogo garantiza estable, o por el id. El endpoint de dropdowns ya devuelve justamente para esto - src/app/api/dropdowns/route.ts lo proyecta en siNo, estados, estadoColectivo, motivoTransferencia y motivoAsignacionLinea, y el comentario en la linea 205 dice literalmente 'La UI resuelve por ella y nunca por el id crudo ni por la etiqueta, que lleva acento y cambia sin avisar'. O sea el patron correcto ya existe en el repo y estos tres sitios no lo usan. VERIFICADO QUE NO ES EL BUG: el desplegable de Estado del formulario de agregar colectivo (src/app/vehiculos/agregar/colectivo/page.tsx:411-430) SI sale del catalogo - lee estadoColectivo del endpoint, que lee v_estado_colectivo, que es SELECT sobre opciones con grupo_nombre='vehiculo', campo_nombre='estado' y borrado_en IS NULL. DEV y PROD devuelven las mismas 3 filas (116 Alta, 117 Baja, 119 Mantenimiento) y TRANSFERENCIA (118) esta soft-deleteada desde 2025-10-13 y correctamente ausente. Ese formulario esta bien. NO EJERCITADO: no barri personas ni entidades buscando la misma forma; solo vehiculos y el componente de choferes que aparecio en el mismo grep.
-
Already shipped on dev tip before this assignment landed: 16ee6ba6/a8a6acd8 (v5.4.104) fixed both real sites (page.tsx isClosed/sucesorActivo via new estadoValorPorId map wired through detail-dropdowns route). Third named site (ChoferExpedienteForm.tsx:32) is NOT the same defect: cambios.tipo is an app-internal event-type literal set at write time (src/actions/choferes.ts:190 etc, values 'alta'/'asignacion_linea'/...), not an opciones catalog value - no valor_opcion exists for it. No code change made.