15 Estado y Proximos Pasos - ronalc90/koptup GitHub Wiki

Estado del trabajo y próximos pasos

Corte: 14 de octubre de 2026. El trabajo se pausó a pedido del dueño y continúa el martes. Esta página resume qué está en main, qué avanzó en la rama de trabajo ccr-55ceecf7-dpc10i, qué falta y qué tiene que hacer el dueño.

Qué quedó en main

Bloque Estado Dónde verlo
Reposicionamiento en sistemas RAG (SEO, inicio, /rag y landings, planes, demo "Prueba con tu documento", medición) ✅ En producción Reposicionamiento RAG
Wiki del plan de producto ✅ Inicio
Imágenes de la tienda y de otras 13 demos (CSS) y catálogo de la tienda (fotos correctas, sin marcas, COP) ✅ En producción /demo/ecommerce
Pruebas: Jest en backend y web, Playwright de punta a punta y CI válido ✅ README.md, .github/workflows/ci.yml
Dependencias: Next 14.2.35 y paquetes con vulnerabilidades actualizados ✅
Seguridad: autorización en el servidor, propiedad de bots del chatbot, topes de gasto de IA, secretos fuera del repo ✅ Seguridad y calidad
Sistema de solicitud y acceso a demos ✅ Sistema de demos
21 demos revisadas: funcionales, sin botones muertos y con promesas verificables ✅ ver lista abajo

Verificación del corte: lint y tipos sin errores; Jest 190/190 en el backend (con Mongo) y 326/326 en la web; build de las dos apps; Playwright 148 pruebas en verde (1 omitida a propósito).

Cómo se usa hoy el sistema de demos

El cliente:

  1. En /demo cada tarjeta dice "Abierta", "Requiere acceso" o "Solo por invitación".
  2. Para las que requieren acceso pulsa Solicitar acceso (o entra a /solicitar-demo), llena el formulario y autoriza el tratamiento de datos (Ley 1581).
  3. Cuando lo aprueban recibe un enlace /activar/<token>, crea su contraseña y entra a Mis demos (/dashboard/demos).

El administrador (iniciar sesión con la cuenta admin):

  1. Solicitudes de demo (/admin/solicitudes): aprobar (demos, días de acceso, nota) o rechazar con motivo. El enlace de activación siempre se muestra para copiarlo o enviarlo por WhatsApp, aunque no haya correo configurado.
  2. Accesos a demos (/admin/accesos): extender, revocar o dar acceso directo por email.
  3. Catálogo de demos (/admin/catalogo-demos): elegir para cada demo si es abierta, con solicitud o solo por invitación.

Valores iniciales: con solicitud → voice-ai, erp, delivery, hrms, lms, telemedicina, wms-logistica, linkedin-ads; solo por invitación → cuentas-medicas, sistema-experto; el resto abiertas. Se cambian desde el catálogo.

Demos revisadas (21)

chatbot, cuentas-medicas, sistema-experto, crm-ia, linkedin-ads, erp, pos, code-review-ia, helpdesk-ia, voice-ai, ecommerce, facturacion-electronica, hrms, loyalty, telemedicina, control-proyectos, delivery, dashboard-ejecutivo, lms, scraping, gestor-contenido.

Avance en la rama de trabajo (ccr-55ceecf7-dpc10i, todavía no en main)

Se trabajó en dos pistas en paralelo. Cada paso tiene un implementador y un revisor adversarial que lo verifica antes de hacer commit.

