Explorer en premier

/opsx:explore est votre partenaire de réflexion. Utilisez-le chaque fois que vous avez un problème mais pas encore de plan. Il examine votre base de code, pèse les options avec vous et clarifie ce que vous voulez réellement, le tout avant qu'un seul artefact ou une seule ligne de code ne soit créé. Quand la situation est claire, il transmet le relais à /opsx:propose.

Si vous ne retenez qu'une seule habitude de ces documents, retenez celle-ci : quand vous n'êtes pas sûr, explorez avant de proposer.

Voici pourquoi c'est important. Les assistants de codage IA sont enthousiastes. Posez une question vague et ils construiront quelque chose avec confiance, mais peut-être pas ce dont vous aviez besoin. Explorer est le remède. C'est une conversation sans enjeu où vous et l'IA trouvez ensemble la bonne marche à suivre, afin que lorsque vous proposez, vous proposiez la bonne chose.

Quand explorer

Explorer est le bon premier pas plus souvent qu'on ne le croit. Utilisez-le quand l'une de ces situations est vraie :

• Vous connaissez le problème mais pas la solution. (« Les pages sont lentes. » « L'authentification est un chaos. » « Nous recevons régulièrement des commandes en double. »)
• Vous hésitez entre plusieurs approches et voulez que les compromis soient exposés par rapport à votre code réel.
• Vous débutez dans une base de code et devez comprendre comment quelque chose fonctionne avant de le modifier.
• Les exigences sont floues et vous voulez les affiner avant de vous engager.
• Vous soupçonnez que le travail est plus grand ou plus petit qu'il n'y paraît et voulez l'estimer honnêtement.

Passez l'exploration uniquement quand vous savez déjà exactement ce que vous voulez et comment. Dans ce cas, allez directement à /opsx:propose.

Ce qu'il fait (et ne fait pas)

Explorer est une conversation, pas un générateur.

Il fait :

• Lire et rechercher dans votre base de code pour répondre à des questions réelles.
• Comparer les options et nommer les compromis de chacune.
• Dessiner des diagrammes pour rendre un design lisible.
• Vous aider à réduire une idée vague en un périmètre concret et réalisable.
• Passer à /opsx:propose quand vous êtes prêt.

Il ne fait pas :

• Créer un dossier de changement.
• Écrire des artefacts (aucune proposition, spécifications, design ou tâches).
• Écrire ou modifier du code.

C'est le but. Explorer ne vous coûte rien et ne vous engage à rien. Vous pouvez explorer trois impasses, apprendre quelque chose de chacune, et seulement alors proposer le chemin qui a survécu.

Il est déjà installé

Bonne nouvelle : /opsx:explore est livré dans le profil core par défaut, aux côtés de propose, apply, update, sync et archive. Vous n'avez rien à activer. Si OpenSpec est configuré dans votre projet, explorer est prêt dans votre chat IA. (Comme pour toutes les commandes /opsx:*, vous la tapez dans le chat de votre assistant, pas dans le terminal. Voir Comment fonctionnent les commandes.)

Un exemple complet

Observez comment une inquiétude vague devient un changement précis et réalisable.

Vous : /opsx:explore

IA   : Que souhaitez-vous explorer ?

Vous : Notre paiement crée parfois des commandes en double. Je ne sais pas
       pourquoi et je ne sais pas comment le corriger en toute sécurité.

IA   : Laissez-moi creuser le parcours de paiement...
       [lit le service de commande, le gestionnaire de webhook de paiement
        et la logique de soumission côté client]

       Voici ce que j'ai trouvé. Il y a deux façons qu'un doublon peut se produire :

       1. Le client peut soumettre deux fois (double-clic, nouvelle tentative sur un réseau lent).
          Rien ne le débounce.
       2. Le webhook de paiement peut se déclencher plus d'une fois, et le gestionnaire
          crée une commande à chaque fois. Il n'y a pas de clé d'idempotence.

       La cause n°2 est la dangereuse : elle peut facturer et livrer deux fois.

       Trois façons de le corriger, approximativement par ordre de robustesse :
       - Clé d'idempotence sur le point d'accès de création de commande (gère les deux causes)
       - Déduplication sur le webhook par identifiant de paiement (gère uniquement la n°2)
       - Debounce côté client (gère uniquement la n°1, masque le vrai bug)

       Étant donné que votre code stocke déjà l'identifiant de paiement,
       l'approche par clé d'idempotence est un petit changement au meilleur rapport bénéfice/effort.
       Voulez-vous que je définisse le périmètre ?

Vous : Oui, faisons la clé d'idempotence.

Vous : /opsx:propose add-order-idempotency-key

IA   : Créé openspec/changes/add-order-idempotency-key/, avec une proposition
       et une spécification delta fondée sur ce que nous venons de découvrir. Prêt pour l'implémentation.

Remarquez ce qui s'est passé. Le point de départ était « quelque chose ne va pas et j'ai peur de toucher à ça. » Vingt secondes d'exploration ont transformé cela en une cause racine nommée, trois options classées, une recommandation liée au code existant, et un changement précis. La proposition qui suit est percutante parce que la réflexion a eu lieu en premier.

Transmission à propose

Explorer n'archive rien. Quand vous êtes prêt, vous démarrez simplement un changement, et l'IA transporte le contexte de votre conversation dans les artefacts.

explore  ──►  propose  ──►  apply  ──►  archive
 (réfléchir)  (s'accorder)  (construire)  (enregistrer)

Vous pouvez le dire en langage naturel (« transformons ça en changement ») ou exécuter /opsx:propose <name> directement. Dans les deux cas, l'exploration que vous venez de faire devient le fondement de la proposition, pas un chat jetable.

Si vous utilisez le jeu de commandes étendu, explorer peut transmettre à /opsx:new à la place, pour une création d'artefacts étape par étape. Voir Workflows.

Conseils pour une bonne exploration

• Apportez le problème, pas la solution. « Les connexions sont lentes » laisse à l'IA de la place pour investiguer. « Ajoutons un cache Redis » vous engage à une réponse que vous n'avez pas encore testée.
• Demandez les compromis à voix haute. « Quels sont les inconvénients de chaque option ? » vous donne une comparaison plus honnête.
• Laissez-le lire d'abord. Les meilleures explorations commencent par l'IA qui regarde réellement votre code, pas qui devine. Pointez-le vers la zone pertinente si cela aide.
• Il est normal d'abandonner. Si l'exploration révèle que l'idée n'en vaut pas la peine, c'est une victoire. Vous l'avez appris à moindre coût.
• Re-Explorez en cours de changement. Bloqué pendant /opsx:apply ? Vous pouvez revenir en arrière et explorer un sous-problème, puis revenir.

Les compromis honnêtes

Ce que vous gagnez : explorer attrape les mauvais virages au moment le moins coûteux possible, avant qu'aucun artefact n'existe. C'est particulièrement puissant dans un code inconnu, où la capacité de l'IA à lire et résumer le système vous épargne un après-midi de fouille.

Ce que ça coûte : un peu de patience. Explorer est une conversation, donc c'est plus lent que de lancer /opsx:propose et espérer. Pour un travail que vous comprenez déjà parfaitement, cette étape supplémentaire est un surcoût pur, et vous devriez la sauter.

La règle de base : plus la tâche est floue, plus explorer rapporte. Plus la tâche est claire, plus vous pouvez passer directement à la proposition.

Où aller ensuite

• Commandes : /opsx:explore : la référence précise
• Workflows : explorer comme partie du cycle quotidien
• Exemples et recettes : explorer dans un parcours complet
• Démarrage : le guide du premier changement, exploration incluse