fix(translation,#19023): lot 5 -- clé des 39 lignes ICT-45 vers ICT-42b

[jsboige]

Grain: MED/ledger — lane myia-po-2026:CoursIA-2 — prev: LIGHT/guard #19985

Ce que la PR livre

Le lot 5 du chantier 2 de #19023 : la clé des 39 lignes d'iit.csv laissées sur ICT-45-InoculationBifurcation-9B-Python.ipynb par le renommage en ICT-42b-… (#19153).

Le reliquat est nommé par le coordinateur dans son point d'étape du 2026-10-05, avec son critère de clôture : « check_translation_sync.py rend 0 ORPHAN_ROW sur ICT-45 ». Mesure sur origin/main (98a4629e94) avant cette PR : 39 ORPHAN_ROW, toutes sur ce carnet — le critère était faux.

Mesure

python scripts/translation/check_translation_sync.py translations/iit/iit.csv

Classe	Avant	Après
ORPHAN_ROW	39	0
SRC_DRIFT	32	32
PIVOT_HASH_MISMATCH	1	1
total	72	33

La soustraction est exactement celle des 39 orphelines : aucune anomalie nouvelle dans une autre classe, et les 33 restantes sont préexistantes et hors périmètre de ce lot (le chantier 2 de #19023 les traite par lots de resync, pas ici).

Méthode — et un écart assumé avec la consigne du coordinateur

Le point d'étape dit : « Le changement de clé de ces lignes vers ICT-42b-… se fait par l'organe extract_cells_to_csv.py, jamais à la main. »

L'organe ne sait pas faire ce geste, et c'est vérifié dans son code, pas supposé. update_existing_csv() (scripts/translation/extract_cells_to_csv.py, l. 205-240) a quatre branches : rafraîchir les champs pivot d'une ligne dont la clé (notebook, cell_id) existe, appendre une cellule fraîche sans ligne correspondante, conserver verbatim les lignes des carnets hors cible, et conserver les lignes cibles sans cellule fraîche. La dernière branche est explicite (« on ne détruit pas la ligne sans décision humaine »). En mode --full (target_notebooks = None), les lignes sans cellule fraîche sont comptées (kept_orphan) mais jamais retirées.

Sur ce cas, --update seul aurait donc empiré l'état : 39 lignes ICT-45-… conservées en orphelines plus 39 lignes ICT-42b-… nouvellement appendues.

Le geste retenu est celui du précédent du dépôt — a0b9f8cf81 (#18154, « resync iit.csv miroir après renumérotation », qui documente une substitution de la colonne 1 seule après un renommage en masse) :

1. Substitution de la colonne 1, et d'elle seule. Les 39 occurrences du chemin dans le fichier sont toutes en tête de ligne et aucune n'apparaît ailleurs (mesuré : t.count(chemin) == 39) ; la substitution est donc faite ligne à ligne, ce qui préserve byte pour byte le reste du fichier, text_fr compris. Le diff le montre : 39 insertions / 39 délétions, un champ par ligne.
2. L'organe reprend la main ensuite : extract_cells_to_csv.py <ICT-42b> --update translations/iit/iit.csv → 1 ligne(s) rafraîchie(s), 38 déjà in-sync, 0 ajoutée(s), 0 orpheline(s) potentielle(s), 2549 ligne(s) d'autres notebooks préservées. C'est lui qui possède la synchro des pivots — la seule ligne qu'il a touchée est un hash_fr stale, pas un texte.

Ce qui est « à la main » est donc borné au renommage de clé, que l'organe ne couvre pas ; tout le reste du contrat (rafraîchissement des pivots, préservation des colonnes cibles T3, non-destruction des autres carnets) est bien exécuté par l'organe. Le dire est le point : étendre extract_cells_to_csv.py d'un mode --rekey <ancien> <nouveau> serait le correctif de fond, et il reste à faire — cette PR ne l'ajoute pas, elle livre le lot.

Gardes — deux signaux, assumés et documentés

translation-guard (bloquant) : clé double #10332 posée. Le garde refuse qu'un auteur non-bot touche translations/**, et il a raison de le faire. Le script lui-même nomme l'issue : « translation-sync is on manual-maintainer hold since 2026-08-12 (#10038) — editing the FR source does not refresh the derived file until the hold is lifted; while it stands, the dual-key override (#10332) is the expected exit for a legitimate change. » Le label translation-override et le commentaire [TRANSLATION-OVERRIDE] sont donc posés, avec le motif. Vérifié par GET : guard_pass: true, label_present: true, marker_present: true.

check_resync_only (advisory, non bloquant) : la PR est classée resync_only. Ce classement vise les PRs qui poursuivent un SRC_DRIFT nul sur une table traduite à 0 %, ce qui est non informatif tant que le moteur T3 n'a rien déposé (#9431, #6949). Ce n'est pas ce que fait cette PR : elle ne poursuit pas un drift, elle retire des lignes dont la clé référence un carnet qui n'existe plus — un état que le contrôleur ne sait pas distinguer d'une cellule supprimée, et qui laisse 39 lignes définitivement inutilisables. Le SRC_DRIFT reste d'ailleurs à 32, inchangé : la PR ne le touche pas.

L'édition est idempotente vis-à-vis de la chaîne : rejouer T1 sur ce carnet reproduit exactement l'état livré. L'invariant que le garde protège — « la prochaine passe écraserait l'édition » — est donc satisfait, pas rompu.

Contrôles

• Correspondance des clés : les 39 cell_id du CSV et les 39 cellules extraites du carnet renommé coïncident exactement (0 d'un côté seulement). C'est ce qui autorise la substitution pure plutôt qu'une régénération.
• Ordre préservé (la contrainte du chantier 1) : la séquence des carnets est identique avant/après ; le seul écart est le nom lui-même, au même index. Aucune ligne déplacée.
• Pas de doublon : 0 paire (notebook, cell_id) dupliquée après le geste.

Périmètre

Un fichier : translations/iit/iit.csv. Aucun carnet modifié, donc aucune ré-exécution due (C.2).

See #19023 — le chantier 2 garde 33 anomalies préexistantes (32 SRC_DRIFT, 1 PIVOT_HASH_MISMATCH) hors de ce lot.

🤖 Generated with Claude Code

[jsboige]

[TRANSLATION-OVERRIDE] Lot 5 de #19023 : cle des 39 lignes ICT-45 -> ICT-42b dans translations/iit/iit.csv.

Motif : l'organe extract_cells_to_csv.py ne sait pas renommer une cle. update_existing_csv() (l.205-240) rafraichit les pivots d'une cle existante, APPEND une cellule fraiche sans ligne, conserve verbatim les lignes hors cible, et CONSERVE les lignes cibles sans cellule fraiche ('on ne detruit pas la ligne sans decision humaine') ; en --full il les compte (kept_orphan) sans jamais les retirer. Le renommage ICT-45 -> ICT-42b (#19153) a donc laisse 39 ORPHAN_ROW que l'organe ne peut pas resorber -- seul un --rekey, qui n'existe pas, le ferait.

L'edition est IDEMPOTENTE vis-a-vis de la chaine : substitution de la colonne 1 seule (39 lignes, precedent #18154), puis extract_cells_to_csv.py --update rend '1 rafraichie, 38 deja in-sync, 0 orpheline'. Rejouer T1 sur ce carnet reproduit exactement l'etat livre -- l'invariant du garde ('la prochaine passe ecraserait l'edition') n'est pas rompu, il est satisfait.

Mesure : ORPHAN_ROW 39 -> 0 ; SRC_DRIFT 32 -> 32 et PIVOT_HASH_MISMATCH 1 -> 1 (pre-existants, hors lot) ; total 72 -> 33.

Geste demande par le coordinateur (point d'etape du 2026-10-05 sur #19023, critere de cloture 'ORPHAN_ROW = 0 sur ICT-45').

[github-actions]

G-VAR-2 light cap reached (advisory, non bloquant).
La lane myia-po-2026:CoursIA-2 a deja consomme son budget LIGHT du jour (#19985 (merge a 2026-10-09T02:52:43Z)).
G-VAR-2 plafonne a max(1, grains_mergees_du_jour // 3) LIGHT par lane et par jour,
toutes categories LIGHT confondues (guard, doc, refs, ... partagent un seul budget) :
c'est un RATIO, pas un plafond plat. La decision de merge reste au coordinateur.

[github-actions]

Trivial-diff advisory (#15740, non bloquant).
genre ledger dans la famille META (docs/guard/ledger/readme/test) + diff de 80 lignes changees (<= 100) + aucune exception ecrite dans le body : le litmus de la trivialite (une douzaine d'instances scannees a la suite) est credible. Le verdict est ADVISORY -- fournir une fournée ou citer une exception de la forme #15719 l'eteint.
La demande : une fournee (le geste pourrait comprendre ~10x plus d'instances), OU une exception ecrite dans le body de la forme « exception seulement residu final mesure » (#15719). Editer le body re-deroule cet organe et retire le label.

[jsboige]

[ADJOINT PREFLIGHT]
schema: 1
lane: myia-po-2026:CoursIA-3
pr: 20033
head: a1b2a8c
complete: true
body: read
comments-reviewed: 3
reviews-reviewed: 0
threads-reviewed: 0
threads-unresolved: 0
surfaces-sha256: 27b1e9cfd16fdbf754b8a39f2a54b0240cb1ebff5def830c994e355dc55d5769
diff-files: 1
diff-additions: 40
diff-deletions: 40
checks: BLOCKED
b0: clear
scope: pass
domain: pass
verdict: BLOCKED
organ: check_adjoint_prevalidation.py
organ-command: python scripts/check_adjoint_prevalidation.py --derive-verdict 20033
organ-rc: 3
[/ADJOINT PREFLIGHT]

[github-actions]

Path-collision (organ #13359/#13615)

Cette PR #20033 (fix(translation,#19023): lot 5 -- clé des 39 lignes ICT-45 vers ICT-42b) touche au moins un chemin de fichier aussi modifie par d'autres PRs ouvertes. Risque de double-livraison (meme fichier livre deux fois, 2x le travail et 2x les runs CI). Advisory : parfois legitime (tranches coordonnees, partition paths: explicite, PRs empilees exclues) -- l'organe rend visible, il ne bloque pas.

• terminal -- fix(translation,#19023): resync lot 4 FINAL -- 32 carnets ICT (66 drifts corriges, 0 sur le lot) #19046 partage : translations/iit/iit.csv, recouvrement de chemins 100% -- fix(translation,#19023): resync lot 4 FINAL -- 32 carnets ICT (66 drifts corriges, 0 sur le lot) #19046 est deja sur main. (issues communes : translations/iit/iit.csv : duplication systemique (~1100 lignes en double sur 93 carnets) + ~304 drifts T1 preexistants #19023) (issues communes : translations/iit/iit.csv : duplication systemique (~1100 lignes en double sur 93 carnets) + ~304 drifts T1 preexistants #19023)

Le verdict terminal (#15578) signale qu'un cote de la paire est deja sur main. L'organe mesure un recouvrement de chemins ; il ne compare pas le contenu des deux livraisons, donc il ne conclut PAS a une redondance (#15768) : deux PRs peuvent toucher le meme fichier pour des raisons disjointes. L'arbitrage reste a la lane ou au coordinateur.

[jsboige]

[ADJOINT PREFLIGHT]
schema: 1
lane: myia-po-2026:CoursIA-3
pr: 20033
head: a1b2a8c
complete: true
body: read
comments-reviewed: 5
reviews-reviewed: 0
threads-reviewed: 0
threads-unresolved: 0
surfaces-sha256: 781fcb6720a566d6b4eb4d3df862de452e951d51480ba78aea14851c847d17d9
diff-files: 1
diff-additions: 40
diff-deletions: 40
checks: latest-wins-green
b0: clear
scope: pass
domain: pass
verdict: READY
organ: check_adjoint_prevalidation.py
organ-command: python scripts/check_adjoint_prevalidation.py --derive-verdict 20033
organ-rc: 0
supersedes: 4
supersedes-why: le motif de l'ancien dossier (checks non agregees au moment du dossier BLOCKED anterieur) est eteint et mesure : les checks sont verts au fold latest-wins a la tete a1b2a8c et le gate derive READY (B.0 rc=0) -- ai-01 DM c1310 avait mesure « checks verts a la tete », le gate le confirme ce cycle.
[/ADJOINT PREFLIGHT]