Paso Estado
Revisión de seguridad de las rutas heredadas ✅ Revisado y con commit
Privacidad y Ley 1581: Admin › Privacidad (exportar y suprimir los datos de una persona), plazo de conservación, autorización en el formulario de contacto, chatbot guardado en MongoDB, política de privacidad, cookies y términos reescritos ✅ Revisado y con commit
Sitio público: embudo RAG, SEO, contenido verificable e inglés completo ✅ Revisado y con commit
Operación: variables, monitoreo programado, CI de seguridad, errores uniformes y código sin uso eliminado ✅ Revisado y con commit
Portal del cliente y panel (facturas, entregables, pedidos, mensajes, usuarios, bitácora, sesiones) ⏪ Revertido; pendiente de rehacer (el avance queda en el historial, commit df42e67). Para publicar solo se corrigió «Nuevo pedido», que ahora envía el pedido a la API configurada
Producto RAG (chatbot) verificado de punta a punta: demo en sus 3 modos, "Prueba con tu documento", widget insertable, backend (bots en MongoDB, cupos, idioma), landings /rag, planes con textos verdaderos y pruebas (Jest backend 313/313, web 773/773 y la suite e2e completa, 212 pruebas, en verde dos veces seguidas contra las builds de producción) ✅ Revisado y con commit (14 de octubre)
Las 28 demos funcionales, honestas y claras (implementación) ✅ Las 28 con commit
Revisión adversarial de cada demo 🟡 9 terminadas (chatbot, hrms, crm-ia, lms, erp, facturacion-electronica, pos, delivery, voice-ai). La de loyalty, gestor-contenido y dashboard-ejecutivo se revirtió (commit 2a15395) y queda pendiente, igual que las otras 16
Flujo de compra (backend de la fase P7) 🔒 Incluido pero apagado: COMMERCE_ENABLED=false por defecto. Sus rutas responden 404, su job no corre y ningún formulario ni acceso escribe leads (Operación y despliegue › 4.3)
Build del backend en Railway ✅ Arreglado (apps/backend/railway.json instala lo necesario para compilar); mientras llega a main, el comando va configurado a mano en Railway
Avisos al dueño por correo y WhatsApp (pedido del dueño: «me envían pocos mensajes, 1 al mes, y por poco uso no se debe bloquear»). Causa de que no llegaran: Railway Hobby bloquea el SMTP y el WhatsApp usaba el sandbox de Twilio (vence a los 3 días) o texto libre fuera de la ventana de 24 h. Ahora: correo por Resend, WhatsApp con la plantilla aprobada koptup_aviso de Meta, estado por canal en cada contacto, reintentos automáticos, prueba mensual, webhook firmado de WhatsApp, tarjeta «Avisos de nuevos contactos» con botón de prueba y «Reenviar aviso» en Contactos 🟡 Implementado y con pruebas en verde (Jest backend 361/361, web 806/806); falta correr el e2e owner-notify.spec.ts, la revisión y el commit. Para que lleguen hace falta la configuración del dueño (ver abajo)

El historial de la rama trae los commits marcados wip y "NO FUSIONAR" (ae60766, a897181, 02fe0fa, df42e67 y e2f8099), pero su contenido ya no queda a medias en el código: las demos que traían se terminaron y revisaron en commits posteriores, el portal y el panel (14658b7) y la revisión a medias de 3 demos (2a15395) se revirtieron, y el flujo de compra quedó apagado con COMMERCE_ENABLED.

Qué falta (martes)

  1. Rehacer y revisar el portal del cliente y el panel (el avance revertido está en el commit df42e67 del 10 de octubre).
  2. Flujo de compra (fases P7–P9): pipeline de leads, "Solicitar propuesta", propuestas con página pública para aceptarlas, anticipo (enlace de pago, transferencia o Wompi con claves) y conversión a proyecto y cliente. El backend está incluido pero apagado (COMMERCE_ENABLED=false por defecto: sus rutas responden 404); falta revisarlo, hacer el frontend (P8) y sus pruebas de punta a punta (P9) antes de encenderlo.
  3. Demos: terminar la revisión adversarial de 19 demos (telemedicina, helpdesk-ia, cuentas-medicas, sistema-experto, linkedin-ads, ecommerce, loyalty, gestor-contenido, dashboard-ejecutivo, control-proyectos, scraping, code-review-ia, sistema-reservas, saas-boilerplate, firma-electronica, wms-logistica, gestor-documentos, automatizacion, moderacion-contenido); catálogo honesto (tarjetas del hub, páginas de producto y un solo nombre por demo); sonda final en las 28.
  4. Pendientes reportados por las fases: ninguno abierto. (Los permisos de la configuración del sistema experto, la lista de errores de hidratación conocidos —hoy vacía—, las cifras del README, el docker-compose.yml roto y el error de /api/expert/generar-excel sin procedimientos ya están corregidos en la rama de trabajo.)
  5. Repaso de honestidad en todo el sitio: quedan los textos del catálogo de "Otras soluciones a medida" (modalidad SaaS solo donde haya base real). /about, /bienvenido-producthunt, /desarrollo-web-colombia, las landings, el pie, el JSON-LD y llms.txt ya solo dicen lo que se puede comprobar; los datos que debe aportar el dueño están en Páginas públicas › Limitaciones conocidas.
  6. Diseño y animaciones: investigación de motion design, sistema de movimiento, animación protagonista que explique RAG, microinteracciones, easter eggs (paleta Ctrl+K, código Konami, mensaje en consola, 404 ingeniosa) y revisión adversarial con video y medición de fluidez.
  7. Correcciones pendientes: al documentar el sitio y dibujar sus diagramas contra el código y al recorrer las 28 demos aparecieron más de 200 puntos. Sin repetir y sin contar los detalles de cada demo, los que quedan están ordenados de P0 a P3 en Correcciones pendientes (la página lleva el conteo al día). Los más urgentes, además de volver a levantar el backend, son estos:
    • no se pueden crear facturas, entregables ni conversaciones.
  8. Crítico de completitud, verificación final completa, actualización de la wiki, PR y merge.

