EN DESARROLLO ACTIVO CONFIDENCIAL — SOLO PARA LPDI

Reporte PMO — Sistema LPDI

Estado del proyecto, criterios de diseño, reglas globales y guía de desarrollo para el equipo técnico y de producto.

Fecha del reporte

7 de abril de 2026

Para

Frank Prieto Pinto — LPDI S.A.S.

Dev técnico

Roberto Aguirre — dev@lpdi.co

Documentos de referencia activos

Fuentes de verdad del proyecto. Toda implementación debe consultarlos antes de codear.

Código	Documento	Subsistema	Contenido clave	Estado
`B1`	Requerimiento Técnico V.3 16-MAR-2026	Global	Requerimientos funcionales y técnicos del sistema completo	Activo
`B2`	Manual de Usuario V.2 16-MAR-2026	Global	Flujos de usuario, pantallas, navegación	Activo
`C1`	Manual SGC V.3 16-MAR-2026	SGC Contenidos	Taxonomías de industrias (pág 43), categorías, formularios SGC	Activo
`E1v3`	Manual SGR V.3 16-MAR-2026	SGR Relacionamiento	Formularios de registro, paneles, opciones de preguntas	Reemplazado por V.4
`E1v4`	Manual SGR V.4 ⭐ 28-MAR-2026	SGR Relacionamiento	Versión vigente. Cambios sobre V.3, nuevos campos, formulario detallado completo (lín. 328–817)	Versión vigente
—	Actas de decisiones UX 2026-04-04 / 04-05 / 04-06	Global	Reglas globales aprobadas por Frank: formularios, diseño, validaciones, géneros, autosave	Activo
—	Stack Estándar LPDI 2026-03-09	Global	SvelteKit + Supabase + Prisma + Cloudflare. Aprobado por Roberto Aguirre.	Activo
—	Decisiones técnicas 2026-03-16	Global	Integraciones externas: MailRelay confirmado. Pasarela pagos: pendiente.	Parcial
—	Auditoría Formulario Detallado 2026-04-05	SGR	Contraste código vs documento V.4. Hallazgos críticos documentados.	Requiere acción
—	Estado + Bugs Formulario Detallado 2026-04-05	SGR	Inventario de paneles completados y bugs reportados por Frank.	En seguimiento

      Regla de consulta: Al recibir cualquier tarea de implementación o modificación de formularios, el equipo debe consultar el Manual SGR V.4 (E1v4) como fuente de verdad. Si hay discrepancia entre el código y el documento, prevalece el documento salvo decisión explícita de Frank.
    

Stack tecnológico estándar

Aprobado por Roberto Aguirre el 2026-03-09. Aplica a los 3 sistemas.

Frontend

SvelteKit

BaaS / Base de datos

Supabase

ORM

Prisma

Edge / Deploy

Cloudflare

Subsistema	Repositorio GitHub	URL producción	Prioridad	Estado
SGR Relacionamiento	`devlapuntadeliceberg/lpdi-relacionamiento`	`lpdi-relacionamiento.vercel.app`	Prioridad #1	En desarrollo
SGC Contenidos	`devlapuntadeliceberg/lpdi-contenidos`	`lpdi-contenidos.vercel.app`	Prioridad #2	Base lista
Productividad	`devlapuntadeliceberg/lpdi-productividad`	—	Prioridad #3	Pendiente

Infraestructura Supabase

Instancia compartida entre los 3 sistemas. Credenciales en .env de cada proyecto. Base de datos PostgreSQL gestionada.

Integración confirmada — MailRelay

Mail marketing y newsletters via MailRelay. Confirmado por Frank el 2026-03-16. Pasarela de pagos, almacenamiento de archivos e infra de despliegue pendientes de confirmar.

Reglas globales de diseño y formularios

Aprobadas por Frank Prieto. Aplican a TODOS los formularios del sistema sin excepción.

Instrucciones estándar de formularios

R-F1

Redes sociales — Plataformas permitidas

Global

