# Análisis de documentos — Sistema LPDI --- ## Doc 1: DESIGN V.1 (09-JUN-2026) — NUEVO ### Resumen ejecutivo Documento **descriptivo** (no prescriptivo) generado por ingeniería inversa del código en producción (eco.lpdi.co). Establece la fuente única de verdad de diseño: tokens de color (acento azul `#006eff`, dark mode), tipografía (Space Grotesk + Outfit), componentes canónicos, anatomía de formularios (680px + stepper + score gamificado), validaciones y voz/copy. Incluye "Regla Cero": prohibido refactorizar lo existente usando este doc como justificación. ### Módulos/features identificados | Feature | Tallaje | Nota | |---|---|---| | Adopción de DESIGN.md como gate en código nuevo (checklist §12) | **S** | Proceso, no código | | Corrección de CLAUDE.md desactualizado (sección "Diseño visual" dark slate→green) | **S** | El propio doc lo marca obsoleto | | Deuda legacy señalada: emoji 🙈/👁 en signup → SVG | **S** | Solo si el cliente lo pide (Regla Cero) | | Mantenimiento continuo (DESIGN.md actualizado en el mismo commit del cambio visual) | **S** | Regla operativa recurrente | ### Dependencias - Es **prerrequisito transversal** para todo desarrollo UI nuevo de SGC/SGR/SGE (B1 y C1). - `scoreColor.ts`, `entity-types.ts` e `investment-categories.ts` como SSOT — consistente con reglas ya vigentes del repo. ### Riesgos - ⚠️ Conflicto DESIGN.md vs CLAUDE.md del repo: hasta que se edite CLAUDE.md, agentes podrían seguir la sección obsoleta. Acción: actualizar CLAUDE.md para referenciar DESIGN.md. - Riesgo de "refactor creep": un ejecutor que tome el doc como orden de alineación violaría la Regla Cero (riesgo de regresiones en código aprobado por Frank). ### Decisiones pendientes - ¿Se autoriza limpiar la sección obsoleta de CLAUDE.md ya? (definición interna — tallaje S). - ¿La deuda legacy (emoji signup) se corrige o se deja? (input cliente). --- ## Doc 2: C1 Manual SGC V.5 (08-JUN-2026) ### Resumen ejecutivo Especificación funcional completa del Subsistema de Gestión de Contenidos: 3 formularios dinámicos (Eventos 4 paneles, Convocatorias 5 paneles, Noticias 3 paneles) con definición campo-a-campo (advertencia/placeholder/tipo/obligatoriedad/opciones/observaciones), 3 modales de consulta pública, 3 directorios de fuentes (organizadores/convocantes/medios con paneles de "calidad"), Super Eventos, 2 formularios de newsletter genérico, y formulario de personalización de newsletters con creación implícita de cuentas de usuario (campos §/ß). ### Módulos/features con tallaje | Módulo | Tallaje | Justificación | |---|---|---| | Formulario dinámico Eventos (4 paneles, lógica condicional modalidad/país, código único) | **L** | ~30+ campos, condicionales, validaciones URL/fecha | | Formulario dinámico Convocatorias (5 paneles, requisitos + condiciones de programa) | **L** | El más extenso (l.742-1176), industrias jerárquicas | | Formulario dinámico Noticias (3 paneles) | **M** | Más corto, asociado a directorio de medios | | Modal consulta pública Eventos (filtros + ficha) | **M** | Filtros por modalidad/temática/superevento | | Modal consulta pública Convocatorias | **M** | Análogo | | Modal consulta pública Noticias | **M** | Análogo | | Directorio Organizadores de Eventos (2 paneles, scoring de calidad) | **M** | Admin interno + calidad | | Directorio Convocantes (2 paneles) | **M** | Análogo | | Directorio Medios de Comunicación (2 paneles) | **M** | Análogo | | Creación de Super Evento (panel de control, mnemotecnia, recategorización) | **S** | Form interno acotado + campo select en form eventos | | Newsletter genérico Eventos/Convocatorias (4 secciones, guardados/enviados, scheduling) | **L** | Curación manual + integración mail marketing + estados | | Newsletter genérico Noticias/Insights (4 secciones) | **M** | Reusa el patrón del anterior | | Personalización de newsletters (matching automático + auto-creación de cuenta §/ß + relleno por afinidad) | **L** | Cruce preferencias×contenidos, fallback "más afines", sincronización con perfil de usuario | ### Dependencias - Personalización de newsletter **depende del sistema de usuarios** (B1): campos § crean/actualizan cuenta — acoplamiento fuerte SGC↔Usuarios. - Opciones de campos referencian otros formularios como SSOT ("usar opciones del campo X del formulario Y") → exige catálogos compartidos (países, roles, temáticas, industrias) — mismo patrón SSOT ya aplicado en LPDI. - Newsletters dependen de integración con sistema de mail marketing externo (conexión previa, B1 lo confirma). - Formulario de eventos depende de Super Eventos (campo select) y del directorio de organizadores. - Toda UI nueva debe cumplir DESIGN V.1. ### Riesgos - ⚠️ Algoritmo de "contenidos más afines" para rellenar newsletters personalizados **no está especificado** (¿similitud por temática? ¿geográfica? ¿ranking?). - Auto-creación de cuentas desde el form de newsletter abre superficie de cuentas fantasma/duplicados — requiere reuso del check-email existente. - Validaciones de mínimos (3 regiones, 5 temáticas, 2 regiones, 3 industrias) son inconsistentes entre categorías — correcto según doc, pero fácil de implementar mal; congelar en tests. - Inconsistencia menor: secciones de noticias en el form (l.51-58: "Inversión y Venture Capital", "Economía, Finanzas y Geopolítica") vs temáticas de personalización (l.2110+: "Finanzas e Inversión", "Economía y Geopolítica") — **los catálogos no coinciden 1:1**; el cruce automático de preferencias fallaría. ### Decisiones pendientes - Sistema de mail marketing destino y modo de integración (API/SMTP) para genéricos y si personalizados usan otro (B1 lo deja abierto). - Especificación del algoritmo de afinidad (definición interna). - Resolver el mismatch de catálogos de temáticas de noticias (input cliente). - UX de modal de noticias y form de noticias "pendiente" según B1 — ¿ya quedó definida en V.5 o sigue abierta? --- ## Doc 3: B1 Requerimiento Técnico V.4 (12-ABR-2026) — cruce ### Resumen ejecutivo Requerimiento macro: Sistema de Usuarios central (multi-perfil, OAuth Google/Teams, magic code, creación/descarga masiva), rediseño del Dashboard (menú lateral completo SGR/SGC/SGE, tabs Relacionamiento/Contenidos/Eventos), notificaciones por correo (Figma estándar), SGC (cubierto en C1) y SGR (formularios FS/FD/FI ya en producción, modales, networking, matchmaking, panel de control) más **2 mapas interactivos** (contenidos + inteligencia del ecosistema). ### Módulos clave con tallaje (los no cubiertos por estado actual del repo) | Módulo | Tallaje | |---|---| | Sistema de usuarios completo (OAuth Teams, magic code, favoritos, creación masiva, export) | **L** | | Rediseño Dashboard según anotaciones (menú gestión + tabs + cards "Próximamente") | **M** | | Notificaciones por correo (gestión usuarios + contenidos + newsletters, Figma estándar) | **M** | | Admin de contenidos (trazabilidad, aprobación, papelera 30 días, permisos especiales auto-aprobación) | **L** | | Admin startups/ICG (trazabilidad, verificación equipos, privacidad campos "exclusivos ICG") | **M** | | Dashboard SGC (métricas + cruces de variables + acceso selectivo) | **M** | | Dashboard Inteligencia SGR (métricas con permisos por ICG) | **M** | | Mapa Interactivo de Contenidos (Mapbox/Leaflet, timeline, clusters, tooltips) | **L** | | Mapa Interactivo de Inteligencia (pines por actor, tamaño BRL/TRL, capas con login-gate) | **L** | | Networking / Matchmaking (referidos a manual SGR, no en estos docs) | **L** ⚠️ tallaje supuesto sin spec | | Modales marca blanca (white-label branding) | **M** | ### Inconsistencias detectadas entre documentos 1. **Catálogos de temáticas noticias** (form vs personalización) — ver arriba. 2. B1 dice "UX de noticias pendiente"; C1 V.5 ya la especifica a nivel campos — B1 V.4 quedó parcialmente superado, conviene marcar B1 como dependiente de C1 para SGC. 3. B1 referencia "perfil de networking/matchmaking distinto al perfil general y al de startup/ICG" — ese formulario no aparece en ninguno de los dos docs (gap de spec). 4. DESIGN exige "Próximamente" honesto y voz «tú» — el dashboard del B1 lo cumple; sin conflicto, pero el rediseño del dashboard B1 debe ejecutarse bajo Regla Cero (cambios solo donde B1 lo pide explícitamente). --- ## Vista consolidada ### Distribución de tallaje (24 módulos) - **S: 5** (gobernanza DESIGN.md, CLAUDE.md fix, deuda emoji, Super Eventos, mantenimiento doc) - **M: 12** (modales ×3, directorios ×3, newsletter noticias, dashboards ×2, dashboard rediseño, notificaciones, admin SGR, white-label) - **L: 8** (forms eventos/convocatorias, newsletter genérico E/C, personalización newsletter, sistema usuarios, admin contenidos, mapas ×2, networking/matchmaking) ### Top 3 riesgos 1. **Mismatch de catálogos de temáticas** entre formulario de noticias y personalización de newsletter → el matching automático (corazón del newsletter personalizado) produciría cruces vacíos o erróneos. Bloquea el módulo L más complejo. 2. **Algoritmo de afinidad sin especificar** para rellenar newsletters cuando no hay suficiente contenido — sin definición, el feature es inimplementable sin ⚠️ supuestos. 3. **Acoplamiento newsletter↔usuarios (campos §/ß)**: auto-creación/actualización de cuentas desde un form público es vector de duplicados y de inconsistencia de perfil; requiere diseño de identidad cuidadoso antes de tocar código. ### Decisiones críticas bloqueantes (input cliente/equipo interno) 1. **Sistema de mail marketing**: cuál es, cómo se integra, y si genéricos y personalizados comparten plataforma — bloquea los 3 módulos de newsletter. 2. **Resolución del catálogo único de temáticas de noticias** (y confirmación de catálogos compartidos como SSOT en código, patrón `investment-categories.ts`) — bloquea personalización. 3. **Spec de networking/matchmaking** ("Manual Subsistema Relacionamiento" referenciado pero no entregado) y del **perfil de networking** distinto al general — bloquea 2 módulos L. 4. Menor pero inmediata: autorización para actualizar CLAUDE.md del repo y eliminar la sección de diseño obsoleta, evitando que agentes apliquen el tema verde extinto. ⚠️ Supuestos: networking/matchmaking tallados L sin spec disponible; los mapas asumen Mapbox/Leaflet sin decisión de licencia tomada (Mapbox tiene costo por carga — decisión pendiente adicional).