Ahora tengo contexto completo: documentos fuente + decisiones tomadas + estado del proyecto. Aquí va el análisis actualizado e integrado: --- # 📊 ANÁLISIS ESTRUCTURADO — SISTEMA LPDI (Actualizado 04-ABR-2026) ## 1. RESUMEN EJECUTIVO LPDI es una plataforma de ecosistema de emprendimiento e innovación para Latam, con **3 subsistemas**: Usuarios, SGC (Contenidos) y SGR (Relacionamiento). Stack: **SvelteKit + Supabase + Prisma + Cloudflare**. Mail marketing: **MailRelay** (confirmado). El proyecto se ejecuta en **3 fases** (decisión Roberto 24-MAR): Fase 1 Core SGR → Fase 2 SGR Avanzado → Fase 3 SGC. Hay **~40% de gaps en diseño/spec** reconocidos. El documento nuevo (XLSX países) **no pudo extraerse** — el archivo en disco es un placeholder de 114 bytes, no un XLSX real. ### ⚠️ Inconsistencia detectada: El análisis de arquitectura original (MAR-2026) estimó 221-246 días-persona. Con 1 dev = 11-12 meses. No hay segundo dev confirmado. --- ## 2. MÓDULOS/FEATURES CON TALLAJE ### A. SISTEMA DE USUARIOS (Transversal) | # | Feature | Tallaje | Estado | |---|---------|---------|--------| | A1 | Auth: email+pwd, Google OAuth, Teams OAuth, magic link | **M** | Fase 1 (simplificado), Fase 2 (completo) | | A2 | Registro simplificado (email, nombre, país, rol, pwd) | **S** | Fase 1 | | A3 | Registro detallado (4 paneles: datos, ecosistema, contacto, RRSS) | **M** | Fase 2 — ⛔ sin diseño visual | | A4 | Multi-perfil no excluyente + gestión privilegios | **M** | Fase 2 | | A5 | Creación masiva usuarios (xlsx/csv) | **S** | Fase 2 | | A6 | Código QR único auto-generado | **S** | Fase 2 | | A7 | Notificaciones email usuarios (5 tipos, templates Figma) | **S** | Fase 1-2 | | A8 | Sincronización bidireccional campos § (perfil↔networking↔matchmaking) | **L** | Fase 2 — ⛔ lógica de conflictos no definida | ### B. SGC — GESTIÓN DE CONTENIDOS (Fase 3) | # | Feature | Tallaje | Estado diseño | |---|---------|---------|---------------| | B1 | Formulario dinámico Eventos (4 paneles, Google Maps, speakers, super eventos) | **L** | ✅ Diseño completo | | B2 | Formulario dinámico Convocatorias | **L** | ✅ Diseño completo | | B3 | Formulario dinámico Noticias | **M** | ⚠️ UX pendiente | | B4 | Motor formularios dinámicos (add/edit/reorder/delete campos runtime) | **L** | Solo spec textual | | B5 | Modal consulta eventos (embebible, marca blanca, filtros) | **M** | ✅ Diseño completo | | B6 | Modal consulta convocatorias | **M** | ⚠️ UX pendiente | | B7 | Modal consulta noticias | **M** | ⚠️ UX pendiente | | B8 | Admin contenidos (workflow curaduría, trazabilidad, papelera 30d) | **M** | Parcial | | B9 | Newsletter genérico ×2 (E&C + N&I) + integración MailRelay | **M** | ✅ Diseño completo | | B10 | Newsletter personalizado (motor matching preferencias×BD) | **L** | Spec completa, sin diseño UX | | B11 | Formulario personalización newsletter | **M** | Spec completa | | B12 | Admin fuentes información (3 directorios) | **S** | Solo spec | | B13 | Dashboard SGC (métricas, cruces, gráficas temporales) | **L** | Sin diseño | | B14 | Mapa interactivo contenidos (Mapbox/Leaflet, clusters, timeline, fly-to) | **L** | ⛔ Decisión Mapbox/Leaflet abierta | | B15 | Panel control SGC (permisos especiales auto-aprobación, descargas) | **M** | Parcial | | B16 | Creación/admin Super Eventos | **S** | Spec completa | | B17 | Notificaciones email SGC (~7 tipos) | **S** | ✅ Templates Figma | ### C. SGR — GESTIÓN DE RELACIONAMIENTO (Fases 1-2) | # | Feature | Tallaje | Fase | Estado diseño | |---|---------|---------|------|---------------| | C1 | Formulario simplificado startups/PyMEs (V4: campo base tecnológica movido aquí) | **M** | 1 | ⛔ Sin diseño visual | | C2 | Formulario detallado startups (6 paneles, BRL/TRL/CRL, equipo, score completitud) | **L** | 1 | ⛔ Sin diseño visual | | C3 | Formulario registro ICG (6 paneles, tesis inversión, tickets, necesidades estratégicas) | **L** | 1 | ⛔ Sin diseño visual | | C4 | Modal consulta startups (embebible, marca blanca) | **M** | 1 | Parcial | | C5 | Modal información detallada startup | **M** | 1 | Solo spec | | C6 | Modal consulta ICG | **M** | 1 | Parcial | | C7 | Modal información detallada ICG | **M** | 1 | Solo spec | | C8 | Admin startups + ICG (aprobación, verificación equipos, privacidad) | **M** | 1 | Solo spec | | C9 | Dashboard SGR (KPIs básicos) | **M** | 1 | Sin diseño | | C10 | Networking: perfil, mis eventos, conexiones, escaneo QR | **L** | 2 | ✅ 26 páginas diseño completo | | C11 | Motor Match Score (5 dims Startup×ICG, 4 dims ICG×ICG, 3 dims S×S + deal-breaker) | **L** | 2 | Spec completa, ⛔ sin diseño matchmaking | | C12 | Panel deal flow (radar, solicitudes, matches, favoritos, descartados 30d) | **L** | 2 | ⛔ Sin diseño | | C13 | Inmail LPDI (mensajería directa con estados) | **L** | 2 | ⛔ Requiere Supabase Realtime (plan Pro) | | C14 | Botones Conversar (Chat + WhatsApp + LinkedIn + Email) | **M** | 2 | Spec completa | | C15 | Newsletter "Smart Match" quincenal | **M** | 2 | Solo spec | | C16 | Dashboard inteligencia ecosistema (métricas avanzadas, acceso ICG) | **L** | 2 | Sin diseño | | C17 | Mapa interactivo ecosistema (pines actores, BRL/TRL sizing, clusters) | **L** | 2 | ⛔ Decisión Mapbox/Leaflet abierta | | C18 | Panel control SGR + admin matchmaking | **M** | 1-2 | Solo spec | | C19 | Notificaciones email SGR | **S** | 1-2 | Sin templates | ### D. CATÁLOGO TRANSVERSAL | # | Feature | Tallaje | Notas | |---|---------|---------|-------| | D1 | Catálogo maestro países/regiones/ciudades | **M** | ⛔ XLSX no legible. ~20 formularios dependen de esto | | D2 | Taxonomía unificada (~40 roles, ~100 subindustrias, industrias tech vs tradicionales) | **M** | ⛔ Decisión abierta: seed data administrable vs hardcode | | D3 | Tabla sinergias industriales (para match Startup×Startup) | **M** | ⛔ No existe — necesaria para C11 | --- ## 3. DEPENDENCIAS ENTRE MÓDULOS (Diagrama de flujo) ``` D1 (Países) + D2 (Taxonomías) ─────────────────────┐ ↓ Catálogos transversales │ ▼ A1-A2 (Auth simplificado) ──→ C1 (Form. Startups) ──→ C4-C5 (Modales) │ ──→ C3 (Form. ICG) ──→ C6-C7 (Modales) │ ──→ C8 (Admin) ──→ C9 (Dashboard) │ ──────────────────────────── Fase 1 │ ├──→ A3-A4 (Reg. detallado + multi-perfil) │ ↕ sync § ├──→ C10 (Networking) ←← depende de Eventos SGC (B1) │ │ ├──→ C11 (Match Score) ←← depende de C1, C2, C3 completos + D3 │ ↓ ├──→ C12 (Deal flow) ←← depende de C11 │ ↓ └──→ C13 (Inmail) ←← depende de Supabase Realtime Pro ──── Fase 2 B1-B2 (Forms E&C) ──→ B5-B6 (Modales) ──→ B14 (Mapa) B9-B11 (Newsletters) ──→ MailRelay API B4 (Motor dinámico) ──→ Todos los formularios ──── Fase 3 ``` **Cadena crítica Fase 1:** D1 + D2 → A1-A2 → C1 → C2 → C3 → C4-C8 → C9 **Cadena crítica Fase 2:** C10 depende de diseño existente ✅ | C11-C12-C13 dependen de diseño pendiente ⛔ --- ## 4. RIESGOS | # | Riesgo | Severidad | Mitigación sugerida | |---|--------|-----------|---------------------| | 🔴 R1 | **Matchmaking sin diseño UX**: Es el feature más valioso del sistema y no tiene diseño visual. Networking sí (26 pgs). | **ALTA** | Escalar a Frank. Definir wireframes antes de Fase 2 | | 🔴 R2 | **Capacidad vs ambición**: 221-246 días-persona con 1 dev = 11-12 meses. No hay 2do dev confirmado | **ALTA** | Decisión Roberto: ¿contratar 2do dev? | | 🔴 R3 | **Motor formularios dinámicos = producto dentro del producto**: Agregar/editar/reordenar campos en runtime es un form-builder completo (B4). Si no se acota, consume más que los formularios mismos | **ALTA** | Definir: ¿admin configurable en v1 o solo código? | | 🟡 R4 | **Catálogo países bloqueado**: XLSX no legible, usado en 20+ formularios. Sin estructura confirmada de regiones→países→estados→ciudades | **MEDIA** | Roberto debe reenviar archivo en formato legible | | 🟡 R5 | **Algoritmo Match Score sin datos de prueba**: 5 dimensiones con pesos y deal-breakers. Sin dataset para calibrar umbrales (60/80/95%) | **MEDIA** | ¿Hay BD con datos reales o solo mockups? (decisión #7 abierta) | | 🟡 R6 | **Supabase plan Pro requerido para Inmail**: WebSockets (Realtime) requiere plan Pro. Costo no presupuestado | **MEDIA** | Validar con Roberto presupuesto infra | | 🟡 R7 | **Cambios V3→V4 del SGR**: Campo "base tecnológica" movido al simplificado; lógica industrias bifurcada (tech vs PyME). Impacta modelo datos ya diseñado en V3 | **MEDIA** | Actualizar modelo Prisma del SGR | | 🟢 R8 | **UX pendiente en ~6 módulos**: Modales noticias, convocatorias, dashboard SGC/SGR, mapas | **BAJA** | No bloquean Fase 1 | --- ## 5. DECISIONES PENDIENTES ### Cerradas ✅ | # | Decisión | Respuesta | Quién | Fecha | |---|----------|-----------|-------|-------| | ✅ | Mail marketing | **MailRelay** | Frank | 16-MAR | | ✅ | Networking/Matchmaking specs | En E1 Manual SGR V.3 | Roberto | 16-MAR | | ✅ | Orden de desarrollo | SGR primero → SGC después | Roberto | 24-MAR | | ✅ | Newsletter personalización | SGC en C1 V.3, SGR en E1 V.3 | Frank | 16-MAR | ### Abiertas ⛔ | # | Decisión | Quién decide | Bloquea | Criticidad | |---|----------|-------------|---------|------------| | ⛔1 | **Mapbox vs Leaflet** | Roberto | Mapas interactivos (B14, C17) | Fase 2 | | ⛔2 | **Google Maps API vs OpenStreetMap** para ubicación eventos | Roberto | Formulario eventos (B1) | Fase 3 | | ⛔3 | **¿Mapas en MVP/Fase 1 o Fase 2?** | Frank | Tamaño de Fase 1 | Fase 1-2 | | ⛔4 | **Taxonomías: administrables o hardcode en v1?** | Frank + Roberto | Arquitectura datos | **Fase 1** 🔴 | | ⛔5 | **¿Hay datos reales en BD o solo mockups?** | Roberto | Migración, testing Match Score | **Fase 1** 🔴 | | ⛔6 | **Contenido XLSX de países** | Roberto | Catálogo maestro, 20+ formularios | **Fase 1** 🔴 | | ⛔7 | **Tabla sinergias industriales** (para match S×S) | Frank | Motor matchmaking C11 | Fase 2 | | ⛔8 | **Google Calendar + Outlook OAuth** para matchmaking | Roberto | Agenda matchmaking | Fase 2 | | ⛔9 | **Supabase plan Pro** (WebSockets para Inmail) | Roberto | Chat Inmail (C13) | Fase 2 | | ⛔10 | **Diseño UX matchmaking** | Frank | Panel deal flow (C12) | **Fase 2** 🔴 | | ⛔11 | **Diseño UX formularios SGR** (startups, ICG, usuario 4 paneles) | Frank | Desarrollo frontend Fase 1 | **Fase 1** 🔴 | | ⛔12 | **¿Contratar segundo dev?** | Frank | Timeline total del proyecto | **Global** 🔴 | | ⛔13 | **Regla de conflicto sync §** (¿cuál dato prevalece?) | Frank | Sincronización bidireccional | Fase 2 | --- ## 6. VISTA CONSOLIDADA ### Distribución de Tallaje | Tallaje | Cantidad | % | |---------|----------|---| | **S** | 7 | 16% | | **M** | 21 | 49% | | **L** | 15 | 35% | | **TOTAL** | **43 módulos** | 100% | **Por fase:** - **Fase 1 (Core SGR):** 12 módulos (2S, 7M, 3L) - **Fase 2 (SGR Avanzado):** 14 módulos (1S, 5M, 8L) ← mayor concentración de L - **Fase 3 (SGC):** 14 módulos (3S, 7M, 4L) - **Transversal:** 3 módulos (0S, 3M, 0L) ### 🔝 Top 3 Riesgos 1. **🔴 Capacidad vs ambición**: 221-246 días-persona, 1 dev, sin 2do confirmado. Con agentes IA el throughput sube, pero las decisiones de negocio (gaps de diseño, taxonomías) siguen siendo bloqueantes humanos. 2. **🔴 Matchmaking sin diseño UX**: Feature estrella del producto sin wireframes. Networking tiene 26 páginas de diseño; matchmaking tiene 0. Es Fase 2 pero su definición debe empezar YA para no bloquear. 3. **🔴 Motor formularios dinámicos**: Si se construye como form-builder configurable en runtime (como lo pide la spec), es un producto en sí mismo — tallaje L++. Si se acota a formularios fijos con cambios solo en código, baja a M. ### 🚨 Decisiones Críticas Bloqueantes para Arrancar | Prioridad | Decisión | Quién | Impacto | |-----------|----------|-------|---------| | 🔴 P1 | **XLSX países en formato legible** | Roberto → enviar | Catálogo maestro → 20+ formularios | | 🔴 P2 | **Taxonomías administrables o hardcode** | Frank + Roberto | Modelo de datos Fase 1 | | 🔴 P3 | **Diseños UX formularios SGR** (startups/ICG) | Frank | Frontend Fase 1 | | 🔴 P4 | **¿Motor formularios dinámico o estático?** | Frank + Roberto | Scope y timeline global | | 🟡 P5 | **¿Datos reales para testing?** | Roberto | Validación Match Score |