context-first-cli 2.3.2 → 2.3.5

package/dist/templates/commands/pt-BR/commands/products/check.md

@@ -1,237 +0,0 @@
-# Validação contra Metaspecs
-
-Este comando valida requisitos, decisões ou implementações contra as metaspecs do projeto.
-
-## ⚠️ IMPORTANTE: Modo de Operação
-
-**Este comando é para VALIDAÇÃO:**
-- ✅ Validar contra metaspecs
-- ✅ **LER** arquivos dos repositórios (read-only)
-- ✅ Gerar relatório de validação
-- ❌ **NÃO fazer checkout de branches nos repositórios principais**
-- ❌ **NÃO modificar código**
-- ❌ **NÃO modificar `context.md` ou `architecture.md`**
-
-## Configuração
-
-Leia `context-manifest.json` e `ai.properties.md` do orchestrator para obter repositórios, base_path e task_management_system.
-
-## Objetivo
-
-Garantir alinhamento com:
-- Estratégia de produto
-- Arquitetura técnica
-- Padrões e convenções
-- ADRs (Architecture Decision Records)
-
-## 📋 Quando Usar
-
-Execute este comando:
-- Após `/spec` - validar PRD
-- Após `/plan` - validar plano técnico
-- Durante `/work` - validar decisões de implementação
-- Antes de `/pr` - validação final
-
-## 📚 Carregar MetaSpecs
-
-**Localizar MetaSpecs automaticamente**:
-1. Leia `context-manifest.json` do orchestrator
-2. Encontre o repositório com `"role": "metaspecs"`
-3. Leia `ai.properties.md` para obter o `base_path`
-4. O metaspecs está em: `{base_path}/{metaspecs-repo-id}/`
-
-## 🔍 Processo de Validação
-
-### 1. Identificar Metaspecs Disponíveis
-
-Navegue até o diretório de metaspecs e identifique quais metaspecs existem:
-
-```bash
-ls -la {base_path}/{metaspecs-repo-id}/
-```
-
-### 2. Validação de Negócio
-
-Se existirem metaspecs de negócio (`repositório de MetaSpecs (seção de negócio)`):
-
-```markdown
-## Validação de Negócio
-
-### Estratégia de Produto
-- **Arquivo**: `repositório de MetaSpecs (seção de negócio)PRODUCT_STRATEGY.md`
-- **Validação**: [Esta feature está alinhada com a estratégia?]
-- **Status**: ✅ Alinhado / ⚠️ Parcialmente / ❌ Desalinhado
-- **Notas**: [Observações]
-
-### Personas
-- **Arquivo**: `repositório de MetaSpecs (seção de negócio)CUSTOMER_PERSONAS.md`
-- **Validação**: [Atende a persona correta?]
-- **Status**: ✅ Alinhado / ⚠️ Parcialmente / ❌ Desalinhado
-- **Notas**: [Observações]
-
-### Métricas
-- **Arquivo**: `repositório de MetaSpecs (seção de negócio)PRODUCT_METRICS.md`
-- **Validação**: [Métrica de sucesso está documentada?]
-- **Status**: ✅ Alinhado / ⚠️ Parcialmente / ❌ Desalinhado
-- **Notas**: [Observações]
-```
-
-### 3. Validação Técnica
-
-Se existirem metaspecs técnicas (`repositório de MetaSpecs (seção técnica)`):
-
-```markdown
-## Validação Técnica
-
-### Stack Tecnológica
-- **Arquivo**: `repositório de MetaSpecs (seção técnica)meta/stack.md`
-- **Validação**: [Usa apenas tecnologias aprovadas?]
-- **Status**: ✅ Conforme / ⚠️ Exceção justificada / ❌ Não conforme
-- **Notas**: [Tecnologias usadas e justificativas]
-
-### Arquitetura
-- **Arquivo**: `repositório de MetaSpecs (seção técnica)ARCHITECTURE.md`
-- **Validação**: [Segue padrões arquiteturais?]
-- **Status**: ✅ Conforme / ⚠️ Parcialmente / ❌ Não conforme
-- **Notas**: [Observações]
-
-### ADRs (Architecture Decision Records)
-- **Diretório**: `repositório de MetaSpecs (seção técnica)adr/`
-- **Validação**: [Respeita decisões arquiteturais documentadas?]
-- **ADRs Relevantes**: [Lista de ADRs verificados]
-- **Status**: ✅ Conforme / ⚠️ Conflito menor / ❌ Conflito crítico
-- **Notas**: [Observações]
-
-### Regras de Negócio
-- **Arquivo**: `repositório de MetaSpecs (seção técnica)BUSINESS_LOGIC.md`
-- **Validação**: [Implementa regras de negócio corretamente?]
-- **Status**: ✅ Conforme / ⚠️ Parcialmente / ❌ Não conforme
-- **Notas**: [Observações]
-```
-
-### 4. Validação de Padrões
-
-```markdown
-## Validação de Padrões
-
-### Código
-- **Arquivo**: `repositório de MetaSpecs (seção técnica)CODE_STANDARDS.md`
-- **Validação**: [Segue padrões de código?]
-- **Status**: ✅ Conforme / ⚠️ Pequenos desvios / ❌ Não conforme
-
-### Testes
-- **Arquivo**: `repositório de MetaSpecs (seção técnica)TEST_STANDARDS.md`
-- **Validação**: [Estratégia de testes adequada?]
-- **Status**: ✅ Conforme / ⚠️ Parcialmente / ❌ Não conforme
-
-### Documentação
-- **Arquivo**: `repositório de MetaSpecs (seção técnica)DOC_STANDARDS.md`
-- **Validação**: [Documentação adequada?]
-- **Status**: ✅ Conforme / ⚠️ Parcialmente / ❌ Não conforme
-```
-
-### 5. Identificação de Conflitos
-
-Se houver conflitos ou desalinhamentos:
-
-```markdown
-## Conflitos Identificados
-
-### Conflito 1: [Descrição]
-- **Severidade**: Crítico / Alto / Médio / Baixo
-- **Metaspec**: [Arquivo que está sendo violado]
-- **Descrição**: [Detalhe do conflito]
-- **Recomendação**: [Como resolver]
-
-### Conflito 2: [Descrição]
-[Mesmo formato acima]
-```
-
-### 6. Exceções Justificadas
-
-Se houver desvios justificados:
-
-```markdown
-## Exceções Justificadas
-
-### Exceção 1: [Descrição]
-- **Metaspec**: [Arquivo que está sendo desviado]
-- **Desvio**: [O que está diferente]
-- **Justificativa**: [Por que é necessário]
-- **Aprovação**: [Quem aprovou]
-- **Documentação**: [Onde foi documentado]
-```
-
-## 📄 Salvamento do Relatório de Validação
-
-**PRIORIDADE 1: Usar MCP (Model Context Protocol)**
-
-- Leia `ai.properties.md` do orchestrator para identificar o `task_management_system`
-- Use o MCP apropriado para adicionar o relatório à issue:
-  - Adicione como comentário na issue
-  - Atualize labels/tags conforme resultado (ex: "validated", "needs-adjustment", "blocked")
-  - Se houver conflitos críticos, atualize status da issue
-- Informe ao usuário: "✅ Relatório de validação adicionado à issue [ID]"
-
-**FALLBACK: Criar arquivo .md apenas se MCP falhar**
-
-Se o MCP não estiver disponível ou falhar, crie `./.sessions/<ISSUE-ID>/check-report.md`:
-
-```markdown
-# Relatório de Validação - [ISSUE-ID]
-
-**Data**: [data/hora]
-**Fase**: [spec/plan/work/pre-pr]
-
-## Status Geral
-✅ Validado / ⚠️ Validado com ressalvas / ❌ Não validado
-
-## Validações Realizadas
-- Negócio: ✅ / ⚠️ / ❌
-- Técnica: ✅ / ⚠️ / ❌
-- Padrões: ✅ / ⚠️ / ❌
-
-## Conflitos
-[Lista de conflitos, se houver]
-
-## Exceções
-[Lista de exceções justificadas, se houver]
-
-## Recomendações
-1. [Recomendação 1]
-2. [Recomendação 2]
-
-## Aprovação
-- [ ] Aprovado para prosseguir
-- [ ] Requer ajustes
-- [ ] Bloqueado
-```
-
-Informe ao usuário: "⚠️ Relatório salvo localmente em .sessions/ (task manager não disponível)"
-
-## 🚨 Ação em Caso de Conflitos
-
-Se conflitos críticos forem encontrados:
-1. 🛑 **PARE** o processo atual
-2. 📝 **DOCUMENTE** todos os conflitos
-3. 💬 **ALERTE** o usuário e stakeholders
-4. **Via MCP**: Atualize status da issue para "Bloqueado" ou "Requer Ajustes"
-5. 🔄 **AJUSTE** o plano/implementação conforme necessário
-6. ✅ **REVALIDE** após ajustes
-
----
-
-**Argumentos fornecidos**:
-
-```
-#$ARGUMENTS
-```
-
----
-
-## 🎯 Resultado
-
-Após validação:
-- Se ✅: Prossiga para próxima fase
-- Se ⚠️: Documente ressalvas e prossiga com aprovação
-- Se ❌: Corrija conflitos antes de prosseguir

