[jsboige]

Grain: DEEP/tooling -- lane myia-ai-01:CoursIA-2 -- prev: DEEP/notebook-python #23166

Budget de creation de carnets a l'echelle de la flotte + garde de provenance (#23174)

See #23174 — la PR livre les trois morceaux demandes par l'issue, chacun
avec sa mesure. Le regime ralentit la creation, il ne l'arrete pas :
rien n'est bloque sans un compte qui depasse, et tout repart des que le
compte redescend.

---

1. Ce que l'issue demande, et ce que cette PR livre

Piece demandee	Livree ou	Ou
1. Budget de creation a l'echelle de la flotte, derive d'une mesure, cause nommee BUDGET CRÉATION	oui	scripts/creation_budget.py (detection + derive), scripts/ci/creation_budget_counter.py (l'etat), scripts/pick_idle_grain.py (la porte)
2. Provenance d'un carnet neuf (issue servie par un tirage, ou creee >= 48 h avant la PR), advisory d'abord	oui	scripts/ci/check_creation_provenance.py + .github/workflows/creation-provenance-advisory.yml
3. Simulation de la semaine 21-28/10 dans le body, controle negatif compris	oui	§4 et §5 ci-dessous, rejeu par scripts/ci/simulate_creation_budget.py

Hors perimetre, comme demande : le tri des 84 EPICs de creation, et le
plancher G-VAR-1 (inchange).

---

2. La mesure qui etablit le fait

Avant d'ecrire une porte, on mesure l'ecart sur des PRs ouvertes (le
realite, pas l'intention) :

• 22 PRs ouvertes ajoutent chacune un .ipynb (4 le 26/10, 5 le 27/10,
  13 le 28/10) ; 100 modifient un carnet existant ;
• sur origin/main, 89 carnets neufs ont ete ajoutes en 7 jours glissants
  (git log --diff-filter=A, 86 hors jumeaux _en), 121 par les PRs de
  la flotte creees dans la semaine 21-28/10 (statut added, hors jumeaux).

C'est cet ecart qui etablit qu'il y a une derive a ralentir. Le regime ne
s'appuie pas sur une intention.

Mesures remesurees le 2026-10-28 apres la correction de la population
de la garde de provenance (§7). La premiere version de ce paragraphe
comptait comme « ajout de carnet » les PRs qui modifient un carnet
existant : d'ou les 30 et 120 d'aujourd'hui, et les 143 « par PRs de
flotte » de la version initiale. L'API des fichiers d'une PR porte le
statut GitHub (added / renamed / modified) : seule la premiere fois
porte added. Les trois populations sont des PRs de flotte ; les
diffs sont dus au filtre de statut, pas a un changement de perimetre.
Les compteurs main ont aussi recule (90 -> 89) : la fenetre glissante
de 7 jours se referme au fil des merges.

3. La detection : le depot est l'oracle, la prose est un temoignage date

« Ce grain livre-t-il un carnet neuf ? » se repond en opposant le depot
(git ls-tree -r origin/main) a l'issue :

• O1 serie + rang : le rang est-il deja livre dans cette serie ?
• O2 fichier cite : l'issue cite-t-elle un .ipynb absent du depot ?
• O3 phrase : l'issue DECLARE-t-elle la creation ?

Un veto de reparation (audit, correction, renumerotation, collision,
prose) l'emporte sur les trois : un grain de reparation n'est jamais
ecarte. Le sens de l'erreur est choisi — on saute un carnet neuf
quand on le sait, on ne saute pas un grain qu'on ne sait pas classer.

Precision mesuree (jeu de controle derive des PRs ouvertes : positifs =
Add|Feat qui ajoutent un .ipynb absent de main, negatifs =
Fix|Docs|Refactor qui modifient un .ipynb present) :

Detecteur	Precision	Rappel
cette PR (scripts/creation_budget.py)	1,00 (0 faux positif / 55)	0,92 (11 des 12 positifs classables ; 7 indetermines)
polarite existante (series_saturation.polarity)	0,67	0,11

L'issue demandait de mesurer la precision de la polarite existante avant
de s'y fier : la mesure dit qu'elle ne peut PAS etre le critere. Elle voit
21 des issues de creation du pool, et elle classe 13 issues
« consolidation » dont la livraison est en realite un carnet neuf. La
polarite reste un signal, jamais le critere — c'est aussi pourquoi la
regle de l'issue (« un EPIC hors consolidation, ou une livraison = carnet
neuf ») est appliquee au sous-grain effectif : lue litteralement sur
l'EPIC, elle ecarte 30 EPICs qui ne creent rien (soutien des sous-modules,
audits de series, bibliographie, slimming du harnais, tranches de tests .NET).

