Frank, los **5 items aprobados están ejecutados y verificados** ✅ --- **Resumen de la limpieza:** | Item | Acción | Resultado | |------|--------|-----------| | 1 | Eliminar 8 ICGs cascarón | ✅ 8 eliminados (Hub Innovación, Ángeles del Pacífico, U. Andes, Latam Ventures, Fondo Verde, Grupo Innovación MX, Acelera Latam, TechStars Santiago) | | 2 | Eliminar profiles demo/facturas/dev | ✅ 3 profiles + 2 startups (LegalBot, LPDI PRUEBA 2) + auth.users eliminados | | 3 | Formato TRL/CRL/BRL | ✅ `TRL3`→`TRL 3`, `CRL5`→`CRL 5`, `BRL5`→`BRL 5`, `3`→`TMRL 3` | | 4 | Manuel Ramírez legacy | ✅ Campo legacy limpiado (ya tenía 17 items en p3) | | 5 | Migrar interest_industries | ✅ LPDI ventures: 3 sub-industrias migradas a p3, legacy limpiado | **Estado actual de la BD:** 6 profiles reales, 3 startups, 2 ICGs (Manuel Ramírez + LPDI ventures). Limpia. --- Ahora, tus preguntas pendientes: ### Item 6 — user_type: ¿Qué pasa si tienen varias startups y/o ICGs? Hoy **ningún usuario real tiene múltiples entidades** (el único que tenía 8 ICGs era demo, ya eliminado). Pero para el futuro, hay opciones: - **Opción A — Enum con prioridad:** FOUNDER > INVESTOR > MEMBER. Si tiene startup = FOUNDER, si tiene ICG = INVESTOR, si tiene ambos = FOUNDER (prioridad). Simple pero pierde el dato del doble rol. - **Opción B — Derivarlo en runtime** (recomendada): No popular user_type manualmente. Que el sistema lo derive automáticamente según si el usuario tiene startup, ICG o ambos. Así no se desincroniza si mañana alguien crea un ICG teniendo ya una startup. - **Opción C — Array multi-valor:** Permite `['FOUNDER', 'INVESTOR']`. Más preciso pero complica filtros y UI. ¿Cuál prefieres? ### Item 7 — Industrias duplicadas: Implicaciones detalladas Encontramos **8 pares con solapamiento** entre la taxonomía "tech" y "tradicional": | Tech | Tradicional | Tipo | |------|-------------|------| | Servicios Profesionales | Servicios profesionales | **Duplicado exacto** (solo difiere mayúscula) | | Consumo, Comercio y Logística | Comercio | Parcial | | Energía, Minería y Recursos | Energía | Parcial | | Educación, Gobierno y ONG | Educación / Gobierno | Parcial | | Finanzas y Seguros | Finanzas | Parcial | | Salud y Ciencias de la Vida | Salud | Parcial | | Manufactura e Industria | Industria | Parcial | | Turismo y Estilo de Vida | Turismo | Parcial | **Si consolidamos:** - Hay que migrar FKs en startups, ICGs, sub-industrias, campos JSON, y tablas junction (`startup_industries`, `icg_industries`). Esfuerzo medio, pero el volumen actual es bajo (~5 registros afectados). - Riesgo: decidir cuáles sub-industrias sobreviven y cuáles se mergean. **Si mantenemos separadas:** - No se rompe nada. Pero confunde al usuario en el registro ("¿elijo Finanzas o Finanzas y Seguros?"). - El concepto tech vs. tradicional podría ser útil para matchmaking, pero se resolvería mejor con un campo `category` en la tabla de industrias. **Mi recomendación:** 1. **Ya mismo:** corregir el duplicado exacto de "Servicios profesionales" (es un bug). 2. **A corto plazo:** agregar campo `category` (TECH/TRADITIONAL) a industrias para diferenciar sin duplicar nombres. 3. **No mergear aún** las parciales hasta revisar juntos cuáles son realmente idénticas vs. cuáles cubren cosas distintas. ¿Qué te parece?