Skill: Verificaciones automatizadas de calidad

Ejecuta la batería de checks automatizados que el stack exige (tipado, linter, unit tests, cobertura, build, e2e, sonar) más las suites de prueba que declare el estándar de testing del repo (integración, contrato, rendimiento…), adaptada al stack detectado, y emite un veredicto con su informe. Las únicas pruebas fijas son unit y cobertura —las dos únicas que se listan siempre, aunque salgan N/A—; el resto del conjunto sale de la config del propio repo (e2e) o del estándar de testing, y lo que no aplica no se lista — ver Suites de prueba.

Alcance: solo el plano automatizado. Este skill responde a «¿el código corre y cumple las reglas?». La pregunta «¿resuelve el problema correcto y está bien diseñado?» es del skill code-review (revisión cualitativa). Y «¿cada criterio de aceptación está probado?» es de trace-validate. Son tres skills independientes, cada uno con su veredicto e informe; quien los encadena es el orquestador de cierre (work-integrate, pr-create). Ver Relación con otros skills.

Audita, no arregla (por defecto). Aplica correcciones solo si el usuario lo autoriza explícitamente —o si .sdd-devkit/settings.json tiene verification.qualityCheck.confirmFix: "never" (ver Política de corrección)— y, tras corregir, vuelve a ejecutar. Fuera de un ciclo de implementación, entregar solo el informe es un resultado válido y frecuente con la política por defecto (always): se pregunta antes de tocar código (ver Corrección de fallos). No edita configuración, no instala dependencias ni hace commit/push/merge sin instrucción explícita. (Única excepción: dejar su propia caché ignorada en el .gitignore —añadiendo esa línea, y creando el archivo si no existiera—, ver Caché de corrida de pruebas.)

Proceso iterativo: toda corrección reinicia la corrida completa hasta un veredicto estable.

Sin cambios en el código no se repiten las pruebas. Si .sdd-devkit/test-run.json está fresco (mismo FINGERPRINT canónico), las suites y las validaciones de arquitectura se toman de ahí en cualquier modo, y solo se ejecutan los checks que la caché no cubre (tipado, linter, build, sonar). Solo no-cache o una petición explícita del usuario fuerzan la re-ejecución. Ver Caché de corrida de pruebas.

Entrada mínima: la raíz de un repositorio reconocible (ver references/stacks.md). Si no se detecta stack, parar y avisar. No se exige ningún artefacto del plugin: el repo puede no tener docs/specs/, ni US-XXX, ni convención de ramas — la corrida y el veredicto son idénticos. Ver Artefactos externos al plugin.

Alcance del informe

La corrida de este skill cubre todo el repositorio en el estado actual de la rama. Es inherente a lo que hace: tsc, el linter, la suite de pruebas y el build operan sobre el proyecto completo, y esa es justamente la señal que se busca. Una regresión provocada por el cambio en un archivo que nadie editó en esta rama solo aparece corriendo la batería entera.