openspec-apply-change

Implémenter les tâches d'un changement OpenSpec.

Entrée : Spécifiez optionnellement 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. Sélectionner le changement

   Si un nom est fourni, l'utiliser. Sinon :

   • Déduire du contexte de la conversation si l'utilisateur a mentionné un changement
   • Sélection automatique s'il n'existe qu'un seul changement actif
   • Si ambiguïté, exécuter openspec list --json pour obtenir les changements disponibles et utiliser l'outil AskUserQuestion pour laisser l'utilisateur sélectionner

   Toujours annoncer : « Utilisation du changement : <nom> » et comment l'ignorer (par ex. /opsx:apply <autre>).

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

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

   Analyser le JSON pour comprendre :

   • schemaName : Le workflow utilisé (par ex. « spec-driven »)
   • Quel artefact contient les tâches (généralement « tasks » pour spec-driven, vérifier le statut pour les autres)

3. Obtenir les instructions d'application

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

   Cela retourne :

   • contextFiles : ID d'artefact → tableau de chemins de fichiers concrets (varie selon le schéma - peut être proposal/specs/design/tasks ou spec/tests/implementation/docs)
   • 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 : procéder à l'implémentation

4. Lire les fichiers de contexte

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

   • spec-driven : proposal, specs, design, tasks
   • Autres schémas : suivre les contextFiles de la sortie CLI

5. Afficher la progression actuelle

   Afficher :

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

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

   Pour chaque tâche en attente :

   • Indiquer quelle tâche est en cours de traitement
   • Effectuer les modifications de code requises
   • Garder les changements minimes et ciblés
   • Marquer la tâche comme complétée dans le fichier tasks : - [ ] → - [x]
   • Continuer vers la tâche suivante

   Pause si :

   • La tâche est peu claire → demander une clarification
   • L'implémentation révèle un problème de conception → suggérer de mettre à jour les artefacts
   • Une erreur ou un blocage est rencontré → signaler et attendre les instructions
   • L'utilisateur interrompt

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

   Afficher :

   • Tâches complétées dans cette session
   • Progression globale : « N/M tâches complétées »
   • Si tout est fait : suggérer l'archivage
   • Si en pause : expliquer pourquoi et attendre les instructions

Sortie pendant l'implémentation

## Implémentation : <change-name> (schéma : <schema-name>)

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

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

Sortie à la fin

## Implémentation terminée

**Changement :** <change-name>
**Schéma :** <schema-name>
**Progression :** 7/7 tâches complétées ✓

### Complétées dans cette session
- [x] Tâche 1
- [x] Tâche 2
...

Toutes les tâches sont complétées ! Prêt à archiver ce changement.

Sortie en pause (problème rencontré)

## Implémentation en pause

**Changement :** <change-name>
**Schéma :** <schema-name>
**Progression :** 4/7 tâches complétées

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

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

Que souhaitez-vous faire ?

Garde-fous

• Continuer à traiter les tâches jusqu'à la fin ou blocage
• Toujours lire les fichiers de contexte avant de commencer (à partir de la sortie des instructions d'application)
• Si une tâche est ambiguë, faire une pause et demander avant d'implémenter
• Si l'implémentation révèle des problèmes, faire une pause et suggérer des mises à jour d'artefacts
• Garder les modifications de code minimes et ciblées pour chaque tâche
• Mettre à jour la case à cocher de la tâche immédiatement après avoir complété chaque tâche
• Faire une pause sur les erreurs, blocages ou exigences peu claires - ne pas deviner
• Utiliser contextFiles à partir de la sortie CLI, ne pas supposer des noms de fichiers spécifiques

Intégration du workflow fluide

Cette compétence supporte le modèle « actions sur un changement » :

• Peut être invoquée à tout moment : Avant que tous les artefacts ne soient terminés (si des tâches existent), après une implémentation partielle, en intercalation avec d'autres actions
• Permet les mises à jour d'artefacts : Si l'implémentation révèle des problèmes de conception, suggérer de mettre à jour les artefacts - pas verrouillé par phase, workflow fluide