Files

T

Uriel JarethandClaude Opus 5 01b817d098 feat: sitio comercial FSPM con micro CRM interno

Sitio público orientado a venta consultiva e implementación de las
recomendaciones de la auditoría de marca y mercado:

- Inicio con tres rutas (industria, riesgo, cumplimiento) y clasificador
  de riesgo en el héroe, contra el hallazgo de que el visitante tenía que
  inferir qué solución le correspondía.
- Cinco páginas por segmento prioritario y catálogo comparable por clase
  de fuego, capacidad y agente.
- Los claims sin evidencia por modelo quedan aislados y se presentan como
  compromiso de documentación, nunca como característica del producto.
- SEO técnico completo: metadatos por página, sitemap derivado de los
  datos, JSON-LD, iconos y tarjeta social generadas.

Micro CRM:

- Captura por formulario embebido y por widget de WhatsApp que registra
  antes de abrir la conversación.
- Atribución de primer toque que sobrevive a la navegación.
- Deduplicación de contacto; un mismo contacto acumula oportunidades.
- Motor de asignación por reglas con reparto por turno de respaldo.
- Panel con dos roles de alcance distinto, tablero analítico, bitácora,
  pedidos y reglas. No enlazado desde el sitio público y con noindex.

Empaquetado en Docker multietapa con la base de demostración horneada en
la imagen y el volumen de datos separado, para que los leads capturados
sobrevivan a los redespliegues.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>

2026-08-28 00:07:20 -06:00

5.2 KiB

Raw Blame History

Tarea: pruebas de calidad del sitio y del panel FSPM

Eres el agente de QA del proyecto. No corriges código. Tu trabajo es ejecutar las pruebas, reproducir lo que falle, y entregar un reporte que el orquestador pueda accionar sin volver a investigar desde cero.

Repo: H:\MegaSync\Proyectos\fspm\fspm-web

Contexto

Sitio comercial de FSPM (protección contra incendios) con un micro CRM interno. Es una demostración para directivos: un error visible cuesta la venta del servicio, así que la barra es alta.

Lee docs/CONTRATO.md para conocer el sistema de diseño y las reglas de contenido, y README.md para entender el circuito de captura.

Preparación — YA ESTÁ HECHA, no la repitas

El artefacto de producción ya está construido y corriendo en un contenedor:

Imagen fspm-web:demo, contenedor fspm-demo, en http://127.0.0.1:3100.
Base sembrada: 5 usuarios, 60 contactos, 95 oportunidades, 18 pedidos, 6 reglas.
curl http://127.0.0.1:3100/api/salud responde {"ok":true,...}.

Playwright está configurado con reuseExistingServer: true apuntando al 3100, así que usa ese contenedor y no arranques ningún servidor de desarrollo.

No corras npm run build ni npm run dev en esta máquina. El repositorio vive dentro de una carpeta sincronizada a la nube y el cliente de sincronización mueve archivos de .next a media compilación: el build falla con Cannot find module './NNNN.js' aunque el código esté bien. Ya está comprobado. Si necesitas reiniciar la aplicación, usa docker restart fspm-demo.

Verifica que el contenedor responde antes de empezar:

docker ps --filter name=fspm-demo
curl -s http://127.0.0.1:3100/api/salud

Ejecución

npm run test:e2e

Cuatro proyectos: escritorio-chromium, escritorio-webkit, movil-webkit, movil-chico (320px). Los dos de WebKit son obligatorios: es el motor de Safari e iOS, donde más se rompe la responsividad, y el cliente lo pidió por nombre. Un resultado que solo cubre Chromium no sirve.

El servidor de pruebas lo arranca Playwright solo, en el puerto 3100.

Las suites:

tests/01-humo.spec.ts — rutas, títulos, meta description, Open Graph, canónicas, sitemap, robots, iconos, 404.
tests/02-responsivo.spec.ts — desborde horizontal de 320 a 1440, menú móvil, widget de WhatsApp, tabla comparativa.
tests/03-captura.spec.ts — el circuito comercial: campaña → navegación → formulario, y que la atribución de primer toque sobreviva.
tests/04-panel.spec.ts — panel no expuesto, sesión obligatoria, y el aislamiento entre administrador y vendedor.
tests/05-accesibilidad.spec.ts — alt, etiquetas, jerarquía de encabezados, foco, movimiento reducido.

Además de las pruebas automáticas: revisión visual

Toma capturas y míralas. Las pruebas no detectan que algo se ve mal.

npx playwright screenshot --viewport-size=1440,900 http://127.0.0.1:3100/ tests/reporte/inicio-1440.png
npx playwright screenshot --viewport-size=375,900 --full-page http://127.0.0.1:3100/ tests/reporte/inicio-375.png

Hazlo para /, /catalogo, una ficha de producto, /soluciones/industria-energia y /admin tras entrar con el acceso rápido. Revisa en cada una:

Texto encima de imagen: ¿se lee de verdad, o el degradado no alcanza?
Espaciado entre secciones: ¿hay saltos incoherentes o secciones pegadas? Es la falla típica cuando varios agentes escriben CSS en paralelo.
¿Alguna sección se ve como plantilla genérica frente al resto?
¿El riel de clases de fuego aparece consistente en sitio y panel?
¿Hay estados vacíos que se vean como errores?
Contraste: ¿algún texto gris sobre fondo oscuro que no se alcance a leer?

Sondeos manuales que valen la pena

Doble envío. Manda el formulario dos veces con el mismo correo y confirma en /admin/contactos que hay un contacto con dos oportunidades, no dos contactos. Es un requisito explícito del cliente.
Fuga entre roles. Entra como vendedor, copia el id de una oportunidad que no sea suya (obtenlo entrando como administrador en otra pestaña) y pide /admin/oportunidades/<id> directo. Debe negarlo. Si la muestra, es una falla de seguridad y va primero en tu reporte.
Widget sin JavaScript de terceros. Confirma que el enlace de WhatsApp que devuelve la API lleva el prefijo [DEMO] y el folio.
Panel en móvil real. 375px de ancho: ¿las tablas se pueden usar o hay que hacer zoom?

Reporte final — lo que necesito de ti

Nada de "todo pasó" ni de listas de pruebas verdes. Quiero:

Resumen: cuántas pruebas por proyecto, cuántas fallaron. Cifras reales, pegadas de la salida.
Fallas, ordenadas por gravedad. Para cada una:
- qué se rompe, en qué ruta y en qué proyecto/ancho;
- el error literal de Playwright;
- el archivo y la línea donde está la causa, si lo pudiste localizar;
- si es una falla real del producto o una prueba mal escrita — dilo con claridad, no todo lo que falla es un bug.
Hallazgos visuales de las capturas, con la ruta y el ancho.
Lo que no pudiste probar y por qué.

Sé directo. Si algo está mal hecho, dilo con el argumento técnico. Un reporte complaciente no sirve de nada aquí.

5.2 KiB Raw Blame History