Acciones del dueño

  • 🔴 Backend de producción caído: la URL configurada (koptupbackend-production.up.railway.app) responde "Application not found" de Railway, es decir, no hay ningún servicio en ese dominio. La web funciona, pero todo lo que necesita el backend falla: formulario de contacto, inicio de sesión y panel admin, solicitudes de demo, respuestas reales del chatbot y "Prueba con tu documento". Hay que revisar en Railway si el servicio se borró, se pausó por facturación o cambió de dominio, volver a desplegarlo desde main con sus variables y, si cambia el dominio, actualizar NEXT_PUBLIC_API_URL en Vercel y redesplegar la web.
  • Urgente: cambiar en Railway la contraseña de MongoDB de producción y los secretos JWT_SECRET y JWT_REFRESH_SECRET. Estuvieron en archivos del repositorio público; ya se quitaron, pero siguen en el historial.
  • 🔔 Avisos de nuevos contactos (correo y WhatsApp): seguir el paso a paso de Operación y despliegue › 4.5: key de Resend (koptup.com ya está verificado allí); en Meta, app con el número de prueba gratis, tu número como destinatario verificado, plantilla koptup_aviso (Utility, Spanish) y token de usuario del sistema que no vence; variables en Railway con Serverless apagado; webhook opcional; en Namecheap, reenvío gratis de [email protected] a tu Gmail y el registro DMARC v=DMARC1; p=none;; en Gmail, el filtro «Nunca enviarlo a Spam». Al final, Enviar aviso de prueba en Admin › Configuración.
  • Variables del backend (Railway): JWT_REFRESH_SECRET (necesaria para iniciar sesión), ADMIN_EMAIL (primer admin si no hay ninguno, y destino de los avisos si falta NOTIFY_EMAIL), FRONTEND_URL=https://www.koptup.com (enlaces de los correos), RESEND_API_KEY y NOTIFY_EMAIL (sin la key no sale ningún correo: Railway Hobby bloquea el SMTP), WHATSAPP_API_TOKEN, WHATSAPP_PHONE_NUMBER_ID y ADMIN_WHATSAPP_NUMBER (avisos por WhatsApp), REDIS_URL (límites y topes de gasto), OPENAI_API_KEY, INTERNAL_API_KEY (igual en Vercel) y, para encender la demo con documento propio, DEMO_UPLOAD_ENABLED=true. Al arrancar, el log avisa cuáles faltan. Lista completa en Operación y despliegue › 4.
  • Variables de la web (Vercel), opcionales: NEXT_PUBLIC_GA_ID, NEXT_PUBLIC_GOOGLE_ADS_ID, NEXT_PUBLIC_LINKEDIN_PARTNER_ID (redesplegar después de crearlas).
  • Wiki de GitHub: ✅ activada. Cada cambio en docs/wiki/ se publica solo con el workflow "Publicar wiki".
  • Plataformas (GitHub, Vercel, Railway): proteger main con CI obligatorio y que Railway espere a CI; dejar un solo proyecto de Vercel (koptup, el que tiene el dominio); montar un volumen en Railway para los archivos subidos; crear la variable BACKEND_HEALTH_URL para que el monitoreo revise también la API; y revisar las alertas de dependencias antes del 31 de diciembre de 2026. Paso a paso en Operación y despliegue › Acciones pendientes del dueño.
  • Privacidad (Ley 1581): que un abogado revise /privacy, /cookies y /terms (hoy describen lo que hace el sistema, pero nadie los ha revisado legalmente); poner la razón social, el NIT y confirmar la dirección del responsable; confirmar en qué proveedor y país están MongoDB y Redis de producción para completar la sección de transferencias internacionales; validar el plazo de conservación de 24 meses (DATA_RETENTION_MONTHS) y cambiar PRIVACY_POLICY_VERSION cada vez que cambie la política. Detalle en SEO, analítica y legal › 4.
  • Pagos: decidir la pasarela (Wompi, PayU o Stripe) para el cobro del anticipo en línea.
⚠️ **GitHub.com Fallback** ⚠️