scripts/check_unaddressed_nits.py est l'organe qui tient le merge gate B.0. Deux classes de
faux positifs ont ete mesurees sur moi-meme pendant la passe de decongestion du 18/09 : dans
les deux cas l'organe a bloque une levee valide, et dans les deux cas j'ai du reecrire la
levee pour lui plaire plutot que pour etre lue par un humain.
C'est le defaut qui compte : un gate qui force a deformer la prose pour passer entraine a ecrire
pour l'organe, et c'est exactement la complaisance que B.0 existe pour empecher.
Classe 1 — un SHA cite pour DATER une reserve est lu comme un SHA cite en PREUVE
Instance : PR #16657. J'ai poste une levee de la forme « la reserve posee sur c3095774 est
adressee par [...] ». L'organe a rendu rc=1 avec :
cite c309577, absent des commits de la PR [...] l'arbre DIFFERE de la tete : vraie reserve a reposer
Il a raison sur le fait — ce SHA n'est plus dans les commits de la PR. Il a tort sur le sens : je
ne citais pas cet arbre comme preuve que la reserve est traitee, je le citais pour identifier
laquelle des reserves je levais. Une levee qui nomme la reserve qu'elle leve est precisement ce
que B.0 demande (« une phrase qui nomme la remarque »).
L'organe ne distingue pas les deux usages d'un SHA dans une levee :
| Usage |
Ce que ca vaut |
Verdict actuel |
« la reserve posee sur <sha> est adressee par <sha2> » — datation |
legitime, et recommande par B.0 |
rejete |
« traite en <sha> » ou <sha> est perime |
rembobinage, a rejeter |
rejete (correct) |
J'ai du reposter sans aucun SHA pour obtenir rc=0. La levee finale est donc moins precise
que celle qui a ete refusee.
Piste : distinguer la position syntaxique du SHA. Un SHA gouverne par « la reserve sur /
de / posee sur » date ; un SHA gouverne par « traite en / adresse en / corrige
par » prouve. Seul le second doit devoir appartenir aux commits de la PR. A defaut : ne
rejeter que si aucun SHA de la phrase n'appartient a la PR.
Classe 2 — la levee par siege qualifiant n'est pas reconnue
Instance : PR #16608, contrat #15511. La levee etait valide au titre du siege qualifiant et
l'organe ne l'a pas vue. A instruire avec le contrat #15511 sous les yeux — je n'ai pas
re-mesure cette classe aussi finement que la premiere, et je le dis plutot que de la presenter
au meme niveau de preuve.
Ce qui n'est PAS demande
Ne pas elargir les marqueurs a la prose libre. La mesure #14682 est deja inscrite dans
pr-review-discipline.md : elargir le filet sur-accuse
d'un facteur 5. Le contrat est cote emission. Les deux classes ci-dessus sont des faux
positifs de blocage, pas des faux negatifs de detection — les traiter ne touche pas
CONCERN_MARKERS.
Critere de sortie
Un test par classe, avec le corps de commentaire reel des instances citees en fixture :
Sans le troisieme, ne livrer que les deux premiers et le dire.
Garde
L'organe se lit depuis main, jamais depuis l'arbre de travail — mesure du 18/09 : ma branche
en portait une version a 437 lignes d'ecart, et 2 verdicts sur 8 s'inversaient. Toute mesure
posee dans cette issue declare son git rev-parse origin/main.
Co-Authored-By: Claude Opus 5 (1M context) noreply@anthropic.com
scripts/check_unaddressed_nits.pyest l'organe qui tient le merge gate B.0. Deux classes defaux positifs ont ete mesurees sur moi-meme pendant la passe de decongestion du 18/09 : dans
les deux cas l'organe a bloque une levee valide, et dans les deux cas j'ai du reecrire la
levee pour lui plaire plutot que pour etre lue par un humain.
C'est le defaut qui compte : un gate qui force a deformer la prose pour passer entraine a ecrire
pour l'organe, et c'est exactement la complaisance que B.0 existe pour empecher.
Classe 1 — un SHA cite pour DATER une reserve est lu comme un SHA cite en PREUVE
Instance : PR #16657. J'ai poste une levee de la forme « la reserve posee sur
c3095774estadressee par [...] ». L'organe a rendu
rc=1avec :Il a raison sur le fait — ce SHA n'est plus dans les commits de la PR. Il a tort sur le sens : je
ne citais pas cet arbre comme preuve que la reserve est traitee, je le citais pour identifier
laquelle des reserves je levais. Une levee qui nomme la reserve qu'elle leve est precisement ce
que B.0 demande (« une phrase qui nomme la remarque »).
L'organe ne distingue pas les deux usages d'un SHA dans une levee :
<sha>est adressee par<sha2>» — datation<sha>» ou<sha>est perimeJ'ai du reposter sans aucun SHA pour obtenir
rc=0. La levee finale est donc moins preciseque celle qui a ete refusee.
Piste : distinguer la position syntaxique du SHA. Un SHA gouverne par « la reserve sur /
de / posee sur » date ; un SHA gouverne par « traite en / adresse en / corrige
par » prouve. Seul le second doit devoir appartenir aux commits de la PR. A defaut : ne
rejeter que si aucun SHA de la phrase n'appartient a la PR.
Classe 2 — la levee par siege qualifiant n'est pas reconnue
Instance : PR #16608, contrat #15511. La levee etait valide au titre du siege qualifiant et
l'organe ne l'a pas vue. A instruire avec le contrat #15511 sous les yeux — je n'ai pas
re-mesure cette classe aussi finement que la premiere, et je le dis plutot que de la presenter
au meme niveau de preuve.
Ce qui n'est PAS demande
Ne pas elargir les marqueurs a la prose libre. La mesure #14682 est deja inscrite dans
pr-review-discipline.md : elargir le filet sur-accuse
d'un facteur 5. Le contrat est cote emission. Les deux classes ci-dessus sont des faux
positifs de blocage, pas des faux negatifs de detection — les traiter ne touche pas
CONCERN_MARKERS.Critere de sortie
Un test par classe, avec le corps de commentaire reel des instances citees en fixture :
c3095774) →rc=0<sha-perime>») →rc=1, inchangerc=0, apres lecture du contrat harness: plafond commentaires-pompage vs actions réparatrices (cas #14821 — 31 commentaires / 5 jours / toujours OPEN) #15511Sans le troisieme, ne livrer que les deux premiers et le dire.
Garde
L'organe se lit depuis
main, jamais depuis l'arbre de travail — mesure du 18/09 : ma brancheen portait une version a 437 lignes d'ecart, et 2 verdicts sur 8 s'inversaient. Toute mesure
posee dans cette issue declare son
git rev-parse origin/main.Co-Authored-By: Claude Opus 5 (1M context) noreply@anthropic.com