pr-simplify

Simplifier la modification

Une relecture par l'auteur de la modification : exécutez-la sur votre propre branche avant d'ouvrir la PR, et à nouveau avant de pousser des réparations volumineuses. Elle précède la revue et ne la remplace jamais. Elle hérite du périmètre et de l'autorité de réparation de la tâche ; une demande de revue seule obtient des observations, pas des modifications. Le flux de travail du mainteneur choisi gère la publication, la revue et la fusion.

Le diff est une proposition. Des tests qui passent prouvent que ça fonctionne, pas que son architecture ou chaque test ajouté est nécessaire.

Règles : les sections "Principes de conception", "Un seul propriétaire, bascule complète", "Garanties d'exécution et de code" et "Produit et validation" du fichier racine AGENTS.md, ainsi que le fichier AGENTS.md de plus proche portée. Les étapes 2 et 3 appliquent toutes les règles à chaque fichier modifié.

1. Retrouver le plus petit correctif complet

Lisez le résultat attendu par l'utilisateur et le dernier périmètre, le diff complet par rapport à la base de fusion cible, et les preuves conservées. Réutilisez le contexte de session déjà rassemblé. Demandez ensuite :

En partant de la base, quel est le plus petit correctif complet utilisant les propriétaires déjà présents ? Introduirais-je encore cette architecture ?

Inspectez d'abord les plus grands modules, états, adaptateurs et structures de test ajoutés. Lisez leurs appelants directs et leur historique pertinent : un comportement apparemment redondant peut protéger une configuration livrée ou une régression antérieure. Le périmètre est le système modifié et les chemins qu'il remplace.

Tracez chaque bloc modifié jusqu'au résultat énoncé. Un bloc qui sert un autre objectif quitte cette modification : supprimez-le ou déplacez-le dans sa propre PR.

Comptez le nombre de lignes modifiées non mécaniques. Au-dessus d'environ 800, ou d'environ 500 pour une logique complexe, nommez la plus petite étape cohérente qui peut atterrir en premier et réduisez la modification à cette étape.

Terminé lorsque vous pouvez énoncer le défaut, l'invariant requis et le plus petit correctif complet en une phrase chacun, et que chaque bloc restant sert ce correctif.

2. Supprimer l'architecture superflue

Appliquez chaque simplification prise en charge dans le diff :

• Un seul décideur. Déplacez la politique répétée du côté de l'appelant vers l'opération qui possède la décision. Migrez les appelants concernés et supprimez les anciennes implémentations, exportations et branches de réparation. Des transports différents peuvent partager une décision tout en conservant leurs propres contrats de livraison.
• L'état existant d'abord. Remettez en question les nouveaux schémas, gestionnaires, caches et représentations combinées. Réutilisez un propriétaire existant lorsque sa durée de vie, son autorité, son atomicité et son nettoyage correspondent. Supprimez une migration proposée uniquement lorsqu'elle est réellement inutile ; conservez la migration qui maintient le fonctionnement de la configuration et de l'état existants après la mise à jour. Un nouvel état appartient à un champ qui le signifie.
• Supprimez le chemin redondant. Supprimez les rendus parallèles, les analyseurs dupliqués, les opérations de cycle de vie factices utilisées uniquement pour obtenir un résultat, l'état dérivé que les appelants peuvent déjà obtenir, et les wrappers qui ne font que rediriger ou renommer. Préférez une représentation plus simple à des modes de repli autour de l'ancienne.
• Polissez en dernier. Dans chaque bloc modifié, ne conservez que ce qu'un mainteneur du fichier environnant écrirait :
  • les commentaires qui expliquent la propriété, le cycle de vie, l'ordonnancement ou les contraintes ;
  • les vérifications et les blocs try/catch qui correspondent au module environnant et protègent les états réels ;
  • les types réels au lieu de conversions frauduleuses (as any, as unknown as T, élargir puis affirmer) ;
  • les variables et les aides qui ajoutent du sens au domaine, suppriment la duplication ou simplifient le flux de contrôle ;
  • les adaptateurs, alias, tentatives et replis soutenus par un contrat livré nommé et un plan de suppression ;
  • le nommage, le flux de contrôle, les imports et le formatage qui correspondent au fichier environnant.

Préservez le correctif demandé et le comportement pris en charge, pas la conception accidentelle de la proposition. Conservez les différences de domaine réelles et la compatibilité publique justifiée. Lorsque l'historique (git log -p -S <symbole>) laisse le but d'un chemin peu clair, conservez-le et signalez-le. Signalez les nouvelles décisions produit, les contrats cassés, le nettoyage sans rapport et le remplacement destructeur de branche comme des observations pour le propriétaire.

3. Conserver les tests pour les échecs

Pour chaque groupe de test ajouté ou modifié et ses aides de configuration, nommez l'échec observable distinct qu'il détecte.

Conservez les régressions pour le défaut réel et les limites distinctes : ordonnancement, annulation, autorité obsolète, redémarrage, rejet, erreurs réelles et différences de consommateurs affectés. Conservez les gardes de contrat statiques qui protègent indépendamment une limite réelle. Supprimez les cas en double sur le même chemin, les échos de simulation, les assertions de copie de champ ou de formulation incidentes, les assertions sur des valeurs définies statiquement, les tests qui ne font que prouver que la logique supprimée a disparu, les tests d'implémentations obsolètes, et les échafaudages ou hooks de production réservés aux tests. Consolidez les cas utiles dans une suite de tests du propriétaire existant.

La suppression de tests n'affaiblit jamais les assertions, la couverture des limites réelles ou les bases de référence qui restent.

Terminé lorsque chaque groupe de test restant a un échec nommé.

4. Prouver le changement réduit et le transmettre

Regroupez les modifications, puis réexécutez la reproduction et les vérifications ciblées pour les contrats modifiés et les consommateurs affectés. Réutilisez les preuves dont les intrants sont inchangés. Une affirmation préservée concernant le redémarrage, la mise à niveau ou le transport nécessite une preuve applicable. Le flux de travail existant sélectionne des vérifications plus larges.

Terminé lorsque le diff complet est inspecté, chaque règle a un verdict pour chaque fichier modifié, les simplifications prises en charge sont appliquées, les chemins remplacés sont inaccessibles et le comportement affecté a toujours une preuve. Aucune modification n'est un résultat valide lorsque la forme existante est justifiée. Visez un code net-négatif, pas un quota de suppression.

Rapportez dans le corps de la PR ou dans les preuves de tâche existantes : la responsabilité ou le mécanisme qui a disparu, le comportement toujours protégé, et les différences de production/test par rapport à la base de fusion. Étiquetez une réduction par rapport à une révision antérieure séparément du delta de l'ensemble du changement. Nommez toute croissance nécessaire ou toute décision non résolue.

Ouvrez ou mettez ensuite à jour la PR. Après les réparations ultérieures, simplifiez uniquement les nouvelles modifications et les propriétaires qu'elles touchent avant de les pousser.