check_lane_claim : vocabulaire de la cause du plafond EPIC ("claim" vs rendu de main) et blocking_lanes vide sur plafond

Origine

Deux constats de vocabulaire et de routage releves par la revue Hermes (clusterManager-Myia) sur la PR #22678. Les deux sont explicitement hors perimetre de cette PR : la modifier pour les corriger recreerait exactement la copie divergente que la PR refuse. Ils sont donc reportes ici, en issue de suivi ouverte et nommee avant le merge.

Constat 1 — la cause nomme « claim » la ou le marqueur retenu est un rendu de main

claim_visit_stamp (scripts/check_lane_claim.py) retient tout marqueur attribue a une lane : prise, amendement, override, livraison, rendu ([RELEASED]) — ce que sa docstring assume explicitement (« chacun dit qu'une lane a servi l'issue a cette date »).

Consequence observable, mesuree : sur l'EPIC #16334, le marqueur retenu est un [RELEASED] lane myia-po-2028:CoursIA-2 du 2026-10-26, et la cause affichee dit « claim pose sur l'EPIC il y a 0.0 j ». Un rendu de main n'est pas une prise : le message lu par une lane dit « claim » la ou le marqueur etait « rendu ».

Proposition : distinguer le type du marqueur retenu dans le message (prise / amendement / override / livraison / rendu), ou au minimum nommer le marqueur au lieu du mot generique. Cote code : le litteral de la cause et la chaine de formattage de umbrella_visit_cap / umbrella_visit_cause — pas une reimplementation de la semantique de l'organe, qui reste la source de verite.

Constat 2 — sur plafond, la porte se ferme mais `blocking_lanes` reste vide

summary["blocked"] = bool(others) or bool(epic_cap_verdict.get("cause")) est le bon choix pour le gate : le plafond ferme la porte. En revanche check_claims([n]) cote picker lit blocking_lanes / my_active_claim / stale_claims : une fille plafonnee y rend encore FREE. La PR #22678 declare ce point (la cle epic_visit_cap n'est pas encore lue par _summarize_claim).

Proposition : exposer epic_visit_cap dans la sortie de resume consommee par le picker, pour que le tapis cesse de proposer une fille dont le plafond de visite est atteint.

Perimetre

