AmanVarshney01/tcut

Implémente les tâches issues d'une modification OpenSpec.

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

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

Étapes

1. Sélectionner la modification

   Si un nom est fourni, utilisez-le. Sinon :

   • Déduisez du contexte de la conversation si l'utilisateur a mentionné une modification
   • Auto-sélectionnez si une seule modification active existe
   • En cas d'ambiguïté, exécutez openspec list --json pour obtenir les modifications disponibles et utilisez l'outil AskUserQuestion pour laisser l'utilisateur choisir

   Annoncez toujours : "Utilisation de la modification : " et comment la remplacer (par exemple, /opsx:apply <autre>).

2. Vérifier le statut pour comprendre le schéma

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

   Analysez le JSON pour comprendre :

   • schemaName : le workflow utilisé (par exemple "spec-driven")
   • planningHome, changeRoot et actionContext : périmètre de planification et contraintes d'édition
   • Quel artefact contient les tâches (généralement "tasks" pour spec-driven, vérifiez le statut pour les autres)

3. Obtenir les instructions d'application

   openspec instructions apply --change "<nom>" --json
   

   Cela renvoie :

   • contextFiles : ID d'artefact -> tableau de chemins de fichiers concrets (varie selon le schéma – peut être proposition/spécifications/conception/tâches ou spec/tests/implémentation/doc)
   • Progression (total, complet, restant)
   • Liste des tâches avec statut
   • Instruction dynamique basée sur l'état actuel

   Gérer les états :

   • Si state: "blocked" (artefacts manquants) : afficher le message, suggérer d'utiliser openspec-continue-change
   • Si state: "all_done" : féliciter, suggérer l'archivage
   • Sinon : passer à l'implémentation

4. Lire les fichiers de contexte

   Lisez chaque chemin de fichier listé sous contextFiles dans la sortie des instructions d'application. Les fichiers dépendent du schéma utilisé :

   • spec-driven : proposition, spécifications, conception, tâches
   • Autres schémas : suivez les contextFiles de la sortie CLI

5. Afficher la progression actuelle

   Affichez :

   • Le schéma utilisé
   • Progression : "N/M tâches terminées"
   • Aperçu des tâches restantes
   • Instruction dynamique de la CLI

6. Implémenter les tâches (boucle jusqu'à terminaison ou blocage)

   Pour chaque tâche en attente :

   • Indiquez quelle tâche est en cours
   • Effectuez les modifications de code nécessaires
   • Gardez les modifications minimales et ciblées
   • Marquez la tâche comme terminée dans le fichier des tâches : - [ ] → - [x]
   • Passez à la tâche suivante

   Faire une pause si :

   • La tâche n'est pas claire → demandez une clarification
   • L'implémentation révèle un problème de conception → suggérez de mettre à jour les artefacts
   • Une erreur ou un blocage survient → signalez et attendez des instructions
   • L'utilisateur interrompt

7. À la fin ou en pause, afficher le statut

   Affichez :

   • Tâches terminées dans cette session
   • Progression globale : "N/M tâches terminées"
   • Si tout est fait : suggérez l'archivage
   • Si en pause : expliquez pourquoi et attendez des instructions

Sortie pendant l'implémentation

## Implémentation en cours : <nom-modification> (schéma : <nom-schéma>)

Travail sur la tâche 3/7 : <description de la tâche>
[...implémentation en cours...]
✓ Tâche terminée

Travail sur la tâche 4/7 : <description de la tâche>
[...implémentation en cours...]
✓ Tâche terminée

Sortie à la fin

## Implémentation terminée

**Modification :** <nom-modification>
**Schéma :** <nom-schéma>
**Progression :** 7/7 tâches terminées ✓

### Terminé dans cette session
- [x] Tâche 1
- [x] Tâche 2
...

Toutes les tâches sont terminées ! Prêt à archiver cette modification.

Sortie en pause (problème rencontré)

## Implémentation en pause

**Modification :** <nom-modification>
**Schéma :** <nom-schéma>
**Progression :** 4/7 tâches terminées

### Problème rencontré
<description du problème>

**Options :**
1. <option 1>
2. <option 2>
3. Autre approche

Que souhaitez-vous faire ?

Garde-fous

• Continuez à travers les tâches jusqu'à terminaison ou blocage
• Lisez toujours les fichiers de contexte avant de commencer (depuis la sortie des instructions d'application)
• Si une tâche est ambiguë, faites une pause et demandez avant d'implémenter
• Si l'implémentation révèle des problèmes, faites une pause et suggérez des mises à jour d'artefacts
• Gardez les modifications de code minimales et limitées à chaque tâche
• Mettez à jour la case à cocher de la tâche immédiatement après avoir terminé chaque tâche
• Faites une pause en cas d'erreurs, de blocages ou d'exigences peu claires – ne devinez pas
• Utilisez contextFiles depuis la sortie CLI, ne supposez pas de noms de fichiers spécifiques

Intégration de workflow fluide

Cette compétence prend en charge le modèle "actions sur une modification" :

• Peut être invoquée à tout moment : avant que tous les artefacts ne soient prêts (si des tâches existent), après une implémentation partielle, entrelacée avec d'autres actions
• Permet les mises à jour d'artefacts : si l'implémentation révèle des problèmes de conception, suggérez de mettre à jour les artefacts – pas de verrouillage de phase, travaillez de manière fluide