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]>

docs/TAREA-QA.md

@@ -0,0 +1,119 @@
+# 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:
+
+```bash
+docker ps --filter name=fspm-demo
+curl -s http://127.0.0.1:3100/api/salud
+```
+
+## Ejecución
+
+```bash
+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.
+
+```bash
+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
+
+1. **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.
+2. **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.
+3. **Widget sin JavaScript de terceros.** Confirma que el enlace de WhatsApp
+   que devuelve la API lleva el prefijo `[DEMO]` y el folio.
+4. **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:
+
+1. **Resumen**: cuántas pruebas por proyecto, cuántas fallaron. Cifras reales,
+   pegadas de la salida.
+2. **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.
+3. **Hallazgos visuales** de las capturas, con la ruta y el ancho.
+4. **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í.