Explore Primeiro

/opsx:explore é seu parceiro de raciocínio. Recorra a ele sempre que tiver um problema, mas ainda não um plano. Ele investiga sua base de código, analisa opções com você e esclarece o que você realmente deseja, tudo antes que qualquer artefato ou linha de código seja criada. Quando o panorama estiver claro, ele transfere a tarefa para /opsx:propose.

Se você adotar apenas um hábito destes documentos, adote este: quando não tiver certeza, explore antes de propor.

Veja por que isso importa. Assistentes de codificação com IA são ávidos. Faça perguntas vagas e eles construirão algo com confiança, talvez não exatamente o que você precisava. O Explore é a cura. É uma conversa sem riscos onde você e a IA descobrem juntos o movimento correto, de modo que, quando chegar a hora de propor, você estará propondo a coisa certa.

Quando explorar

Explorar é o primeiro passo adequado mais frequentemente do que as pessoas esperam. Use-o quando qualquer uma das seguintes condições for verdadeira:

• Você conhece o problema, mas não a solução. ("As páginas parecem lentas." "A autenticação é uma bagunça." "Continuamos recebendo pedidos duplicados.")
• Você está escolhendo entre abordagens e quer ver os prós e contras expostos em relação ao seu código real.
• Você é novo na base de código e precisa entender como algo funciona antes de alterá-lo.
• Os requisitos estão nebulosos e você quer refiná-los antes de se comprometer.
• Você suspeita que o trabalho é maior ou menor do que aparenta e quer dimensioná-lo honestamente.

Pule a exploração apenas quando você já souber exatamente o que deseja e como fazer. Nesse caso, vá diretamente para /opsx:propose.

O que faz (e o que não faz)

Explore é uma conversa, não um gerador.

Ele faz:

• Ler e pesquisar sua base de código para responder a perguntas reais.
• Comparar opções e apontar os prós e contras de cada uma.
• Criar diagramas para tornar um design legível.
• Ajudar a reduzir uma ideia vaga para um escopo concreto e construtível.
• Transicionar para /opsx:propose quando você estiver pronto.

Ele não faz:

• Criar uma pasta de alterações.
• Escrever nenhum artefato (nenhuma proposta, especificações, design ou tarefas).
• Escrever ou modificar código.

Esse é o ponto. Explorar não custa nada e não o compromete com nada. Você pode explorar três becos sem saída, aprender algo com cada um deles e só então propor o caminho que sobreviveu.

Já está instalado

Boas notícias: /opsx:explore vem incluído no perfil padrão core, junto com propose, apply, update, sync e archive. Você não precisa ativar nada. Se o OpenSpec estiver configurado no seu projeto, o explore estará pronto no seu chat de IA. (Assim como todos os comandos /opsx:*, você o digita no chat do seu assistente, não no terminal. Veja Como os Comandos Funcionam.)

Um exemplo completo

Veja como uma preocupação vaga se transforma em uma alteração nítida e construtível.

Você: /opsx:explore

IA:  O que você gostaria de explorar?

Você: Nosso checkout às vezes cria pedidos duplicados. Não sei por quê
     e não sei como corrigir isso com segurança.

IA:  Vou investigar o fluxo de checkout...
     [lê o serviço de pedidos, o manipulador de webhook de pagamento e a
      lógica de envio do cliente]

     Aqui está o que encontrei. Existem duas maneiras pelas quais uma duplicação pode ocorrer:

     1. O cliente pode enviar duas vezes (duplo clique, nova tentativa em rede lenta).
        Nada evita isso (debounce).
     2. O webhook de pagamento pode disparar mais de uma vez, e o manipulador
        cria um pedido a cada vez. Não há chave de idempotência.

     A causa #2 é a perigosa: ela pode cobrar e atender duas vezes.

     Três maneiras de corrigir isso, aproximadamente em ordem de robustez:
     - Chave de idempotência no endpoint de criação de pedidos (resolve ambas as causas)
     - Deduplicação no webhook pelo ID da intenção de pagamento (resolve apenas a #2)
     - Debounce no lado do cliente (resolve apenas a #1, mascara o bug real)

     Considerando que seu código já armazena o ID da intenção de pagamento, a
     abordagem de chave de idempotência é uma alteração pequena com o maior retorno.
     Quer que eu dimensione isso?

Você: Sim, vamos usar a chave de idempotência.

Você: /opsx:propose add-order-idempotency-key

IA:  Criado openspec/changes/add-order-idempotency-key/, com uma proposta
     e especificação delta fundamentadas no que acabamos de descobrir. Pronto para implementação.

Observe o que aconteceu. O ponto de partida era "algo está errado e estou com medo de mexer nisso". Vinte segundos de exploração transformaram isso em uma causa raiz nomeada, três opções classificadas, uma recomendação vinculada ao código existente e uma alteração precisa. A proposta que se segue é afiada porque o pensamento ocorreu primeiro.

Transferindo para propose

Explore não arquivia nada. Quando estiver pronto, basta iniciar uma alteração, e a IA levará o contexto de sua conversa para os artefatos.

explore  ──►  propose  ──►  apply  ──►  archive
 (pensar)    (concordar)   (construir)  (registrar)

Você pode dizer isso em linguagem natural ("vamos transformar isso em uma alteração") ou executar /opsx:propose <nome> diretamente. De qualquer forma, a exploração que você acabou de fazer se torna a base da proposta, não um bate-papo descartável.

Se você usar o conjunto expandido de comandos, explore pode transferir para /opsx:new em vez disso, para a criação passo a passo de artefatos. Veja Workflows.

Dicas para uma boa exploração

• Traga o problema, não a solução. "Os logins parecem lentos" dá à IA espaço para investigar. "Adicionar um cache Redis" o compromete antecipadamente com uma resposta que você ainda não testou.
• Peça para expor os prós e contros em voz alta. "Quais são os pontos negativos de cada opção?" resulta em uma comparação mais honesta.
• Deixe-a ler primeiro. As melhores explorações começam com a IA realmente olhando para o seu código, não adivinhando. Aponte-a para a área relevante se ajudar.
• É okay desistir. Se a exploração revelar que a ideia não vale a pena, isso é um ganho. Você aprendeu isso de forma barata.
• Explore novamente durante a alteração. Preso durante /opsx:apply? Você pode voltar atrás e explorar um subproblema e depois retornar.

Os tradeoffs honestos

O que você ganha: o explore captura desvios no momento mais barato possível, antes que qualquer artefato exista. É especialmente poderoso em códigos desconhecidos, onde a capacidade da IA de ler e resumir o sistema poupa você de uma tarde inteira de investigação profunda.

O que custa: um pouco de paciência. Explore é uma conversa, então é mais lento do que disparar /opsx:propose e torcer. Para trabalhos que você realmente já entende, essa etapa extra é pura sobrecarga, e você deve pulá-la.

A regra prática: quanto mais nebulosa a tarefa, mais o explore compensa. Quanto mais clara a tarefa, mais você pode pular direto para propor.

Para onde ir a seguir

• Comandos: /opsx:explore: a referência precisa
• Workflows: explore como parte do loop diário
• Exemplos & Receitas: explore em um walkthrough completo
• Introdução: o guia de primeira alteração, incluindo exploração