{
  "errata": [
    {
      "id": "t29-e1",
      "date": "2026-10-04",
      "dates_concernees": [
        "2026-09-23",
        "2026-09-24",
        "2026-09-25",
        "2026-09-26",
        "2026-09-27",
        "2026-09-28",
        "2026-09-29",
        "2026-09-30",
        "2026-10-01"
      ],
      "titre": "Deux mesures distinctes : les mesures antérieures au gel des engagements sont une évaluation statistique interne (piste A), pas une mesure reproductible à la publication",
      "texte": "Marquage définitif (publié le 04/10/2026, tâche 29). À partir du 02/10/2026, chaque classement complet est gelé par un engagement (hash sha256 publié avant la clôture du jour qu'il engage, nonce révélé le lendemain — registre public engagements.json). La mesure reproductible à la publication est la piste B (journal_b.csv) : classement publié le jour J avant la clôture 00h00 UTC fin J, entrée à la clôture réelle du jour J, sortie à la clôture du jour J+1. Les lignes du journal historique (journal.csv, classements du 23/09/2026 au 01/10/2026) ont été mesurées à 08h10 UTC sur un classement du jour précédent dont le gel pré-fenêtre n'était pas encore engagé : elles ne sont PAS conformes à la règle B et ne représentent pas un parcours reproductible par un client à la publication. Conformément à la doctrine d'immutabilité, elles ne sont NI effacées NI recalculées : elles restent visibles à jamais sous l'étiquette « évaluation statistique interne (piste A) », distincte de la piste B. Les seules mesures présentées comme preuve publique reproductible sont les lignes de journal_b.csv, chacune adossée à un engagement vérifiable. Les lignes piste A du 02/10/2026 et du 03/10/2026 (classements gelés ce jour-là) restent elles aussi des mesures de statistique interne — la mesure reproductible de ces jours est la ligne B correspondante."
    },
    {
      "id": "t30-e1",
      "date": "2026-10-04",
      "dates_concernees": [
        "2026-09-23",
        "2026-09-24",
        "2026-09-25",
        "2026-09-26",
        "2026-09-27",
        "2026-09-28",
        "2026-09-29",
        "2026-09-30",
        "2026-10-01",
        "2026-10-02",
        "2026-10-03"
      ],
      "titre": "Présentation des frais : deux périodes distinctes, rien de rétroactif",
      "texte": "Correction de présentation (publiée le 04/10/2026). Règle définitive : la période initiale du forward test (classements du 23/09/2026 au 02/10/2026) est BRUTE — aucun frais n'y est déduit. À partir du classement du 03/10/2026, les frais de 0,30 % aller-retour sont déduits de chaque ligne (protocole 1.0). Faits exacts : notre post d'erratum du 03/10 affirmait que les frais avaient été déduits « rétroactivement sur tout l'historique », et cette déduction avait bien été exécutée sur le journal le 03/10 (1 386 lignes historiques à couts=0.0030 pendant ~24 h). Le 04/10, nous avons annulé cette déduction sur la période initiale : le journal historique est restauré à brut (couts=0.0000, rendement_net = rendement_brut), sans réécrire aucune mesure de prix — seul le champ de frais de ces lignes a été neutralisé, et l'opération est elle-même consignée ici. La période courante (à partir du 03/10) reste nette. Les résultats des deux périodes ne sont pas directement comparables : la période initiale est brute, la période courante est nette de frais. Le post d'erratum du 03/10 reste consultable dans les archives, avec sa version corrigée.",
      "lien": "https://www.strateforge.app/methodologie.html#erratum"
    },
    {
      "id": "t30-e2",
      "date": "2026-10-04",
      "dates_concernees": [
        "2026-10-01",
        "2026-10-02",
        "2026-10-03"
      ],
      "titre": "Compteurs des posts désynchronisés du JSON (début octobre)",
      "texte": "Correction de compteur (publiée le 04/10/2026). Les posts des 01/10 et 02/10 annonçaient des compteurs (« 8 jours », « 9 jours ») absents du scores.json servi à la même heure (clés nulles), et le post du 03/10 annonçait « 10 jours évalués, cumul panier −0,7 % » alors que le JSON servi à la même heure annonçait « 9 jours évalués, cumul panier −0,459 % ». Cause : les statistiques n'étaient pas rafraîchies après la mesure quotidienne et aucun contrôle ne vérifiait les textes contre le JSON. Le journal public était exact en permanence ; l'écart ne concernait que les compteurs des textes et du JSON dérivé. Corrigé le 04/10/2026 : recalcul des stats après chaque mesure, synchronisation du stats dans le scores.json public, et contrôle automatique (validate_chaine) exigeant que chaque post cite exactement les chiffres du JSON — tout écart bloque la publication.",
      "lien": "https://www.strateforge.app/forward-test/errata.json"
    },
    {
      "id": "t32-e1",
      "date": "2026-10-04",
      "dates_concernees": [
        "2026-09-23",
        "2026-09-24",
        "2026-09-25",
        "2026-09-26",
        "2026-09-27",
        "2026-09-28",
        "2026-09-29",
        "2026-09-30",
        "2026-10-01",
        "2026-10-02",
        "2026-10-03",
        "2026-10-04"
      ],
      "titre": "Observation « compression de volatilité » : percentile de largeur de Bollinger inversé",
      "texte": "Correction de formule (publiée le 04/10/2026). Dans l'observation d'événement « Compression de volatilité en cassure », le percentile de la largeur de Bollinger (4σ/ma20, fenêtre 120 j) était calculé à l'envers : la formule comptait la part de la fenêtre inférieure ou égale à la valeur courante, donnant ~100 quand la largeur était à son MINIMUM et ~0,8 à son maximum. Le seuil « percentile < 15 » déclenchait donc le texte « compression » sur une EXPANSION de la volatilité, et ne déclenchait rien sur une compression réelle. Vérification sur données réelles (30 actifs, 300 jours) : 99 jours-actifs en expansion réelle (percentile correct 87-100) avaient été étiquetés « compression » (ex. BTC 2026-06-04, ETH 2026-08-21), et 36 jours-actifs en compression réelle (percentile correct 0,8-13) ne déclenchaient rien (ex. LINK 2026-05-04, ETH 2026-09-11). L'observation publiée le 04/10 pour IMX (percentile affiché 5) était en réalité une expansion (percentile correct 94, largeur ×9,1 son minimum de fenêtre). Périmètre exact : seul le TEXTE d'alerte était affecté — la feature boll_b du modèle, les scores, les classements et le forward test n'utilisent jamais ce percentile. Corrigé le 04/10/2026 : percentile standard (part de la fenêtre ≤ valeur courante, convention identique à l'indicateur pine), le seuil < 15 déclenche désormais sur une compression réelle. Les publications du 23/09 au 04/10 citant cette observation sont à relire à l'envers : un percentile affiché élevé désignait une compression, un faible une expansion.",
      "lien": "https://www.strateforge.app/forward-test/errata.json"
    },
    {
      "id": "t39-c24-e1",
      "date": "2026-10-09",
      "dates_concernees": [
        "2026-10-04",
        "2026-10-05"
      ],
      "titre": "Horodatages publics des engagements des 4 et 5 octobre : attestations batch incorrectes, statuts probatoires marqués",
      "texte": "Erratum d'horodatage (identifié le 09/10/2026, tâche 39 palier P4, fiche C24). Les engagements des 4 et 5 octobre 2026 ont été publiés dans une récupération batch du 2026-10-06 (commit 16h39Z) qui a recopié les horodatages du 2026-10-03 pour le 2026-10-04, et omis le 2026-10-05. Les attestations internes (attestations.json) pour ces deux dates sont donc incertaines : le 2026-10-04 porte public_published_at=2026-10-03T16:00Z (antérieur au gel 2026-10-04T08:00Z, incohérence manifeste), et le 2026-10-05 est absent. Conformément à la doctrine d'immutabilité, les lignes originales sont CONSERVÉES sans modification ; des statuts probatoires sont ajoutés côte à côte : 2026-10-04 → statut_probatoire='non_démontrable' (attestation incohérente), 2026-10-05 → statut_probatoire='tardive' (publiée le 2026-10-06 après la clôture du jour engagé). L'engagement 2026-10-02 reste marqué 'vérifiée' (gel avant fenêtre, déviation documentée). Tous les engagements postérieurs au 2026-10-06 sont vérifiés par attestations complètes.",
      "lien": "https://www.strateforge.app/forward-test/errata.json"
    },
    {
      "id": "t39-p8-e1",
      "date": "2026-10-10",
      "dates_concernees": [
        "2026-10-02",
        "2026-10-03",
        "2026-10-04",
        "2026-10-05",
        "2026-10-07",
        "2026-10-08",
        "2026-10-09"
      ],
      "titre": "Corrections d'horodatage d'attestations (fuseau, faux positif, chaîne interrompue) — réparation P8",
      "texte": "Les horodatages de publication enregistrés dans attestations.json pour les engagements 2026-10-02, 2026-10-03 et 2026-10-04 portaient une troncature de fuseau : l'heure réelle du commit de première apparition (16:00 +08:00) avait été lue comme si le fuseau était Z, décalant les valeurs de 8 heures ('2026-10-03T16:00Z' enregistré partout). Les valeurs réelles, prouvées par git (git log --diff-filter=A sur la preuve publique de chaque jour), sont : 2026-10-02 → 2026-10-05T20:58Z (6d67387), 2026-10-03 → 2026-10-04T08:00Z (b52d045), 2026-10-04 → 2026-10-03T08:00Z (2e1df99). Les publications des engagements 10-02 et 10-03 sont ainsi TARDIVES (après la clôture de leur fenêtre) : le mécanisme de déviation documentée (fiche 17) s'applique — le gel interne (calcul du hash au scoring, 08:00Z le jour J, archives internes) précède la fenêtre mesurée et la récupération batch a publié ensuite ; la règle B est inchangée pour ces jours. L'engagement 10-04 reste « non_démontrable » (sa première preuve publique est antérieure au jour engagé, incohérence de batch). L'engagement 10-05, publié le 2026-10-06 après clôture SANS déviation documentée, reste « tardive » sans ligne B. Enfin, la valeur public_published_at 08:00Z du 2026-10-07 était un faux positif du bug t37 (publication supposée, jamais poussée — dernier push engagements.json avant réparation : 2026-10-06T18:46Z) : elle est retirée, le scoring du jour étant réel (validated_at 08:00Z, log). Les engagements 2026-10-08 et 2026-10-09 n'ont jamais été rendus publics : la chaîne de publication était interrompue du 2026-10-07 au 2026-10-09 (mesure_b TypeError nonce + défauts validateur t37/C35/C36), réparée le 2026-10-10. Conséquence : aucune ligne B pour ces jours (règle B anti-extrapolation) ; les mesures reprennent au run du 2026-10-10. Aucune valeur inventée : toutes les corrections sont vérifiables par git et les logs de run."
    }
  ]
}