fswp-qa-engineer

FSWP QA Engineer

Verifique la carpeta compilada, no corrija durante la validación. Reporte primero, luego corrija en el bucle de corrección del enrutador.

1. Puerta mecánica

bash scripts/setup_toolchain.sh              # una vez por entorno (solo apt + GitHub, sin Composer)
bash scripts/run_gate.sh <dir> [min-php] [--fix]

run_gate.sh detecta un tema (un style.css con un encabezado Theme Name) y ejecuta scripts/theme_check.py; de lo contrario ejecuta scripts/qa_check.py. Ambos usan solo la biblioteca estándar de Python y siempre funcionan. Luego añade, donde existan PHP y las herramientas: php -l, PHPCS WordPress-Extra (los errores fallan, las advertencias se listan), compatibilidad PHP para la versión mínima de PHP, y PHPStan nivel 5 con stubs de WordPress.

• --fix ejecuta phpcbf (estándar de WordPress) primero. Úselo después del andamiaje y después de ediciones grandes; revise el diff.
• Plugin Check necesita una instalación de WordPress y la línea de comandos (wp plugin check <slug>); NO SE EJECUTA en otros lugares. Indique al usuario que lo ejecute antes de enviar un plugin a WordPress.org. Para temas, el equivalente es el plugin Theme Check o la revisión automatizada del directorio.
• theme_check.py <dir> [--directory]: sin la bandera, los defectos reales generan FAIL y las reglas solo de directorio generan WARN; con --directory, los requisitos del Directorio de Temas de WordPress.org generan FAIL (encabezados faltantes, tamaño y proporción de la captura de pantalla, archivos no permitidos, código de territorio de plugins, llamadas requeridas de temas clásicos).
• qa_check.py también verifica las reglas de encabezado de plugin y readme del manual (longitud de descripción, URI de Plugin única, máximo 5 etiquetas, sin Stable tag: trunk, Tested up to numérico, longitud de descripción corta) como advertencias.
• qa_check.py exige, para plugins: protecciones ABSPATH, coincidencia de versiones (encabezado, constante, etiqueta Stable tag del readme), sin example.com ni CDN ni fuentes alojadas, permission_callback en cada ruta con __return_true comentado, verificación de actualización de BD, encolado dentro de callbacks, funciones prohibidas, protección de desinstalación, unidades solo de rem, traducciones JS, código fuente incluido con la salida compilada, licencias de fuentes. theme_check.py verifica el encabezado, licencia, plantillas de entrada, validez de theme.json, funciones prohibidas, heurística de echo sin escapar, activos remotos, dominio de texto, captura de pantalla y readme.

Regla de reporte: cada verificación es PASS, FAIL o NOT RUN, con las versiones de herramientas utilizadas. NOT RUN nunca es un aprobado y nunca se resume como "limpio". Si falta PHP o una herramienta, dígalo y nombre el comando que la ejecutaría.

1a. Verificación de alcance

Compare el diff o la lista de archivos con el resumen aprobado. Los archivos, hooks, opciones o dependencias que el plan no solicitó se reportan como desviación de alcance (consulte fswp-developer/references/lean-coding.md). Cuente las líneas agregadas versus eliminadas y comente sobre la desproporción.

2. Lista de verificación manual

references/checklist.md: solo los elementos que un script no puede juzgar. Ejecútela después de que la puerta mecánica esté en verde.

3. Pruebas de escenarios

Cada escenario numerado en el PRD (fswp-architect) obtiene PASS, FAIL o NOT RUN con evidencia. Siempre incluya:

• Instalación limpia sin opciones ni tablas previas: sin avisos ni errores fatales.
• Desactivar y luego reactivar: sin programaciones ni opciones duplicadas.
• Actualización desde datos almacenados de una versión anterior sin reactivar: el esquema y las opciones migran al cargar.
• Desinstalación: solo se eliminan los datos propiedad del plugin.
• Modo de migración: exportar diffs y puerta de regresión visual contra baseline/ (fswp-architect).

Según el tipo de trabajo, añada:

• Tema: cada tipo de plantilla que el PRD lista se renderiza con contenido real y con contenido vacío; el editor y el front-end coinciden; la navegación solo con teclado funciona; cambiar a otro tema y volver no deja errores fatales.
• Actualización: cada elemento en la lista de paridad del resumen de cambios se vuelve a verificar y marcar; la actualización desde los datos almacenados de la versión anterior funciona; nada fuera del resumen cambió (leer el diff).
• Complemento: anfitrión activo y en rango (funciona); anfitrión inactivo (el complemento permanece en silencio, muestra un aviso, sin error fatal); anfitrión por debajo de la versión compatible (rechaza limpiamente).
• Parche del núcleo: la reproducción del ticket falla antes y pasa después; el grupo relevante de PHPUnit pasa; PHPCS limpio en las líneas cambiadas; consulte fswp-core-contributor.

Donde se pueda ejecutar PHP, ejercite la lógica de activación y migración con un pequeño script PHP; de lo contrario, rastree leyendo y etiquételo como "rastreado, no ejecutado".

4. Verificación de lanzamiento

Después de que todo lo anterior esté en verde: references/release-check.md.

Salida

Una tabla: verificación | PASS/FAIL/NOT RUN | detalle. Luego lista de FAIL con archivo y línea, seguido de lo que el usuario debe ejecutar por sí mismo. Para compilaciones de varias sesiones, copie la tabla en HANDOFF.md.