Repo-grounded Change / Modification Fondée sur le Dépôt

Modification Fondée sur le Dépôt (Repo-grounded Change)

Transformez une demande d'optimisation d'un projet existant en une modification confirmée, prête à être implémentée, puis exécutez uniquement l'option approuvée.

Contrat d'interaction et d'autorisation

• Inspectez le dépôt actuel avant de recommander une solution. Ne demandez pas à l'utilisateur des informations que l'on peut déduire du code, des tests, de la configuration ou des documents produit applicables.
• Restez en lecture seule jusqu'à ce que l'utilisateur approuve explicitement une option ou une base de modification. Les diagnostics et l'inspection du dépôt n'autorisent pas les modifications.
• N'imposez pas ce flux de travail à une demande d'implémentation directe et non ambiguë. Utilisez la barrière lorsque l'utilisateur demande d'abord une évaluation ou lorsqu'un choix affecte de manière significative le comportement, la compatibilité, le risque ou le périmètre.
• Ne posez que des questions déterminantes pour la décision. Utilisez un contrôle structuré de saisie utilisateur lorsqu'il est disponible ; sinon, utilisez des codes d'options concis comme Q1-A.
• Proposez normalement 2 ou 3 options viables mutuellement exclusives. Placez l'option recommandée en premier et expliquez pourquoi. S'il n'existe qu'une seule option sûre, expliquez pourquoi les alternatives ont été rejetées au lieu d'inventer de faux choix.
• Après confirmation, implémentez l'option sélectionnée sans ajouter silencieusement un nettoyage non lié. Si de nouveaux faits issus du dépôt modifient de manière significative le comportement approuvé, le périmètre, la migration, la dépendance ou les critères d'acceptation, arrêtez-vous et demandez une décision révisée.

Indices et étiquettes de décision

Séparez les faits de l'interprétation :

• Objectif utilisateur : le problème et le résultat énoncés par l'utilisateur.
• Fait de code : comportement observé dans le code source actuel, les tests, l'exécution ou la configuration.
• Fait documentaire : comportement requis par le document produit applicable approuvé.
• Suggestion technique : recommandation d'implémentation qui préserve le comportement produit prévu.
• Hypothèse produit : hypothèse réversible nécessitant confirmation.
• En attente de confirmation : choix non résolu empêchant l'implémentation.
• Confirmé : option ou base explicitement approuvée par l'utilisateur.
• Non modifié cette fois : comportement ou code intentionnellement exclu de la modification approuvée.

Sauf indication contraire de l'utilisateur, utilisez cet ordre d'autorité :

1. Instructions explicites actuelles de l'utilisateur.
2. Décisions explicitement confirmées dans la tâche en cours.
3. Spécification produit applicable approuvée.
4. Code et tests actuels pour le comportement existant.
5. Fichiers README et documents historiques.

Exposez les conflits ; ne choisissez pas silencieusement une source.

Workflow

1. Découvrir le comportement actuel

Lisez references/discovery-and-impact.md. Inspectez uniquement les zones du dépôt nécessaires pour reproduire ou expliquer le problème. Protégez les modifications existantes de l'utilisateur et établissez la base de référence des tests actuelle lorsque c'est proportionné.

Rapportez le comportement actuel, l'impact sur l'utilisateur, les limites de code pertinentes et les preuves manquantes avant de présenter les options.

2. Clarifier l'objectif de modification

Traduisez la demande en résultats observables et en contraintes. Ne clarifiez que les problèmes qui peuvent modifier l'option, le périmètre, la stratégie de compatibilité ou le résultat d'acceptation.

Ne traitez pas le libellé littéral de l'interface utilisateur comme un mécanisme d'implémentation requis lorsque cela introduirait des sémantiques d'interaction incorrectes. Expliquez la distinction et proposez une option compatible avec le dépôt.

3. Comparer les options viables

Lisez references/options-and-clarification.md. Comparez l'impact produit et technique, y compris l'expérience utilisateur, le comportement préservé, la compatibilité des états et des données, l'accessibilité, l'impact sur les tests, l'effort d'implémentation, la difficulté de retour arrière et les risques significatifs.

4. Produire le cahier des charges de modification recommandé

Lisez references/change-spec-and-acceptance.md. L'option recommandée doit être directement exécutable par Codex et inclure :

• comportement et interaction cibles ;
• modules, composants, fichiers, interfaces et état affectés ;
• gestion de la compatibilité, persistance, migration, dégradation et retour arrière là où c'est pertinent ;
• comportement et données qui doivent être préservés ;
• exclusions explicites ;
• plan de test et critères d'acceptation observables.

Ne modifiez pas le code à cette étape.

5. Obtenir une approbation explicite

Présentez la recommandation et les choix restants. Arrêtez-vous après avoir demandé à l'utilisateur de sélectionner une option ou de répondre au plus petit tour de clarification nécessaire.

Après la réponse, résumez l'option confirmée, les modifications utilisateur, les problèmes non résolus, les impacts aval et la base d'acceptation finale. Ne commencez l'implémentation que lorsque la réponse autorise clairement l'exécution, par exemple Confirmer option A ou Exécuter selon la recommandation.

6. Implémenter l'option approuvée

Revérifiez l'arbre de travail sale, préservez les modifications non liées et effectuez la plus petite implémentation cohérente. Les commentaires doivent expliquer les invariants ou les décisions de compatibilité non évidents, pas reformuler le code.

Ne supprimez pas les données de domaine sous-jacentes simplement parce que leur présentation UI est supprimée, sauf si la suppression a été explicitement approuvée. Lorsque vous modifiez des états, routes, schémas ou énumérations persistés, gérez les valeurs héritées lorsque le dépôt indique qu'elles peuvent exister.

7. Vérifier et rapporter

Exécutez d'abord des tests ciblés, puis des vérifications proportionnées à l'échelle du dépôt telles que la vérification de type, le lint, les tests complets, la construction et la vérification visuelle ou d'interaction UI. N'affirmez pas qu'une vérification a réussi si elle n'a pas pu s'exécuter.

Rapportez le résultat implémenté, les fichiers principaux, les preuves de vérification, les limitations connues et tout avertissement préexistant non lié. Si une surface de validation demandée n'est pas disponible, divulguez-la et ne contournez pas un outil ou un environnement explicitement sélectionné sans approbation.

Conditions d'arrêt obligatoires

Arrêtez-vous et demandez une décision lorsque :

• deux options viables produisent un comportement utilisateur sensiblement différent ;
• l'implémentation nécessite une dépendance, intégration, information d'identification, migration, action destructive ou changement de règle métier non approuvé ;
• les modifications actuelles de l'utilisateur chevauchent la modification requise et ne peuvent pas être préservées en toute sécurité ;
• les faits du dépôt contredisent l'option approuvée ;
• les critères d'acceptation ne peuvent pas être rendus observables ;
• terminer la modification en toute sécurité nécessiterait d'élargir le périmètre approuvé.

La difficulté, la durée ou les détails d'implémentation ordinaires ne sont pas des raisons de rouvrir une décision confirmée.

Critère d'achèvement

Le workflow est terminé uniquement lorsque l'option sélectionnée est implémentée dans le périmètre, les décisions de compatibilité sont traitées, les critères d'acceptation correspondent à des preuves observables, les vérifications pertinentes ont été exécutées et les limitations sont rapportées honnêtement.