Incluir: LinkedIn, Instagram, Facebook, YouTube, TikTok. Excluir: X (Twitter), GitHub, Sitio web (va en campo separado). Texto del campo: "Agrega las redes sociales (mínimo 1)" — sin mencionar máximo. El sistema normaliza la URL por plataforma; el usuario solo escribe el handle/username.

Red	Input usuario	URL guardada
Instagram	`usuario` o `@usuario`	`https://instagram.com/usuario`
TikTok	`usuario` o `@usuario`	`https://tiktok.com/@usuario`
LinkedIn	`empresa`	`https://linkedin.com/company/empresa`
Facebook	`pagina`	`https://facebook.com/pagina`
YouTube	`canal`	`https://youtube.com/@canal`

R-F2

Validación visual de campos obligatorios

Crítico

Todos los campos obligatorios (*) muestran borde rojo al intentar avanzar sin completarlos. Caja de resumen de errores en la parte superior del panel (fondo rojo/rosado) listando los campos pendientes. Scroll automático al primer campo con error. Aplica igual a inputs nativos, selects y componentes custom. Al corregir el campo, el borde rojo desaparece inmediatamente.

R-F3

Placeholders — Genéricos siempre

Global

Siempre genéricos. Nunca usar nombres reales de empresas o personas como ejemplo. Formato: ej: nombre-de-usuario, ej: empresa, ej: tu@correo.com. No usar "La Punta del Iceberg" ni ningún otro nombre real.

R-F4

Países y regiones — Catálogo ONU

Global

Usar siempre catálogo ONU (UN M49 / ISO 3166-1) — 199 países, 8 regiones. Regiones: Norteamérica, Centroamérica, Caribe, Suramérica, Europa, Asia, África, Oceanía. Sin categoría "Resto del mundo".

R-F5

Géneros — 6 opciones exactas

Global

R-F6

Auto-save en todos los formularios

Global

Auto-save activado en todos los formularios. Guarda progreso al cambiar de campo o panel. Además existe botón "Guardar" manual. Aplica a formulario detallado y todos los formularios futuros.

Reglas de diseño globales (aprobadas 2026-04-06)

R-D1

Orden de elementos por campo

Crítico

Orden estándar para TODOS los campos:
1. Label → 2. Helper text (inmediatamente después del label, ANTES del input) → 3. Input / componente
La clase .field-helper siempre va dentro de .field-group entre el <label> y el componente de entrada.

R-D2

"Deseleccionar todos" en selectores múltiples

Global

El botón "Deseleccionar todos" debe aparecer junto a los chips/tags de elementos seleccionados (debajo del dropdown trigger). Nunca junto al label. Implementado con div.tags-header + justify-content: flex-end. Aplica a: RegionCountryPicker, BusinessNeedsPicker, IndustryPicker y todos los nuevos multi-select.

R-D3

Indicador de campo opcional

Global

Usar Opcional. Sin guiones: ~~-Opcional-~~ ❌ · Sin paréntesis: ~~(opcional)~~ ❌ · Solo: Opcional ✅

R-D4

Preguntas de madurez (BRL, TRL, CRL, TMRL)

Especial

Ícono título: ℹ (no "?") con tooltip de descripción general. Ícono por opción: "?" con tooltip específico en formato subtítulo + descripción (salto de línea via white-space: pre-line). Subtítulo NO visible en la tarjeta (solo en tooltip). Implementado en BRL, TRL, CRL, TMRL ✅.

R-D5

Helper text con pregunta orientadora + texto explicativo

Global

Formato: [Pregunta orientadora] [Texto explicativo]. Ambos formularios (FS y FD) deben tener siempre el mismo helper text completo y con el mismo formato.

R-D6

Asterisco en campos obligatorios

Global

Todos los campos obligatorios llevan * en el label. Clase definida en app.css con color rojo.

R-D7

Consistencia de diseño entre formularios ⭐ NUEVA

Crítico