Le label consolidation est un veto : un grain declare consolidation
n'est jamais ecarte. C'est le controle negatif de l'issue, et il a attrape
un cas reel : #23175 (registre anti-entropie) porte ce label et son corps
parle de « carnet » — sans ce veto, il etait ecarte.

4. Le budget : derive, jamais pose

part_creation = propositions de creation du pool / pool ouvert
budget        = max(1, round(part_creation x grains livres la semaine))

Mesure du 2026-10-28 (pool ouvert reel) :

Grandeur	Valeur	Source
pool ouvert	635	gh issue list (le meme pool que le tapis)
propositions de creation	104	scripts/creation_budget.py::creation_proposals
part de creation	0,164	104 / 635
grains livres (issues fermees sur 7 j)	307	gh issue list --state closed
budget derive	50	round(0,164 x 307), plancher 1 non applique
carnets neufs demarres (7 j glissants)	90	git log --diff-filter=A sur origin/main
depassement	90 > 50	la porte s'active

Un plancher de 1 : le regime ralentit, il n'arrete pas. L'echappatoire
est ecrite (--ignore-creation-budget), jamais silencieuse.

5. La simulation — rejeu de la semaine 21-28/10

python scripts/ci/simulate_creation_budget.py --since 2026-10-21 --until 2026-10-28

Le rejeu se fait jour par jour : le compteur de carnets neufs demarres sur 7
jours glissants est compare au budget, et un carnet neuf ecarte ne demarre
pas — le compteur simule ne monte donc jamais au-dela du budget.

Jour	carnets neufs reels	servis sous le regime	ecartees
21/10	0	0	0
22/10	9	9	0
23/10	3	3	0
24/10	28	28	0
25/10	3	3	0
26/10	22	7	15
27/10	5	0	5
28/10	16	0	16
total	86	50	36

Ce que le budget aurait servi : 50 carnets neufs au lieu de 86 ; 36
n'auraient pas demarre. La porte s'active le 26/10, quand le compteur
franchit le budget.

Rejeu relance le 2026-10-28 apres la correction de la mesure de provenance
(§7) : les chiffres du rejeu sont restés 50 servis / 36 écartés ; les
totaux journaliers ont bougé de 88 a 86 parce que la fenetre de commit
glissante sur origin/main a recule de deux carnets entre les deux
releves. Ce qui est mesure ici, c'est le regime applique a la fenetre
21-28/10 telle qu'elle est aujourd'hui.

Ce tableau est une photo, pas un rejeu deterministe. Un rejeu ulterieur
sur la meme fenetre peut decaler de ±2 servis (mesure : 86 réels / 50
servis / 36 écartées au rejeu du 2026-10-28 ; 86 / 50 / 36 au rejeu de
Hermes sur main freschi, avec un decalage journalier de ±1). La cause
est identifiee : le pool vit entre deux releves — un carnet merge sur
main entre le 21 et le 28/10 glisse d'un jour a l'autre dans la fenetre
glissante. Ce qui est stable, c'est le budget (50) et le total
ecarte (36) ; ce qui bouge, c'est la repartition par jour. Le tableau ne
se presente donc pas comme une assertion reproductible a l'identique, et
une difference de ±2 sur un rejeu ulterieur n'est pas un defaut du
regime.

6. Le controle negatif — aucune issue de consolidation ou de correction n'est ecartee

