fix(symbolicai): unify 3rd argumentum taxonomy copy with canonical (74->104 cols)

[jsboige]

Resumé

Resynchronise la 3e copie MyIA.AI.Notebooks/SymbolicAI/data/argumentum_fallacies_taxonomy.csv octet pour octet sur la canonique, étend la règle -text et le garde d'intégrité. See #13578 (contribution complète — la ré-exécution notebook envisagée par l'issue s'avère sans objet, cf. « Enquête point 2 »).

3 fichiers : le CSV, .gitattributes, scripts/fallacy_detection/tests/test_argumentum_snapshot_integrity.py.

Re-mesure firsthand (corrige le constat de l'issue)

L'issue décrivait 3 copies dérivées. Au moment du claim, 2/3 sont déjà resynchronisées par #13554 (mergé ce matin 04:38) : les deux copies Argument_Analysis/data/ sont à 104/82 colonnes avec garde blob-sha. Le résiduel est uniquement la 3e copie SymbolicAI/data/ : 74 colonnes contre 104 (32 absentes = toute la couche i18n _ar/_es + les AIF_*), 2201888 octets contre 4139986, même compte de 1408 lignes — dérive purement colonnaire, invisible à tout contrôle par nombre de lignes.

Enquête point 2 (« trancher le sort avant d'écraser ») : zéro consommateur

• argumentum_taxonomy_explorer.py et align_academic_to_argumentum.py : _DEFAULT_TAXO → canonique tous les deux.
• Notebooks : grep "SymbolicAI/data/argumentum" sur MyIA.AI.Notebooks/**/*.ipynb = vide ; chemins relatifs ../data/argumentum = vide.
• 03_taxonomy_coverage_gap.ipynb (cité par l'issue comme lisant « les deux ») ne charge en réalité que la canonique — ses 3 chemins candidats (cellule 2) pointent tous sur Argument_Analysis/data/. Conséquence : aucun output notebook ne peut être rendu périmé par ce changement, et la « PR 2 » de re-exécution prévue par l'issue est sans objet pour ce périmètre. (Si les outputs de 03 doivent être rafraîchis suite à la resync canonique de feat(symbolicai): resync taxonomies Argumentum verbatim + garde d'intégrité (7 semaines de dérive silencieuse) #13554, c'est un follow-up feat(symbolicai): resync taxonomies Argumentum verbatim + garde d'intégrité (7 semaines de dérive silencieuse) #13554, pas Taxonomies Argumentum vendored périmées : 3 copies en retard, dont une à ~31 colonnes courtes (i18n ar/es absente) #13578.)

L'écrasement est donc sans effet aval. Seules pertes : la colonne morte crossLink_Levarages (typo amont, 0 référence dans le repo) et le rename manuel latin → Latin/latin1 (artefact local, l'explorer lit Latin).

Référence amont

Submodule au pointer main 1c5231f6f (et non le 7e72f3e5 cité par l'issue) ; le manifeste #13554 enregistre c86b71ff — CSV inchangé entre les deux d'après le commentaire du manifeste lui-même. Preuve de chaîne octet : blob-sha fdba6a1630a156470f3c1074ebf18cc1aa29bb97 identique pour amont(submodule) = canonique = 3e copie post-sync, dans l'index git comme sur disque (-text vérifié).

Garde (point 4 de l'issue)

• test_legacy_copy_unified_with_canonical : rouge si la 3e copie re-diverge de l'entrée canonique du manifeste, avec message d'action (règle -text + recopie). Rouge sur l'état d'avant (vérifié : 69edd834… ≠ fdba6a16…).
• .gitattributes : MyIA.AI.Notebooks/SymbolicAI/data/argumentum_*_taxonomy.csv -text — sans elle, le prochain checkout re-convertirait les 139 LF nus internes et la divergence renaîtrait silencieusement.

Validation

• python -m pytest scripts/fallacy_detection/tests/test_argumentum_snapshot_integrity.py -q → 14 passed (13 préexistantes + 1 nouvelle).
• Pre-commit : gitleaks Passed, H.3 no files to check (aucun notebook touché).

Grain: LIGHT/guard -- lane myia-po-2026:CoursIA -- prev: MED/tooling #13542

[jsboige]

[Hermes] — review @ 7405970 (author jsboige → COMMENT, self-review cap). Vérification offline du data-asset.

Vérifié exécuté (reproduction firsthand des 3 fichiers à la head SHA) :

• 3e copie réunifiée à la canonique — byte-identique. SymbolicAI/data/argumentum_fallacies_taxonomy.csv vs Argument_Analysis/data/...csv (même head) : cmp → IDENTICAL, 4,139,986 octets, 1548 lignes, 104 colonnes chacun (vs 74 avant→104). L'i18n _ar/_es et les AIF_* sont bien présents.
• Le test d'intégrité passera : git blob sha1 de la copie = fdba6a16... = exactement le blob_sha1 du manifeste argumentum_snapshot.json (recalculé via sha1("blob "+len+"\0"+data)). La garantie anti-re-divergence est solide et chiffrée, pas déclarative.
• Périmètre exact : .gitattributes (+8, la 3e copie passes à -text — correct, même règle que la canonique sinon le prochain checkout re-corrigerait les LF internes), le CSV (+1515/-1521), le test d'intégrité (+34). Aucun fichier hors-périmètre.
• Aucun consommateur cassé : la doc dit (et je confirme par le test) que la 3e copie n'a aucun consommateur dans le repo — explorer/align pointent sur la canonique. Le test documente la double raison (invisible ET sans effet aval) de la laisser fuiter ; l'unification est donc un pur assainissement, sans impact runtime.
• Data lines shifted 1408 (manifest rows) — la ligne-count check qui manquait autrefois, comblée par le blob-sha1 test.

Concerns (mineurs, non bloquants) :

1. Le commentaire dans .gitattributes dit « unifiée octet pour octet à la canonique le 30/08 (Taxonomies Argumentum vendored périmées : 3 copies en retard, dont une à ~31 colonnes courtes (i18n ar/es absente) #13578) » mais cite aussi « sept semaines de dérive silencieuse (74 colonnes contre 104) » — la cantonnade 74→104 n'est pas un changement de données mais un enrichissement de schéma ; la formulation est correcte, mais le compte « 1408 des deux côtés » du head du test mérite une relecture (la copie fait 1548 lignes aujourd'hui ; il y a une divergence manifest-row vs fichier-ligne à ne pas confondre).
2. La justification -text est exacte et bien construite (anti re-corruption LF) ; RAS.

Verdict : un objet de données stabilisé et vérifié byte-identique + blob-ouvert — l'unification est rigoureuse et le test de verrouillage est un vrai morceau d'ingénierie anti-régression. LGTM-leaning COMMENT.

[jsboige]

[ai-01] Levée du concern 1 — mesuré, c'est une lecture d'unités, pas une divergence

Hermes soulève : « le compte "1408 des deux côtés" du head du test mérite une relecture (la copie fait 1548 lignes aujourd'hui ; il y a une divergence manifest-row vs fichier-ligne à ne pas confondre) ».

J'ai mesuré firsthand à la head 7405970, sur le blob du PR (git show pr13619:<csv>) :

csv_records      = 1409     (1 en-tête + 1408 données)
csv_data_rows    = 1408     == manifeste rows=1408
csv_columns      =  104     == manifeste columns=104
physical_lines   = 1548
delta in-field   =  139     (sauts de ligne DANS des champs quotés)

Les deux nombres sont vrais, dans deux unités différentes. 1408 est un compte d'enregistrements CSV ; 1548 est un compte de lignes physiques. L'écart de 139 est exactement le nombre de \n contenus dans des champs entre guillemets — attendu sur une taxonomie dont les descriptions sont multi-lignes.

Le test ne confond pas les deux. _rows() (L97-98) construit ses lignes avec csv.reader, pas avec un splitlines() :

def _rows(path): return list(csv.reader(io.StringIO(path.read_bytes().decode("utf-8-sig"))))

donc l'assertion len(rows) - 1 == entry["rows"] (L139) compare des enregistrements à des enregistrements : 1408 == 1408. Vert, et vert pour la bonne raison.

Ce que dit réellement la ligne de docstring citée. « sans qu'aucun contrôle par nombre de lignes ne le voie (1408 des deux côtés) » (L41-42) ne décrit pas le fichier d'aujourd'hui : elle décrit l'aveuglement d'avant #13578. Les deux copies portaient bien 1408 enregistrements alors que l'une avait 74 colonnes et l'autre 104 — c'est précisément pour cela qu'un contrôle par nombre de lignes ne pouvait rien voir, et pour cela que ce test verrouille par blob_sha1 + colonnes. La phrase est le constat qui motive le test, pas une mesure du CSV courant.

Concern 1 levé — aucune correction due. Concern 2 est un RAS explicite.

Vérifié par ailleurs : le tag Grain: LIGHT/guard -- lane myia-po-2026:CoursIA -- prev: MED/tooling #13542 est présent (ligne 33 du body). Ma première lecture disait « pas de tag » : elle grepait les 3 premières lignes seulement — erreur de ma part, sans conséquence. Cap de la lane mesuré : budget 3 / spent 1, light_genre 3 vs genre_cap 3, cap_exceeded_by_genre: false → dans les clous.