docs/migrations/ contiene decisiones vinculantes que ningun ticket ni memoria indexa - 86 archivos, cinco re-derivaciones en una noche
Hallazgo estructural de la noche del 2026-08-20 (coder02, 06:26). En veinte minutos cuatro carriles re-derivaron desde cero DOS decisiones documentadas hace seis dias, y salieron a la luz solo porque Elazar se acordo. Casos: (1) MOVILBA-85, la cuarentena de AH924PV por Fecha_Alta 1900-01-06; (2) MOVILBA-84, los 4 pares legitimos AD919PL/AE922FX/AE971FE/AE971FF que difieren solo en Fecha_Baja. Los dos estaban en el MISMO archivo, docs/migrations/2026-08-14-historial-por-tramite-backfill-rutap-PROD.sql, nombrados y con motivo. Ademas la normalizacion de expedientes que db03 estaba por reinventar tambien esta ahi: regexp_replace(replace(coalesce(expediente,''), chr(160), ' '), '\s+', ' ', 'g'). EL PROBLEMA: docs/migrations/ son 86 archivos y es el registro MAS autoritativo que tenemos sobre nuestros propios datos, y el MENOS descubrible -- no esta en MEMORY.md, no esta en bwi, y no aparecio en la auditoria del indice de memoria que se hizo esa misma noche. La practica que quedo vigente ('grep docs/migrations/ antes de filear algo raro del libro') arregla el sintoma solo para quien se acuerda de grepear. OPCIONES A DECIDIR, no implementar a ciegas: (a) un indice de docs/migrations/ que liste archivo -> decisiones vinculantes que contiene; (b) promover a memoria las decisiones que SIGUEN vigentes, dejando el .sql como evidencia y no como fuente; (c) las dos. Ojo con (b): duplicar una decision en dos lugares es el defecto que ya nos costo tres archivos duplicados esta noche -- si se promueve, el .sql pasa a ser evidencia historica y la memoria el canonico, explicitamente.
Activity
-
docs/migrations/README.md creado y deployado a dev (v5.3.226). Indexa los 87 archivos en cinco secciones: (1) NO APLICAR - 12 archivos que corren si los ejecutas y ninguno debe ejecutarse (retirados, parkeados sin GO, congelados por dependencia de codigo); (2) las 7 reglas permanentes de Elazar que solo vivian adentro de headers de migraciones - filtrado en vistas y no en Next.js, la identidad del vehiculo es el chasis, una regla repetida en N archivos es un defecto, el expediente es texto libre, los catalogos se leen por vista, un GO autoriza lo descrito y no el numero de paso, los archivos PROD ensayan y hacen ROLLBACK por defecto; (3) la trampa DDL-vs-drizzle/schema.ts que causo la caida de dev del 06:05, con la distincion medida entre DDL estructural (SI llega al schema) y COMMENT ON (NO llega, diff vacio); (4) las cinco cadenas de decision que se revirtieron y donde cada archivo leido solo parece vigente - el export de bajas dio TRES vueltas y la vigente es la del 19/08; (5) indice cronologico con la decision de cada archivo y donde se aplico. HALLAZGO COLATERAL, MEDIDO CONTRA PROD Y DEV: pending-prod-changes.md listaba CINCO items como pendientes de prod que ya estaban aplicados en los dos entornos - api_keys.expires_at, chk_numero_linea_range>=0, bwi#60 motivo_id, bwi#62 brand-strip (0 filas empiezan con la marca, de 1736 en prod) y MOBAAPI-678 scopes text[] (la columna vieja scope ya no existe). Una lista de pendientes que enumera cosas hechas infla la cola de GOs de Elazar. Auditoria escrita en el propio archivo. Tambien reconciliado ahi el 14-contra-13 de las matvistas: el archivo del incidente restaura 14, hoy hay 13, y la que falta es v_temporadas porque se convirtio en vista normal quince dias despues - las dos cifras correctas en su fecha, verificado por diferencia de conjuntos.