context-first-cli 2.3.2 → 2.3.5

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

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

package/dist/templates/commands/pt-BR/commands/quality/metrics.md

@@ -1,266 +0,0 @@
-# Métricas de Qualidade
-
-Este comando coleta e analisa métricas de qualidade do código e do processo de desenvolvimento.
-
-## 🎯 Objetivo
-
-Medir e documentar a qualidade da implementação através de métricas objetivas:
-- Cobertura de testes
-- Complexidade do código
-- Dívida técnica
-- Performance
-- Conformidade com padrões
-
-## Configuração
-
-Leia `context-manifest.json` e `ai.properties.md` do orchestrator para obter repositórios, base_path e task_management_system.
-
-## 📋 Pré-requisitos
-
-- Implementação concluída (após `/work`)
-- Testes implementados
-- Build funcionando
-
-## 📊 Métricas a Coletar
-
-### 1. Cobertura de Testes
-
-Para cada repositório modificado:
-
-```bash
-cd <repositório>
-
-# Executar testes com cobertura (exemplos por stack):
-# Node.js: npm run test:coverage / jest --coverage
-# Python: pytest --cov=src tests/
-# Java: mvn jacoco:report / gradle jacocoTestReport
-# Go: go test -cover ./...
-# Ruby: rspec --coverage
-# Rust: cargo tarpaulin
-# PHP: ./vendor/bin/phpunit --coverage-html coverage/
-# C#: dotnet test /p:CollectCoverage=true
-
-# Capturar resultados
-```
-
-Documente:
-```markdown
-## Cobertura de Testes
-
-### <repo-1>
-- **Cobertura Total**: X%
-- **Statements**: X%
-- **Branches**: X%
-- **Functions**: X%
-- **Lines**: X%
-- **Arquivos não cobertos**: [lista]
-
-### <repo-2>
-[Mesmo formato]
-```
-
-### 2. Complexidade do Código
-
-Analise a complexidade ciclomática dos arquivos modificados:
-
-```markdown
-## Complexidade do Código
-
-### Arquivos com Alta Complexidade
-- **arquivo1.ts**: Complexidade 15 (recomendado: < 10)
-- **arquivo2.ts**: Complexidade 12
-
-### Recomendações
-- [Sugestão de refatoração 1]
-- [Sugestão de refatoração 2]
-```
-
-### 3. Qualidade do Código
-
-```bash
-# Executar linting (exemplos por stack):
-# Node.js: npm run lint / eslint .
-# Python: flake8 . / pylint src/
-# Java: mvn checkstyle:check
-# Go: golangci-lint run
-# Ruby: rubocop
-# Rust: cargo clippy
-
-# Verificar formatação (exemplos por stack):
-# Node.js: prettier --check .
-# Python: black --check .
-# Java: mvn formatter:validate
-# Go: gofmt -l .
-# Ruby: rubocop --format-only
-# Rust: cargo fmt --check
-
-# Análise estática (exemplos por stack):
-# Node.js: npm run analyze (se configurado)
-# Python: mypy src/ / bandit -r src/
-# Java: mvn pmd:check / spotbugs:check
-# Go: go vet ./...
-# Ruby: brakeman (para Rails)
-# Rust: cargo audit
-```
-
-Documente:
-```markdown
-## Qualidade do Código
-
-### Linting
-- **Erros**: 0
-- **Warnings**: X
-- **Warnings Justificados**: [lista com justificativas]
-
-### Formatação
-- **Status**: ✅ Conforme / ⚠️ Ajustes necessários
-
-### Análise Estática
-- **Problemas Críticos**: 0
-- **Problemas Médios**: X
-- **Problemas Baixos**: Y
-```
-
-### 4. Performance
-
-Se aplicável, meça performance:
-
-```markdown
-## Performance
-
-### Benchmarks
-- **Operação X**: Yms (baseline: Zms)
-- **Operação Y**: Yms (baseline: Zms)
-
-### Otimizações Aplicadas
-- [Otimização 1 e impacto]
-- [Otimização 2 e impacto]
-
-### Gargalos Identificados
-- [Gargalo 1 e plano de mitigação]
-```
-
-### 5. Tamanho e Impacto
-
-```markdown
-## Tamanho e Impacto
-
-### Linhas de Código
-- **Adicionadas**: +X linhas
-- **Removidas**: -Y linhas
-- **Modificadas**: Z linhas
-
-### Arquivos
-- **Novos**: X arquivos
-- **Modificados**: Y arquivos
-- **Removidos**: Z arquivos
-
-### Dependências
-- **Novas dependências**: [lista]
-- **Tamanho do bundle**: +X KB
-```
-
-### 6. Dívida Técnica
-
-Identifique dívida técnica introduzida ou resolvida:
-
-```markdown
-## Dívida Técnica
-
-### Dívida Introduzida
-- **Item 1**: [Descrição e justificativa]
-  - Severidade: Alta / Média / Baixa
-  - Plano de resolução: [quando e como resolver]
-
-### Dívida Resolvida
-- **Item 1**: [O que foi resolvido]
-  - Impacto: [melhoria obtida]
-```
-
-## 📄 Relatório de Métricas
-
-Crie `./.sessions/<ISSUE-ID>/metrics.md`:
-
-```markdown
-# Relatório de Métricas - [ISSUE-ID]
-
-**Data**: [data/hora]
-**Repositórios**: [lista]
-
-## Resumo Executivo
-
-- **Cobertura de Testes**: X% (meta: Y%)
-- **Qualidade do Código**: ✅ / ⚠️ / ❌
-- **Performance**: ✅ / ⚠️ / ❌
-- **Dívida Técnica**: Baixa / Média / Alta
-
-## Métricas Detalhadas
-
-[Incluir todas as seções acima]
-
-## Comparação com Baseline
-
-| Métrica | Antes | Depois | Variação |
-|---------|-------|--------|----------|
-| Cobertura | X% | Y% | +Z% |
-| Complexidade Média | X | Y | +Z |
-| Bundle Size | X KB | Y KB | +Z KB |
-
-## Ações Recomendadas
-
-1. [Ação 1 - prioridade alta]
-2. [Ação 2 - prioridade média]
-3. [Ação 3 - prioridade baixa]
-
-## Aprovação para Merge
-
-- [ ] Cobertura de testes >= meta
-- [ ] Sem problemas críticos de qualidade
-- [ ] Performance dentro dos requisitos
-- [ ] Dívida técnica documentada e aprovada
-```
-
-## 🎯 Metas de Qualidade
-
-Se o projeto tiver metas definidas nas metaspecs, valide:
-
-```markdown
-## Validação contra Metas
-
-### Metas do Projeto
-- **Cobertura mínima**: 80%
-- **Complexidade máxima**: 10
-- **Performance**: < 100ms
-
-### Status
-- Cobertura: ✅ 85% (meta: 80%)
-- Complexidade: ⚠️ 12 (meta: 10) - Justificado
-- Performance: ✅ 85ms (meta: 100ms)
-```
-
-## 🚨 Alertas
-
-Se alguma métrica estiver fora do aceitável:
-1. 🛑 **DOCUMENTE** o problema
-2. 💬 **ALERTE** o usuário
-3. 🔧 **PROPONHA** ações corretivas
-4. ⏸️ **CONSIDERE** bloquear o merge até resolução
-
----
-
-**Argumentos fornecidos**:
-
-```
-#$ARGUMENTS
-```
-
----
-
-## 🎯 Resultado
-
-Após executar este comando, você terá:
-- Relatório completo de métricas
-- Comparação com baseline e metas
-- Identificação de problemas de qualidade
-- Recomendações de ações
-- Base objetiva para aprovação de merge

