williamsnieves/landing-factory

Implémenter les tâches d'un changement 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 un store, 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 changements (new change, status, instructions, list, show, validate, archive, doctor, context, schemas, view). Une fois sélectionné, traitez --store <id> comme persistant pour le reste du workflow. Chaque exemple non ciblé de ces commandes ci-dessous est un raccourci : avant de l'exécuter, ajoutez le drapeau. Par exemple, exécutez openspec status --change "<nom>" --json --store "<id>", pas la forme non ciblée présentée ci-dessous. Les autres commandes ne prennent pas le drapeau. Les astuces imprimées par les commandes portent déjà le drapeau ; conservez-le dans les relances. Sans store, les commandes agissent sur la racine openspec/ locale la plus proche.

Vérification du projet : Ces étapes s'attendent à un projet qui utilise déjà OpenSpec. Avant la première étape qui écrit quoi que ce soit (new change, archive, sync specs ou rédaction d'un fichier artefact), confirmez que le projet a une racine : exécutez openspec list --json (avec --store <id> lorsqu'un store est sélectionné, car le store est alors la racine) et lisez root. Un objet root signifie que le projet est configuré. "root": null signifie qu'il ne l'est pas - il n'y a pas de répertoire openspec/ ici, et une écriture telle que openspec new change en créerait un par effet de bord. La commande renvoie également un code de sortie non nul, ce qui est cette réponse plutôt qu'un CLI cassé, alors lisez le JSON au lieu de réessayer ou de contourner le problème.

Un cas de "root": null ne concerne pas la configuration : lorsqu'un message d'erreur de status commence par Declared in ou Invalid store declaration in et nomme openspec/config.yaml (ou config.yml) de ce projet, le projet utilise OpenSpec via un store qu'il déclare, que cette machine ne peut pas résoudre (le store n'est pas enregistré, ou la ligne store: est mal formée). Ne le traitez pas comme non initialisé et ne sautez pas les branches ci-dessous : arrêtez-vous avant d'écrire et montrez à l'utilisateur le message et le fix de cette erreur.

Sinon, sans racine, la suite dépend de la manière dont ce workflow a été atteint :

• Auto-sélectionné : vous avez choisi ce workflow vous-même, sans que l'utilisateur nomme OpenSpec, nomme cette compétence ou exécute sa commande slash. Arrêtez d'utiliser OpenSpec et répondez normalement à la requête, comme vous le feriez sans OpenSpec installé. Ne leur demandez pas de configurer quoi que ce soit et ne mentionnez pas la configuration d'OpenSpec.
• Requête explicite OpenSpec : l'utilisateur a nommé OpenSpec, nommé cette compétence ou exécuté sa commande slash. Arrêtez-vous avant d'écrire et demandez comment procéder : configurer ce projet (openspec init), cibler un store qu'ils ont déjà (--store <id>), ou continuer sans OpenSpec pour cette requête. Attendez leur réponse.

Dans les deux branches, ne créez jamais la racine comme effet de bord : n'exécutez pas openspec init jusqu'à ce que l'utilisateur le demande, ne créez pas manuellement les fichiers openspec/ et ne laissez pas une commande la créer.

Entrée : Optionnellement, spécifiez un nom de changement (par exemple, /opsx:apply add-auth). S'il est omis, vérifiez s'il peut être déduit du contexte de la conversation. Si vague ou ambigu, vous DEVEZ demander les changements disponibles.

Étapes