package/dist/templates/commands/pt-BR/commands/products/collect.md

@@ -1,170 +0,0 @@
-# Coleta de Ideias e Requisitos
-
-Você é um especialista em produto responsável por coletar e documentar novas ideias, features ou bugs.
-
-## ⚠️ IMPORTANTE: Este Comando NÃO Implementa Código
-
-**Este comando é APENAS para planejamento e documentação:**
-- ✅ Coletar e entender requisitos
-- ✅ Criar issue no task manager via MCP
-- ✅ Fazer perguntas de esclarecimento
-- ✅ **LER** arquivos dos repositórios principais (read-only)
-- ❌ **NÃO implementar código**
-- ❌ **NÃO fazer edits em arquivos de código**
-- ❌ **NÃO fazer checkout de branches nos repositórios principais**
-- ❌ **NÃO fazer commits**
-
-**Próximo passo**: `/refine [ISSUE-ID]` para refinar os requisitos coletados.
-
----
-
-## Configuração
-
-Leia `context-manifest.json` e `ai.properties.md` do orchestrator para obter repositórios, base_path e task_management_system.
-
-## Objetivo
-
-Entender a solicitação do usuário e capturá-la como issue no task manager (via MCP).
-
-**Nesta fase, você NÃO precisa:**
-- ❌ Escrever especificação completa
-- ❌ Validar contra metaspecs (isso é feito no `/refine` ou `/spec`)
-- ❌ Detalhar implementação técnica
-
-Apenas certifique-se de que a ideia esteja **adequadamente compreendida**.
-
-## Formato da Issue
-
-```markdown
-# [Título Claro e Descritivo]
-
-## Descrição
-[2-3 parágrafos explicando o que é a feature/bug e por que é importante]
-
-## Tipo
-- [ ] Nova Feature
-- [ ] Melhoria de Feature Existente
-- [ ] Bug
-- [ ] Tech Debt
-- [ ] Documentação
-
-## Contexto Adicional
-[Informações relevantes: onde o bug ocorre, inspiração para a feature, etc.]
-
-## Repositórios Afetados
-[Liste quais repositórios do projeto serão impactados]
-
-## Prioridade Sugerida
-- [ ] 🔴 Crítica
-- [ ] 🟡 Alta
-- [ ] 🟢 Média
-- [ ] ⚪ Baixa (Backlog)
-```
-
-## Processo de Coleta
-
-1. **Entendimento Inicial**
-   - Faça perguntas de esclarecimento se necessário
-   - Identifique: É feature nova? Melhoria? Bug?
-   - Identifique quais repositórios serão afetados
-
-2. **Rascunho da Issue**
-   - Título claro (máximo 10 palavras)
-   - Descrição objetiva (2-3 parágrafos)
-   - Contexto adicional relevante
-   - Repositórios afetados
-   - Prioridade sugerida
-
-3. **Avaliação de Complexidade e Sugestão de Quebra**
-   
-   Antes de finalizar, avalie a complexidade da issue:
-   
-   **Se a implementação parecer grande** (> 5 dias de esforço estimado):
-   - 🚨 **Sugira quebrar em múltiplas issues menores**
-   - Explique o racional da quebra (ex: "Esta feature envolve 3 áreas distintas: autenticação, processamento e notificação")
-   - Proponha uma quebra **lógica** (por funcionalidade, por repositório, por camada, etc.)
-   - Exemplo de quebra:
-     ```
-     Issue Original: "Sistema de pagamentos completo"
-     
-     Quebra Sugerida:
-     - FIN-101: Integração com gateway de pagamento (backend)
-     - FIN-102: Interface de checkout (frontend)
-     - FIN-103: Webhook de confirmação e notificações (backend + jobs)
-     ```
-   - **Importante**: A decisão final é do usuário - ele pode aceitar a quebra ou manter como issue única
-   
-   **Se o usuário aceitar a quebra**:
-   - Crie cada issue separadamente usando o mesmo processo
-   - Adicione referências cruzadas entre as issues relacionadas
-   - Sugira ordem de implementação se houver dependências
-
-4. **Aprovação do Usuário**
-   - Apresente o rascunho (ou rascunhos, se houver quebra)
-   - Faça ajustes conforme feedback
-   - Obtenha aprovação final
-
-5. **Salvamento da Issue**
-
-   **PRIORIDADE 1: Usar MCP (Model Context Protocol)**
-   
-   Verifique se há MCP configurado para task manager:
-   - Leia `ai.properties.md` do orchestrator para identificar o `task_management_system`
-   - Se `task_management_system=jira`: Use MCP do Jira para criar a issue
-   - Se `task_management_system=linear`: Use MCP do Linear para criar a issue
-   - Se `task_management_system=github`: Use MCP do GitHub para criar a issue
-   - Se `task_management_system=azure`: Use MCP do Azure Boards para criar a issue
-   
-   **Ao usar MCP:**
-   - Crie a issue diretamente no task manager
-   - Obtenha o ID da issue criada (ex: FIN-123, LIN-456)
-   - Informe ao usuário: "✅ Issue [ID] criada no [task manager]"
-   - **NÃO crie arquivo .md**
-   
-   **FALLBACK: Criar arquivo .md apenas se MCP falhar**
-   
-   Se o MCP não estiver disponível ou falhar:
-   - Crie arquivo em `./.sessions/<ISSUE-ID>/collect.md`
-   - Use formato de ID manual: `LOCAL-001`, `LOCAL-002`, etc.
-   - Inclua data, tipo e conteúdo completo
-   - Informe ao usuário: "⚠️ Issue salva localmente em .sessions/ (task manager não disponível)"
-
-## Perguntas de Esclarecimento
-
-**Para Features**:
-- Que problema resolve?
-- Quem se beneficia?
-- É funcionalidade visível ou infraestrutura?
-- Tem relação com alguma feature existente?
-- Quais repositórios precisam ser modificados?
-
-**Para Bugs**:
-- Onde o bug ocorre? (repositório, componente, fluxo)
-- Como reproduzir?
-- Qual comportamento esperado vs atual?
-- Severidade do impacto?
-
-**Para Melhorias**:
-- O que está funcionando mas pode melhorar?
-- Qual métrica queremos impactar?
-- É otimização técnica ou de negócio?
-
----
-
-**Argumentos fornecidos**:
-
-```
-#$ARGUMENTS
-```
-
----
-
-## 🎯 Próximo Passo
-
-Após aprovação e salvamento da issue:
-
-```bash
-/refine [ISSUE-ID]
-```
-
-Este comando irá transformar a issue coletada em requisitos refinados e validados.

