Explorar primero

/opsx:explore es tu compañero de pensamiento. Acude a él cada vez que tengas un problema pero aún no un plan. Investiga tu base de código, evalúa opciones contigo y aclara lo que realmente quieres, todo antes de crear un solo artefacto o línea de código. Cuando la imagen está clara, lo entrega a /opsx:propose.

Si te llevas un solo hábito de estos documentos, llévate este: cuando no estás seguro, explora antes de proponer.

Aquí está por qué eso importa. Los asistentes de codificación con IA son entusiastas. Si preguntas vagamente, construirán algo con confianza, solo que quizás no sea lo que necesitabas. Explorar es la cura. Es una conversación sin riesgos donde tú y la IA encuentran juntos el movimiento correcto, para que cuando propongas, estés proponiendo lo correcto.

Cuándo explorar

Explorar es el primer paso correcto más a menudo de lo que la gente espera. Úsalo cuando alguna de estas condiciones sea verdadera:

• Conoces el problema pero no la solución. ("Las páginas se sienten lentas." "La autenticación es un desastre." "Seguimos recibiendo pedidos duplicados.")
• Estás eligiendo entre enfoques y quieres que se expongan los compromisos frente a tu código real.
• Eres nuevo en una base de código y necesitas entender cómo funciona algo antes de cambiarlo.
• Los requisitos son vagos y quieres afinarlos antes de comprometerte.
• Sospechas que el trabajo es más grande o más pequeño de lo que parece y quieres dimensionarlo honestamente.

Salta explorar solo cuando ya sabes exactamente qué quieres y cómo. En ese caso, ve directamente a /opsx:propose.

Qué hace (y no hace)

Explorar es una conversación, no un generador.

Lo que hace:

• Leer y buscar en tu base de código para responder preguntas reales.
• Comparar opciones y nombrar los compromisos de cada una.
• Dibujar diagramas para hacer un diseño legible.
• Ayudarte a reducir una idea vaga a un alcance concreto y construible.
• Transicionar a /opsx:propose cuando estés listo.

Lo que no hace:

• Crear una carpeta de cambios.
• Escribir artefactos (sin propuesta, especificaciones, diseño o tareas).
• Escribir o modificar código.

Ese es el punto. Explorar no te cuesta nada y no te compromete a nada. Puedes explorar tres callejones sin salida, aprender algo de cada uno, y solo entonces proponer el camino que sobrevivió.

Ya está instalado

Buenas noticias: /opsx:explore viene incluido en el perfil core por defecto, justo al lado de propose, apply, update, sync y archive. No necesitas habilitar nada. Si OpenSpec está configurado en tu proyecto, explorar está listo en tu chat de IA. (Como con todos los comandos /opsx:*, lo escribes en el chat de tu asistente, no en la terminal. Consulta Cómo funcionan los comandos.)

Un ejemplo completo

Observa cómo una preocupación vaga se convierte en un cambio nítido y construible.

You: /opsx:explore

AI:  What would you like to explore?

You: Our checkout sometimes creates duplicate orders. I don't know why
     and I don't know how to fix it safely.

AI:  Let me dig into the checkout path...
     [reads the order service, the payment webhook handler, and the
      client submit logic]

     Here's what I found. There are two ways a duplicate can happen:

     1. The client can submit twice (double-click, retry on slow network).
        Nothing debounces it.
     2. The payment webhook can fire more than once, and the handler
        creates an order each time. There's no idempotency key.

     Cause #2 is the dangerous one: it can charge and fulfill twice.

     Three ways to fix it, roughly in order of robustness:
     - Idempotency key on the order-creation endpoint (handles both causes)
     - Dedup on the webhook by payment-intent id (handles #2 only)
     - Client-side debounce (handles #1 only, papers over the real bug)

     Given your code already stores the payment-intent id, the
     idempotency-key approach is a small change with the biggest payoff.
     Want me to scope that?

You: Yes, let's do the idempotency key.

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

AI:  Created openspec/changes/add-order-idempotency-key/, with a proposal
     and delta spec grounded in what we just found. Ready for implementation.

Fíjate en lo que pasó. El punto de partida fue "algo está mal y me da miedo tocarlo." Veinte segundos de exploración convirtieron eso en una causa raíz nombrada, tres opciones clasificadas, una recomendación ligada al código existente y un cambio preciso. La propuesta que sigue es nítida porque el pensamiento ocurrió primero.

Entregando a propose

Explorar no archiva en nada. Cuando estés listo, simplemente inicias un cambio, y la IA lleva el contexto de tu conversación a los artefactos.

explore  ──►  propose  ──►  apply  ──►  archive
 (think)     (agree)       (build)     (record)

Puedes decirlo en lenguaje llano ("convirtamos esto en un cambio") o ejecutar /opsx:propose <name> directamente. De cualquier manera, la exploración que acabas de hacer se convierte en la base de la propuesta, no en un chat descartable.

Si usas el conjunto de comandos expandido, explorar puede entregar a /opsx:new en su lugar, para la creación de artefactos paso a paso. Consulta Flujos de trabajo.

Consejos para una buena exploración

• Trae el problema, no la solución. "Los inicios de sesión se sienten lentos" le da espacio a la IA para investigar. "Agrega una caché Redis" te compromete a una respuesta que aún no has probado.
• Pide los compromisos en voz alta. "¿Cuáles son las desventajas de cada opción?" te da una comparación más honesta.
• Déjalo leer primero. Las mejores exploraciones comienzan con la IA mirando realmente tu código, no adivinando. Apúntalo al área relevante si ayuda.
• Está bien retirarse. Si la exploración revela que la idea no vale la pena, eso es una victoria. Lo aprendiste a bajo costo.
• Explora de nuevo a mitad de cambio. ¿Atascado durante /opsx:apply? Puedes dar un paso atrás y explorar un subproblema, y luego regresar.

Los compromisos honestos

Lo que ganas: explorar detecta los desvíos en el momento más barato posible, antes de que exista cualquier artefacto. Es especialmente poderoso en código poco familiar, donde la capacidad de la IA para leer y resumir el sistema te ahorra una tarde de exploración.

Lo que cuesta: un poco de paciencia. Explorar es una conversación, así que es más lento que disparar /opsx:propose y esperar. Para trabajo que ya entiendes genuinamente, ese paso extra es puro sobrecargo, y deberías saltártelo.

La regla general: cuanto más vaga sea la tarea, más rinde explorar. Cuanto más clara sea la tarea, más puedes saltar directamente a proponer.

Dónde ir a continuación

• Comandos: /opsx:explore: la referencia precisa
• Flujos de trabajo: explorar como parte del ciclo diario
• Ejemplos y recetas: explorar en un recorrido completo
• Primeros pasos: la guía del primer cambio, incluida la exploración