@maestro-ai/mcp-server 1.2.0 → 2.1.0

package/dist/content/skills/specialist-arquitetura-software/resources/reference/architecture-guide.md

@@ -0,0 +1,489 @@
+# Guia de Arquitetura de Software
+
+## Fundamentos de Arquitetura
+
+### 1. Princípios Fundamentais
+
+#### Single Responsibility Principle
+Cada componente deve ter uma única responsabilidade bem definida.
+
+#### Open/Closed Principle
+Componentes devem estar abertos para extensão, mas fechados para modificação.
+
+#### Dependency Inversion
+Módulos de alto nível não devem depender de módulos de baixo nível.
+
+#### Separation of Concerns
+Separar responsabilidades em diferentes camadas e componentes.
+
+### 2. Padrões Arquiteturais
+
+#### Monolithic Architecture
+- **Quando usar**: Times pequenos, produtos simples
+- **Vantagens**: Simplicidade, facilidade de deploy
+- **Desvantagens**: Escalabilidade limitada, acoplamento alto
+
+#### Microservices Architecture
+- **Quando usar**: Times grandes, produtos complexos
+- **Vantagens**: Escalabilidade, independência de deploy
+- **Desvantagens**: Complexidade, overhead de comunicação
+
+#### Event-Driven Architecture
+- **Quando usar**: Sistemas assíncronos, real-time
+- **Vantagens**: Desacoplamento, escalabilidade
+- **Desvantagens**: Complexidade de debugging, consistência eventual
+
+#### Serverless Architecture
+- **Quando usar**: Workloads esporádicos, pay-per-use
+- **Vantagens**: Custos operacionais zero, escalabilidade infinita
+- **Desvantagens**: Cold starts, vendor lock-in
+
+### 3. Arquitetura C4
+
+#### Level 1: Context Diagram
+- Mostra o sistema como uma caixa no centro
+- Identifica usuários e sistemas externos
+- Mostra fluxos de dados principais
+
+#### Level 2: Container Diagram
+- Mostra principais containers (web app, API, database)
+- Identifica tecnologias usadas
+- Mostra comunicação entre containers
+
+#### Level 3: Component Diagram
+- Detalha componentes dentro de containers
+- Mostra APIs e interfaces
+- Identifica responsabilidades específicas
+
+#### Level 4: Code (Opcional)
+- Detalha classes e módulos
+- Mostra estrutura de código
+- Raramente necessário para documentação
+
+## Stack Tecnológica
+
+### 1. Frontend Stack
+
+#### Frameworks Web
+- **React**: Component-based, grande ecossistema
+- **Vue.js**: Progressivo, fácil aprendizado
+- **Angular**: Enterprise-ready, TypeScript-first
+- **Next.js**: React com SSR/SSG otimizado
+
+#### Linguagens
+- **TypeScript**: Tipagem estática, melhor IDE support
+- **JavaScript**: Flexível, ubiquo
+- **Elm**: Funcional, sem runtime errors
+
+#### Estilos
+- **Tailwind CSS**: Utility-first, customizável
+- **Styled Components**: CSS-in-JS, scoped styles
+- **Bootstrap**: Component-based, rápido protótipo
+- **Material-UI**: Design system, componentes prontos
+
+#### State Management
+- **Redux**: Predictable state, middleware ecosystem
+- **Zustand**: Minimal, TypeScript-friendly
+- **MobX**: Reactive, simples
+- **Context API**: Built-in, simples para apps pequenos
+
+### 2. Backend Stack
+
+#### Runtimes
+- **Node.js**: JavaScript, event-driven, non-blocking I/O
+- **Python**: Simples, grande ecossistema de ML/AI
+- **Java**: Enterprise-ready, performance
+- **Go**: Concurrency, performance, simples
+
+#### Frameworks
+- **Express.js**: Minimal, middleware ecosystem
+- **FastAPI**: Python moderno, automatic docs
+- **Spring Boot**: Java enterprise, auto-configuration
+- **Gin**: Go minimal, performance
+
+#### Bancos de Dados
+- **PostgreSQL**: Relacional, extensível, JSON support
+- **MongoDB**: NoSQL, flexible schema
+- **Redis**: Cache, session store, pub/sub
+- **ClickHouse**: Analytics, columnar, fast queries
+
+#### ORMs
+- **Prisma**: Type-safe, auto-generated client
+- **SQLAlchemy**: Python, mature, flexible
+- **TypeORM**: TypeScript, decorator-based
+- **Hibernate**: Java, mature, enterprise
+
+### 3. Infraestrutura
+
+#### Cloud Providers
+- **AWS**: Líder de mercado, vasto ecossistema
+- **Azure**: Enterprise-friendly, integração Microsoft
+- **GCP**: AI/ML focus, competitive pricing
+- **DigitalOcean**: Simples, developer-friendly
+
+#### Containers
+- **Docker**: Padrão de fato, isolamento de aplicações
+- **Kubernetes**: Orquestração, auto-scaling
+- **Docker Compose**: Desenvolvimento local, simples
+
+#### CI/CD
+- **GitHub Actions**: Integrado com GitHub, marketplace rico
+- **GitLab CI**: Integrado com GitLab, YAML-based
+- **Jenkins**: Customizável, plugin ecosystem
+- **CircleCI**: Rápido, Docker-first
+
+## Decisões Arquiteturais (ADRs)
+
+### 1. Estrutura de ADR
+
+#### Metadata Obrigatória
+- Título claro e descritivo
+- Status (Proposed/Accepted/Deprecated/Superceded)
+- Data de criação e última revisão
+- Autores e revisores
+
+#### Conteúdo Essencial
+- Contexto do problema
+- Decisão tomada
+- Consequências (positivas e negativas)
+- Alternativas consideradas
+
+### 2. ADRs Comuns
+
+#### ADR-001: Escolha do Padrão Arquitetural
+```
+Contexto: Precisamos decidir entre monolito vs microservices
+Decisão: Monolito modular inicial, evoluir para microservices
+Consequências: Simplicidade inicial, complexidade gerenciada
+```
+
+#### ADR-002: Escolha do Banco de Dados
+```
+Contexto: Precisamos escolher entre SQL vs NoSQL
+Decisão: PostgreSQL para dados transacionais, Redis para cache
+Consequências: Consistência ACID, performance de cache
+```
+
+#### ADR-003: Estratégia de Autenticação
+```
+Contexto: Precisamos definir estratégia de autenticação
+Decisão: OAuth2 + JWT com refresh tokens
+Consequências: Stateless auth, revogação complexa
+```
+
+### 3. Boas Práticas de ADRs
+
+#### Writing Good ADRs
+- Seja específico e claro
+- Inclua contexto suficiente
+- Analise trade-offs honestamente
+- Considere alternativas reais
+
+#### Managing ADRs
+- Version control todos ADRs
+- Review regularmente ADRs antigos
+- Superceda ADRs quando necessário
+- Comunique mudanças para time
+
+## SLOs e SLIs
+
+### 1. Service Level Indicators (SLIs)
+
+#### Performance SLIs
+- **Response Time**: Tempo de resposta das APIs
+- **Throughput**: Requisições por segundo
+- **Error Rate**: Percentual de erros
+- **Latency**: Latência de rede e processamento
+
+#### Availability SLIs
+- **Uptime**: Tempo que sistema está online
+- **Downtime**: Tempo que sistema está offline
+- **Recovery Time**: Tempo para recuperação
+- **Recovery Point**: Perda de dados máxima
+
+#### Business SLIs
+- **Transaction Success**: Taxa de sucesso de transações
+- **User Engagement**: Engajamento dos usuários
+- **Conversion Rate**: Taxa de conversão
+- **Customer Satisfaction**: Satisfação dos clientes
+
+### 2. Service Level Objectives (SLOs)
+
+#### Setting Realistic SLOs
+- Baseie-se em dados históricos
+- Considere capacidade atual
+- Inclua buffer para imprevistos
+- Alinhe com expectativas dos usuários
+
+#### Common SLOs
+- **API Response Time**: p95 < 200ms
+- **System Availability**: > 99.9%
+- **Error Rate**: < 0.1%
+- **Recovery Time**: < 5 minutes
+
+### 3. Error Budget
+
+#### Calculating Error Budget
+```
+Monthly Budget = (100% - SLO%) × Monthly Minutes
+Example: (100% - 99.9%) × 43,200 minutes = 43.2 minutes
+```
+
+#### Managing Error Budget
+- Track budget consumption
+- Stop releases when budget exhausted
+- Use budget for innovation
+- Communicate budget status
+
+## Segurança em Arquitetura
+
+### 1. Princípios de Segurança
+
+#### Defense in Depth
+Múltiplas camadas de segurança
+- Network security
+- Application security
+- Data security
+- Physical security
+
+#### Least Privilege
+Dar acesso mínimo necessário
+- Role-based access control (RBAC)
+- Principle of least privilege (PoLP)
+- Zero trust architecture
+- Regular access reviews
+
+#### Secure by Default
+Configurações seguras por padrão
+- Secure defaults
+- Automatic security updates
+- Minimal attack surface
+- Security headers
+
+### 2. OWASP Top 10 2025
+
+#### 1. Broken Access Control
+- Implement RBAC em todas requests
+- Validar autorização em cada operação
+- Usar principle of least privilege
+- Audit access logs regularmente
+
+#### 2. Cryptographic Failures
+- Usar TLS 1.3+ em todas comunicações
+- Implementar bcrypt/Argon2 para passwords
+- Usar AES-256 para dados sensíveis
+- Gerenciar chaves criptográficas
+
+#### 3. Injection
+- Usar ORMs e prepared statements
+- Validar todos inputs
+- Sanitize dados de usuário
+- Implementar CSP headers
+
+### 3. Security Architecture
+
+#### Authentication Strategies
+- **JWT**: Stateless, scalable
+- **OAuth2**: Delegated authorization
+- **SAML**: Enterprise SSO
+- **MFA**: Multi-factor authentication
+
+#### Authorization Models
+- **RBAC**: Role-based access control
+- **ABAC**: Attribute-based access control
+- **PBAC**: Policy-based access control
+- **ReBAC**: Relationship-based access control
+
+## Performance e Escalabilidade
+
+### 1. Performance Patterns
+
+#### Caching Strategies
+- **Application Cache**: In-memory cache
+- **Database Cache**: Query results cache
+- **CDN**: Static content cache
+- **Edge Computing**: Distributed cache
+
+#### Database Optimization
+- **Indexing**: Strategic index creation
+- **Query Optimization**: Efficient queries
+- **Connection Pooling**: Reuse connections
+- **Read Replicas**: Distribute read load
+
+#### Load Balancing
+- **Round Robin**: Equal distribution
+- **Least Connections**: Smart distribution
+- **IP Hash**: Session persistence
+- **Geographic**: Regional distribution
+
+### 2. Scalability Patterns
+
+#### Horizontal Scaling
+- Add more machines
+- Stateless applications
+- Load balancers
+- Auto-scaling groups
+
+#### Vertical Scaling
+- Upgrade existing machines
+- More CPU/RAM/Storage
+- Simpler architecture
+- Single point of failure
+
+#### Database Scaling
+- **Read Replicas**: Distribute reads
+- **Sharding**: Distribute data
+- **Partitioning**: Logical separation
+- **Caching Layers**: Reduce load
+
+### 3. Performance Monitoring
+
+#### Key Metrics
+- **Response Time**: API latency
+- **Throughput**: Requests per second
+- **Error Rate**: Failed requests
+- **Resource Usage**: CPU/Memory/IO
+
+#### Monitoring Tools
+- **Prometheus**: Metrics collection
+- **Grafana**: Visualization
+- **Jaeger**: Distributed tracing
+- **ELK Stack**: Log aggregation
+
+## Monitoramento e Observabilidade
+
+### 1. Three Pillars of Observability
+
+#### Logs
+- Structured logging
+- Centralized collection
+- Proper log levels
+- Sensitive data protection
+
+#### Metrics
+- Business metrics
+- Technical metrics
+- Custom metrics
+- Time-series data
+
+#### Traces
+- Distributed tracing
+- Request flow tracking
+- Performance bottlenecks
+- Service dependencies
+
+### 2. Monitoring Strategy
+
+#### Proactive Monitoring
+- Health checks
+- Performance thresholds
+- Anomaly detection
+- Predictive analytics
+
+#### Reactive Monitoring
+- Alerting rules
+- Incident response
+- Post-mortem analysis
+- Continuous improvement
+
+#### Business Monitoring
+- User behavior
+- Conversion rates
+- Revenue impact
+- Customer satisfaction
+
+### 3. Alerting Best Practices
+
+#### Alert Design
+- Actionable alerts
+- Clear severity levels
+- Proper escalation
+- Documentation links
+
+#### Alert Fatigue Prevention
+- Alert grouping
+- Noise reduction
+- Threshold tuning
+- Regular reviews
+
+## Roadmap e Implementação
+
+### 1. Phased Implementation
+
+#### Phase 1: Foundation
+- Core architecture
+- Basic functionality
+- Essential integrations
+- Initial monitoring
+
+#### Phase 2: Expansion
+- Additional features
+- Performance optimization
+- Security hardening
+- Advanced monitoring
+
+#### Phase 3: Maturity
+- Advanced features
+- Full automation
+- Complete observability
+- Continuous optimization
+
+### 2. Risk Management
+
+#### Technical Risks
+- Technology obsolescence
+- Performance bottlenecks
+- Security vulnerabilities
+- Scaling limitations
+
+#### Business Risks
+- Budget overruns
+- Timeline delays
+- Resource constraints
+- Market changes
+
+#### Mitigation Strategies
+- Regular risk assessments
+- Contingency planning
+- Insurance policies
+- Diversification
+
+### 3. Success Metrics
+
+#### Technical Metrics
+- System performance
+- Availability targets
+- Security posture
+- Code quality
+
+#### Business Metrics
+- User adoption
+- Customer satisfaction
+- Revenue impact
+- Market position
+
+## Referências e Recursos
+
+### 1. Livros Essenciais
+- "Designing Data-Intensive Applications" - Martin Kleppmann
+- "Building Microservices" - Sam Newman
+- "The Art of Scalability" - Martin L. Abbott
+- "Clean Architecture" - Robert C. Martin
+
+### 2. Blogs e Artigos
+- Martin Fowler's Blog
+- AWS Architecture Blog
+- Google Cloud Architecture
+- Microsoft Azure Architecture
+
+### 3. Ferramentas e Frameworks
+- ArchiMate - Modeling language
+- C4 Model - Architecture visualization
+- Architecture Decision Records
+- Architecture Metrics
+
+### 4. Comunidades
+- Software Architecture Weekly
+- InfoQ Architecture
+- GOTO Conference
+- AWS re:Invent

