Criar Spike Técnico

Restrições Inegociáveis

• Não gere o spike sem antes coletar respostas de clarificação via AskUserQuestion.
• Não altere a estrutura do template em assets/spike-template.md.
• O spike documenta descobertas e recomendações; não implementa soluções nem altera código-fonte da aplicação.
• Todo achado precisa de fonte verificável (documentação oficial, RFC, benchmark, código do repositório, post oficial). Achados sem fonte são descartados.
• Sempre apresente a opção de "não fazer nada" como baseline na comparação de alternativas.

Procedimentos

Passo 1: Esclarecer (Obrigatório)

1. Leia references/clarification-checklist.md e selecione os blocos pertinentes à solicitação do usuário.
2. Formule perguntas agrupadas via AskUserQuestion, cobrindo no mínimo: dúvida técnica principal e secundárias, contexto/motivação, decisões dependentes, critério de sucesso e o que está fora do escopo (registrado no Contexto, não em seção própria).
3. Não prossiga ao Passo 2 enquanto houver perguntas não respondidas.

Passo 2: Pesquisar (Obrigatório)

1. Use WebSearch para localizar documentação oficial, artigos técnicos, benchmarks, RFCs e CVEs relacionados ao tema. Cite as fontes nos achados.
2. Quando aplicável, analise o código existente do repositório com Read e Grep para entender restrições, dependências e padrões já adotados.
3. Identifique no mínimo duas alternativas além de "não fazer nada"; compare-as com trade-offs explícitos (esforço, risco, performance, custo, manutenibilidade).
4. Colete métricas, benchmarks ou evidências sempre que disponíveis. Registre limitações dos dados encontrados.

Passo 3: Planejar (Obrigatório)

1. Defina a abordagem da investigação que será descrita na seção ## Abordagem do documento (análise de código, análise de padrões, análise de impacto, pesquisa documental, prototipagem, benchmark, consulta a especialista) e justifique cada uma.
2. Liste as perguntas que o spike deve responder e o critério de sucesso a ser declarado em ## Perguntas a Responder.
3. Identifique os critérios de comparação entre alternativas (ex.: performance, custo, manutenibilidade, lock-in) — esses critérios devem aparecer na descrição/prós/contras de cada opção.
4. Exiba o plano resumido ao usuário antes de redigir o documento.

Passo 4: Redigir o Spike (Obrigatório)

1. Leia assets/spike-template.md e replique sua estrutura exatamente, preservando a numeração e a ordem das seções: 1. Contexto → 2. Pergunta Principal → 3. Perguntas Secundárias e Critério de Sucesso → 4. Abordagem → 5. Achados → 6. Opções Identificadas → 7. Comparação Resumida → 8. Recomendação → 9. Perguntas Abertas → 10. Próximos Passos → 11. Fora de Escopo → 12. Referências.
2. Preencha a **Data:** no cabeçalho com a data atual (AAAA-MM-DD).
3. Numere os achados como ### Achado N: [Título]. Cada achado deve seguir o bloco padronizado: **Achado:**, **Evidência:** (em bloco de código quando for trecho de código/log/métrica) e **Fonte:** (arquivo:linha ou link verificável). Após o bloco padronizado, é permitido (e recomendado) acrescentar contexto adicional, tabelas e diagramas em texto livre.
4. Liste as opções como ### Opção 0: Não Fazer Nada (Baseline), ### Opção 1: ..., ### Opção 2: .... Para cada opção preencha Descrição, Esforço, Risco, Prós e Contras.
5. Preencha a tabela de ## 7. Comparação Resumida com os critérios definidos no Passo 3. Mantenha "Esforço" e "Risco" como critérios obrigatórios e substitua/adicione os demais conforme o caso (ex.: latência p99, curva de aprendizado, lock-in).
6. Em ## 8. Recomendação, registre opção escolhida, justificativa referenciando achados específicos, e nível de confiança classificado conforme references/confidence-rubric.md. Se a confiança for Médio ou Baixo, registre explicitamente o que aumentaria a confiança.
7. Em ## 9. Perguntas Abertas, liste hipóteses não validadas e indique como cada uma poderia ser respondida.
8. Em ## 10. Próximos Passos, use a tabela | Ação | Tipo | Prioridade | Descrição | (Tipo é Task, Spike ou Decisão; Prioridade é Alta, Média ou Baixa).
9. Em ## 11. Fora de Escopo, declare explicitamente o que não foi investigado e por quê.
10. Cite em ## 12. Referências os arquivos do repositório, commits, branches, RFCs ou links de documentação consultados.

Passo 5: Criar Diretório e Salvar (Obrigatório)

1. Derive o slug em kebab-case a partir do tema do spike (ex.: "Adoção de gRPC para integração interna" → adocao-grpc-integracao).
2. Crie o diretório ./docs/tasks/spike-[slug]/ via Bash se ainda não existir.
3. Salve o documento em ./docs/tasks/spike-[slug]/spike.md via Write.

Passo 6: Validar com o Checklist de Qualidade (Obrigatório)

1. Leia references/quality-checklist.md.
2. Verifique cada item obrigatório contra o documento gerado.
3. Se algum item obrigatório falhar, retorne ao Passo correspondente e corrija antes de reportar.

Passo 7: Reportar Resultados

1. Informe o caminho completo do arquivo gerado.
2. Forneça um resumo bem breve com: recomendação principal, nível de confiança e próximos passos imediatos.
3. Não anexe o conteúdo do documento na resposta — apenas o resumo e o caminho.

Helpers Bundled

• assets/spike-template.md — read-only. Estrutura canônica do documento final. Replicar sem alterar a ordem das seções.
• references/clarification-checklist.md — read-only. Base para as perguntas obrigatórias do Passo 1.
• references/confidence-rubric.md — read-only. Critério para classificar o nível de confiança da recomendação no Passo 4.
• references/quality-checklist.md — read-only. Auditoria final no Passo 6.

Tratamento de Erros

• Usuário não respondeu às perguntas de clarificação: repita o Passo 1 com perguntas mais específicas; não suponha respostas.
• Sem evidência factual para uma alternativa: rebaixe a alternativa para "hipótese" na seção de perguntas em aberto e indique o experimento necessário para validá-la.
• Confiança final BAIXA: registre explicitamente o que aumentaria a confiança (POC, benchmark, consulta a especialista, mais dados de produção).
• Diretório ./docs/tasks/ inexistente: crie-o como parte do Passo 5; não trate como erro.
• Conflito com spike anterior de mesmo slug: confirme com o usuário se deve sobrescrever ou usar sufixo numérico (-v2).