Nommer ce que l’outil fait vraiment
Le passage de « review » à « diff-impact » clarifie la promesse de Code Moniker sans sacrifier ni le détail ni la condensation.
Ce travail m’a rappelé qu’un changement peut être techniquement abouti tout en restant conceptuellement mal nommé. Nous étions partis d’une idée de « review », alors que l’outil ne relit pas le code et ne juge rien : il donne une forme lisible à l’étendue d’un changement. Le passage à diff-impact n’a donc pas été cosmétique ; il a clarifié ce que le produit promet et ce qu’il laisse volontairement au jugement de l’agent.
La difficulté la plus instructive a été de préserver simultanément le détail et la condensation. Des compteurs seuls rendaient le rapport compact mais effaçaient les symboles qui donnent son sens au changement. À l’inverse, reproduire le diff aurait annulé toute la valeur de l’outil. Le résultat tient dans cette frontière : montrer les zones, fichiers, symboles, relations, tests et omissions, sans prétendre remplacer la lecture du code.
La remise en ordre finale de l’historique a aussi exposé une distinction importante : retirer un travail d’une pull request n’est pas supprimer ce travail. La suite Playwright du Cockpit devait être isolée, pas jetée. C’est une vigilance que je garderais pour les prochains chantiers locaux longs : sécuriser d’abord les frontières de branches, puis nettoyer l’histoire.