Ingénieur QA FSWP

Que fait Ingénieur QA FSWP ?

Vérifiez le dossier construit, ne corrigez pas pendant le passage en passerelle. Signalez d'abord, puis corrigez dans la boucle de correction du routeur.

1. Passerelle mécanique

bash scripts/setup_toolchain.sh              # une fois par environnement (apt + GitHub uniquement, pas de Composer)
bash scripts/run_gate.sh <dir> [min-php] [--fix]

run_gate.sh détecte un thème (un style.css avec un en-tête Theme Name) et exécute scripts/theme_check.py ; sinon, il exécute scripts/qa_check.py. Les deux utilisent uniquement la bibliothèque standard de Python et fonctionnent toujours. Ensuite, il ajoute, là où PHP et les outils existent : php -l, PHPCS WordPress-Extra (les erreurs font échouer, les avertissements sont listés), la compatibilité PHP pour le PHP minimum, et PHPStan niveau 5 avec les stubs WordPress.

• --fix exécute phpcbf (standard WordPress) en premier. Utilisez-le après le scaffold et après les modifications importantes ; examinez le diff.
• Plugin Check nécessite une installation WordPress et la ligne de commande (wp plugin check <slug>) ; il n'est PAS EXÉCUTÉ ailleurs. Dites à l'utilisateur de l'exécuter avant une soumission de plugin sur WordPress.org. Pour les thèmes, l'équivalent est le plugin Theme Check ou la révision automatisée de l'annuaire.
• theme_check.py <dir> [--directory] : sans le drapeau, les défauts réels font échouer (FAIL) et les règles spécifiques aux répertoires sont des avertissements (WARN) ; avec --directory, les exigences du répertoire de thèmes WordPress.org font échouer (en-têtes manquants, taille et ratio de la capture d'écran, fichiers interdits, code de territoire de plugin, appels requis classic-theme).
• qa_check.py vérifie également les règles d'en-tête de plugin et de readme issues du manuel (longueur de la description, URI de plugin unique, au plus 5 tags, pas de Stable tag: trunk, Tested up to numérique, longueur de la courte description) sous forme d'avertissements.
• qa_check.py applique, pour les plugins : les gardes ABSPATH, la correspondance de version (en-tête, constante, Stable tag du readme), pas de example.com ni de CDN ni de polices hébergées, permission_callback sur chaque route avec __return_true commenté, vérification de mise à jour de base de données, enqueue dans les callbacks, fonctions bannies, garde de désinstallation, unités en lecture seule, traductions JS, source fournie avec la sortie compilée, licences de polices. theme_check.py vérifie l'en-tête, la licence, les modèles d'entrée, la validité de theme.json, les fonctions bannies, l'heuristique d'echo non échappé, les ressources distantes, le domaine de texte, la capture d'écran et le readme.

Règle de rapport : chaque vérification est PASS, FAIL ou NOT RUN, avec les versions des outils utilisés. NOT RUN n'est jamais un succès et n'est jamais résumé comme "propre". Si PHP ou un outil est manquant, dites-le et nommez la commande qui l'exécuterait.

1a. Vérification du périmètre

Comparez le diff ou la liste de fichiers avec le brief approuvé. Les fichiers, hooks, options ou dépendances que le plan n'a pas demandés sont signalés comme une dérive de périmètre (voir fswp-developer/references/lean-coding.md). Comptez les lignes ajoutées par rapport à celles supprimées et commentez une disproportion.

2. Checklist manuelle

references/checklist.md : uniquement les éléments qu'un script ne peut pas juger. Exécutez-la après que la passerelle mécanique est verte.

3. Tests de scénarios

Chaque scénario numéroté dans le PRD (fswp-architect) obtient PASS, FAIL ou NOT RUN avec des preuves. Incluez toujours :

• Installation propre sans options ni tables préexistantes : pas d'avis ni d'erreurs fatales.
• Désactivation puis réactivation : pas de planifications ou d'options en double.
• Mise à jour depuis des données stockées d'une version précédente sans réactivation : le schéma et les options migrent au chargement.
• Désinstallation : seules les données appartenant au plugin sont supprimées.
• Mode migration : exportez les diffs et la passerelle de régression visuelle par rapport à baseline/ (fswp-architect).

Par type de travail, ajoutez :

• Thème : chaque type de modèle que le PRD liste s'affiche avec du contenu réel et avec du contenu vide ; l'éditeur et le front-end correspondent ; la navigation au clavier uniquement fonctionne ; le changement de thème vers un autre et le retour ne laissent pas d'erreur fatale.
• Mise à jour : chaque élément de la liste de parité du brief de changement est revérifié et marqué ; la mise à jour depuis les données stockées de la version précédente fonctionne ; rien en dehors du brief n'a changé (diff lu).
• Extension : l'hôte est actif et dans la plage (fonctionne) ; l'hôte inactif (l'extension reste silencieuse, affiche un avis, pas d'erreur fatale) ; l'hôte en dessous de la version supportée (refuse proprement).
• Correctif noyau : la reproduction du ticket échoue avant et réussit après ; le groupe PHPUnit pertinent passe ; PHPCS est propre sur les lignes modifiées ; voir fswp-core-contributor.

Là où PHP peut s'exécuter, exercez la logique d'activation et de migration avec un petit script PHP ; sinon, tracez en lisant et étiquetez-le "traced, not run" (traçé, non exécuté).

4. Vérification de livraison

Après que tout ce qui précède est vert : references/release-check.md.

Sortie

Un tableau : vérification | PASS/FAIL/NOT RUN | détail. Ensuite, la liste des échecs avec fichier et ligne, puis ce que l'utilisateur doit exécuter lui-même. Pour les sessions multi-builds, copiez le tableau dans HANDOFF.md.