robsonprod/portfolio

Implémente des tâches à partir 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 si le travail se trouve 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, schemas, view). Une fois sélectionné, considérez --store <id> comme persistant pour le reste du workflow. Chaque exemple non ciblé de ces commandes ci-dessous est une abréviation : avant de l'exécuter, ajoutez le drapeau. Par exemple, exécutez openspec status --change "<name>" --json --store "<id>", et non 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 suivis. Sans store, les commandes agissent sur la racine openspec/ locale la plus proche.

Vérification du projet : Ces étapes supposent un projet qui utilise déjà OpenSpec. Avant la première étape qui écrit quoi que ce soit (new change, archive, sync specs ou la rédaction d'un fichier d'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 se termine également avec un code non nul, ce qui est la réponse plutôt qu'une CLI cassée, alors lisez le JSON au lieu de réessayer ou de contourner.

Un "root": null ne concerne pas la configuration : lorsqu'un message d'erreur status commence par Declared in ou Invalid store declaration in et nomme le 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 façon 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 oblique. Arrêtez d'utiliser OpenSpec et répondez à la demande normalement, 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.
• Demande explicite d'OpenSpec : l'utilisateur a nommé OpenSpec, nommé cette compétence ou exécuté sa commande oblique. 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 demande. Attendez leur réponse.

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

Entrée : Facultativement, 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 s'il n'existe qu'un seul changement actif
   • 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 <other>).

2. Vérifier l'état pour comprendre le schéma

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

   Analysez le JSON pour comprendre :

   • schemaName : Le workflow utilisé (par exemple, « spec-driven »)
   • planningHome, changeRoot et actionContext : portée de la planification et contraintes d'édition
   • Quel artefact contient les tâches (généralement « tasks » pour spec-driven, vérifiez l'état pour les autres)

3. Obtenir les instructions apply

   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, chemin source et ligne source
   • Instruction dynamique basée sur l'état actuel
   • context optionnel : entrée d'instruction de projet actuelle requise depuis la racine sélectionnée
   • operationGuidance optionnel : conseil avisé actuel pour apply
   • missingArtifacts (lorsqu'il est présent) : ID d'artefacts requis sans sortie

   Gérer les états :

   • Si state: "blocked" : affichez le message et interrompez l'implémentation.
     • Si missingArtifacts n'est pas vide : suggérez de compléter les artefacts manquants. Exécutez openspec status --change "<name>" --json, sélectionnez le prochain artefact ready (pas skipped ou blocked), et utilisez openspec instructions "<artifact-id>" --change "<name>" --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 démarrez pas l'implémentation pendant 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 : procédez à l'implémentation

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

   Gardez les deux champs séparés de l'état retourné par la 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 de l'achèvement des tâches, 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 la CLI, signalez le conflit et préservez la valeur de contrôle. Si les conseils ne sont pas applicables ou entrent en conflit avec ces entrées de contrôle, 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 apply. 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 operationGuidation 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 de la CLI

6. Implémenter les tâches (boucle jusqu'à la fin ou le 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 d'éditer, confirmez que la case à cocher au sourcePath et à la line retournés correspond toujours à la description de la tâche ; si ce n'est pas le cas, relancez les instructions apply et utilisez l'emplacement rafraîchi
   • Marquez la tâche comme terminée à son sourcePath et sa line retournés : - [ ] → - [x]
   • Relancez les instructions apply et confirmez que cette tâche est maintenant terminée et que la progression a changé
   • Passez à la tâche suivante

   Interrompre 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 la spécification et les tâches décrivent, ou si vous êtes tenté de supprimer, réduire, différer ou accepter des exceptions au comportement spécifié pour l'adapter → signalez la portée ajoutée et demandez ; ne l'absorbez pas silencieusement
   • Erreur ou blocage rencontré → signalez et attendez des instructions
   • L'utilisateur interrompt

7. En cas d'achèvement ou d'interruption, afficher l'état

   Affichez :

   • Tâches terminées dans 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 interrompu : expliquez pourquoi et attendez des instructions

Sortie pendant l'implémentation

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

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 :** <change-name>
**Schéma :** <schema-name>
**Progression :** 7/7 tâches terminées ✓

### Terminé dans 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 cas d'interruption (problème rencontré)

## Implémentation interrompue

**Changement :** <change-name>
**Schéma :** <schema-name>
**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'à la fin ou le blocage
• Lisez toujours les fichiers de contexte avant de commencer (à partir du résultat des instructions apply)
• Si la tâche est ambiguë, interrompez-vous et demandez avant d'implémenter
• Si l'implémentation révèle des problèmes, interrompez-vous et suggérez des mises à jour des 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
• Interrompez-vous en cas d'erreurs, de blocages ou d'exigences peu claires - ne devinez pas
• Lorsqu'une tâche nécessite un travail au-delà de ce que la spécification décrit, signalez la portée ajoutée et interrompez-vous - ne réduisez, ne différez ou 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'elle est partiellement terminée ou différée
• Utilisez contextFiles du résultat CLI, ne supposez pas de noms de fichiers spécifiques
• Utilisez le sourcePath et la line de chaque tâche pour mettre à jour sa case à cocher exacte
• N'utilisez pas le contexte ou les conseils opérationnels comme preuve qu'une tâche est terminée
• Appliquez le contexte de projet pertinent ; signalez les conflits avec les entrées de contrôle du workflow
• Considérez chaque entrée de conseil ; expliquez tout conseil inapplicable ou conflictuel
• Ne copiez pas le contexte d'exécution ou les conseils opérationnels dans les fichiers d'implémentation ou les artefacts de planification
• Préservez le comportement contrôlé par la CLI (bloqué/prêt/tout terminé) et les critères d'achèvement

Intégration fluide du workflow

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, 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