La misma pregunta debe tener exactamente el mismo diseño en TODOS los formularios (FS, FD, dashboard, y cualquier futuro), salvo que Frank indique lo contrario. Esto aplica a: estilo de input, valores por defecto, label, helper text, placeholder, comportamiento obligatorio/opcional e indicadores visuales. Responsable de verificar: PMO Agent al recibir cualquier tarea de UI.

      Nota sobre formulario ICG: URL definida como /registro/icg (no /registro-icg). Confirmado 2026-04-05.
    

Decisiones técnicas permanentes

Arquitectura, integraciones y decisiones de producto que afectan todo el sistema.

Relación FS → FD (Simplificado → Detallado)

El formulario simplificado es SOLO para el primer registro (onboarding). El formulario detallado es el formulario permanente del sistema. Todo dato del simplificado se arrastra al detallado y es editable. Todo campo del FD es editable a menos que se indique expresamente lo contrario.

Ciudades — Fuente de datos

Usar GeoNames o fuente confiable equivalente. Catálogo asocia ciudades con provincias/regiones/estados/departamentos. Implementar como select dinámico según país seleccionado.

Pitch Deck

Formato: PDF únicamente. Tamaño máximo: 25 MB. Checkbox de autorización de visibilidad para ICG incluido en el formulario.

Scoring "Completar mi 100%"

Al hacer clic navega al panel que tiene campos incompletos. Dentro del panel, el campo específico incompleto se resalta con color de alerta.

Selector multi-rol post-login

Muestra nombre del perfil + resumen de progreso (ej: "tu startup tiene X% completado"). Objetivo: motivar al usuario a completar el formulario. Decisión: 2026-04-05.

KPIs globales del dashboard

Visibles solo para administradores por ahora. Cuando haya suficientes registros se harán públicos (decisión futura a tomar por Frank).

Flujo SSO entre módulos (SGC → SGR)

Se diseñan las pantallas en esta fase para análisis de UX. No se deja para después — incluir en el diseño del flujo de usuario desde ya.

Integración MailRelay

Confirmado por Frank el 2026-03-16 para mail marketing y newsletters. Integración técnica pendiente de implementar.

Pendientes de confirmar: Pasarela de pagos (si aplica) · Proveedor de almacenamiento de archivos/media · Permisos de edición de miembros del equipo (resolver al llegar a Panel 5 Tabla de fundadores) · Emails transaccionales de verificación de equipo.

Estado actual — Formulario detallado

Ruta: /mi-empresa/perfildetallado · Actualizado: 2026-04-05

Panel 1

Identidad legal

Ciudad y año opcionales · Condicional nombre legal corregido (solo si constitución = Sí) · Textos literales del documento · Placeholder: "Registra el nombre de la compañía"

Completado Talla S

Panel 2

Perfil de la compañía

Campos reorganizados desde Panel 3 anterior · BRL 9 niveles con tooltips · TRL 9 niveles condicional a empresa tech (Startup/Scaleup)

Completado Talla M

Panel 3

Modelo de Negocio

High Concept Pitch (140 chars + contador) · ICP, Problema, Solución (250 chars c/u) · CRL 9 niveles · Modelo de negocio (1000 chars + contador) · Necesidades actuales

Completado Talla M

Panel 4 — NUEVO

Tesis de Inversión

Fuentes inversión dilutiva/no dilutiva · Financiamiento de deuda condicional · Ticket de inversión (7 rangos) · Propósito inversión multiselect · Fuentes previas con lógica "Ninguna" exclusiva · Rondas anteriores · Pitch deck PDF + checkbox consentimiento

Revisar con Frank Talla L

Panel 5 — NUEVO

Equipo

5A: TMRL niveles 1-9 con descripciones · 5B: CEO completo (nombre, apellido, género, LinkedIn, email, teléfono, consentimiento) · 5C: checkboxes composición equipo + tabla 5 fundadores + consentimiento

Revisar con Frank Talla L

Panel 6

Presencia digital

Ya estaba implementado. Se respetó el contenido existente.

Completado Talla S

Migración de base de datos

✓Migración 007 ejecutada en Supabase
✓Todos los campos nuevos en schema.prisma y autosave
!Frank debe revisar el formulario en sgr.lpdi.co/mi-empresa/perfildetallado
!Verificar que textos del documento coincidan con lo implementado
!Paneles 4 y 5 son nuevos y requieren validación visual del cliente