package/dist/templates/commands/pt-BR/commands/quality/observe.md

@@ -1,172 +0,0 @@
-# Observabilidade de Decisões
-
-Este comando registra decisões importantes tomadas durante o desenvolvimento, criando um log auditável para explicabilidade e rastreabilidade.
-
-## 🎯 Objetivo
-
-Criar registro estruturado de decisões técnicas e de produto, garantindo:
-- **Explicabilidade**: Por que cada decisão foi tomada
-- **Rastreabilidade**: Quais fontes (PRD, metaspecs, ADRs) embasaram a decisão
-- **Auditoria**: Histórico completo de escolhas para revisão futura
-- **Aprendizado**: Documentação de trade-offs e alternativas consideradas
-
-**IMPORTANTE**: Este comando NÃO gera decisões novas. Ele apenas REGISTRA decisões que já foram tomadas no processo de 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
-
-- Executou pelo menos um dos comandos que geram decisões:
-  - `/spec` - gera PRD com decisões de produto
-  - `/plan` - gera plan.md com decisões técnicas
-  - `/work` - implementação gera decisões durante desenvolvimento
-
-## 🔍 Processo de Observação
-
-### 1. Identificar Decisões Relevantes
-
-Analise os arquivos da sessão (`./.sessions/<ISSUE-ID>/`) para identificar decisões:
-
-**Após `/spec`** - Decisões de Produto:
-- Leia `./.sessions/<ISSUE-ID>/prd.md`
-- Identifique decisões em:
-  - Escopo (o que entra/não entra na feature)
-  - Personas atendidas (quem é o público-alvo)
-  - Métricas de sucesso (como medir resultados)
-  - Requisitos não-funcionais (performance, acessibilidade)
-  - Restrições e trade-offs
-
-**Após `/plan`** - Decisões Técnicas:
-- Leia `./.sessions/<ISSUE-ID>/plan.md`
-- Identifique decisões em:
-  - Arquitetura de componentes/módulos
-  - Escolha de bibliotecas ou ferramentas
-  - Padrões de implementação
-  - Estrutura de dados
-  - Estratégia de testes
-
-**Durante `/work`** - Decisões de Implementação:
-- Leia `./.sessions/<ISSUE-ID>/work.md`
-- Identifique decisões em:
-  - Refatorações realizadas
-  - Mudanças de abordagem
-  - Otimizações aplicadas
-  - Tratamento de edge cases
-
-### 2. Documentar Cada Decisão
-
-Para cada decisão identificada, documente:
-
-```markdown
-## Decisão: [Título Claro]
-
-**Contexto**: [Por que precisamos decidir isso? Qual o problema ou necessidade?]
-
-**Opções Consideradas**:
-1. **Opção A**: [Descrição]
-   - Prós: [vantagens]
-   - Contras: [desvantagens]
-2. **Opção B**: [Descrição]
-   - Prós: [vantagens]
-   - Contras: [desvantagens]
-
-**Decisão**: [Opção escolhida]
-
-**Justificativa**: [Por que escolhemos esta opção? Quais critérios foram mais importantes?]
-
-**Fontes**:
-- [PRD seção X]
-- [Metaspec Y]
-- [ADR-00Z]
-
-**Trade-offs Aceitos**: [Quais desvantagens aceitamos conscientemente?]
-
-**Reversibilidade**: Fácil / Média / Difícil
-
-**Data**: [data da decisão]
-```
-
-### 3. Criar Log de Decisões
-
-Salve em `./.sessions/<ISSUE-ID>/decisions.md`:
-
-```markdown
-# Log de Decisões - [ISSUE-ID]
-
-## Resumo
-[Breve resumo das principais decisões tomadas nesta feature]
-
-## Decisões de Produto
-
-### [Decisão 1]
-[Conforme template acima]
-
-### [Decisão 2]
-[Conforme template acima]
-
-## Decisões Técnicas
-
-### [Decisão 3]
-[Conforme template acima]
-
-### [Decisão 4]
-[Conforme template acima]
-
-## Decisões de Implementação
-
-### [Decisão 5]
-[Conforme template acima]
-
-## Lições Aprendidas
-- [Lição 1]
-- [Lição 2]
-
-## Decisões Pendentes
-- [Decisão que ainda precisa ser tomada]
-```
-
-## 📊 Análise de Impacto
-
-Para decisões críticas, documente o impacto:
-
-```markdown
-## Análise de Impacto
-
-**Repositórios Afetados**: [lista]
-
-**Componentes Impactados**: [lista]
-
-**Dependências Criadas**: [lista]
-
-**Riscos Introduzidos**: [lista]
-
-**Mitigações Aplicadas**: [lista]
-```
-
-## 🔄 Revisão de Decisões
-
-Periodicamente, revise as decisões tomadas:
-- Ainda fazem sentido?
-- Os trade-offs se provaram corretos?
-- Há aprendizados para documentar?
-- Alguma decisão precisa ser revertida?
-
----
-
-**Argumentos fornecidos**:
-
-```
-#$ARGUMENTS
-```
-
----
-
-## 🎯 Resultado
-
-Após executar este comando, você terá:
-- Log completo de decisões em `./.sessions/<ISSUE-ID>/decisions.md`
-- Rastreabilidade de cada escolha feita
-- Documentação para futuras referências
-- Base para ADRs (se decisões forem de arquitetura)