fix(merge-gate): la levee coordinateur est par-PR et non par-reserve — elle eteint silencieusement les reserves de tiers #14216

Le defaut

Le marqueur de levee coordinateur reconnu par check_unaddressed_nits.py agit par PR, jamais par reserve. Un seul commentaire le portant eteint toutes les reserves ouvertes de la PR — y compris celles d'un tiers, que le coordinateur n'a ni la legitimite ni l'intention de lever.

La prose du commentaire n'y change rien : une phrase disant « la reserve de X n'est pas concernee par cette levee » est invisible a l'organe.

C'est exactement le mode de defaillance que la section B.0 du harnais existe pour empecher — se lever soi-meme une reserve d'autrui n'est pas y repondre, c'est la declarer repondue — sauf qu'ici il se produit sans que personne ne l'ait voulu, comme effet de bord d'une levee legitime.

Reproduction — mesuree le 2026-09-02 sur #14166

#14166 portait deux reserves : une de myia-ai-01 (collision a trois PRs, la mienne) et une de clusterManager-Myia (revue structurelle NanoClaw, COMMENT_WITH_CONCERNS, portant sur une fidelite de contenu).

Controle positif, pris au meme instant : #14105, meme relecteur, meme forme de reserve (review:COMMENTED, prefixe NanoClaw), aucun commentaire de levee de ma part → l'organe l'y rend BLOCKED. La bascule tient donc bien au marqueur, et non a une difference d'etat des reserves entre les deux PRs.

Portee — pourquoi ce n'est pas theorique

La levee que j'ai postee etait legitime : ma reserve portait sur une collision que je venais d'arbitrer (#14214), et cette PR en etait le survivant nomme. Le geste juste, execute correctement, a eteint la reserve d'un tiers — laquelle porte, en l'espece, un defaut de contenu reel (une prose qui enseigne Race la ou le code definit Switch).

Si je n'avais pas relance l'organe apres avoir poste, #14166 serait apparue mergeable et le serait devenue. La trappe s'ouvre precisement dans le cas nominal : un coordinateur qui leve sa reserve sur une PR qui en porte une autre.

Aggravant : le compte jsboige est l'identite de poussee partagee de la flotte (#13316). Le predicat qui reconnait le marqueur n'a donc pas de moyen fiable de distinguer « le coordinateur leve » de « l'auteur de la PR se leve tout seul ».

Le geste attendu

1. Rendre la levee scopee. Une levee doit nommer ce qu'elle leve — l'auteur de la reserve, ou son identifiant de commentaire/review. Une levee non scopee ne doit lever que les reserves dont l'auteur du commentaire est lui-meme l'auteur.
2. Interdire la levee croisee par defaut. Lever la reserve d'un tiers doit demander un scope explicite qui le nomme — et rester refuse quand l'auteur de la levee est aussi l'auteur de la PR.
3. Controle positif obligatoire — la reproduction ci-dessus en fixture :
   • PR a 2 reserves, auteurs differents ; levee non scopee par l'auteur de la premiere → l'organe doit rendre BLOCKED avec 1 nit restant, pas OK.
   • Le controle negatif symetrique : levee scopee nommant les deux (par un compte habilite) → OK.
     Le jeu de motifs se valide par ses faux negatifs : ecrire les formes qu'il doit continuer a bloquer.
4. Verifier l'inverse aussi : que le durcissement ne fasse pas rougir les levees scopees deja postees dans l'historique. Un organe de gate qui sur-accuse apres correctif est aussi casse qu'un organe qui laisse passer.

Reflexe a garder en attendant le correctif

Relancer l'organe apres avoir poste une levee, et lire ce qu'il reste — jamais avant seulement. Une levee n'est effective que mesuree ; et ici, elle peut etre trop effective.

Tier

MED/guard. Un predicat, un scope, deux fixtures. Il touche l'integrite du merge-gate, donc il se teste plus qu'il ne s'ecrit.

Trouve en levant ma propre reserve sur #14166 pendant l'arbitrage de collision #14214. La PR reste non mergeable : la reserve clusterManager-Myia est reelle et appartient a son auteur.