mcp-memory-taskmanager

# Project Rules - Regras Específicas de Projetos ## 🎯 Diretrizes para Gerenciamento de Projetos Este arquivo define as regras e padrões específicos para o gerenciamento de projetos usando o sistema MCP Memory com Task Manager. ## 📋 Estrutura de Projetos ### Tipos de Projeto Suportados ```yaml tipos_projeto: - DEVELOPMENT: "Desenvolvimento de software" - RESEARCH: "Pesquisa e análise" - PLANNING: "Planejamento e arquitetura" - TESTING: "Testes e validação" - DOCUMENTATION: "Documentação técnica" - DEPLOYMENT: "Deploy e infraestrutura" - MAINTENANCE: "Manutenção e otimização" - LEARNING: "Aprendizado e capacitação" ``` ### Fases Obrigatórias Todo projeto deve incluir as seguintes fases: 1. **Análise e Planejamento** - Definição de requisitos e arquitetura 2. **Decomposição** - Quebra em tarefas executáveis 3. **Execução** - Implementação das tarefas 4. **Validação** - Testes e verificação de qualidade 5. **Documentação** - Documentação técnica e de usuário 6. **Deploy** - Implantação e configuração 7. **Retrospectiva** - Análise de resultados e aprendizados ## 🏗️ Padrões de Arquitetura ### 🧩 Integração com Sistema de Memória MCP ```yaml memory_integration: domain_specific_storage: true pattern_learning: "continuous" cross_project_knowledge: true knowledge_graph_enabled: true microinteractions: "automatic" specialization_domains: - "frontend" - "backend" - "devops" - "mobile" - "database" - "security" - "testing" - "architecture" ``` ### 🧠 Metodologia de Pensamento Sequencial ```yaml planning_methodology: use_sequential_thinking: true structured_reasoning: "mandatory" reflection_enabled: true decomposition_strategy: "domain_based" validation_checkpoints: true learning_from_failures: "automatic" pattern_recognition: "enabled" ``` ### Estrutura de Diretórios ``` projeto/ ├── docs/ # Documentação │ ├── README.md │ ├── ARCHITECTURE.md │ └── API.md ├── src/ # Código fonte │ ├── components/ # Componentes reutilizáveis │ ├── services/ # Lógica de negócio │ ├── utils/ # Utilitários │ └── types/ # Definições de tipos ├── tests/ # Testes │ ├── unit/ │ ├── integration/ │ └── e2e/ ├── config/ # Configurações ├── scripts/ # Scripts de automação └── .env.example # Variáveis de ambiente ``` ### Convenções de Nomenclatura - **Arquivos**: kebab-case (ex: `user-service.js`) - **Diretórios**: kebab-case (ex: `user-management/`) - **Componentes React**: PascalCase (ex: `UserProfile.tsx`) - **Funções**: camelCase (ex: `getUserData()`) - **Constantes**: UPPER_SNAKE_CASE (ex: `API_BASE_URL`) ## 🎯 Otimização por Domínio Específico ```yaml domain_optimization: frontend_patterns: - "react_optimization" - "component_composition" - "performance_monitoring" - "accessibility_compliance" backend_patterns: - "api_design_best_practices" - "database_optimization" - "security_implementation" - "scalability_patterns" devops_patterns: - "ci_cd_best_practices" - "infrastructure_as_code" - "monitoring_observability" - "security_automation" mobile_patterns: - "performance_optimization" - "offline_first_design" - "native_integration" - "user_experience" cross_domain_patterns: - "knowledge_sharing" - "pattern_reuse" - "technology_alignment" - "quality_consistency" ``` ## 🔄 Fluxo de Desenvolvimento ### Metodologia de Trabalho 1. **Análise de Requisitos** - Definir objetivos claros - Identificar stakeholders - Mapear dependências externas - Estimar complexidade e tempo 2. **Design e Arquitetura** - Criar diagramas de arquitetura - Definir APIs e contratos - Escolher tecnologias apropriadas - Planejar estrutura de dados 3. **Decomposição de Tarefas** - Quebrar em tarefas de 2-8 horas - Definir critérios de aceitação - Estabelecer dependências - Atribuir prioridades 4. **Implementação** - Seguir padrões de código estabelecidos - Implementar testes unitários - Documentar código complexo - Realizar code reviews 5. **Validação e Testes** - Testes unitários (>80% cobertura) - Testes de integração - Testes end-to-end - Validação de performance ## 📊 Critérios de Qualidade ### Métricas Obrigatórias - **Cobertura de Testes**: Mínimo 80% - **Performance**: Tempo de resposta < 200ms para APIs - **Acessibilidade**: WCAG 2.1 AA para interfaces - **Segurança**: Análise de vulnerabilidades - **Documentação**: 100% das APIs documentadas ### Padrões de Código ```yaml linting: - ESLint para JavaScript/TypeScript - Pylint para Python - Prettier para formatação - Husky para pre-commit hooks qualidade: - SonarQube para análise estática - Lighthouse para performance web - OWASP ZAP para segurança - Dependabot para dependências ``` ## 🚀 Estratégias de Deploy ### Ambientes Obrigatórios 1. **Development** - Desenvolvimento local 2. **Staging** - Testes de integração 3. **Production** - Ambiente de produção ### Pipeline CI/CD ```yaml stages: - lint: "Verificação de código" - test: "Execução de testes" - build: "Construção da aplicação" - security: "Análise de segurança" - deploy: "Deploy automático" - monitor: "Monitoramento pós-deploy" ``` ### Estratégias de Release - **Blue-Green Deployment** para aplicações críticas - **Rolling Updates** para aplicações tolerantes a falhas - **Canary Releases** para validação gradual - **Feature Flags** para controle de funcionalidades ## 📝 Documentação Obrigatória ### Documentos por Projeto 1. **README.md** - Visão geral e instruções de setup 2. **ARCHITECTURE.md** - Arquitetura e decisões técnicas 3. **API.md** - Documentação de APIs 4. **DEPLOYMENT.md** - Instruções de deploy 5. **CHANGELOG.md** - Histórico de mudanças 6. **CONTRIBUTING.md** - Guia para contribuidores ### Padrões de Documentação - **Linguagem**: Português brasileiro - **Formato**: Markdown com diagramas Mermaid - **Estrutura**: Hierárquica com índice - **Exemplos**: Sempre incluir exemplos práticos - **Atualização**: Manter sincronizado com código ## 🔍 Monitoramento e Observabilidade ### Métricas Essenciais ```yaml performance: - response_time: "Tempo de resposta" - throughput: "Taxa de transferência" - error_rate: "Taxa de erro" - availability: "Disponibilidade" business: - user_engagement: "Engajamento do usuário" - conversion_rate: "Taxa de conversão" - feature_usage: "Uso de funcionalidades" - user_satisfaction: "Satisfação do usuário" ``` ### Ferramentas de Monitoramento - **Logs**: Structured logging com Winston/Pino - **Métricas**: Prometheus + Grafana - **Traces**: Jaeger ou Zipkin - **Alertas**: PagerDuty ou Slack - **Uptime**: Pingdom ou UptimeRobot ## 🛡️ Segurança e Compliance ### Práticas Obrigatórias 1. **Autenticação e Autorização** - JWT tokens com refresh - RBAC (Role-Based Access Control) - Rate limiting - Input validation 2. **Proteção de Dados** - Criptografia em trânsito (HTTPS) - Criptografia em repouso - Sanitização de dados - Backup seguro 3. **Auditoria e Compliance** - Logs de auditoria - Análise de vulnerabilidades - Compliance com LGPD - Revisões de segurança ## 📈 Gestão de Riscos ### Identificação de Riscos - **Técnicos**: Complexidade, dependências, performance - **Cronograma**: Prazos apertados, recursos limitados - **Qualidade**: Falta de testes, documentação inadequada - **Segurança**: Vulnerabilidades, exposição de dados ### Estratégias de Mitigação ```yaml riscos_tecnicos: - proof_of_concept: "Validar viabilidade técnica" - spike_solutions: "Explorar alternativas" - refactoring: "Melhorar qualidade do código" riscos_cronograma: - buffer_time: "Incluir tempo de contingência" - parallel_work: "Paralelizar tarefas independentes" - mvp_approach: "Focar no mínimo viável" riscos_qualidade: - automated_testing: "Automatizar testes" - code_reviews: "Revisões de código obrigatórias" - continuous_integration: "Integração contínua" ``` ## 🎯 Definição de Sucesso ### Critérios de Aceitação Todo projeto deve atender aos seguintes critérios: - ✅ Todos os requisitos funcionais implementados - ✅ Cobertura de testes >= 80% - ✅ Performance dentro dos SLAs definidos - ✅ Segurança validada por auditoria - ✅ Documentação completa e atualizada - ✅ Deploy automatizado funcionando - ✅ Monitoramento configurado - ✅ Equipe treinada para manutenção ### Métricas de Sucesso ```yaml entrega: - on_time_delivery: ">= 90%" - budget_adherence: ">= 95%" - scope_completion: "100%" qualidade: - bug_rate: "< 1 bug/1000 LOC" - customer_satisfaction: ">= 4.5/5" - performance_sla: ">= 99.9%" equipe: - team_satisfaction: ">= 4.0/5" - knowledge_transfer: "100%" - documentation_quality: ">= 4.0/5" ``` --- *Este arquivo deve ser revisado e atualizado a cada projeto para incorporar lições aprendidas e melhorias de processo.*