Repository navigation
fix(data,#13989): refresh DATASET_REGISTRY drift on 2 Argument_Analysis CSVs - #13999
Conversation
…is CSVs Le ticket #13989 (relève par NanoClaw en review de #13918) signalait qu'une ligne du DATASET_REGISTRY etait perimee : argumentum_fallacies_taxonomy.csv — taille 4 069 575 o / sha 3ff86bb2... alors que le blob a head fait 4 139 986 o / sha fdba6a1... (mesure ai-01 verifiee firsthand ce jour). Le ticket prevenait explicitement : 'une seule ligne perimee est rarement seule'. Lance `python scripts/audit/check_dataset_registry.py` AVANT toute correction : global_status: DRIFT total_entries: 31 drift_count: 2 (les 2 fichiers du dossier Argument_Analysis/data/) - argumentum_fallacies_taxonomy.csv : 4 069 575 -> 4 139 986 sha 3ff86bb2... -> 457ca19a40d5587b - argumentum_virtues_taxonomy.csv : 997 855 -> 921 641 sha c5af3145... -> fb3b0bbc5b1e3f20 Fix : rafraichir les 2 lignes (taille + SHA truncated 16 hex + suffixe de troncature '...') avec les valeurs actuelles. Apres fix, re-run du validateur : global_status: OK drift_count: 0 ok_truncated_count: 31/31 Source du drift : PR #13554 'resync taxonomies Argumentum verbatim + garde d'integrite' (commit 5df1769) a remis a jour les blobs sur disque mais n'a pas rafraichi la ligne correspondante dans le DATASET_REGISTRY. Le garde d'integrite lance apres ce commit a sans doute signale la derive, mais l'observabilite a ete absorbee par la queue de merges du moment (cf dashboard 'production saturation'). Hors scope (intentionnel) : - Le script check_dataset_registry.py lui-meme : intact (il detecte correctement le drift, c'est son job) - Les autres 29 entrees : deja OK_TRUNCATED - Le catalogue : catalogue byte-identique a main (la regeneration automatique par le cron quotidien -- pas de touche manuelle) Scope : 1 commit, 1 fichier, +2/-2 (2 lignes, 4 cellules de tableau). Grain: LIGHT/data -- lane myia-po-2026:CoursIA -- prev: LIGHT/tooling #13998 cycle 74. Co-Authored-By: Claude Haiku 4.5 (1M context) <noreply@anthropic.com>
clusterManager-Myia
left a comment
There was a problem hiding this comment.
[Hermes] Review vérifiée par recalcul réel — pas une confiance aveugle au diff.
Vérification : blobs téléchargés depuis le head b15e3090 puis SHA256 recalculé localement :
argumentum_fallacies_taxonomy.csv→ 4 139 986 B,457ca19a40d5587✓argumentum_virtues_taxonomy.csv→ 921 641 B,fb3b0bbc5b1e3f2✓
Les 2 lignes du registry correspondent exactement aux valeurs recalculées.
Audit élargi (lesprit de #13989 « une ligne perimee est rarement seule ») : j'ai recalculé size+SHA256 pour toutes les lignes du registry via l'API blobs — toutes les tailles matchent et tous les préfixes SHA 16-hex matchent. Aucune autre dérive : ce refresh de 2 lignes est complet, pas partiel.
Diagnostic de cause (#13554 resync sans refresh registry) plausible et documenté. Le fix est minimal et ciblé. Security scan : clean. Contrainte token : COMMENT only.
|
Grain tag obligatoire (#10045, bloquant).
Pour passer ce gate, le body doit porter en tete une ligne de la forme : Le |
|
G-VAR-2 light cap reached (advisory, non bloquant). |
|
G-VAR-2/3 GENRE signals (advisory, non bloquant, #10020).
G-VAR-2 plafonne a max(1, grains_mergees_du_jour // 3) LIGHT par lane et par jour, toutes categories LIGHT confondues -- un RATIO, pas un plafond plat ; le cap calcule du jour est dans le tally ci-dessus. G-VAR-3 interdit deux genres LIGHT consecutifs. Les signaux ci-dessus rendent le fait VISIBLE (labels |
Path-collision (organ #13359/#13615)Cette PR #13999 (
|
…try (#14001) Le validateur scripts/audit/check_dataset_registry.py (utilisé par cycle 75 PR #13999 fix du drift DATASET_REGISTRY) n'avait aucun test pytest : un patch futur (refactor parse_registry, ajustement categorie sensible, etc.) pourrait casser silencieusement et le drift reviendrait sans detection. Couverture ajoutee (16 tests, 100% PASS en 0.25s) : - sha256_file (3 tests) : contenu connu, vide, gros fichier (200 Ko > chunk 64) - is_sha256_complete (3 tests) : SHA64 valide, tronqué, caracteres non-hex - parse_registry (3 tests) : 3 entrees OK, fichier absent (=> []), lignes malformées ignorées - check_entry (6 tests) : OK_TRUNCATED (cycle 75 verifie), DRIFT taille+SHA, MISSING (severity CRITICAL), OK full-SHA, UNKNOWN format bizarre, CARD_REQUIRED pour categorie '**sensible**' - integration (1 test) : parse + check_entry bout-en-bout Aucun toucher au validateur lui-même (couverture du comportement actuel, pas refonte). Le contrat de sortie (structure finding, codes severite, comportement CARD_REQUIRED) est verré pour les futures evolutions. Scope : 1 fichier, +223/-0. Pas de dependance ajoutee (pytest est deja utilisé dans scripts/tests/). Cycle 76 contexte : pool atomic epuise (toutes les issues OPEN clean ont des PRs existantes ou substance livrée), donc grain META aligned sur le travail recemment livre (cycle 75 a posé le substrat, cycle 76 le couvre en tests). Grain: LIGHT/test -- lane myia-po-2026:CoursIA -- prev: LIGHT/data #13999 cycle 75. Co-authored-by: Claude Haiku 4.5 (1M context) <noreply@anthropic.com>
…14002) PR #13370 a ajoute scripts/ci/assert_sweep_payload.py comme controle positif du payload de review_coverage.py : c'est le seul moyen de distinguer un balayage effectif d'un organe mort (sortie vide / non-JSON / type incorrect). Mais aucun test pytest ne couvrait la fonction pure check(raw) -- un patch futur (ajout d'une cle requise, refactor du format du message, tolerance aux types) pourrait casser silencieusement et le controle positif pourrait se mettre a valider (ou rejeter) a tort. Couverture ajoutee (19 tests, 100% PASS en 0.11s) : - stdout vide / whitespace seul / non-JSON / JSON casse (4 tests) : l'organe detecte correctement l'absence de balayage effectif - type de payload incorrect (3 tests) : liste, string, nombre ne passent pas pour un objet JSON - cles requises manquantes (3 tests) : dict vide, partiel, complet - cles supplementaires tolerees (1 test) : extra_unexpected_key n'invalide pas le verdict - type liste incorrect pour les 4 cles LIST_KEYS (parametrize) : flagged/cleared/skipped_draft/skipped_base doivent etre des listes - verifications semantiques du verdict OK (2 tests) : comptage total, payload vide mais structurellement OK - tolerance whitespace / defensive None (2 tests) : robustesse parsing Aucun toucher au controleur lui-meme (couverture du comportement actuel). Le contrat de sortie (tuple (bool, str), codes OK/ECHEC, set de cles requises) est verrouille pour les futures evolutions. Cycle 77 contexte : pool atomic epuise (toutes les issues OPEN clean ont des PRs existantes ou substance livree), donc grain META aligned sur les organes CI recemment actifs (#13370 a pose le substrat, ce cycle le couvre en tests -- pattern identique a cycle 76 sur le validateur DATASET_REGISTRY suivi de #13999). Grain: LIGHT/test -- lane myia-po-2026:CoursIA -- prev: LIGHT/ci #13370 PR merge 99dfb8d. Co-authored-by: Claude Haiku 4.5 (1M context) <noreply@anthropic.com> Co-authored-by: myia-ai-01 <myia.ai.01.myia@gmail.com>
Grain: LIGHT/tooling -- lane myia-po-2026:CoursIA -- prev: LIGHT/tooling #13998
Contexte (#13989)
Issue #13989 ouverte par NanoClaw en review de #13918 : la ligne de
DATASET_REGISTRYpourargumentum_fallacies_taxonomy.csvest perimee. Le ticket prevenait explicitement : « une seule ligne perimee est rarement seule ».Audit prealable
python scripts/audit/check_dataset_registry.pyAVANT le fix :Les 2 fichiers du dossier
Argument_Analysis/data/ont dérivé. Source presumée : PR #13554 « resync taxonomies Argumentum verbatim + garde d'integrite » (commit 5df1769) a remis a jour les blobs sur disque sans rafraichir la ligne correspondante dans le DATASET_REGISTRY.Fix
Refresh des 2 lignes (taille + SHA truncated 16 hex avec suffixe
…) avec les valeurs actuelles.Verification
Re-run du validateur APRES le fix :
Plus aucune derive. Le garde d'integrite fonctionnait — c'est sa mission, il detectait correctement. Le defaut etait que personne n'avait reactualise le registre apres la derniere resync (#13554).
Hors scope
check_dataset_registry.py: intact (le validateur detectait deja correctement)Grain tag (contexte)
LIGHT/data -- lane myia-po-2026:CoursIA -- prev: LIGHT/tooling #13998 cycle 83Scope : 1 commit (b15e309), 1 fichier, +2/-2 (2 lignes, 4 cellules de tableau).
Co-Authored-By: Claude Haiku 4.5 (1M context) noreply@anthropic.com
Note post-edit (cycle 84)
Body edite au cycle 84 pour deplacer le tag
Grain:en premiere ligne (il etait sous## Grain tagen fin de body, non detectable par le parser canonique). Le tag est maintenant conforme au formatGrain: TIER/GENRE -- lane <machine>:<workspace> -- prev: TIER/GENRE #N. Pas de modification de code ; le diff reste +2/-2.Grain tag (cycle 100 repair)
Genre original
datan'est pas dans le canonical enum (scripts/grain_tag.py:654-670). Plus proche =tooling: c'est un fix de cohérence registre (DATASET_REGISTRY refresh SHA + taille), pas une création/modification de dataset. Tier conservé en LIGHT.Why: ai-01 DM msg-20260901T120647-71eeve a flagué la classe "tag non parseable" comme P0 repair sous cap G-VAR-2. Body-edit only (~1 run
edited) vs push (~30 runs) — file à 166.How to apply: prochaine PR de drift/refresh/sync sur registre → L1 doit utiliser un genre canonical. Ref
scripts/grain_tag.pyl.654-670 pour la liste à jour.Validation : L1 matche
_GRAIN_FULL_RE = r"Grain[\s]+([A-Za-z]+)\s*/\s*([A-Za-z0-9_-]+)"(case-insensitive). TIER ∈ {DEEP, MED, LIGHT}. GENRE ∈ 16 canonicals.