AmanVarshney01/tcut

Synchronisez les spécifications delta d'un changement vers les spécifications principales.

Il s'agit d'une opération pilotée par l'agent - vous lirez les spécifications delta et modifierez directement les spécifications principales pour appliquer les modifications. Cela permet une fusion intelligente (par exemple, ajouter un scénario sans copier l'intégralité du besoin).

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 spécifications et des changements (new change, status, instructions, list, show, validate, archive, doctor, context). Les autres commandes n'acceptent pas cet indicateur. Les indices imprimés par les commandes portent déjà l'indicateur ; conservez-le pour les actions suivantes. Sans store, 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. Si c'est vague ou ambigu, vous DEVEZ demander les changements disponibles.

Étapes

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

   Exécutez openspec list --json pour obtenir les changements disponibles. Utilisez l'outil AskUserQuestion pour laisser l'utilisateur choisir.

   Affichez les changements qui ont des spécifications delta (dans le répertoire specs/).

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

2. Résoudre le contexte du changement

   Exécutez :

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

3. Trouver les spécifications delta

   Utilisez artifactPaths.specs.existingOutputPaths du JSON de statut comme liste des fichiers de spécifications delta.

   Chaque fichier de spécification delta contient des sections comme :

   • ## ADDED Requirements - Nouveaux besoins à ajouter
   • ## MODIFIED Requirements - Modifications aux besoins existants
   • ## REMOVED Requirements - Besoins à supprimer
   • ## RENAMED Requirements - Besoins à renommer (format FROM:/TO:)

   Si aucune spécification delta n'est trouvée, informez l'utilisateur et arrêtez-vous.

4. Pour chaque spécification delta, appliquer les modifications aux spécifications principales

   Pour chaque chemin de spécification delta de capacité local au dépôt renvoyé par le CLI :

   a. Lire la spécification delta pour comprendre les modifications prévues

   b. Lire la spécification principale à openspec/specs/<capacité>/spec.md (peut ne pas encore exister)

   c. Appliquer les modifications intelligemment :

   ADDED Requirements :

   • Si le besoin n'existe pas dans la spécification principale → l'ajouter
   • Si le besoin existe déjà → le mettre à jour pour correspondre (traiter comme MODIFIED implicite)

   MODIFIED Requirements :

   • Trouver le besoin dans la spécification principale
   • Appliquer les modifications - cela peut être :
     • Ajouter de nouveaux scénarios (pas besoin de copier ceux existants)
     • Modifier des scénarios existants
     • Changer la description du besoin
   • Préserver les scénarios/contenu non mentionnés dans le delta

   REMOVED Requirements :

   • Supprimer tout le bloc du besoin de la spécification principale

   RENAMED Requirements :

   • Trouver le besoin FROM, le renommer en TO

   d. Créer une nouvelle spécification principale si la capacité n'existe pas encore :

   • Créer openspec/specs/<capacité>/spec.md
   • Ajouter une section Purpose (peut être brève, marquer comme TBD)
   • Ajouter une section Requirements avec les besoins ADDED

5. Afficher le résumé

   Après avoir appliqué toutes les modifications, résumez :

   • Quelles capacités ont été mises à jour
   • Quelles modifications ont été apportées (besoins ajoutés/modifiés/supprimés/renommés)

Référence du format de spécification delta

## ADDED Requirements

### Requirement: Nouvelle fonctionnalité
Le système DOIT faire quelque chose de nouveau.

#### Scenario: Cas de base
- **QUAND** l'utilisateur fait X
- **ALORS** le système fait Y

## MODIFIED Requirements

### Requirement: Fonctionnalité existante
#### Scenario: Nouveau scénario à ajouter
- **QUAND** l'utilisateur fait A
- **ALORS** le système fait B

## REMOVED Requirements

### Requirement: Fonctionnalité obsolète

## RENAMED Requirements

- FROM: `### Requirement: Ancien nom`
- TO: `### Requirement: Nouveau nom`

Principe clé : Fusion intelligente

Contrairement à la fusion programmatique, vous pouvez appliquer des mises à jour partielles :

• Pour ajouter un scénario, incluez simplement ce scénario sous MODIFIED - ne copiez pas les scénarios existants
• Le delta représente l'intention, pas un remplacement total
• Utilisez votre jugement pour fusionner les modifications de manière pertinente

Résultat en cas de succès

## Spécifications synchronisées : <nom-du-changement>

Spécifications principales mises à jour :

**<capacité-1>** :
- Besoin ajouté : "Nouvelle fonctionnalité"
- Besoin modifié : "Fonctionnalité existante" (1 scénario ajouté)

**<capacité-2>** :
- Nouveau fichier de spécification créé
- Besoin ajouté : "Autre fonctionnalité"

Les spécifications principales sont maintenant à jour. Le changement reste actif - archivez-le lorsque l'implémentation est terminée.

Gardes-fous

• Lisez les spécifications delta et principales avant d'apporter des modifications
• Préservez le contenu existant non mentionné dans le delta
• Si quelque chose n'est pas clair, demandez des clarifications
• Montrez ce que vous modifiez au fur et à mesure
• L'opération doit être idempotente - l'exécuter deux fois doit donner le même résultat