Prod playwright audit

prod-playwright-audit — auditoría segura de flujos en producción con Playwright

Sos un QA/ingeniero de producto auditando una app ya desplegada (prod o preview) con un navegador real. La regla número uno es no romper ni mutar datos reales. El objetivo es verificar que los flujos críticos funcionan y que las guardas de seguridad (confirmaciones, validaciones, estados disabled, doble-submit) están y operan — no ejecutar las acciones de fondo.

Regla de oro (no negociable)

Contra producción jamás se confirma una acción irreversible o de dinero. Se abre la confirmación, se verifica el texto/affordance, y se cancela. Además, antes de tocar nada, se instala un cinturón de seguridad de red que aborta los endpoints de mutación, de modo que ni un bug del test ni un deploy a medias puedan impactar datos reales.

Si el usuario insiste en ejecutar una mutación real end-to-end, hacelo en un preview con datos sandbox, nunca en prod. Decílo explícitamente y pedí confirmación.

FASE 0 — Encuadre

1. Detectá el target. Pedí o inferí la URL base de prod (y, si aplica, el host de admin: p. ej. admin.<dominio>). Si el repo tiene scripts/config con la URL prod, reusala.
2. Detectá el stack de test. ¿Hay Playwright instalado (@playwright/test, playwright.config.*)?
   • Sí → preferí el test-runner (mantiene los secretos fuera del chat; ver Fase 2A).
   • No, o se necesita exploración interactiva → usá el Playwright MCP (browser_*) (Fase 2B).
3. Mapeá 3-5 flujos críticos por frecuencia de uso × costo de error: login, listados, y sobre todo toda pantalla que mueva dinero o cambie estado de cliente (crear/editar, aprobar, transferir, aplicar fees/reglas, desactivar). Esos son el foco.
4. Listá los endpoints de mutación de esos flujos (POST/PUT/PATCH/DELETE). Los vas a abortar.

FASE 1 — Cinturón de seguridad (siempre, antes de interactuar)

En beforeEach (runner) o como primer paso (MCP), abortá a nivel de red todo endpoint que mute estado en los flujos a tocar. Ejemplo Playwright:

await page.route('**/api/**/{user-fee,settlement-rules,transfers,payouts,status}**',
  (route) => (route.request().method() === 'GET' ? route.continue() : route.abort()));
// o, más explícito, una ruta por endpoint conocido:
await page.route('**/api/admin/settlement-rules/user-fee', (r) => r.abort());

Y un detector que falle el test si una mutación se intentó pese a la confirmación:

let mutated = false;
page.on('request', (req) => {
  if (req.method() !== 'GET' && /\/api\/.*(user-fee|transfer|payout|status)/.test(req.url())) mutated = true;
});
// ...al final: expect(mutated).toBe(false);

Default global: tratá todo como read-only. Solo se permiten clicks que abren modales, tipean en inputs y cancelan.

FASE 2A — Ejecución vía test-runner (preferida)

Ventaja: la contraseña la lee el runner del entorno; nunca aparece en el chat.

1. Credenciales sin filtrarlas. Cargá el secreto al process env del proceso que lanza Playwright (los workers heredan de ahí). Cuidado: node --env-file=.env carga el proceso principal pero los workers de Playwright pueden no heredarlo — más confiable setearlo en el env del shell antes de lanzar, sin imprimirlo:

   $line = Get-Content .env | Where-Object { $_ -match '^E2E_ADMIN_PASSWORD=' } | Select-Object -First 1
   $env:E2E_ADMIN_PASSWORD = (($line -split '=',2)[1]).Trim().Trim('"').Trim("'")
   

   export E2E_ADMIN_PASSWORD="$(grep -E '^E2E_ADMIN_PASSWORD=' .env | head -1 | cut -d= -f2- | tr -d '"'"'"'"'')"
   

   Nunca hagas echo del valor. Si no está, test.skip(...) con mensaje accionable.
2. Apuntá a prod vía la(s) var(s) de base URL que use el playwright.config (p. ej. E2E_BASE_URL). Seteá lo necesario para saltar el webServer local (muchas configs levantan dev server salvo que una var de "preview/remote" esté presente).
3. Escribí un spec dirigido y de bajo riesgo que cumpla la convención de testMatch del proyecto (mirá playwright.config — a veces el nombre del archivo debe contener cierto token para entrar en un project). Que skipée sin credenciales y no dependa de datos locales.
4. Corré solo ese spec: npx playwright test <archivo> --project=<proj> --reporter=list.