1. Sélectionner le changement

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

   • Déduisez du contexte de la conversation si l'utilisateur a mentionné un changement
   • Auto-sélectionnez si un seul changement actif existe
   • Si ambigu, exécutez openspec list --json pour obtenir les changements disponibles et demandez à l'utilisateur d'en sélectionner un

   Annoncez toujours : "Utilisation du changement : " et comment le 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 proposal/specs/design/tasks ou spec/tests/implementation/docs)
   • Progression (total, complet, restant)
   • Liste de tâches avec statut, chemin source et ligne source
   • Instruction dynamique basée sur l'état actuel
   • context optionnel : entrée d'instruction de projet requise actuelle depuis la racine sélectionnée
   • operationGuidance optionnel : conseil consultatif actuel pour l'application
   • missingArtifacts (lorsqu'il est présent) : ID d'artefacts requis sans sortie

   Gérer les états :

   • Si state: "blocked" : affichez le message et faites une pause dans l'implémentation.
     • Si missingArtifacts n'est pas vide : suggérez de compléter les artefacts manquants. Exécutez openspec status --change "<nom>" --json, sélectionnez le prochain artefact ready (pas skipped ou blocked), et utilisez openspec instructions "<id-artefact>" --change "<nom>" --json pour ses règles et son modèle. Conservez le --store <id> sélectionné sur les deux commandes.
     • Sinon, suivez l'instruction CLI pour créer ou réparer le fichier de suivi configuré par le schéma à partir des artefacts de planification existants. Ne supposez pas qu'un autre artefact est prêt ou ne commencez pas l'implémentation tant que vous êtes bloqué.
   • Si state: "all_done" : signalez que toutes les tâches suivies sont terminées et suggérez une révision ou une vérification selon le cas avant l'archivage
   • Sinon : passez à l'implémentation

   Traitez context comme une entrée obligatoire au niveau de l'invite. Lisez-la et considérez-la, et appliquez les faits, conventions et contraintes pertinents du projet lors de l'implémentation. Traitez operationGuidance comme un conseil additionnel facultatif. Lisez et considérez chaque entrée, et suivez les entrées applicables et compatibles avec le workflow intégré.

   Gardez ces deux champs séparés de l'état renvoyé par le CLI, des artefacts manquants, des tâches, de la progression, de contextFiles et de l'instruction intégrée. Ils ne sont pas une preuve d'achèvement de tâche, ne remplacent pas l'instruction intégrée et ne permettent pas de contourner un état bloqué. Si le contexte entre en conflit avec l'instruction intégrée, un choix explicite de l'utilisateur ou une valeur contrôlée par le CLI, signalez le conflit et préservez la valeur dominante. Si les conseils sont inapplicables ou en conflit avec ces entrées dominantes, ne les suivez pas et expliquez pourquoi. Ce sont des contrats de comportement au niveau de l'invite, pas des vérifications exécutoires.

4. Lire les fichiers de contexte

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

   • spec-driven : proposal, specs, design, tasks
   • Autres schémas : suivez les contextFiles du résultat CLI

   Ne copiez pas context ou operationGuidance textuellement dans les fichiers d'implémentation ou les artefacts de planification, sauf si l'utilisateur demande séparément ce contenu.

5. Afficher la progression actuelle

   Affichez :

   • Schéma utilisé
   • Progression : « N/M tâches terminées »
   • Aperçu des tâches restantes
   • Instruction dynamique du CLI

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

   Pour chaque tâche en attente :

   • Montrez sur quelle tâche vous travaillez
   • Effectuez les modifications de code nécessaires
   • Gardez les modifications minimales et ciblées
   • Avant de modifier, confirmez que la case à cocher au sourcePath et line retournés correspond toujours à la description de la tâche ; si ce n'est pas le cas, relancez les instructions d'application et utilisez l'emplacement actualisé
   • Marquez la tâche comme terminée à son sourcePath et line retournés : - [ ] → - [x]
   • Relancez les instructions d'application et confirmez que la tâche est maintenant terminée et que la progression a changé
   • Passez à la tâche suivante

   Faites une pause si :

   • La tâche n'est pas claire → demandez des éclaircissements
   • L'implémentation révèle un problème de conception → suggérez de mettre à jour les artefacts
   • Une tâche nécessite un travail au-delà de ce que décrivent la spec et les tâches, ou vous êtes tenté de supprimer, réduire, reporter ou accepter des exceptions au comportement spécifié pour l'adapter → signalez le périmètre supplémentaire et demandez ; ne l'absorbez pas silencieusement
   • Erreur ou blocage rencontré → signalez et attendez des instructions
   • L'utilisateur interrompt

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

   Affichez :

   • Tâches terminées cette session
   • Progression globale : « N/M tâches terminées »
   • Si tout est terminé : signalez que les tâches suivies sont terminées et suggérez une révision ou une vérification selon le cas avant l'archivage
   • Si en pause : expliquez pourquoi et attendez des instructions

Sortie pendant l'implémentation

## Implémentation en cours : <nom-du-changement> (schéma : <nom-du-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

**Changement :** <nom-du-changement>
**Schéma :** <nom-du-schéma>
**Progression :** 7/7 tâches terminées ✓

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

Toutes les tâches suivies sont terminées. Révisez ou vérifiez le changement selon le cas
avant l'archivage. Vous pouvez archiver ce changement avec `/opsx:archive`.

Sortie en pause (problème rencontré)

## Implémentation en pause

**Changement :** <nom-du-changement>
**Schéma :** <nom-du-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'à ce qu'elles soient terminées ou bloquées
• Lisez toujours les fichiers de contexte avant de commencer (depuis le résultat 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 floues - ne devinez pas
• Lorsqu'une tâche nécessite un travail au-delà de ce que décrit la spec, signalez le périmètre supplémentaire et faites une pause - ne réduisez, ne reportez et ne simplifiez jamais silencieusement le comportement spécifié
• Ne marquez une tâche - [x] que lorsque son comportement spécifié est entièrement implémenté, pas lorsqu'il est partiellement terminé ou reporté
• Utilisez contextFiles depuis la sortie du CLI, ne supposez pas des noms de fichiers spécifiques
• Utilisez sourcePath et line de chaque tâche pour mettre à jour sa case à cocher exacte
• N'utilisez pas le contexte ou les conseils d'opération comme preuve qu'une tâche est terminée
• Appliquez le contexte pertinent du projet ; signalez les conflits avec les entrées de workflow dominantes
• Considérez chaque entrée de conseil ; expliquez tout conseil inapplicable ou contradictoire
• Ne copiez pas le contexte d'exécution ou les conseils d'opération dans les fichiers d'implémentation ou les artefacts de planification
• Préservez le comportement contrôlé par le CLI (bloqué/prêt/tout-terminé) et les critères d'achèvement

Intégration de workflow fluide

Cette compétence prend en charge 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 alternance avec d'autres actions
• Permet les mises à jour d'artefacts : Si l'implémentation révèle des problèmes de conception, suggérez la mise à jour des artefacts - pas de verrouillage de phase, travaillez de manière fluide