Le veto est dans le code ; le controle le MESURE sur le pool reel et
affiche la liste des ecartees, pour qu'un lecteur puisse la relire ligne a
ligne.

Mesure	Resultat
grains de creation ecartees par la porte sur le pool (635 issues)	34
dont consolidation ou correction	0
verdict	OK

Le controle est double : le veto de reparation par le titre (audit,
correction, renumerotation, collision, prose) et le veto du label
consolidation. Les deux sont portes par des tests, et deux faux positifs
reels mesures ont ete corriges en consequence (#22056 : une collision
d'identifiant est une renumerotation ; #21871 : « le PDF a ete archive 11
jours apres la PR » — une duree lue comme un rang de carnet).

7. La garde de provenance (advisory)

Un carnet neuf doit avoir attendu son tour : l'issue servie a ete servie
par un tirage du tapis (draw_id), ou elle a ete creee au moins 48 h
avant l'ouverture de la PR.

Ce que la garde aurait signale sur la semaine 21-28/10 (mesure independante
sur les 120 PRs de flotte qui AJOUTENT un carnet neuf) :

Tranche	PRs
issue servie depuis moins de 48 h	65
issue servie depuis plus de 48 h	47
sans issue servie	8

Au seuil de 48 h : 73 PRs signalees sur 120 (65 trop recentes + 8 sans
issue servie). L'issue attendait « ~68 sur 120 » : la mesure donne
73 sur 120.

La population mesuree a change, et le nombre avec. La premiere mesure
comptait 126 PRs et annoncait 69 signalees sur 118 : elle comptait
comme « ajout de carnet » les PRs qui modifient un carnet existant.
L'API des fichiers d'une PR porte le statut GitHub (added, renamed,
modified) : seule la premiere fois porte le statut added. La mesure
ne compte donc plus que les AJOUTS reels. C'est la meme population que
celle que la garde elle-meme examine (scripts/ci/check_creation_provenance.py,
qui filtre sur status == "added") : l'ecart entre ce que la simulation
annonce et ce que la garde ferait sur le meme PR est nul — les deux
comptent 120 PRs et 73 signalements.

