context-first-cli 2.3.0 → 2.3.2

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

@@ -0,0 +1,231 @@
+# 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.

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

@@ -0,0 +1,271 @@
+# Criação de Especificação (PRD)
+
+Este comando cria a especificação completa (Product Requirements Document) da feature.
+
+## ⚠️ IMPORTANTE: Este Comando NÃO Implementa Código
+
+**Este comando é APENAS para documentação de requisitos:**
+- ✅ Criar PRD (Product Requirements Document)
+- ✅ Atualizar issue no task manager via MCP
+- ✅ **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**: `/start` para iniciar o desenvolvimento.
+
+---
+
+## Configuração
+
+Leia `context-manifest.json` e `ai.properties.md` do orchestrator para obter repositórios, base_path e task_management_system.
+
+## Pré-requisitos
+
+- Issue refinada via `/refine`
+- Aprovação para prosseguir com a feature
+
+## 📚 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}/`
+5. Leia os arquivos `index.md` relevantes para garantir conformidade com:
+   - Arquitetura do sistema
+   - Padrões de design
+   - Restrições técnicas
+   - Convenções do projeto
+
+## 🎯 Objetivo
+
+Criar um PRD completo que servirá como fonte única de verdade para a implementação.
+
+## 📝 Estrutura do PRD
+
+### 1. Visão Geral
+
+```markdown
+# [Título da Feature]
+
+## Contexto
+[Por que estamos construindo isso? Qual problema resolve?]
+
+## Objetivo
+[O que queremos alcançar com esta feature?]
+
+## Métricas de Sucesso
+- [Métrica 1]: [Como medir]
+- [Métrica 2]: [Como medir]
+```
+
+### 2. Requisitos Funcionais
+
+```markdown
+## Requisitos Funcionais
+
+### RF-01: [Nome do Requisito]
+**Descrição**: [Descrição detalhada]
+**Prioridade**: Must Have / Should Have / Could Have
+**Repositórios**: [repos afetados]
+
+### RF-02: [Nome do Requisito]
+**Descrição**: [Descrição detalhada]
+**Prioridade**: Must Have / Should Have / Could Have
+**Repositórios**: [repos afetados]
+```
+
+### 3. Requisitos Não-Funcionais
+
+```markdown
+## Requisitos Não-Funcionais
+
+### Performance
+- [Requisito de performance]
+
+### Segurança
+- [Requisito de segurança]
+
+### Acessibilidade
+- [Requisito de acessibilidade]
+
+### Escalabilidade
+- [Requisito de escalabilidade]
+```
+
+### 4. Fluxos de Usuário
+
+```markdown
+## Fluxos de Usuário
+
+### Fluxo Principal
+1. [Passo 1]
+2. [Passo 2]
+3. [Passo 3]
+
+### Fluxos Alternativos
+**Cenário**: [Nome do cenário]
+1. [Passo 1]
+2. [Passo 2]
+
+### Tratamento de Erros
+**Erro**: [Tipo de erro]
+**Comportamento**: [Como o sistema deve reagir]
+```
+
+### 5. Especificação Técnica
+
+```markdown
+## Especificação Técnica
+
+### Arquitetura
+
+#### <repo-1>
+- **Componentes novos**: [lista]
+- **Componentes modificados**: [lista]
+- **APIs**: [endpoints novos/modificados]
+
+#### <repo-2>
+- **Componentes novos**: [lista]
+- **Componentes modificados**: [lista]
+- **APIs**: [endpoints novos/modificados]
+
+### Integrações
+- **Entre repos**: [como os repos se comunicam]
+- **Externas**: [APIs externas, se houver]
+
+### Modelo de Dados
+[Descreva mudanças no modelo de dados, se houver]
+```
+
+### 6. Critérios de Aceitação
+
+```markdown
+## Critérios de Aceitação
+
+### Funcional
+- [ ] [Critério específico e testável]
+- [ ] [Critério específico e testável]
+
+### Técnico
+- [ ] Testes unitários com cobertura >= X%
+- [ ] Testes de integração implementados
+- [ ] Performance dentro dos requisitos
+- [ ] Documentação atualizada
+
+### Qualidade
+- [ ] Code review aprovado
+- [ ] Sem regressões
+- [ ] Acessibilidade validada
+```
+
+### 7. Fora do Escopo
+
+```markdown
+## Fora do Escopo
+
+Funcionalidades que NÃO serão implementadas nesta versão:
+- [Item 1]
+- [Item 2]
+
+Justificativa: [Por que ficam para depois]
+```
+
+### 8. Riscos e Mitigações
+
+```markdown
+## Riscos e Mitigações
+
+### Risco 1: [Descrição]
+- **Probabilidade**: Alta / Média / Baixa
+- **Impacto**: Alto / Médio / Baixo
+- **Mitigação**: [Como mitigar]
+
+### Risco 2: [Descrição]
+- **Probabilidade**: Alta / Média / Baixa
+- **Impacto**: Alto / Médio / Baixo
+- **Mitigação**: [Como mitigar]
+```
+
+### 9. Dependências
+
+```markdown
+## Dependências
+
+### Técnicas
+- [Dependência técnica 1]
+- [Dependência técnica 2]
+
+### De Negócio
+- [Dependência de negócio 1]
+- [Dependência de negócio 2]
+
+### Bloqueadores
+- [Bloqueador 1 e plano para resolver]
+```
+
+### 10. Plano de Testes
+
+```markdown
+## Plano de Testes
+
+### Testes Unitários
+- [Área 1 a ser testada]
+- [Área 2 a ser testada]
+
+### Testes de Integração
+- [Cenário 1]
+- [Cenário 2]
+
+### Testes Manuais
+- [Cenário 1]
+- [Cenário 2]
+```
+
+## 📄 Salvamento do PRD
+
+**PRIORIDADE 1: Usar MCP (Model Context Protocol)**
+
+- Leia `ai.properties.md` do orchestrator para identificar o `task_management_system`
+- Use o MCP apropriado para atualizar a issue com o PRD:
+  - Adicione o PRD completo como comentário na issue
+  - Ou anexe como arquivo (se o task manager suportar)
+  - Atualize status/labels (ex: "spec-ready", "ready-for-dev")
+- Informe ao usuário: "✅ PRD adicionado à issue [ID]"
+
+**FALLBACK: Criar arquivo .md apenas se MCP falhar**
+
+Se o MCP não estiver disponível ou falhar:
+- Salve em `./.sessions/<ISSUE-ID>/prd.md`
+- Informe ao usuário: "⚠️ PRD salvo localmente em .sessions/ (task manager não disponível)"
+
+## 🔍 Revisão e Aprovação
+
+Antes de finalizar:
+1. Revise o PRD com stakeholders
+2. Valide contra metaspecs (se disponíveis)
+3. Obtenha aprovação para iniciar implementação
+4. **Via MCP**: Atualize a issue no task manager com status "Pronto para Desenvolvimento"
+5. **Fallback**: Documente aprovação em `./.sessions/<ISSUE-ID>/prd.md`
+
+---
+
+**Argumentos fornecidos**:
+
+```
+#$ARGUMENTS
+```
+
+---
+
+## 🎯 Próximo Passo
+
+Após aprovação do PRD:
+
+```bash
+/start
+```
+
+Este comando iniciará o desenvolvimento da feature.