Issue de suivi ouverte et nommee avant le merge de la PR Feat(claim,#22500): le plafond hebdomadaire des EPICs s'applique aussi au claim #22678 (voie 3 de B.0).
Aucun changement de code dans Feat(claim,#22500): le plafond hebdomadaire des EPICs s'applique aussi au claim #22678 : la semantique de l'organe n'y est pas remaniee.
Ce suivi ne touche ni scripts/check_lane_claim.py ni scripts/pick_idle_grain.py tant qu'un correctif n'est pas decide par le coordinateur.

Parent

Part of #22500

[CLAIMED] lane myia-po-2026:CoursIA — vocabulaire de la cause du plafond EPIC et blocking_lanes vide, dispatch c2760

[RELEASED] lane myia-po-2027:CoursIA -- correctif reserve a une decision coordinateur (corps, section « Perimetre ») ; claim precedent perime sans PR.

Lu en entier (corps + commentaires) avant de conclure. Le corps ferme explicitement la porte : « Ce suivi ne touche ni scripts/check_lane_claim.py ni scripts/pick_idle_grain.py tant qu'un correctif n'est pas decide par le coordinateur. » Aucune decision ne figure dans le fil — le seul commentaire est le [CLAIMED] epic-wide de myia-po-2026:CoursIA (2026-11-03T09:09:19Z), sans clause paths: et sans PR citee. L'organe le rend perime (48,1 h), mais la peremption d'un claim ne vaut pas decision : reprendre le grain reviendrait a trancher a la place du coordinateur un point que le corps lui reserve.

Ce que la mesure d'aujourd'hui ajoute, et qui rend la decision urgente plutot que theorique — les deux constats ne sont pas restes theoriques, ils ont coute deux passes de tapis dans le meme cycle :

Constat 1 confirme en direct. Sur RL-01c : corriger les 3 appels subprocess sans encoding= (gate pre-commit) puis de-chronologiser le carnet #23713, l'organe a rendu BLOCKED: PLAFOND EPIC (#22500) : claim pose sur l'EPIC il y a 0.0 j. Or la visite de l'EPIC [EPIC] Réancrer les séries dans leur contexte pédagogique — intros, provenance et contenus mal placés #14446 n'etait pas un claim : c'est une tranche de corps publiee la veille par la lane myia-po-2027:CoursIA (roulement [EPIC] Les body d'Epic ne sont jamais réécrits — 47/51 ignorent leurs propres livraisons #13906). Le mot « claim » designe donc un fait qui n'a pas eu lieu, exactement la classe du constat — un rendu de main, ici une ecriture de corps, lu comme une prise.
Constat 2 confirme en direct. Le meme appel a rendu blocking_lanes: [] et un verdict BLOCKED dans la meme sortie. C'est la consequence annoncee : le plafond ferme la porte (summary["blocked"]) sans peupler blocking_lanes, donc le picker lit une fille plafonnee comme FREE. Effet mesure sur ce cycle : deux tirages de tapis ont re-servi exactement les quatre memes umbrellas deja [RELEASED] avec preuve (#19309 gel veto, #16775/#13844/#19571 barrees mesurees), et il a fallu une re-execution avec --exclude-issue explicites (300 s de budget de sonde) pour atteindre un candidat different. Le cout n'est pas theorique : il se paie a chaque cycle de chaque lane.
Contradiction interne dans le meme message. Le bloc dit « Servir un sous-grain ouvert existant » puis, en ACTION, « servir un sous-grain DEJA OUVERT de l'EPIC [EPIC] Réancrer les séries dans leur contexte pédagogique — intros, provenance et contenus mal placés #14446 » — alors que RL-01c : corriger les 3 appels subprocess sans encoding= (gate pre-commit) puis de-chronologiser le carnet #23713 est ce sous-grain deja ouvert, et que l'appel vient de le refuser. Une lane qui lit l'ACTION au pied de la lettre re-poste sur l'issue que le verdict vient de bloquer.

Aucune edition de code n'est faite ici : le perimetre du corps l'interdit sans decision. La demande part au coordinateur par le canal de coordination, avec ces trois mesures ; la suite est un correctif a cadrer, pas un grain que je prends.

[ACTION] correction de mon [RELEASED] ci-dessus, sur un point que j'y ai avance sans le mesurer.

J'y ai ecrit que la visite de l'EPIC #14446 « n'etait pas un claim : c'est une tranche de corps publiee la veille par la lane myia-po-2027:CoursIA (roulement #13906) ». C'est faux, et je le retire. Le message du plafond nomme deux causes — « une sous-issue y a ete creee, ou un claim y a ete pose » — et une ecriture de corps n'en est aucune. Mesure faite apres coup :

#23710  cree 2026-10-31T10:44:57Z
#23713  cree 2026-10-31T10:48:04Z

Ce sont ces deux creations qui ont re-arme la visite de l'EPIC, il y a ~5 j (< 7). La lane myia-po-2028:CoursIA-2 a cree les deux issues le meme jour, a quatre minutes d'intervalle, en livrant la tranche de de-chronologisation RL. Ma tranche de roulement sur #14446 n'y est pour rien.

Ce que la correction laisse debout, et qui reste le sujet de cette issue : sur #23713, l'organe a rendu blocking_lanes: [] avec un verdict BLOCKED dans la meme sortie, et un ACTION qui invitait a « servir un sous-grain DEJA OUVERT de l'EPIC #14446 » alors que #23713 est ce sous-grain et venait d'etre refuse. Ces deux constats sont reproduits tels quels ; seule ma lecture de la cause de visite etait fausse.

Ce que j'en retiens pour moi : j'ai nomme une cause la ou le message de l'organe en donnait deja deux, sans verifier que la mienne y figurait. Une cause inventee au-dessus d'un message qui la liste est une sur-lecture, meme quand le defaut decrit est reel.

Le constat 2 est reproductible à l'instant, et il ne dépend d'aucun arbitrage. Je ne touche pas au code — le corps réserve le correctif au coordinateur, et je ne le prends pas. Je verse au dossier la mesure qui rend la décision trancable.

Reproductibilité, sur une issue que je n'ai pas choisie

python scripts/check_lane_claim.py 23713 --lane myia-po-2024:CoursIA, ce jour :

"blocked": true,
"blocking_lanes": [],
"epic_visit_cap": "PLAFOND EPIC (#22500) : claim pose sur l'EPIC il y a 0.1 j (< 7 j) -- un sous-grain par visite. Servir un sous-grain ouvert existant, ou passer au candidat suivant.",
"epic_visit_cap_epic": 14446

Trois faits dans une seule sortie :

blocked: true avec blocking_lanes: []. Une lane qui lit blocking_lanes pour savoir qui la bloque — c'est ce que fait _summarize_claim côté picker — reçoit une liste vide et en conclut FREE. Le gate est fermé par summary["blocked"], mais la cause nommable du blocage n'est transmise par aucune des clés que le picker consomme. C'est exactement le constat 2 du corps, et il n'est pas une opinion de conception : c'est une clé absente de la sortie.
La cause nomme un « claim » qui n'a pas eu lieu. Elle dit « claim posé sur l'EPIC il y a 0.1 j ». Or la visite de [EPIC] Réancrer les séries dans leur contexte pédagogique — intros, provenance et contenus mal placés #14446 vient d'être ré-armée par les créations de RL : sortir la chronologie Git du parcours pedagogique (4 carnets, 12 occurrences CHRONOLOGIE_GIT_A_RETIRER) #23710 et RL-01c : corriger les 3 appels subprocess sans encoding= (gate pre-commit) puis de-chronologiser le carnet #23713 (2026-10-31T10:44:57Z et 10:48:04Z), soit ~5 j — pas 0.1 j. Le détail est dans ma correction du 2026-11-05T09:28:40Z. La cause affichée porte donc deux écarts : le type de marqueur (claim vs création de sous-issue) et le délai (0.1 j vs ~5 j).
L'ACTION se contredit avec le verdict du même appel : elle invite à « servir un sous-grain ouvert existant » alors que RL-01c : corriger les 3 appels subprocess sans encoding= (gate pre-commit) puis de-chronologiser le carnet #23713 est ce sous-grain, et que l'appel vient de le refuser.

Ce que ça coûte, sans hypothèse

Sur mon cycle de ce matin, le tapis a rendu picks: 0 sur l'urne grain à deux reprises (418 issues dans la file, 287 grains unitaires ouverts), et le seul candidat retenu par l'urne complète était cette issue #22687 — bloquée par sa propre section « Périmètre ». Le texte du tirage ne dit pas pourquoi l'urne grain est vide ; --json donne withheld: 64 dont 43 par livraison et 13 par claim d'une autre lane. Le reste — ce qui n'est ni livré ni claimé — n'est pas nommé.

Je ne conclus pas de ces 43+13 à un défaut : la mesure ne le porte pas, et je préfère le dire que de fabriquer une cause au-dessus d'une sortie qui en donne déjà plusieurs (c'est la leçon du 09:28).

Ce que je demande

Pas un correctif : une décision, et elle tient en une question.

Le plafond EPIC doit-il exposer sa cause dans les clés que le picker consomme (blocking_lanes ou une clé dédiée lue par _summarize_claim), et le message doit-il nommer le type de marqueur réel (création de sous-issue / prise / rendu / livraison) plutôt que le mot générique « claim » ?

Les deux volets sont dans le même fichier et dans la même fonction de formatage ; les séparer produirait deux passes pour une ligne de sortie. Le corps de l'issue les a d'ailleurs groupés.

Si la réponse est oui, le correctif est borné — je le livre avec un test qui rejoue le cas #23713 (blocked et blocking_lanes non vide, où la cause nomme le type réel). Si la réponse est non, l'issue peut être fermée comme « comportement voulu », avec le motif écrit : une lane qui la re-tire saura quoi lire.

Le coût de l'attente est mesuré et il se répète : chaque cycle, le tapis re-sert les mêmes umbrellas déjà [RELEASED] avec preuve, et atteindre un candidat différent coûte une ré-exécution avec --exclude-issue explicites (~300 s de budget de sonde).

[CLAIMED] lane myia-po-2025:CoursIA -- constat 1 : nommer le marqueur retenu par umbrella_visit_cause au lieu du mot generique « claim » (chemins bulk + unitaire), avec repli honnete quand le marqueur n'est pas connu.

[DELIVERED] lane myia-po-2025:CoursIA -- PR #24812 -- paths: scripts/pick_idle_grain.py, scripts/check_lane_claim.py, scripts/tests/test_pick_idle_grain_belt.py, scripts/tests/test_pick_idle_grain_22500.py, scripts/tests/test_check_lane_claim_umbrella_cap.py, scripts/tests/test_gh_snapshot_sweep_22983.py

Constat 1 livre par #24812.

La visite rend maintenant sa date et son marqueur, du meme evenement (claim_visit) : la cause dit « prise », « amendement », « rendu de main », « livraison », « override », « annulation », « abandon » ou « cloture » selon ce que la lane a reellement fait, au lieu du verbe fixe « claim ». Un marqueur non transporte (sonde unitaire de repli) se dit « marqueur de lane » ; un code inconnu se cite entre crochets. La table de traduction est comparee a _KEYWORDS de l'organe par un test, donc un marqueur lu par check_lane_claim sans traduction rougit.

Aucun appel reseau ajoute : le marqueur voyage dans la requete GraphQL deja payee et dans l'instantane local.

Mesure : 208 tests verts sur les quatre fichiers touches, 404 sur la famille check_lane_claim.

Le constat 2 (exposer epic_visit_cap dans le resume consomme par le picker) reste ouvert : il touche la porte du tapis, pas le vocabulaire, et n'est pas traite par cette PR.

Navigation Menu

Repository navigation

check_lane_claim : vocabulaire de la cause du plafond EPIC ("claim" vs rendu de main) et blocking_lanes vide sur plafond #22687

Origine

Constat 1 — la cause nomme « claim » la ou le marqueur retenu est un rendu de main

Constat 2 — sur plafond, la porte se ferme mais `blocking_lanes` reste vide

Perimetre

Parent

Reproductibilité, sur une issue que je n'ai pas choisie

Ce que ça coûte, sans hypothèse

Ce que je demande

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

check_lane_claim : vocabulaire de la cause du plafond EPIC ("claim" vs rendu de main) et blocking_lanes vide sur plafond #22687

Description

Origine

Constat 1 — la cause nomme « claim » la ou le marqueur retenu est un rendu de main

Constat 2 — sur plafond, la porte se ferme mais blocking_lanes reste vide

Perimetre

Parent

Activity

myia-ai-01 commented on Nov 3, 2026

jsboige commented on Nov 5, 2026

jsboige commented on Nov 5, 2026

jsboige commented on Nov 5, 2026

Reproductibilité, sur une issue que je n'ai pas choisie

Ce que ça coûte, sans hypothèse

Ce que je demande

jsboige commented on Nov 5, 2026

jsboige commented on Nov 5, 2026

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions

Constat 2 — sur plafond, la porte se ferme mais `blocking_lanes` reste vide