package/dist/content/skills/specialist-arquitetura-software/resources/templates/adr.md

@@ -0,0 +1,61 @@
+# ADR-[Número]: [Título da Decisão]
+
+## Status
+[ ] Proposed
+[ ] Accepted
+[ ] Deprecated
+[ ] Superceded by [ADR-Número]
+
+## Contexto
+[Descreva o contexto e o problema que motivou esta decisão arquitetural. Inclua:
+- O problema sendo abordado
+- Restrições ou limitações
+- Stakeholders envolvidos
+- Impacto no negócio ou nos usuários]
+
+## Decisão
+[Descreva claramente a decisão tomada. Seja específico e conciso.
+Exemplo: "Usaremos microservices com comunicação via API REST"
+Exemplo: "Adotaremos PostgreSQL como banco de dados principal"
+Exemplo: "Implementaremos cache Redis com TTL de 1 hora"]
+
+## Consequências
+[Descreva as consequências desta decisão, incluindo:
+- Impactos positivos (benefícios)
+- Impactos negativos (custos, complexidade)
+- Trade-offs considerados
+- Riscos introduzidos
+- Dependências criadas]
+
+## Alternativas Consideradas
+[Liste as alternativas que foram consideradas e rejeitadas:
+- Alternativa 1: [Descrição] - [Motivo da rejeição]
+- Alternativa 2: [Descrição] - [Motivo da rejeição]
+- Alternativa 3: [Descrição] - [Motivo da rejeição]]
+
+## Implementação
+[Descreva como esta decisão será implementada:
+- Componentes afetados
+- Mudanças necessárias
+- Timeline estimada
+- Responsáveis]
+
+## Validação
+[Como validaremos que esta decisão foi bem-sucedida:
+- Métricas de sucesso
+- Testes necessários
+- Monitoramento
+- Critérios de aceite]
+
+## Referências
+[Liste referências relevantes:
+- Documentação técnica
+- Artigos ou posts
+- Exemplos de outras empresas
+- Discussões com a equipe]
+
+---
+**Criado em:** [Data]  
+**Autor:** [Nome]  
+**Revisores:** [Nomes]  
+**Próxima revisão:** [Data]