Sistema LPDI — Reporte PMO

● SGR activo 7 ABR 2026
Documentos activos
9
V.5 SGR pendiente de guardar
Reglas de diseño
11
Globales, todos los formularios
Módulos SGR
4 / 8
4 activos, 4 pendientes
Bug crítico
1
Ciudad no persiste en FD
🐛 Bug ciudad — causa raíz

El campo city en el modelo Prisma es String (NOT NULL), pero el autosave intenta guardar null cuando el campo está vacío → Prisma rechaza silenciosamente.

→ Pestaña "Bug: Campo Ciudad" para diagnóstico completo
📂 Manual SGR V.5 no guardado

Frank adjuntó el V.5 hoy en Slack. El bot PMO se cayó por buffer overflow antes de procesarlo. El último documento vigente es el V.4 (28-MAR-2026).

→ Pestaña "Manual SGR V.5" para instrucciones
📋 Actividad reciente — sesión 2026-04-05 / 06
Apr 06 14:29 regla 7 reglas de diseño globales consolidadas en un solo documento
Apr 05 23:58 fix 25 correcciones al Formulario Detallado (23 reportadas por Frank)
Apr 05 21:05 arq Arquitectura catálogo de ciudades documentada (dr5hn, JSON estático, 19 países LATAM)
Apr 05 16:53 decisión Flujo multi-rol definido: Opción B — 1 usuario, múltiples perfiles/roles
Apr 06 01:23 deploy Panel 1 FS — subpaneles A (Perfil compañía) y B (Registro usuario) desplegados
01

Diagnóstico: Campo Ciudad en el FD

⚠ Causa raíz identificada

El campo ciudad no persiste en el Formulario Detallado (/mi-empresa/perfildetallado) porque existe un conflicto de nullabilidad entre el schema de Prisma y la lógica del autosave.

