check_unaddressed_nits: la voie 3 de B.0 (issue de suivi nommee) est fermee au coordinateur -- borne de nommeur trop etroite

[myia-ai-01]

Symptome

La voie 3 de B.0 — « une issue de suivi ouverte et nommee AVANT le merge (reportee sciemment) » — ne peut pas etre exercee par le coordinateur. check_unaddressed_nits.py credite le report uniquement quand le nommeur est l'auteur du nit ou l'auteur de la PR. Or B.0 est le gate du coordinateur : c'est lui qui arbitre le report au moment de merger.

Mesure (PR #14673, reserve Hermes du 2026-09-04T22:31:28Z, issue de suivi #14704)

Toutes les conditions de substance passent ; seule l'identite du nommeur echoue.

Condition (analyse, ~l.3269)	Valeur mesuree
cond. 5 — issue creee apres la reserve	True
cond. 6 — _issue_references_pr(info, 14673)	True
fenetre — when < t < cutoff	True
nommeur — namer in (login, pr_author)	False (namer='myia-ai-01', login='jsboige', pr_author='jsboige')

collect_followup_lifts collecte bien le report ([('2026-09-05 03:06:36+00:00', 'myia-ai-01', <IssueInfo #14704 open>)]) : le filtre de collecte (issue / ouverte / creee avant cutoff / _FOLLOWUP_MARK delibere) est satisfait. C'est la borne d'identite appliquee plus tard, dans analyse, qui le jette.

Controle positif — memes donnees, namer remplace par pr_author, tout le reste inchange :

lifted = (when < t < cutoff and pr_author in (login, pr_author)
          and when < info.created_at and _issue_references_pr(info, 14673))
       -> True

Le report est donc valide en substance et rejete en identite — le controle isole exactement la borne en cause, pas une supposition.

Pourquoi c'est un defaut et pas une garde voulue

La borne d'identite existe pour une bonne raison sur les voies 1 et 2 : se lever a soi-meme la reserve d'un tiers n'est pas y repondre (#11145, #12798). Cette raison ne transpose pas a la voie 3, et le code le dit lui-meme — le docstring de collect_followup_lifts note que « l'auteur de la PR est explicitement ouvert comme nommeur (borne #13563) », c'est-a-dire qu'on a deja du elargir la borne une fois pour que la voie 3 soit utilisable. Elle a ete elargie a l'auteur de la PR, jamais au coordinateur.

La difference de nature : une voie-1 affirme que la reserve est traitee (d'ou la borne d'auteur). Une voie-3 affirme le contraire — la reserve n'est pas traitee, elle est reportee, tracee et datee. Un report ne se falsifie pas en le declarant : il se falsifie en n'ouvrant pas l'issue, et cela, les conditions 1-6 le verifient deja cote serveur (issue reelle, ouverte, posterieure a la reserve, referencant la PR). L'identite du nommeur n'ajoute aucune garantie ici, alors qu'elle retire au coordinateur la seule voie que B.0 lui donne.

Consequence pratique observee : pour merger #14673 avec un report legitime, il a fallu passer par [OVERRIDE] lane — un mecanisme d'arbitrage exceptionnel — la ou B.0 prevoit une voie ordinaire. Faire passer l'ordinaire par la porte de l'exception use l'exception et rend les vrais overrides indistinguables des reports de routine dans l'audit.

Correctif propose

Ajouter le coordinateur aux nommeurs credites pour la voie 3 seule :

or any(when < t < cutoff
       and (namer in (login, pr_author) or namer in LIFT_OVERRIDE_LOGINS)
       and when < info.created_at
       and _issue_references_pr(info, pr_number)
       for (t, namer, info) in followup_lifts)

LIFT_OVERRIDE_LOGINS ({"myia-ai-01"}) est deja la constante qui nomme le coordinateur, et elle est deja utilisee pour l'override — la reutiliser ici ne cree pas de surface neuve. Les voies 1 et 2 gardent leur borne d'auteur inchangee : ce correctif n'ouvre rien sur « lever une reserve », uniquement sur « la reporter ».

Acceptance

• Un report nomme par myia-ai-01, satisfaisant les conditions 1-6, leve la reserve sans [OVERRIDE].
• Controle negatif : un report nomme par un compte tiers quelconque (ni nit-author, ni pr-author, ni coordinateur) ne leve pas — le test doit echouer si la borne est simplement supprimee.
• Controle negatif 2 : les voies 1 et 2 restent fermees a l'auto-levee (les tests existants de check_unaddressed_nits: borner la levee a l'auteur de la reserve (reserves Hermes #11108) #11145 / fix(gametheory,#12580): call_llm_provider reel vLLM + cassette rejouable (lift Hermes reserve) #12798 restent verts).
• Un test couvre le cas mesure ici : nit-author == pr-author == jsboige, nommeur == myia-ai-01, issue ouverte posterieure referencant la PR -> leve.

Provenance

• B.0 (CLAUDE.md) — les trois voies de levee ; la voie 3 ne restreint pas le nommeur.
• feat(picker,#14591): persistance CSV --prev-genre par lane (Volet A) #14673 — PR ou le defaut s'est manifeste ; mergee sous [OVERRIDE] lane myia-po-2027:CoursIA-2 faute de voie ordinaire.
• picker(#14591 volet A): le CSV mono-colonne last_genre ferme l'inter-cycles, pas la multiplicite intra-session -- et condamne le format #14704 — l'issue de suivi qui aurait du lever, et qui porte la reserve reportee.
• fix(gate,#13495): B.0 voie 3 (issue de suivi nommée) + trappe coordinateur fermée pour l'auteur #13563 — precedent elargissement de la meme borne (a l'auteur de la PR).