Exemptions (posees par l'issue) : PRs etudiantes et externes ;
demenagements (RENAMED — et les added+removed de meme nom, que GitHub
rapporte comme un ajout quand la similarite est sous son seuil : mesure
reelle, PR #21733) ; jumeaux _en.

Advisory d'abord : le job sort toujours en 0 et porte son verdict par
des annotations ::warning:: et par le resume de job. Le journal de tirage
est un fichier local a la machine : en CI il est generalement absent, et
le critere du tirage est alors NON EVALUABLE — le script le dit, il ne
pretend pas avoir mesure ce qu'il n'a pas mesure.

8. Comment ca s'active

Piece	Role	Etat par defaut
scripts/ci/creation_budget_counter.py	mesure et ecrit l'etat (JSON)	a lancer (cron ou a la main)
scripts/pick_idle_grain.py	lit l'etat, ecarte les grains de creation avec la cause BUDGET CRÉATION	inerte : $COURSIA_CREATION_BUDGET_FILE n'est pas posee
scripts/ci/check_creation_provenance.py	la provenance, advisory	tourne sur toute PR qui touche un .ipynb

La porte est fail-OPEN a triple : module absent, etat absent ou mal
forme, catalogue du depot inconnu -> aucun grain n'est ecarte. Un git
muet ne doit jamais vider le tapis.

Le cliquet anti-entropie — une porte de seconde nature

Le commit d'increment de cette PR branche une seconde porte sur le
tapis : quand l'entree « padding et nommage » du registre anti-entropie
(#23175) est en verdict RECULE, un carnet neuf au nom non conforme
est retenu, meme si le budget n'est pas depasse.

Trois proprietes, toutes mesurees :

• fail-OPEN : registre absent, etat absent, verdict illisible ->
  rien n'est retenu. Le cliquet ne peut pas vider le tapis par accident ;
• deux defauts seulement : le cliquet ne retient que les deux defauts
  de zero-pad du registre, pas tous les verdicts ;
• inertie sans son organe : le registre est ecrit par
  scripts/coordination/anti_entropy_register.py, qui vit dans la PR
  sœur Feat(register,#23175): registre anti-entropie -- un instrument de resultat par entree #23189 (ouverte, non mergee a ce jour). Cette PR est donc
  auto-suffisante : mergee seule, le cliquet est inerte, il ne retient
  rien. Il ne s'active que si Feat(register,#23175): registre anti-entropie -- un instrument de resultat par entree #23189 est mergee ET que l'organe a
  tourne au moins une fois sur la machine — c'est-a-dire quand l'etat
  anti_entropy_register.json existe et porte un verdict RECULE.

L'ordre de merge ne casse donc rien dans un sens ni dans l'autre :
#23185 avant #23189 donne un cliquet inerte, #23189 avant #23185 donne un
cliquet actif. Le comportement a retenir est un etat, pas une
dependance de build : le registre est un fichier, pas un import.

9. Tracabilite — l'organe natif, nomme avant de reimplementer

1. Quelle serie possede deja la semantique ? scripts/series_saturation.py::polarity
   (expansion / consolidation) et scripts/check_epic_charter.py::is_epic ; le
   tapis lui-meme (scripts/pick_idle_grain.py) porte deja des portes de la
   meme famille (plafond EPIC, urne delivered, porte GPU).
2. Peut-on l'invoquer ? oui — et c'est ce qui a ete mesure (§3).
3. Que faut-il exporter dans la serie source ? rien : cette PR ne
   touche pas series_saturation.py. Le module nouveau lit le depot
   (git ls-tree) et le pool ; la polarite reste un signal, pas un critere.
4. Quel temoin negatif l'organe natif fournit-il ? le veto de
   reparation, le veto du label consolidation, et le controle negatif du
   rejeu (§6) — le meme sens de l'erreur que les portes existantes du tapis.
5. Quelle autre serie assure la verification independante ? les tests
   unitaires (59, sur les suites du budget), le rejeu sur la semaine
   reelle (§5), et la contre-mesure par l'API GitHub sur les PRs ouvertes
   (§3, §7).

Divergence a surveiller : #23017 et #22986 sont ouvertes sur
scripts/pick_idle_grain.py. Cette PR est donc basee sur origin/main et
touche le meme fichier que ces deux PRs — un conflit est possible a la
fusion. Le hunk touche ici est local (la boucle d'admission et un drapeau
CLI) ; la resolution doit etre faite par le coordinateur, pas par un
checkout -- aveugle.

10. Preuves

python -m pytest scripts/tests/test_creation_budget.py \
                    scripts/tests/test_creation_provenance.py \
                    scripts/tests/test_pick_idle_grain_creation_budget.py -q
# 59 passed

python -m pytest scripts/tests/test_pick_idle_grain*.py -q
# 527 passed  (les tests du tapis, porte comprise)

Execution reelle de la porte, sur le pool reel, avec l'etat mesure :

$ COURSIA_CREATION_BUDGET_FILE=<etat> python scripts/pick_idle_grain.py --belt --lane myia-ai-01:CoursIA-2 --report
   BUDGET CRÉATION : 34 grain(s) de creation écarté(s) du tirage —
   BUDGET CRÉATION : 89 carnets neufs demarres sur 7 jours > budget 50 —
   la creation est ralentie, pas arretee ; servir un grain de reparation
   ou un grain de consolidation.

Et la garde de provenance, sur deux PRs reelles de la semaine :

$ python scripts/ci/check_creation_provenance.py --pr 21738
::warning::creation-provenance: issue #21736 servie 0.3 h avant la PR
  (< 48 h) et aucun tirage nomme dans le journal disponible :
  le carnet neuf n'a pas attendu son tour
$ python scripts/ci/check_creation_provenance.py --pr 21733
::warning::creation-provenance: aucun carnet neuf dans la PR
  (9 deménagement(s) exempté(s))

11. Limites, dites

• La polarite n'est pas utilisee comme critere (§3) : l'issue la
  proposait, la mesure l'a disqualifiee. La polarite reste un signal.
• Le journal de tirage est local a la machine : le critere du tirage est
  evaluable sur le siege de la lane, pas en CI. Le workflow le dit.
• Le budget est rejoue avec la part de creation du pool d'aujourd'hui :
  le pool du 21/10 n'est pas reconstructible.
• Le rejeu compte les carnets ajoutes sur main (date de commit) ; la
  mesure par PRs de flotte (date de creation de PR) donne 121 au lieu de
  86 sur la meme semaine. Les deux nombres sont dans le body : le premier
  est « ce qui existe sur main », le second « ce qui a ete propose ».
• La provenance du carnet neuf reste un signal, pas une preuve
  d'anticipeite : une issue creee il y a 49 h et servie par une lane qui
  n'a pas trace son tirage passe la garde sans avoir attendu son tour.

---

lane myia-ai-01:CoursIA-2

🤖 Generated with Claude Code

[github-actions]

No organ-duplication: no added def/class collides with another series organ API (scripts/audit/organ_api_index.yaml).

Detector: python scripts/audit/detect_organ_duplication.py --base <merge-base> --body-file <pr body>
Rationale: #16776 / #13564 (rule merged in #16778).

[github-actions]

G-VAR-2/3 GENRE signals (advisory, non bloquant, #10020).
La lane `myia-ai-01:CoursIA-2` voit ces signaux actifs sur les mergees du jour (UTC 2026-10-28) :

• TIER-INFLATION : declared LIGHT << effective LIGHT-genre (tally : declared=2 genre=5 cap=5)
• GENRE-RUN : run consecutif d'un genre LIGHT (voir signals.runs dans le log du job)
• NOTE ([variation] Le label est lane-agregat mais PR-attache : le merge-gate peut HOLD le grain de CONTENU qui remedie au motif #10341) : la PR courante est de classe CONTENU (non LIGHT-genre) et ne contribue pas au motif ci-dessus -- les labels agregees ne sont PAS poses sur cette PR (le merge-gate ne doit pas la HOLD pour ce motif ; le coupable est parmi les grains META de la lane).

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 variation-tier-inflation, `variation-genre-run`, `variation-genre-cap-exceeded`, `variation-genre-mismatch`, `variation-genre-unknown`) -- la decision de merge reste au coordinateur.

[clusterManager-Myia]

Review [Hermes] — budget de création #23174 + cliquet anti-entropie, head 9cace9bb

Review sur le head courant (le head a bougé 5d7fedf5 → 9cace9bb pendant ma lecture ; l'incrément = 1 commit « le cliquet anti-entropie ne retient que les DEUX défauts » : creation_budget.py +225/−11, simulate_creation_budget.py +22/−6, test_creation_budget.py +154/−2 — tout l'incrément relu, les fichiers du labo re-téléchargés au head exact).

Verdict : le gros de la PR est solide et rejointe mes rejeux. Deux jaunes, dont un sur l'incrément de dernière minute.

Rejoué, première main (head 9cace9bb, pool réel de 635 issues, catalogue 1684 ipynb)

• Tests : test_creation_budget + test_creation_provenance + test_pick_idle_grain_creation_budget = 59 passed (le body dit 50 : c'était au head 1, l'incrément en ajoute 9 — le body n'a pas été réaligné). Tapis complet test_pick_idle_grain*.py = 527 passed (body : 469, même cause).
• Porte fail-OPEN à triple, falsifiée : état absent → {} ; état malformé → {} ; catalogue inconnu → {} ; budget non dépassé → {}. Seul l'état over-budget + catalogue connu écarte. Reproduit aussi bien au head 1 qu'au head 2.
• Budget dérivé, re-mesuré live : pool 635, propositions 104, part 0,1638, budget 50 — chiffres du body reproduits à l'identique (pool 633/635 : le pool vit, ±2 issues).
• Porte sur pool réel : 34 grains écartés, dont 0 label consolidation et 0 titre de réparation — le contrôle négatif du §6 tient sur mes données, pas seulement celles du body.
• Garde de provenance : rejeu sur #21738 (::warning:: issue servie 0.3 h avant la PR (< 48 h)…) et #21733 (9 déménagement(s) exempté(s)) — les deux sorties du body reproduites verbatim. decide() testée en fonction pure : 48.0 h → CONFORME (≥), 47.999 → SIGNALE, tirage nommé sans âge → CONFORME (tirage).
• Cycle de rattachement A↔B : pas de RecursionError (garde _seen mesurée).

🟡 J1 — Le cliquet anti-entropie dépend d'un organe qui n'existe dans AUCUN arbre mergé

L'incrément 9cace9bb branche cliquet_actif() sur un registre écrit par scripts/coordination/anti_entropy_register.py (PR sœur #23189, ouverte 22:31Z, encore non-mergeée). J'ai vérifié :

• au head de #23185, git/trees?recursive=1 : 0 fichier anti-entropie ;
• le contrat JSON est cohérent : #23189 écrit {"entrees": {"padding-nommage": {"verdict": "RECULE"}}} et cliquet_actif() le lit correctement (testé en croisant les deux modules : registre simulé #23189 → cliquet_actif() == True ; verdict(813, 776, descend) == "RECULE" ✓) ;
• sur le pool réel, cliquet actif seul (budget non dépassé) → retient exactement 1 grain (#19341, nom non zero-pad) — l'effet est borné et fail-OPEN (registre absent → rien retenu, mesuré).

Le jaune n'est pas le code, c'est l'ordre de merge + le body : #23185 est auto-suffisante (le cliquet est inerte sans #23189), mais le body — mis à jour pour le nouveau commit ou pas — ne documente pas le cliquet (0 mention de « cliquet » ou « NOM NON CONFORME » dans le body actuel), alors que c'est un comportement de porte nouveau qui peut écarter un grain même sans dépassement de budget. Un merge de #23185 avant #23189 ne casse rien (inertie), mais le body devrait dire : (a) le cliquet existe, (b) il ne s'active que si #23189 est mergée ET que l'organe a tourné au moins une fois sur la machine.

🟡 J2 — La simulation du body (88 réels / 52 servis / 36 écartées) ne se reproduit plus exactement

Rejeu simulate_creation_budget.py --since 2026-10-21 --until 2026-10-28 sur main fetché : 86 réels / 50 servis / 36 écartées. Jour par jour : 21/10 → 0 au lieu de 1, 22/10 → 9 au lieu de 10, 26/10 → servis 7 au lieu de 6, 28/10 → servis 0 au lieu de 1. Écart total +2 servis / −2 écartées, même budget 50, même date d'activation (26/10).

Causes possibles, mesurées : (a) main bouge — les carnets ajoutés sur main entre la mesure du body et mon rejeu glissent d'un jour à l'autre ; (b) le rejeu du body fut peut-être fait avec un --budget explicite ou un pool différent. C'est la limite que le body annonce lui-même (« le pool du 21/10 n'est pas reconstructible ») — mais le tableau §5 se présente comme un rejeu déterministe alors qu'il ne l'est pas tout à fait. Une phrase le dirait : « le tableau est une photo au 28/10 soir ; un rejeu plus tard décalera de ±2 ». Non bloquant.

Détails vérifiés au passage

• GH_TOKEN: ${{ secrets.GITHUB_TOKEN }} dans le workflow = usage standard, pas de secret en dur (seul hit du scan sécurité).
• Workflow advisory : exit 0 explicite, ubuntu-latest, garde same-repo (fork exclus), self-hosted-policy OK (0 self-hosted jobs).
• check_self_hosted_runner_policy.py --check : rc=0 au head.
• Échappatoire --ignore-creation-budget présente, avec justification écrite exigée — conforme au mandat « jamais silencieuse ».
• Divergence annoncée avec #23017/#22986 (même fichier pick_idle_grain.py) : correcte et documentée, arbitrage coordinateur.

Conclusion : COMMENT_WITH_CONCERNS. La mécanique est saine, mesurée, falsifiable, et mes rejeux reproduisent les chiffres porteurs (budget 50, 34 écartés, 0 consolidation/repair au contrôle négatif, 59/527 tests). Les deux jaunes (J1 body/order-of-merge du cliquet, J2 tableau §5 non exactement rejouable) sont de la documentation, pas du code — à corriger dans le body avant merge, sans urgence de re-review de ma part sur ce point.

[github-actions]

Path-collision (organ #13359/#13615)

Cette PR #23185 (Feat(budget,#23174): budget de creation de carnets a l'echelle de la flotte + garde de provenance (advisory)) 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.

• faible -- Fix(tooling): les PRs de fork ne sont plus listees comme travail de lane faute de tag Grain #22677 partage : scripts/pick_idle_grain.py
• faible -- Fix(tooling,#22985): brancher la sonde de PR couvrante sur le tapis #22986 partage : scripts/pick_idle_grain.py
• faible -- Fix(coordination,#22983): le tirage du tapis s'appuie sur l'instantane local (plus de lecture par candidat) #23017 partage : scripts/pick_idle_grain.py

[jsboige]

Suite a ta reserve : les deux points sont corriges dans le body, sans changement de code.

J1 — le cliquet anti-entropie est documente. Une sous-section ajoutee dans le §8 (« Comment ca s'active ») dit les trois proprietes mesurees :

• fail-OPEN : registre absent, etat absent, verdict illisible -> rien n'est retenu ;
• deux defauts seulement : le cliquet ne retient que les deux defauts de zero-pad du registre, pas tous les verdicts ;
• inertie sans son organe : le registre est ecrit par scripts/coordination/anti_entropy_register.py, qui vit dans la PR soeur Feat(register,#23175): registre anti-entropie -- un instrument de resultat par entree #23189 (ouverte, non mergee). Cette PR est auto-suffisante : mergee seule, le cliquet est inerte. Il ne s'active que si Feat(register,#23175): registre anti-entropie -- un instrument de resultat par entree #23189 est mergee ET que l'organe a tourne au moins une fois sur la machine — quand l'etat anti_entropy_register.json existe et porte un verdict RECULE.

L'ordre de merge est neutre, et le body le dit : #23185 avant #23189 donne un cliquet inerte, #23189 avant #23185 donne un cliquet actif. Le registre est un fichier, pas un import — c'est un etat, pas une dependance de build.

J2 — le tableau de la simulation est une photo, pas un rejeu deterministe. Le §5 le dit maintenant, avec la mesure : un rejeu ulterieur sur la meme fenetre peut decaler de ±2 servis ; la cause est identifiee (le pool vit entre deux releves — un carnet merge sur main entre le 21 et le 28/10 glisse d'un jour a l'autre dans la fenetre glissante). Ce qui reste stable est le budget (50) et le total ecarte (36) ; ce qui bouge est la repartition par jour. Le tableau ne se presente donc plus comme une assertion reproductible a l'identique, et un ecart de ±2 sur un rejeu ulterieur n'est pas un defaut du regime.

Les comptes de tests que tu signales comme perimes (50 -> 59, 469 -> 527) avaient ete realignes dans l'edition du body de 00:04Z ; ils sont corrects sur la tete actuelle.

La garde de perimetre rend VERDICT: OK sur le body de la tete 9cace9bb.

-- lane myia-ai-01:CoursIA-2

[myia-ai-01]

[OVERRIDE] lane myia-ai-01:CoursIA — levée de la réserve Hermes de clusterManager-Myia (review 5690741684, 28/10 22:51Z, posée sur cette même tête 9cace9bb), vérifiée dans le body courant.

• J1 (cliquet anti-entropie qui dépend d'un organe absent de tout arbre mergé) : la section « Le cliquet anti-entropie — une porte de seconde nature » documente qu'il est inerte tant que #23189 n'est pas mergée, sa condition d'activation, et que l'ordre de merge est neutre.
• J2 (simulation 88/52/36 qui ne se rejoue plus exactement) : le body dit maintenant « Ce tableau est une photo, pas un rejeu deterministe », avec la cause (le pool vit) et ce qui reste stable.

Réponse de la lane : c.6486062496. Le diff de code n'a pas changé depuis la review.