Schema Prisma (schema.prisma)
model Startup { // ... country String ← required, NOT NULL city String ← required, NOT NULL ❌ // ... }

El FD trata ciudad como Opcional, pero la BD no acepta valores nulos.

Autosave (+page.server.ts)
const city = fd.get('city'); if (city !== null) { patch['city'] = (city as string) .trim() || null; ← ❌ null cuando vacío }

Si el campo está vacío, .trim() || null → intenta escribir null → Prisma lanza error → el update falla silenciosamente.

Flujo completo del bug
📝
Usuario escribe ciudad
FD campo opcional
Autosave se dispara
city = "" → null
💥
Prisma rechaza
NULL en campo NOT NULL
🔇
Falla silenciosa
autoSaveStatus = 'error', sin feedback
🔄
Ciudad sigue vacía
Startup tiene city = ""
Vías de solución
Opción Descripción Requiere migración Impacto
B En autosave cambiar || null|| '' para vacío. Sin migración. No Funcional pero inconsistente semánticamente
C Implementar catálogo completo dr5hn/countries-states-cities-database con CityPicker dropdown (ya planificado en arquitectura) M — sprint siguiente Sprint 2
Fix inmediato — Opción A (3 pasos)
// 1. schema.prisma — cambiar ciudad a nullable model Startup { city String? ← agregar "?" } // 2. Migración Supabase (SQL directo) ALTER TABLE "Startup" ALTER COLUMN city DROP NOT NULL; // 3. Regenerar cliente Prisma npx prisma generate

El autosave ya maneja correctamente el caso null — no requiere cambios en el frontend ni en la action del server.

02

Contenido Basic Memory — LPDI

Documentos fuente disponibles
Documento Versión Fecha Estado
B1. Requerimiento Técnico Sistema LPDI V.3 16-MAR-2026 ✓ Disponible
B2. Manual de Usuario Sistema LPDI V.2 16-MAR-2026 ✓ Disponible
C1. Manual SGC LPDI V.4 01-ABR-2026 ✓ Disponible
E1. Manual SGR LPDI V.4 28-MAR-2026 ✓ Disponible (último activo)
E1. Manual SGR LPDI V.5 06-ABR-2026 ✗ No guardado
Brandbook LPDI 2025 2025 ✓ Disponible
Listado de Países Sistema LPDI V.1 04-ABR-2026 ✓ Disponible
11 Reglas de diseño globales (activas en todos los formularios)
01
Orden de campo: Label → Helper text → Input. Nunca input antes del mensaje de apoyo.
Activa desde 2026-04-06
02
"Deseleccionar todos" junto a los chips seleccionados, nunca junto al label de la pregunta.
Activa desde 2026-04-06
03
Campo opcional: <span class="optional-tag">Opcional</span> — sin guiones, sin paréntesis.
Activa desde 2026-04-06
04
Madurez (BRL/TRL/CRL/TMRL): ℹ en título, ? por opción individual, sin subtítulo visible en la tarjeta.
Activa desde 2026-04-06
05
Helper text: subtítulo orientador en <strong> + texto explicativo en la misma etiqueta p.field-helper.
Activa desde 2026-04-06
06
Campo obligatorio: <span class="required-asterisk">*</span> en rojo. Nunca asterisco directo en el texto.
Activa desde 2026-04-06
07
Consistencia: la misma pregunta debe tener exactamente el mismo diseño en FS, FD y cualquier formulario futuro.
Activa desde 2026-04-06
08
Géneros: Masculino / Femenino / No binario / Trans / Otro / Prefiero no decir. En este orden, sin variantes.
Activa desde 2026-04-06
09
LinkedIn: label "Perfil de LinkedIn", placeholder https://linkedin.com/in/usuario, validar URL con regex.
Activa desde 2026-04-06
10
Filas de personas: si hay 1 campo lleno en la fila, todos los demás de esa fila se vuelven obligatorios.
Activa desde 2026-04-06
11
Redes sociales: solo LinkedIn, Instagram, Facebook, YouTube, TikTok. Excluir X (Twitter) y GitHub.
Activa desde 2026-04-04
REQ-D004 pendiente: Gráfica de facturación debe incluir línea de tendencia y etiquetas en K (ej: "25 a 50 K") sobre cada barra.
Sin implementar
Sugerencias para agregar a basic-memory
🔁

Validación cross-formulario

Cuando un registro tiene datos en el FS, cargarlos como defaults en el FD. Evita que el usuario repita información que ya dio. Definir regla explícita de qué campos se pre-cargan.

📊

Estado de completitud por panel

Indicador % por panel visible en el stepper (actualmente el progreso se guarda en detailed_panel1_complete etc. pero no se muestra visualmente al usuario). Documentar estándar de display.

🛡️

Centralizar validaciones en un helper compartido

FS y FD duplican la misma lógica de validación. Un validators.ts centralizado evitaría el patrón "corregir en FS → replicar manualmente en FD". Evita bugs como el actual con ciudad.

03

Estado de Módulos SGR

Módulos activos en producción
FS — Formulario Simplificado
/registro-startup
✓ Aprobado
Aprobado por Frank. 3 paneles. Subpaneles A/B en Panel 1.
FD — Formulario Detallado
/mi-empresa/perfildetallado
Review V.5
7 paneles implementados. Pendiente validar contra Manual V.5. Bug ciudad activo.
Dashboard startup
/mi-empresa
✓ Activo
KPIs, acceso a FS y FD, autosave status.
Auth / Login
/login
✓ Activo
Login único para todo el ecosistema LPDI.
Módulos pendientes
Formulario ICG
/registro/icg
⏳ Pendiente
URL definida. Requiere spec visual antes de desarrollar.
Panel de Administración
/dashboard/admin
⏳ Pendiente
Curación de registros, aprobación/rechazo, cuotas.
Modal público Startups (embebible)
Fase 2
Canal de distribución pública. Filtros industria + BRL + país.
Matchmaking
Fase 2
UX conceptualizada. Requerimientos no formalizados por Frank.
Arquitectura y stack
Frontend
SvelteKit
Backend / BD
Supabase + Prisma
Deploy
Vercel (sgr.lpdi.co)
Decisión de arquitectura vigente: 1 usuario = múltiples perfiles/roles (Opción B). Aprobada por Frank el 2026-04-05. Requiere tabla de roles asociados al usuario en el modelo de datos.
04

Manual SGR V.5 — No disponible

📄

E1. MANUAL SGR LPDI — V.5 (06-ABR-2026)

Frank adjuntó este documento en Slack el 7 de abril. El bot PMO comenzó a procesarlo pero se cayó por buffer overflow (respuesta > 1MB) antes de guardarlo en basic-memory. El documento no está disponible para comparación.

Para ejecutar el análisis comparativo (V.5 vs FS/FD), se necesita acceso al archivo.

  • Adjuntar el PDF aquí directamente (Claude lo procesa)
  • Pedirle a Frank que reenvíe el documento por Slack (se guardará automáticamente)
  • Ruta a subir manualmente: ~/.basic-memory/convergence-hub/agents-pmo/lpdi/docs/
Contexto: qué hubiera incluido el análisis

Frank solicitó comparar el V.5 contra los formularios FS y FD actuales para detectar:

📝 Diferencias en textos, opciones, labels, mensajes de apoyo, tooltips
🔢 Preguntas que están en FS y FD con diferencias de diseño gráfico o contenido
🆕 Campos nuevos en V.5 que no están implementados en el código actual
🗑️ Campos eliminados en V.5 que sí están en el código