AmanVarshney01/tcut

Révise les artefacts de planification existants d'un changement et les maintient cohérents. N'édite jamais de code.

Sélection du magasin : Si l'utilisateur nomme un magasin (un magasin est un dépôt OpenSpec autonome enregistré sur cette machine) ou que le travail y réside, exécutez openspec store list --json pour découvrir les identifiants de magasin enregistrés, puis passez --store <id> aux commandes qui lisent ou écrivent des spécifications et des changements (new change, status, instructions, list, show, validate, archive, doctor, context). Les autres commandes ne prennent pas cet indicateur. Les indications imprimées par les commandes portent déjà l'indicateur ; conservez-le dans les suivis. Sans magasin, les commandes agissent sur la racine locale openspec/ la plus proche.

Entrée : Spécifiez éventuellement un nom de changement. S'il est omis, vérifiez s'il peut être déduit du contexte de la conversation. S'il est vague ou ambigu, vous DEVEZ demander les changements disponibles.

Étapes

1. Si aucun nom de changement n'est fourni, demandez une sélection

   Exécutez openspec list --json pour obtenir les changements disponibles triés par date de modification la plus récente. Utilisez ensuite l'outil AskUserQuestion pour permettre à l'utilisateur de sélectionner le changement à mettre à jour.

   Présentez les 3 à 4 changements les plus récemment modifiés comme options, en affichant :

   • Nom du changement
   • Schéma (du champ schema s'il est présent, sinon "spec-driven")
   • Statut (par ex., "0/5 tâches", "terminé", "aucune tâche")
   • Date de modification (du champ lastModified)

   Marquez le changement le plus récemment modifié comme "(Recommandé)" car c'est probablement celui que l'utilisateur souhaite mettre à jour.

   IMPORTANT : Ne devinez pas et ne sélectionnez pas automatiquement un changement. Laissez toujours l'utilisateur choisir.

2. Obtenez les artefacts du changement

   openspec status --change "<nom>" --json
   

   Analysez le JSON pour comprendre l'état actuel. La réponse inclut :

   • schemaName : Le schéma de workflow utilisé (par ex., "spec-driven")
   • artifacts : Tableau d'artefacts avec leur statut ("done", "ready", "blocked")
   • isComplete : Booléen indiquant si tous les artefacts sont terminés
   • planningHome, changeRoot, artifactPaths et actionContext : contexte de chemin et de portée. Utilisez-les au lieu de supposer des chemins locaux au dépôt.

   Les identifiants et chemins des artefacts proviennent du schéma actif – ne les supposez PAS et ne bifurquez PAS sur des noms d'artefacts codés en dur. Les schémas personnalisés doivent fonctionner sans modification.

   Les fichiers à éditer sont artifactPaths.<id>.existingOutputPaths – les fichiers concrets qui existent sur le disque, déjà expansés par glob pour les artefacts glob (par ex. specs/**/*.md). N'écrivez PAS dans resolvedOutputPath : pour un artefact glob, il s'agit toujours du motif glob, pas d'un fichier réel.

3. Comprenez la demande

   • Si l'utilisateur a demandé une révision spécifique ("le design utilise maintenant X"), c'est la modification de départ.
   • S'il a seulement dit "mettre à jour" / "rendre cela cohérent", traitez cela comme une revue de cohérence : lisez les artefacts existants et vérifiez-les les uns par rapport aux autres pour détecter contradictions, lacunes et doublons.

4. Lisez et réconciliez

   • Lisez le ou les artefacts concernés par la demande ainsi que les autres artefacts existants du changement.
   • Appliquez la modification demandée. Vérifiez ensuite chaque autre artefact existant par rapport à celle-ci – dans TOUTE direction : une modification d'un artefact ultérieur peut nécessiter la révision d'un artefact antérieur, pas seulement l'inverse. L'ordre de construction est un ordre de lecture utile, pas une contrainte sur quels artefacts peuvent être révisés.
   • Notez tout ce qui est désormais incohérent, manquant ou contradictoire.
   • Révisez uniquement les fichiers qui existent déjà (existingOutputPaths). Ne créez PAS d'artefacts qui n'existent pas encore et n'inventez PAS de nouveaux fichiers sous un artefact glob – notez-les et dirigez l'utilisateur vers /opsx:continue pour les créer.
   • Si le changement est déjà cohérent, dites-le et n'appliquez aucune modification.

5. Confirmez et appliquez, un artefact à la fois

   • Montrez chaque révision proposée et sa justification. N'écrivez qu'après confirmation de l'utilisateur.
   • Si l'utilisateur rejette une révision, ne l'écrivez pas – laissez cet artefact inchangé.
   • Lorsqu'une réécriture substantielle est nécessaire, obtenez d'abord les règles et le modèle de cet artefact :

     openspec instructions <id-artefact> --change "<nom>" --json
     

6. Indiquez la prochaine étape (guidance uniquement – n'agissez JAMAIS en conséquence)

   • Artefacts toujours manquants -> suggérez /opsx:continue pour les créer.
   • Changement déjà implémenté (tâches cochées / déjà appliqué) -> le code peut ne plus correspondre au plan révisé ; suggérez /opsx:apply pour reporter le delta dans le code.
   • Tout est fait et implémenté -> suggérez /opsx:archive.

Sortie

Après chaque invocation, affichez :

• Quels artefacts ont été révisés (et quelles révisions proposées ont été rejetées)
• Tout ce qui est différé vers /opsx:continue (artefacts ou fichiers non encore créés)
• Où en est le changement et la commande suivante recommandée

Gardes-fous

• Artefacts de planification uniquement – n'éditez JAMAIS de code d'implémentation. Si le plan révisé implique des modifications de code, arrêtez-vous et renvoyez vers /opsx:apply.
• Utilisez les identifiants et chemins d'artefacts rapportés par openspec status ; ne bifurquez jamais sur des noms d'artefacts codés en dur.
• Éditez uniquement les fichiers concrets dans existingOutputPaths ; n'écrivez jamais dans un resolvedOutputPath de glob.
• N'avancez pas la frontière de construction : pas de nouveaux artefacts, pas de nouveaux fichiers sous des artefacts glob – c'est le travail de /opsx:continue.
• Confirmez chaque modification auprès de l'utilisateur avant d'écrire.
• Si la demande change l'intention du changement plutôt que de l'affiner, recommencez avec /opsx:new (heuristique "Mettre à jour vs. Repartir de zéro").