Playwright no necesita otro runner

La mayoría de las demos de «QA con IA» hacen lo mismo: toman el título de un ticket, escupen un spec y dan la tarea por cerrada. Ese spec no tiene dueño. Nadie sabe de qué criterio salió, el selector está pegado en el test, y a la semana el pipeline queda rojo por un cambio de clase de CSS. El equipo aprende a ignorar el rojo. Eso no es automatización. Es ruido con sintaxis de TypeScript.

qa-ai-harness parte de otra premisa. Playwright ya es el runner. El harness es un playground, versión 0.1, para equipos que ya escriben specs contra un producto real y guardan los casos en algún tracker. No sirve para «aprender Playwright desde cero». Si todavía no hay un suite, este repo no lo inventa.

Hay cuatro lazos, y ninguno es un chat.

El primero arma un spec desde un ticket. Lee título, tipo y criterios de aceptación. Parte cada criterio en cláusulas y las marca: interfaz firme, interfaz opcional, algo que no es UI, o una prueba que sigue siendo manual. El spec importa page objects. No lleva selectores CSS sueltos. El orden de búsqueda es rol, etiqueta, texto, test id y, recién al final, CSS. El modo por defecto es adversarial. Si una cláusula firme no está en la aplicación, el test falla y queda etiquetado como divergencia. Existe un modo de conformidad que no deja ese test en rojo, pero igual anota el hueco. Las capas de cobertura son pocas y explícitas: Playwright, divergencia, QA manual, no-UI, o sin cubrir.

El segundo lazo sincroniza al revés: del spec al tracker. Cada test es un caso. El título empieza con «Verify that». Si no hay un id, se crea el ticket, se enlaza al requerimiento y se escribe el id de vuelta en el spec. No borra, no cierra y no mueve tickets que ya existían. Si el título está repetido, lo saltea.

El tercero lee un reporte de CI, en este corte un JSON de Playwright. Separa el fallo duro del flake —el que pasó en un reintento— y lo clasifica contra una lista de patrones. Acá está la regla que más me importa: si el bloqueo es de la aplicación o del entorno, no se parcha el test para que quede verde. Se abre o se actualiza un bug de producto y esa unidad se detiene. Un diff no alcanza como evidencia. Hay que volver a correr el spec en un navegador de verdad antes de guardar el patrón.

El cuarto es Jev, de TypeSafe. No es un modelo de conversación. Se le manda un estado y preguntas tipadas, y devuelve probabilidades. Antes de una acción peligrosa —tocar producción, borrar datos— la decisión es permitir, revisar o bloquear. Una confianza baja no puede quedarse en «permitir». Si no hay una clave de API, Jev corre en mock y la consola igual funciona.

Para que todo eso tenga algo que probar, el repo incluye Mesa, una bandeja de soporte de ejemplo: login, lista, detalle, resolver. No es un producto de un cliente. Es la mesa estable sobre la que corren el spec de muestra y la consola.

Las piezas que cambian de equipo —Jira, Linear, GitHub Issues, TestRail, Xray, Currents— viven en adaptadores y en harness.config.json. La skill publicada se mantiene genérica. Si el id de un proyecto queda escrito dentro de la skill, el siguiente equipo hereda una configuración que no es suya.

Nada de esto está listo para venderse como plataforma. Es una tajada abierta para ver si los lazos aguantan un ticket de verdad. La consola local tiene rutas para scaffold, sync, self-heal, guardrail y triage. El código, y los límites, están en el repositorio.