package/dist/templates/commands/pt-BR/commands/products/refine.md

@@ -1,231 +0,0 @@
-# Refinamento de Requisitos
-
-Você é um especialista em produto encarregado de ajudar a refinar requisitos para o projeto.
-
-## ⚠️ IMPORTANTE: Este Comando NÃO Implementa Código
-
-**Este comando é APENAS para planejamento e documentação:**
-- ✅ Validar requisitos contra metaspecs
-- ✅ Criar especificação refinada
-- ✅ Salvar documentação em `.sessions/`
-- ✅ Atualizar issue no task manager
-- ❌ **NÃO implementar código**
-- ❌ **NÃO fazer edits em arquivos de código**
-- ❌ **NÃO executar testes ou deploy**
-
-**Próximo passo**: `/spec [ISSUE-ID]` para criar PRD completo baseado nos requisitos refinados.
-
----
-
-## Configuração
-
-Leia `context-manifest.json` e `ai.properties.md` do orchestrator para obter repositórios, base_path e task_management_system.
-
-## Objetivo
-
-Transformar um requisito inicial em especificação refinada e validada, pronta para se tornar PRD completo.
-
-## Processo
-
-### 1. Fase de Esclarecimento
-
-Leia o requisito inicial e faça perguntas para alcançar clareza total sobre:
-- **Objetivo**: Por que construir isso?
-- **Valor de Negócio**: Qual métrica/persona impacta?
-- **Escopo**: O que inclui e o que NÃO inclui?
-- **Interações**: Quais features/componentes existentes são afetados?
-
-Continue fazendo perguntas até ter entendimento completo.
-
-### 2. Validação Contra Metaspecs
-
-**IMPORTANTE**: Primeiro leia `ai.properties.md` para obter o `base_path`. Os índices JÁ devem estar em contexto (você rodou `/warm-up`). Consulte os índices e leia APENAS os documentos relevantes para validar o requisito.
-
-**Processo de Validação**:
-
-1. **Consulte os índices carregados** pelo `/warm-up`:
-   - Leia `context-manifest.json` para encontrar o repositório com `role: "metaspecs"`
-   - Obtenha o `id` desse repositório (ex: "my-project-metaspecs")
-   - Leia `ai.properties.md` para obter o `base_path`
-   - O repositório de metaspecs está em: `{base_path}/{metaspecs-id}/`
-   - Consulte `{base_path}/{metaspecs-id}/index.md` - Visão geral do projeto
-   - Consulte índices específicos (ex: `specs/business/index.md`, `specs/technical/index.md`)
-
-2. **Identifique documentos relevantes** para este requisito específico:
-   - Em `specs/business/`: Quais documentos de negócio são relevantes?
-   - Em `specs/technical/`: Quais documentos técnicos são relevantes?
-
-3. **Leia APENAS os documentos relevantes** identificados (não leia tudo!)
-
-4. **Valide o requisito** contra as metaspecs lidas:
-   - ✅ Alinhamento com estratégia e visão de produto
-   - ✅ Atende necessidades das personas corretas
-   - ✅ Compatível com stack tecnológica aprovada
-   - ✅ Respeita decisões arquiteturais (ADRs)
-   - ✅ Segue regras de negócio existentes
-   - ⚠️ Identifique conflitos ou violações
-
-**Se identificar violações**: 🛑 **PARE** e peça esclarecimento ao usuário antes de prosseguir (Princípio Jidoka).
-
-### 3. Fase de Resumo e Aprovação
-
-Uma vez que tenha coletado informações suficientes e validado contra metaspecs, apresente um resumo estruturado com:
-- **Feature**: Nome da funcionalidade
-- **Objetivo**: Por que construir (1-2 frases)
-- **Valor de Negócio**: Métrica, persona, fase do roadmap (consulte metaspecs)
-- **Escopo**: O que INCLUI e o que NÃO INCLUI
-- **Componentes Afetados**: Lista baseada na arquitetura atual (consulte metaspecs técnicas)
-- **Validação contra Metaspecs**: ✅ Aprovado / ⚠️ Atenção necessária
-- **Estimativa de Esforço**: Pequeno (< 1 dia) / Médio (1-3 dias) / Grande (3-5 dias) / Muito Grande (> 5 dias)
-
-**Avaliação de Complexidade e Sugestão de Quebra**:
-
-**Se a implementação parecer grande** (> 5 dias de esforço estimado):
-- 🚨 **Sugira quebrar em múltiplas issues menores**
-- Explique o racional da quebra (ex: "Esta feature envolve 3 áreas distintas que podem ser implementadas independentemente")
-- Proponha uma quebra **lógica** baseada em:
-  - Funcionalidades independentes
-  - Repositórios diferentes
-  - Camadas da aplicação (backend, frontend, infra)
-  - Fases de implementação (MVP, melhorias, otimizações)
-- Exemplo de quebra:
-  ```
-  Issue Original: "Sistema de notificações multi-canal"
-  
-  Quebra Sugerida:
-  - FIN-201: Infraestrutura de filas e workers (backend)
-  - FIN-202: Notificações por email (backend + templates)
-  - FIN-203: Notificações push (backend + mobile)
-  - FIN-204: Preferências de notificação (frontend + backend)
-  ```
-- **Importante**: A decisão final é do usuário - ele pode aceitar a quebra ou manter como issue única
-
-**Se o usuário aceitar a quebra**:
-- Documente cada issue separadamente
-- Adicione referências cruzadas entre as issues relacionadas
-- Sugira ordem de implementação se houver dependências
-- Cada issue quebrada deve passar pelo mesmo processo de refinamento
-
-Peça aprovação do usuário e incorpore feedback se necessário.
-
-**Dica**: Você pode pesquisar no código-base ou internet antes de finalizar, se necessário.
-
-### 4. Salvamento dos Requisitos Refinados
-
-Uma vez que o usuário aprove, salve os requisitos:
-
-**IMPORTANTE**: Sempre crie backup local E atualize o task manager (se configurado).
-
-**Processo de Salvamento**:
-
-1. **SEMPRE criar backup local primeiro**:
-   - Crie arquivo completo em `./.sessions/<ISSUE-ID>/refined.md` (ex: `./.sessions/FIN-5/refined.md`)
-   - Onde `<ISSUE-ID>` é o ID da issue (ex: FIN-5, FIN-123)
-   - Inclua TODOS os detalhes do refinamento (backup completo)
-
-2. **Se task manager estiver configurado** (leia `ai.properties.md` para identificar `task_management_system`):
-   - Identifique a ferramenta MCP do task manager
-   - **Atualize o BODY (description) da issue** com versão CONCISA dos requisitos refinados
-     - Para Jira: Use MCP do Jira com campo `description`
-     - Para Linear: Use MCP do Linear com campo `description`
-     - Para GitHub: Use MCP do GitHub com campo `body`
-     - Para Azure Boards: Use MCP do Azure Boards com campo `description`
-     - Inclua todo o conteúdo refinado no campo description/body da issue
-     - Se o conteúdo for muito extenso e houver erro de API, considere criar versão resumida
-   - **SEMPRE sobrescrever** o body existente (não adicionar ao final)
-
-**Observação**:
-- O backup local SEMPRE está salvo e completo
-- Se houver erro de API, verifique manualmente se a issue foi atualizada no task manager
-
-**Template de Saída**:
-
-**IMPORTANTE**: O template padrão para requisitos refinados pode estar documentado no repositório de metaspecs. Consulte `{base_path}/{metaspecs-id}/specs/refined/` ou similar.
-
-**Template COMPLETO** (para backup local `.sessions/<ISSUE-ID>/refined.md`):
-- **Metadados**: Issue, ID, Task Manager, Projeto, Data, Sprint, Prioridade
-- **🎯 POR QUE**: Razões, valor de negócio, métrica, persona, alinhamento estratégico
-- **📦 O QUE**: Funcionalidades detalhadas, componentes afetados, integrações, escopo negativo completo
-- **🔧 COMO**: Stack, padrões de código, estrutura de arquivos, dependências, ordem de implementação, failure modes, considerações de performance/custo/UX
-- **✅ Validação contra Metaspecs**: Documentos consultados (business e technical), ADRs verificados, resultado da validação
-- **📊 Métricas de Sucesso**: Técnicas, produto/UX, critérios de aceitação
-- **🔄 Impacto no Produto**: Alinhamento com objetivos, habilitadores, riscos mitigados
-- **⚠️ Limitações Conhecidas**: Limitações do MVP
-- **📝 Checklist de Implementação**: Tarefas por área (backend, frontend, testes, segurança, etc.)
-
-**Template para Task Manager**:
-```markdown
-# [Nome Feature] - Requisitos Refinados
-
-**Sprint X** | **Y dias** | **Prioridade**
-
-## Objetivo
-[1-2 parágrafos: o que é e por que fazer]
-
-## Escopo
-
-### Principais Funcionalidades
-- Funcionalidade 1: [resumo]
-- Funcionalidade 2: [resumo]
-- Validações/Guards: [resumo]
-
-### Componentes Afetados
-- Componente 1: [tipo de mudança]
-- Componente 2: [tipo de mudança]
-
-### Segurança
-✅ [item 1] ✅ [item 2] ✅ [item 3]
-
-## Escopo Negativo
-❌ [item 1] ❌ [item 2] ❌ [item 3]
-
-## Stack
-[Tech stack resumida por área]
-
-## Estrutura
-[Árvore de arquivos RESUMIDA - principais módulos apenas]
-
-## Failure Modes (Evitar)
-🔴 [crítico 1] 🔴 [crítico 2]
-🟡 [médio 1] 🟡 [médio 2]
-
-## Critérios de Aceitação
-- [ ] [item 1]
-- [ ] [item 2]
-- [ ] [item 3]
-
-## Validação
-**ADRs**: [lista]
-**Specs**: [principais]
-**Status**: ✅ Aprovado
-
-**Impacto**: [resumo]
-**Limitações**: [resumo]
-
----
-📄 **Documento completo**: `.sessions/<ISSUE-ID>/refined.md`
-```
-
-**Audiência**: Desenvolvedor IA com capacidades similares às suas. Seja conciso mas completo.
-
----
-
-**Requisito para Refinar**:
-
-```
-#$ARGUMENTS
-```
-
----
-
-## 🎯 Próximo Passo
-
-**Após aprovação do usuário e salvamento dos requisitos refinados**, o fluxo natural é:
-
-```bash
-/spec [ISSUE-ID]
-```
-
-**Exemplo**: `/spec FIN-3`
-
-Este comando irá criar um PRD (Product Requirements Document) completo baseado nos requisitos refinados, detalhando funcionalidades, user stories, critérios de aceitação e validações finais.