Bugs activos y criterios de aceptación

Reportados por Frank el 2026-04-05. Prioridad alta — requieren fix antes de continuar.

#B01

Placeholders y textos de apoyo incorrectos

No se están usando los placeholders, mensajes de apoyo y nombres de paneles tal como aparecen en el Manual SGR V.4. Regla: copiar exactamente del documento, sin interpretación ni parafraseo.

#B02

Preguntas condicionales no respetan activación

Hay preguntas que deben mostrarse solo bajo ciertas condiciones (respuestas previas) y no se activan/desactivan correctamente. Requiere mapeo completo de condicionales del documento.

#B03

Validaciones faltantes en formulario detallado

Ciertos campos no tienen las validaciones que sí se corrigieron en el formulario simplificado. Se deben alinear validaciones entre ambos formularios.

#B04

Campos con visualización/selección inconsistente

Campos que se muestran de manera diferente a como fueron aprobados en el formulario simplificado. El tipo de input (dropdown vs multi-select vs radio) debe ser idéntico en ambos formularios para la misma pregunta.

Criterios de aceptación para cierre de bugs

!Todos los placeholders, labels y textos de apoyo coinciden exactamente con el Manual SGR V.4
!Las preguntas condicionales se activan/desactivan correctamente según las respuestas previas
!Las validaciones del formulario detallado son equivalentes a las del formulario simplificado
!Los campos comparten el mismo tipo de input/selección entre ambos formularios

Acción requerida del Architect: Revisar el Manual SGR V.4 (secciones del formulario detallado, líneas 328–817) y contrastar contra el código actual para generar lista exhaustiva de discrepancias antes de delegar fix al dev.

Criterios de diseño sugeridos

Criterios que se sugiere documentar en la basic-memory basados en las reglas existentes y mejores prácticas de UX para formularios complejos multi-panel.

Navegación

Indicador de progreso persistente en formularios multi-panel

Agregar un stepper visual fijo en la parte superior del formulario que muestre el panel actual vs total de paneles, con indicadores de estado por panel: completado (verde), actual (azul), pendiente (gris), con error (rojo). El stepper debe ser clickeable para saltar a paneles completados, pero no a paneles con errores o paneles futuros bloqueados. Esto reduce la ansiedad del usuario en formularios de 6+ paneles y complementa el scoring "Completar mi 100%".

Feedback visual

Estado de guardado visible y persistente

El auto-save debe comunicarse visualmente al usuario de forma no intrusiva: un indicador "Guardando..." que transiciona a "Guardado hace X segundos" en la esquina superior derecha del formulario. Si el auto-save falla (sin conexión), mostrar aviso claro con instrucción de qué hacer. Nunca dejar al usuario sin saber si su información fue guardada.

Formularios condicionales

Documentar mapa de condicionales antes de implementar

Antes de codear cualquier formulario nuevo, el architect debe producir un diagrama o tabla de todos los campos condicionales: qué campo lo activa, qué valor lo activa, qué campo aparece/desaparece. Este artefacto debe vivir en basic-memory y ser revisado por Frank antes de implementación. El Bug #B02 actual evidencia el costo de no hacerlo.

Accesibilidad

Estándares mínimos de accesibilidad WCAG 2.1 AA

Documentar como regla global: todos los componentes de formulario deben cumplir contraste de color mínimo 4.5:1 para texto normal y 3:1 para texto grande. Todos los campos deben tener aria-label o aria-labelledby correctamente enlazados. Los mensajes de error deben anunciarse con aria-live="polite". Los tooltips de BRL/TRL/CRL/TMRL deben ser navegables por teclado.

Tablas complejas

Patrón para tabla de fundadores (Panel 5C)

La tabla de 5 fundadores × 8 columnas es el componente más complejo del formulario. Sugerimos documentar: comportamiento de validación fila a fila, campos mínimos requeridos por fila para que se considere "válida", qué pasa al agregar menos de 5 fundadores (¿las filas vacías se ignoran?), y si hay lógica de emails de invitación. Documentar en acta antes de implementar.

