Le défaut
Le pré-enregistrement de la case 15 (confabulation) est cité comme posté à 2026-09-17T05:59Z en trois endroits du head de #16512 :
ict/confabulation_ignition.py:24
ict/tests/test_confabulation_ignition.py:6
docs/ict/dissociations-matrix.md:709
L'heure réelle du commentaire de pré-enregistrement, telle que le serveur l'enregistre :
$ gh api repos/jsboige/CoursIA/issues/comments/5709692119 --jq .created_at
2026-09-17T06:00:27Z
Écart : 87 secondes.
Pourquoi ça vaut une correction, alors que l'écart est minuscule
L'ordre n'est pas en cause : le pré-enregistrement précède l'exécution dans les deux lectures, et le texte qui l'entoure (« AVANT toute exécution ») reste vrai. Personne n'est induit en erreur sur la conclusion.
Ce qui est en cause, c'est la nature de l'objet. Un pré-enregistrement ne vaut que par l'auditabilité de son horodatage : sa fonction entière est de permettre à un tiers de vérifier qu'une prédiction a précédé un résultat. Un document dont le seul rôle est de rendre une date vérifiable, et qui cite cette date de façon inexacte, se contredit dans sa fonction — indépendamment de l'amplitude.
La série vise une publication. Une heure arrondie à la minute inférieure au lieu d'être recopiée du serveur est exactement ce qu'un relecteur extérieur vérifie en premier quand un travail s'appuie sur un pré-enregistrement.
Origine et statut
Nit posé par NanoClaw dans sa review de #16512 (2026-09-17T06:25:24Z), qualifié Nit par son auteur, et factuellement exact — je l'ai vérifié contre l'API, valeur ci-dessus.
Il n'était levé par aucune des trois voies B.0 au moment du merge de #16512. Cette issue est ouverte avant ce merge pour le porter : c'est la troisième voie.
Pourquoi par issue et non par commit : les trois occurrences sont des corrections d'une ligne, mais tout nouveau commit ré-arme le minuteur DWELL de 120 minutes sur la PR. Deux heures d'attente pour 87 secondes d'horodatage n'est pas un arbitrage serré dans ce sens-là — à l'inverse du cas #16398, où la rebaseline nue rendait une attestation de registre fausse et où j'ai demandé le commit.
Ce qui ferme cette issue
Les trois occurrences portent 2026-09-17T06:00:27Z, recopié du champ created_at du serveur et non arrondi.
À vérifier dans le même geste : les autres horodatages de pré-enregistrement cités dans docs/ict/dissociations-matrix.md (claims c.5709691931, amendement c.5709716652, re-scope c.5709770262) sont-ils, eux, recopiés du serveur ? Corriger la seule occurrence signalée en laissant ses voisines non mesurées reproduirait le défaut — c'est la règle E appliquée à un fichier de matrice plutôt qu'à un README.
Le défaut
Le pré-enregistrement de la case 15 (confabulation) est cité comme posté à
2026-09-17T05:59Zen trois endroits du head de #16512 :L'heure réelle du commentaire de pré-enregistrement, telle que le serveur l'enregistre :
Écart : 87 secondes.
Pourquoi ça vaut une correction, alors que l'écart est minuscule
L'ordre n'est pas en cause : le pré-enregistrement précède l'exécution dans les deux lectures, et le texte qui l'entoure (« AVANT toute exécution ») reste vrai. Personne n'est induit en erreur sur la conclusion.
Ce qui est en cause, c'est la nature de l'objet. Un pré-enregistrement ne vaut que par l'auditabilité de son horodatage : sa fonction entière est de permettre à un tiers de vérifier qu'une prédiction a précédé un résultat. Un document dont le seul rôle est de rendre une date vérifiable, et qui cite cette date de façon inexacte, se contredit dans sa fonction — indépendamment de l'amplitude.
La série vise une publication. Une heure arrondie à la minute inférieure au lieu d'être recopiée du serveur est exactement ce qu'un relecteur extérieur vérifie en premier quand un travail s'appuie sur un pré-enregistrement.
Origine et statut
Nit posé par NanoClaw dans sa review de #16512 (2026-09-17T06:25:24Z), qualifié
Nitpar son auteur, et factuellement exact — je l'ai vérifié contre l'API, valeur ci-dessus.Il n'était levé par aucune des trois voies B.0 au moment du merge de #16512. Cette issue est ouverte avant ce merge pour le porter : c'est la troisième voie.
Pourquoi par issue et non par commit : les trois occurrences sont des corrections d'une ligne, mais tout nouveau commit ré-arme le minuteur DWELL de 120 minutes sur la PR. Deux heures d'attente pour 87 secondes d'horodatage n'est pas un arbitrage serré dans ce sens-là — à l'inverse du cas #16398, où la rebaseline nue rendait une attestation de registre fausse et où j'ai demandé le commit.
Ce qui ferme cette issue
Les trois occurrences portent
2026-09-17T06:00:27Z, recopié du champcreated_atdu serveur et non arrondi.À vérifier dans le même geste : les autres horodatages de pré-enregistrement cités dans
docs/ict/dissociations-matrix.md(claimsc.5709691931, amendementc.5709716652, re-scopec.5709770262) sont-ils, eux, recopiés du serveur ? Corriger la seule occurrence signalée en laissant ses voisines non mesurées reproduirait le défaut — c'est la règle E appliquée à un fichier de matrice plutôt qu'à un README.