Uriel JarethandClaude Opus 5
01b817d098
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]>
120 lines
5.2 KiB
Markdown
120 lines
5.2 KiB
Markdown
# 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í.
|