Update: 260118_tareas_tablas.md - hashtags como proceso largo

tareas/260118_tareas_tablas.md

@@ -16,67 +16,45 @@ Crear trigger `validar_set_hst_por_tabla()` que:
 2. Verifique que el `set_hst` está en `hst_permitidos`
 3. Rechace si no está permitido
 
-### Tablas afectadas
-- tzzr_storage.atc
-- tzzr_core_itm_base.itm, loc, ply
-- tzzr_core_produccion.mth
-- tzzr_core_secretaria.secretaria_bck, secretaria_mst
-- tzzr_core_oracle.oracle_mst
-- Y demás tablas con set_hst
-
 ---
 
-## 2. Campo hashtags (ANÁLISIS COMPLETADO - DECISIÓN PENDIENTE)
+## 2. Migración hashtags legacy (PROCESO LARGO)
 
-### Situación actual
+### Situación
-- 15 tablas tienen campo `hashtags` (JSONB)
+- 15 tablas con campo `hashtags` (JSONB)
-- Contienen **texto legible**: `["payment", "cable", "invoice"]`
+- Contienen texto: `["payment", "cable", "invoice"]`
-- **228 tags únicos**, 2,747 usos totales
+- Deberían contener hashes mrf → `hst`
-- Deberían contener **hashes mrf** referenciando `hst`
+- **228 tags únicos**, 2,747 usos
 
-### Problema detectado
+### Problema
-Los tags de texto son ambiguos y no mapean 1:1 a entradas hst:
+Tags ambiguos sin mapeo 1:1:
-- "cable" → 6 entradas hst diferentes (plano, cinta, rígido, link...)
+- "cable" → 6 hst diferentes
-- "compra" → 4 entradas hst diferentes
+- "compra" → 4 hst diferentes
-- "2025" → 3 entradas hst diferentes
 
-**Crear hst automáticamente NO es viable** - contaminaría la tabla curada (1077 entradas) con datos duplicados/ambiguos.
+### Plan de migración
+1. **Crear tabla de mapeo**: `legacy_tag_mapping(tag_texto, mrf_destino, estado)`
+2. **Poblar con tags únicos**: INSERT desde las 15 tablas
+3. **Entrenar agentes**: Para asistir en curación
+4. **Revisión humana**: Resolver ambigüedades
+5. **Aplicar migración**: UPDATE masivo cuando mapeo esté completo
+6. **Validar**: Trigger para nuevos hashtags solo mrf
 
-### Opciones
+### Estado: Pendiente - proceso manual a largo plazo
-| Opción | Pros | Contras |
-|--------|------|---------|
-| **A. Deprecar** | Sin pérdida, backward compatible | Campo legacy permanece |
-| **B. Limpiar** | Limpio, fuerza uso correcto | Pierde datos legacy |
-| **C. Curación manual** | Preserva valor | Costoso en tiempo |
-| **D. Ignorar** | Nada que hacer | Deuda técnica |
-
-### Recomendación
-**Opción A + validación**: 
-1. Mantener hashtags texto como legacy (read-only)
-2. Crear campo `hashtags_mrf` (JSONB) para nuevos tags validados
-3. Trigger que valide que todos los mrf existen en `hst`
-4. Gradualmente migrar cuando sea necesario
 
 ---
 
 ## 3. Sincronización hst_rules
 
-### Tarea
+Verificar sync entre DECK y HST.
-Verificar que `hst_rules` esté sincronizada entre:
-- DECK (tzzr.tzzr_core_hst.hst_rules)
-- HST (pendiente verificar)
 
 ---
 
 ## 4. Campo set_flg
 
-### Situación
+Documentar tablas que lo usan y restricciones.
-- Campo similar a set_hst pero para flags
-- Investigar tablas que lo usan
-- Documentar restricciones necesarias
 
 ---
 
 ## Historial
-- 2026-01-18: Análisis hashtags completado. Migración automática descartada.
+- 2026-01-18: Hashtags identificado como proceso manual largo (mapeo + agentes)
-- 2026-01-18: FK set_hst creadas en 16 tablas (datos inválidos limpiados)
+- 2026-01-18: FK set_hst creadas en 16 tablas