fix(ci,#14598): re-poser le plafond ICT contre la mesure (30 -> 60 min)

[myia-ai-01]

Grain: MED/guard — lane myia-ai-01:CoursIA — prev: LIGHT/guard #15732

Résumé

ict-tests.yml porte timeout-minutes: 30 au niveau du job. Le 2026-09-12, trois PRs de contenu sont mortes dessus — #15657 (30,5 min), #15660 (30,4 min), #15609 (30,4 min) — sur trois lanes et deux workspaces, toutes rendues cancelled, aucune failure, et toutes porteuses d'un grain notebook-python. L'organe d'infrastructure tuait exactement le contenu que le protocole demande de produire.

Le passage 15 → 30 (#14598 Option A) avait déplacé le mur sans mesurer sa position. Cette PR la mesure, puis pose le plafond contre la mesure.

La mesure

Sonde hors plafond — ict-tests-profile.yml (timeout-minutes: 90), même commande (pytest tests, matrice test-args: tests), même test-cwd, même pool de runners ([self-hosted, coursia-ephemeral, coursia-linux]). Job 103508457858, run 34676978324, runner myia-po-2024-linux-docker-2 :

1076 passed, 3 skipped, 7 warnings in 890.36s (0:14:50)
step `Run` = 15,23 min mur

Run tué — #15609, job 103531764037, runner myia-po-2024-linux-docker-4, step Run 29,13 min, coupé à 58 % de la suite.

Les deux runs ne parcourent pas la même portion de la suite : comparer leurs totaux n'aurait aucun sens. La comparaison est donc faite sur le préfixe strictement identique, avec les mêmes deux items d'ancrage présents dans les deux logs :

ancre	sonde	tué
test_active_inference.py::test_belief_pdf_normalized	06:01:52	09:47:38
test_pregnance_animat.py::test_behavioral_reversibility_verdict	06:15:59	10:16:35
préfixe	847,22 s	1737,00 s

Ratio = 2,050 ×. C'est une variance de runner, pas une dérive de la suite : même commande, même code, même pool.

Extrapolé au total : 30,42 min contre un budget de step de 28,94 min (30 min de job − 1,06 min d'install).

Déficit : 89 s, soit 5,1 %. Le plafond de 30 était posé sur la frontière, pas au-dessus. Le run tué progressait normalement, une seconde avant la coupe.

Le choix du 60

	valeur	marge à 60 min
nominal mesuré	15,23 min	3,94 ×
pire cas observé	30,42 min	1,97 ×

Choisi contre la mesure, pas contre une marge de confort.

Ce que cette PR n'est pas

Ce n'est pas le correctif de fond. La concentration mesurée sur la sonde (--durations=25 --durations-min=0) :

	durée	part
top-25 items	792,56 s	89,0 %
top-4 items	407,95 s	45,8 %
les 1054 autres	97,80 s	11,0 %

Les 25 items vivent dans 6 modules ; sous -n --dist loadscope le chemin critique tombe à ~4,25 min nominal (~8,7 min à 2,05 ×). C'est la suite (#14598 lever (b)), à mon nom également.

Le plafond posé ici est ce qui cesse de tuer du contenu pendant que la parallélisation se valide — et le commentaire du fichier le dit explicitement : « A RELIRE quand la parallelisation atterrit : un plafond dimensionne pour une suite sequentielle de 30 min n'a plus de sens sur une suite de 9 min. »

Portée du diff — zéro conflit avec les cinq PRs ouvertes

Cinq PRs ouvertes touchent ict-tests.yml : #15665, #15660, #15657, #15627, #15547. Toutes éditent le bloc de prose des floors (lignes 12-32) et/ou la matrice (lignes 90-110), avec des valeurs mutuellement contradictoires (678 / 681 / 686 / 686 / 703) issues d'une base où le floor valait 670.

Ce diff est confiné aux lignes 70-76. Vérifié hunk par hunk sur les cinq : aucun ne touche cette région. Elles ne prennent donc aucun conflit de ma part.

Le fait que cinq PRs doivent toutes réécrire les mêmes quatre lignes de prose pour ajouter des tests est un aimant à conflits structurel — la prose duplique un nombre qui vit dans la matrice, donc elle ne peut que dériver (elle dit aujourd'hui 1046/670 contre 1071/692 en matrice). Je le traite séparément et après ces cinq merges, pour ne pas imposer un rebase à des PRs de contenu déjà bloquées.

Validation

• python -c "import yaml; …" → timeout-minutes = 60, YAML valide.
• python scripts/ci/check_self_hosted_runner_policy.py → OK -- all self-hosted jobs satisfy isolation policy (workflows=159 jobs=202 self_hosted=131).
• Le job lui-même se valide en s'exécutant : la jambe ICT tests/ (56) de cette PR est le contrôle.

Note de lecture pour les lanes

Un kill par timeout-minutes rend conclusion cancelled, jamais failure. La couleur ne distingue pas « le code est faux » de « la machine a été coupée ». Le commentaire du fichier porte désormais cet avertissement, pour qu'aucune lane ne se voie imputer un rouge produit par cette ligne.

See #14598

🤖 Generated with Claude Code

[github-actions]

G-VAR-2 light cap reached (advisory, non bloquant).
La lane myia-ai-01:CoursIA a deja consomme son budget LIGHT du jour (#15454 (merge a 2026-09-12T00:17:28Z)).
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]

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

• CAP-EXCEEDED-BY-GENRE : light_genre > cap partage G-VAR-2 (tally : declared=1 genre=2 cap=1)

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.

[myia-ai-01]

Mesure firsthand du plafond — 4/4 tues au chronometre

Quatre derniers passages de la jambe ICT tests/ (56), pool coursia-ephemeral/coursia-linux :

run	debut -> fin	duree	verdict
34691699169	11:56:28Z -> 12:26:48Z	30 min 20 s	cancelled
34691319229	12:13:51Z -> 12:44:12Z	30 min 21 s	cancelled
34687179631	10:26:06Z -> 10:56:35Z	30 min 29 s	cancelled
34686865045	09:57:11Z -> 10:27:35Z	30 min 24 s	cancelled

4/4 tues au plafond timeout-minutes: 30 (.github/workflows/ict-tests.yml:76), a 20-29 s pres. La jambe soeur ICT ict/tests/ (42 package) conclut success en 11.4-15.5 min sur ces memes runs : le plafond ne mord que sur tests/ (56).

Pourquoi c'est une reparation de capacite, pas un confort

Un plafond qu'une jambe ne peut pas tenir ne rend aucun verdict. Il rend cancelled, et cancelled :

1. rougit le PR gate (RED set de pr-gate-stale-sweep.yml:268) ;
2. est invisible a blocking_causes() du picker (Un check REQUIS a CANCELLED ne rend aucune cause : la PR est BLOCKED et la lane n'est informee de rien #15769) — aucune lane ne voit donc la cause ;
3. rend la PR eligible au balayage, qui relance la jambe — retuee au meme plafond.

Chaque tour consomme 30 min pleines d'un runner du pool le plus charge. Mesure a 13:24Z : coursia-ephemeral/coursia-linux 12/12 occupes, coursia-waiter 4/12, coursia-lean 0/2. La saturation n'est pas subie : elle est en partie fabriquee par cette boucle.

Perimetre de ce que la mesure etablit — et de ce qu'elle n'etablit pas

Elle etablit que 30 min est trop bas. Elle n'etablit pas que 60 est le bon chiffre : la vraie duree de tests/ (56) n'a jamais ete observee, puisqu'aucun passage n'a pu la rendre. Ce sont les deux runs de contrat de #15762 — 34693685670 (sequentiel) et 34694385724 (xdist), qui portent deja 60 sur leur branche — qui la rendront.

Le controle est deja rendu, lui : la jambe 42 package sous xdist a conclu success en 14.32 min, dans la bande 11.4-15.5 min mesuree sequentiellement. Le controle ne derive pas, la comparaison sera donc lisible.

[github-actions]

Path-collision (organ #13359/#13615)

Cette PR #15761 (fix(ci,#14598): re-poser le plafond ICT contre la mesure (30 -> 60 min)) 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 -- ci(ict,#15471): planchers de collecte 746->1046 et 42->670 + garde bidirectionnelle #15485 partage : .github/workflows/ict-tests.yml (recouvrement 100%) -- ci(ict,#15471): planchers de collecte 746->1046 et 42->670 + garde bidirectionnelle #15485 est deja sur main, la substance est consommee.
• faible -- feat(ict,#8182): case 5 attention schema (Graziano AST) executed — verdict INCONCLUSIF #15547 partage : .github/workflows/ict-tests.yml
• faible -- feat(ict,#15479): endpoints multi-lentilles sans ecrasement de semantique (tranche 4/n) #15627 partage : .github/workflows/ict-tests.yml
• faible -- feat(ict,#15480): banc synthetique factorise Mess3/RRXOR — generateurs, beliefs exacts, vary-one (tranche 1/n) #15657 partage : .github/workflows/ict-tests.yml
• faible -- feat(ict,#15480): gates geometriques des lentilles — R2/RMSE held-out, angles, recouvrement, additivite, z-score H4 (tranche 2a/n) #15660 partage : .github/workflows/ict-tests.yml
• faible -- feat(ict,#15480): dictionnaire sparse SAE top-k + selectivite aux facteurs — tranche 2b #15665 partage : .github/workflows/ict-tests.yml
• faible -- feat(#15480): batterie d'intervention -- chaine etat -> comportement testee (tranche 3, branche d'integration) #15799 partage : .github/workflows/ict-tests.yml
• faible -- feat(ict,#15481): POC S-Lens — self-location, jambe causale appariée, gate de promotion (verdict INCONCLUSIVE) #15814 partage : .github/workflows/ict-tests.yml
• faible -- fix(ci,#15652): ajouter 'edited' aux types: des 55 workflows gates sur branches:[main]+paths: (retarget PR empilee) #15840 partage : .github/workflows/ict-tests.yml

Le verdict terminal (#15578) signifie que la substance est deja sur main : le cote merge n'est plus une collision a arbitrer, c'est du travail deja integre.

[jsboige]

La jambe a conclu — le plafond se juge maintenant sur un chiffre, plus sur une coupure

Complement a mon commentaire precedent sur les quatre coupures. La mesure pairee a rendu son premier resultat.

Jambe	Duree	Fenetre
tests/ (56) xdist -n 4 --dist loadscope (#15762)	18.88 min	13:28:20 -> 13:47:13
tests/ (56) sequentielle, sous le plafond 60 de cette PR	> 26.87 min, en cours a 13:52	13:25:30 -> …
ict/tests/ (42 package) — temoin	14.32 min	13:03:18 -> 13:17:37

Ce que ca etablit pour cette PR precisement :

• Le plafond 30 etait reellement trop bas, et non victime d'un aleas de runner : la jambe sequentielle a franchi 26.87 min et tourne encore, alors que l'ancien plafond l'aurait coupee a 13:55:30. Les quatre cancelled a 20-29 s d'ecart mesuraient une duree, pas une instabilite.
• Le temoin n'a pas derive (14.32 min sous xdist contre 13.60 min en sequentiel, dans la bande 11.4-15.5 min deja observee), donc les deux autres chiffres portent.
• La mesure ne justifie pas encore la valeur 60. Elle justifie « plus que 30 ». La borne haute vraie sortira du run en vol ; c'est elle qui doit porter le nombre retenu, et je preferai l'ecrire dans le body plutot que de laisser 60 reposer sur une estimation.

Une remarque de perimetre, parce qu'elle change l'ordre de valeur des deux PRs : #15762 ramene la jambe a 18.88 min, sous l'ancien plafond de 30, avec 11 min de marge. La parallelisation seule suffisait donc a rendre la jambe verte. Le relevement porte par cette PR est la marge de securite qui absorbe la variance — ce qui reste utile, et se dit mieux ainsi que comme le correctif principal.

Mesure faite par ai-01 sur les runs 34693685670 (cette PR) et 34694385724 (#15762).

[jsboige]

Les deux jambes ont conclu — le plafond de 60 min repose maintenant sur une mesure

Le contrat annonce plus haut est complet. Les deux jambes ICT tests/ (56) ont
conclu success, sur coursia-ephemeral :

Jambe	Fenetre	Duree
Sequentielle (run 34693685670)	13:25:30Z -> 14:01:21Z	35,85 min
xdist -n 4 --dist loadscope (run 34694385724)	13:28:20Z -> 13:47:13Z	18,88 min

Acceleration mesuree : 1,90x.

Ce que ce chiffre etablit, et ce qu'il n'etablit pas

Il etablit que 30 etait trop bas. La jambe sequentielle demande 35,85 min :
l'ancien plafond la tuait avec environ six minutes de travail restant. C'est le
mecanisme exact qui rendait cancelled cette jambe et qui n'avait jamais ete
observe jusqu'au bout — le contrat existait pour cela.

Il etablit aussi que 60 n'est plus une estimation. Le pire cas observe sans
xdist est 35,85 min ; 60 min lui laisse 1,67x de marge. J'avais ecrit plus
haut que la mesure prouvait que 30 etait trop bas sans prouver que 60 etait juste :
cette moitie-la est desormais couverte. 45 aurait suffi a la jambe sequentielle
(35,85 < 45), mais sans marge pour un runner lent ou une degradation de xdist.

Ce qu'il n'etablit pas : que le plafond soit la reparation principale. Avec
#15762 merge, la jambe tourne en 18,88 min et repasse sous l'ancien plafond de 30
avec 11 min de marge. L'ordre reste celui que j'ai annonce — xdist est le
correctif de fond, ce plafond est la marge de securite qui empeche un cancelled
si le parallelisme se degrade. Les deux se tiennent ; aucun ne remplace l'autre.

Controle

Le temoin ict/tests/ (42 package) a rendu 14,32 min, dans sa bande connue de
11,4-15,5 min : le banc n'a pas derive pendant la mesure, les deux durees ci-dessus
sont comparables entre elles.