Mobile / Responsive

Breakpoints y comportamiento móvil de los formularios

Definir y documentar el comportamiento de los formularios en mobile (< 768px): ¿los paneles se convierten en acordeón? ¿El stepper colapsa? ¿Los multi-select tienen bottom sheet en mobile? Los formularios del SGR son extensos y el porcentaje de usuarios móviles en LATAM es alto. Sin definición previa, cada dev implementa diferente.

Pitch Deck

UX para subida de archivos pesados (PDF 25MB)

Definir: barra de progreso durante upload, feedback de error si el archivo supera 25MB antes de intentar subirlo (validación client-side), qué pasa si el upload falla a mitad (¿se puede reintentar?), y si el archivo subido se puede previsualizar o solo descargar. El auto-save no debe intentar guardar si el PDF está en proceso de upload.

Sugerencias para mejorar el proceso de desarrollo

Recomendaciones concretas para los próximos componentes del SGR basadas en patrones identificados.

Proceso

1. Acta de campo antes de codear

Para cada panel nuevo, generar un acta con la lista exhaustiva de campos, tipos de input, validaciones, condicionales y textos exactos del documento. Frank aprueba el acta antes de que el dev escriba una línea. Esto elimina los bugs #B01–#B04 de raíz.

Testing

2. Checklist de QA por panel

Crear un checklist estándar de QA por panel: ¿todos los placeholders coinciden con el doc? ¿Los condicionales funcionan? ¿El auto-save guarda correctamente? ¿La validación muestra el error esperado? El QA lo ejecuta el dev antes de marcar el panel como listo.

Componentes

3. Biblioteca de componentes compartidos LPDI

Crear una librería interna de componentes Svelte que apliquen automáticamente las reglas R-D1 a R-D7: FieldGroup, MultiSelectPicker, MaturitySelector, CountryPicker. Así las reglas se heredan por defecto y no dependen de que cada dev las recuerde.

Revisiones

4. Sesiones de revisión por secciones, no por formulario completo

En lugar de esperar a que el formulario completo esté listo para revisión de Frank, hacer revisiones panel a panel. Esto permite detectar desviaciones del documento antes de que se propaguen a los paneles siguientes. Reduce el retrabajo y el número de bugs acumulados.

Documentación

5. Registro de decisiones técnicas por sesión

Cada sesión con Frank que produzca una decisión técnica o de diseño debe generar un acta en basic-memory ese mismo día, con el formato: Decisión · Contexto · Quién decidió · Cuándo. Las decisiones verbales no documentadas se olvidan o se interpretan diferente.

Consistencia

6. Audit automático de consistencia entre formularios

Implementar un script o test que compare el mismo campo (por nombre/ID) en FS, FD y dashboard/nuevo para verificar que tienen el mismo tipo de input, validaciones y textos. Ejecutarlo como paso de CI antes de cada merge a main. Detecta el bug #B04 automáticamente.

Base de datos

7. Versionado de migraciones con naming consistente

Documentar la convención de naming para migraciones de Prisma (actualmente van por número: 001, 002, ..., 007). Agregar descripción en el nombre de la migración (ej: 007_panel4_panel5_campos). Facilita el rollback y la comunicación entre devs.

Escalabilidad

8. Definir estrategia para formulario ICG antes de empezar

El formulario ICG reutilizará muchos campos del SGR (países, géneros, industrias, redes sociales) y debe aplicar las mismas reglas globales. Antes de iniciar su desarrollo, mapear qué componentes se reusan y cuáles son específicos de ICG para evitar duplicación de código y garantizar consistencia.

      Estado del proyecto al 2026-04-07: SGR Relacionamiento en desarrollo activo. Formulario detallado 6 paneles implementados — pendiente revisión de Frank en sgr.lpdi.co/mi-empresa/perfildetallado. 4 bugs activos de alta prioridad. Reglas globales de diseño estabilizadas (7 reglas aprobadas por Frank). Stack técnico definido y operativo.
    