modernize

Modernize commence par des garde-fous: récupérer le dernier origin pour la branche de travail, la branche principale et toute branche liée avant de commencer; traiter les changements existants du worktree comme appartenant à l'utilisateur, en utilisant un worktree jetable quand le worktree actif est sale ou utilisé ailleurs; et se rappeler que moderniser autorise seulement le rebase et la mise à jour de la branche de la PR. Cela n'autorise ni la fusion, ni la fermeture, ni le changement de branche de base, ni l'élargissement du périmètre. Il n'utilise jamais de force push non qualifié: une branche rebasée est mise à jour avec force-with-lease par rapport au SHA de tête observé avant le rebase. Il ne publie aucun commentaire de PR sauf si l'utilisateur l'a demandé. L'intention de la PR est établie d'abord: URL, état, base, dépôt et branche de tête, SHA de tête courant, auteur, vérifications et état de révision, plus titre, corps, enjeux liés, commits, fils de révision et diff complet. Le plus petit objectif cohérent que la PR essayait d'accomplir est énoncé avant que son implémentation soit jugée. Ensuite, la branche de base est inspectée pour les commits et diffs ajoutés depuis la divergence de la PR, y compris les PR fusionnées et ouvertes qui suggèrent un remplacement ou une implémentation concurrente. La vérification regarde au-delà des lignes qui se chevauchent: le même problème visible par l'utilisateur a-t-il déjà été résolu, les API, types, schémas, dépendances ou frontières architecturales ont-ils changé, les deux côtés revendiquent-ils maintenant le même comportement, le code a-t-il été supprimé, déplacé ou intentionnellement simplifié, l'atterrissage de la PR restaurerait-il un vieux comportement ou créerait-il deux façons de faire la même chose, et le bénéfice d'origine justifie-t-il encore le coût de maintenance? La disposition est choisie avant de pousser. MODERNIZE veut dire que l'objectif est toujours utile et que l'implémentation garde la bonne forme: rebase, résolution des conflits, tests et mise à jour de la branche. REWORK veut dire que l'objectif est toujours utile mais qu'un rebase mécanique préserverait la mauvaise implémentation: expliquer la plus petite refonte crédible et s'arrêter avant de pousser sauf si l'utilisateur a aussi demandé cette refonte. CLOSE veut dire que la PR est remplacée, obsolète, mauvaise dans sa direction, ou ne vaut plus son coût: citer des preuves concrètes et s'arrêter, sans passer du temps à rebaser une branche obsolète. Pour une disposition MODERNIZE, le rebase utilise une branche locale sûre ou un worktree jetable, résout chaque conflit selon l'intention courante de la PR et les nouveaux invariants de la branche de base, compare les séries avant et après rebase avec git range-diff, lance les vérifications ciblées du dépôt pour la zone touchée, et pousse avec force-with-lease. Si le bail échoue, récupérer et réévaluer plutôt qu'écraser du nouveau travail. Limites telles qu'écrites dans le SKILL.md: ne pas fusionner la PR, et ne pas la fermer sans permission explicite. Ne pas décrire une PR comme actuelle simplement parce que Git ne signale aucun conflit. Séparer les faits observés du jugement, et dire ce qui n'a pas pu être vérifié au lieu de fabriquer de la confiance. Le rapport commence par MODERNIZE, REWORK ou CLOSE et la raison, puis résume les changements de la branche de base, les conflits conceptuels ou leur absence, le résultat du rebase et du push s'ils ont été effectués, les vérifications lancées et leurs résultats, et la décision ou le travail restant, avec un lien vers la PR.