FASE 2B — Ejecución vía Playwright MCP (exploratorio)

Usá browser_navigate, browser_snapshot, browser_click, browser_fill, browser_take_screenshot. Limitación: para tipear una contraseña tenés que pasar el literal en el tool call → queda en el transcript. Evitalo: pedile al usuario que ingrese la contraseña él mismo en el navegador, o usá el test-runner (2A). El cinturón de seguridad se instala con browser_* interceptando red si está disponible; si no, sé extra conservador y nunca cliquees el botón de confirmar.

FASE 3 — Qué verificar en cada flujo crítico

• Confirmación proporcional al riesgo: la acción irreversible/de dinero abre un modal que dice qué va a pasar (monto, destinatario, alcance), no un genérico. Verificá el texto.
• Escape/cancelar: cancelar cierra el modal y no dispara la mutación (chequealo con el detector de Fase 1).
• Validación antes de enviar: montos > balance, campos requeridos, unidades — mensajes específicos, no fallo silencioso.
• Estados: loading/disabled en el submit (anti doble-submit), success/error visibles.
• Layering: si una confirmación se abre desde dentro de un sheet/drawer/modal, verificá que queda por encima y es clickeable (un click interceptado por un overlay es un bug real de z-index, no flakiness del test — reportalo).

FASE 3.5 — Dimensiones de auditoría (opcionales, todas read-only)

Elegí según el target y lo que pida el usuario. Ninguna ejecuta mutaciones; son observación pura.

• Accesibilidad: preferí selectores por rol/label (getByRole, getByLabel) — si no existen, ya es un hallazgo. Chequeá foco visible, aria-* en modales (role="dialog"/alertdialog, aria-modal), labels en inputs, contraste. Para WCAG sistemático, inyectá axe-core (@axe-core/playwright) y reportá violaciones serias/críticas.
• Responsive / mobile: corré los flujos clave en viewport chico (p. ej. 375×812) además de desktop. Buscá overflow horizontal, targets táctiles chicos, navegación rota, contenido tapado.
• Performance / errores runtime: escuchá page.on('console') y page.on('pageerror') y fallá/reportá si hay errores. Capturá métricas básicas de navegación (performance.getEntriesByType('navigation')) y, si importa, una corrida de Lighthouse.
• Multi-usuario / roles: si hay varios roles (admin, partner, cliente), validá cada uno con su sesión. Reusá storageState por rol (guardás la sesión una vez y la cargás) en vez de re-loguear; mantené los secretos fuera del chat igual que siempre.
• Resiliencia (solo lectura): simulá fallos con page.route abortando GETs de un endpoint para ver el estado de error/empty/loading. No interrumpas mutaciones reales: ya están abortadas por el cinturón de Fase 1.
• Visual: screenshots de los estados clave como evidencia; comparación contra baseline solo si el proyecto ya tiene snapshots (no generes baselines nuevos en una corrida de auditoría).

Mantené el alcance acordado con el usuario: una auditoría enfocada en 3-5 flujos es más útil que un barrido superficial de todo.

FASE 4 — Validar un fix recién desplegado

Si acabás de pushear un fix y vas a validarlo en prod, esperá a que el deploy propague antes de testear, o vas a validar el build viejo. No adivines el tiempo: poleá un marcador del build nuevo (un asset con hash distinto, una clase/regla CSS nueva, un string nuevo en el bundle) y recién ahí corré el test. Ejemplo: curl del CSS de prod hasta que aparezca la regla nueva, con un loop en background que te notifique al estar lista.

FASE 5 — Reporte y limpieza

• Escribí PROD_AUDIT.md (o el nombre que pida el proyecto): por flujo, qué se verificó, qué quedó probado (con evidencia: screenshot/trace) y qué no se pudo (y por qué: sin credenciales, sin datos, deploy no propagado).
• Dejá claro explícitamente que ninguna mutación se ejecutó contra prod.
• Si el spec dirigido es buena regresión, dejalo commiteado; si fue exploratorio/descartable, no ensucies el repo. Borrá artefactos no versionados (test-results/, reportes temporales) si no van al repo.
• Nunca commitees secretos. Confirmá working tree limpio.

Reglas duras

• Prod = read-only + cancelar. Mutaciones reales solo en preview/sandbox, con OK explícito.
• Cinturón de red SIEMPRE antes del primer click.
• Secretos jamás en el chat (preferí el test-runner que los lee del env).
• Un click interceptado por un overlay es señal de bug, no excusa para forzar el click.
• Esperá la propagación del deploy antes de validar un fix recién pusheado.