myconvergio 2.1.0

package/.claude/rules/testing-standards.md

@@ -0,0 +1,266 @@
+# Testing Standards
+
+> This rule is enforced by the MyConvergio agent ecosystem.
+
+## Overview
+Comprehensive testing is mandatory in the MyConvergio ecosystem. All code must include appropriate unit, integration, and end-to-end tests to ensure reliability, prevent regressions, and facilitate confident refactoring.
+
+## Requirements
+
+### Test Coverage
+- Minimum 80% code coverage for all business logic
+- 100% coverage for critical paths (authentication, payment, data integrity)
+- Track coverage metrics in CI/CD pipeline
+- Coverage should include branches, not just lines
+
+### Unit Testing
+- Required for all business logic functions
+- Test pure functions in isolation
+- Mock external dependencies (databases, APIs, file system)
+- Each test should verify one specific behavior
+- Fast execution (< 1ms per test ideal)
+- No network calls or file I/O in unit tests
+
+### Integration Testing
+- Required for all API endpoints
+- Test database interactions with test database
+- Verify external service integrations
+- Test authentication and authorization flows
+- Use fixtures and factories for test data
+- Clean up test data after each test
+
+### Test Naming Conventions
+- Use descriptive names that explain the scenario
+- Format: `describe('ComponentName', () => it('should do X when Y'))`
+- Name should read like a specification
+- Group related tests in describe blocks
+- Use nested describe blocks for context
+
+### Test Data Management
+- Use fixtures for complex test data
+- Use factories for generating test objects
+- Never use production data in tests
+- Reset database state between tests
+- Avoid test interdependencies
+
+### Test Isolation
+- Tests must run independently
+- No shared state between tests
+- Each test should set up its own data
+- Clean up resources in afterEach/teardown
+- Tests should pass in any order
+
+### Mocking & Stubbing
+- Mock external dependencies (APIs, databases, time)
+- Use dependency injection to enable mocking
+- Avoid over-mocking (test real integration when possible)
+- Document what is mocked and why
+- Use test doubles appropriately (mocks, stubs, spies, fakes)
+
+### Performance
+- Unit tests should run in milliseconds
+- Integration tests should run in seconds
+- Optimize slow tests
+- Parallelize test execution when possible
+- Flag and investigate flaky tests
+
+## Examples
+
+### Good Examples
+
+#### Unit Test (TypeScript/Jest)
+```typescript
+// Good: Clear naming, isolated, single behavior
+describe('calculateDiscount', () => {
+  it('should apply 10% discount for premium users', () => {
+    const user = { isPremium: true };
+    const price = 100;
+
+    const result = calculateDiscount(price, user);
+
+    expect(result).toBe(90);
+  });
+
+  it('should return original price for non-premium users', () => {
+    const user = { isPremium: false };
+    const price = 100;
+
+    const result = calculateDiscount(price, user);
+
+    expect(result).toBe(100);
+  });
+
+  it('should throw error for negative prices', () => {
+    const user = { isPremium: true };
+    const price = -50;
+
+    expect(() => calculateDiscount(price, user))
+      .toThrow('Price must be positive');
+  });
+});
+```
+
+#### Integration Test (Python/pytest)
+```python
+# Good: Database integration, fixtures, cleanup
+@pytest.fixture
+def test_db():
+    """Create test database and clean up after."""
+    db = create_test_database()
+    yield db
+    db.cleanup()
+
+def test_create_user_endpoint(test_db, client):
+    """Should create user and return 201 with user data."""
+    # Arrange
+    user_data = {
+        "email": "test@example.com",
+        "name": "Test User"
+    }
+
+    # Act
+    response = client.post("/api/users", json=user_data)
+
+    # Assert
+    assert response.status_code == 201
+    assert response.json["email"] == user_data["email"]
+
+    # Verify in database
+    user = test_db.query(User).filter_by(email=user_data["email"]).first()
+    assert user is not None
+    assert user.name == user_data["name"]
+```
+
+#### Mocking External Services (TypeScript)
+```typescript
+// Good: Mock external API, test error handling
+describe('UserService', () => {
+  let mockHttpClient: jest.Mocked<HttpClient>;
+  let userService: UserService;
+
+  beforeEach(() => {
+    mockHttpClient = {
+      get: jest.fn(),
+      post: jest.fn(),
+    } as any;
+    userService = new UserService(mockHttpClient);
+  });
+
+  it('should fetch user profile from API', async () => {
+    const mockUser = { id: '123', name: 'John' };
+    mockHttpClient.get.mockResolvedValue({ data: mockUser });
+
+    const result = await userService.getProfile('123');
+
+    expect(result).toEqual(mockUser);
+    expect(mockHttpClient.get).toHaveBeenCalledWith('/users/123');
+  });
+
+  it('should handle API errors gracefully', async () => {
+    mockHttpClient.get.mockRejectedValue(new Error('Network error'));
+
+    await expect(userService.getProfile('123'))
+      .rejects.toThrow('Failed to fetch user profile');
+  });
+});
+```
+
+#### Test Fixtures (Python)
+```python
+# Good: Reusable fixtures, factory pattern
+@pytest.fixture
+def sample_user():
+    """Create a sample user for testing."""
+    return User(
+        id="123",
+        email="test@example.com",
+        name="Test User",
+        is_premium=True
+    )
+
+@pytest.fixture
+def user_factory():
+    """Factory for creating test users with custom attributes."""
+    def _create_user(**kwargs):
+        defaults = {
+            "email": "test@example.com",
+            "name": "Test User",
+            "is_premium": False
+        }
+        return User(**{**defaults, **kwargs})
+    return _create_user
+
+def test_with_factory(user_factory):
+    premium_user = user_factory(is_premium=True)
+    regular_user = user_factory()
+
+    assert premium_user.is_premium
+    assert not regular_user.is_premium
+```
+
+### Bad Examples
+
+#### Poor Test Naming
+```typescript
+// Bad: Unclear test names
+describe('User', () => {
+  it('test1', () => {
+    // What does this test?
+  });
+
+  it('works', () => {
+    // Works for what scenario?
+  });
+});
+```
+
+#### Shared State
+```typescript
+// Bad: Tests share state, order-dependent
+let userId;
+
+it('creates user', async () => {
+  const user = await createUser({ email: 'test@example.com' });
+  userId = user.id; // Shared state!
+});
+
+it('updates user', async () => {
+  await updateUser(userId, { name: 'Updated' }); // Depends on previous test!
+});
+```
+
+#### No Mocking (Slow Tests)
+```typescript
+// Bad: Real API call in unit test
+it('should fetch user data', async () => {
+  const result = await fetch('https://api.example.com/users/123');
+  // This is slow, unreliable, and not a unit test!
+  expect(result.status).toBe(200);
+});
+```
+
+#### Magic Values
+```python
+# Bad: Magic numbers and unclear test data
+def test_calculate_price():
+    result = calculate_price(100, 0.1, True, 5)
+    assert result == 427.5  # What do these numbers mean?
+```
+
+#### No Assertions
+```typescript
+// Bad: No verification of behavior
+it('should process order', () => {
+  processOrder(order);
+  // Test passes but doesn't verify anything!
+});
+```
+
+## References
+- [Jest Documentation](https://jestjs.io/docs/getting-started)
+- [Pytest Documentation](https://docs.pytest.org/)
+- [Testing Best Practices](https://testingjavascript.com/)
+- [Martin Fowler - Test Pyramid](https://martinfowler.com/articles/practical-test-pyramid.html)
+- [Test-Driven Development by Kent Beck](https://www.amazon.com/Test-Driven-Development-Kent-Beck/dp/0321146530)
+- [xUnit Test Patterns](http://xunitpatterns.com/)
+- [Google Testing Blog](https://testing.googleblog.com/)

package/.claude/skills/architecture/SKILL.md

@@ -0,0 +1,228 @@
+# Architecture Design Skill
+
+> Reusable workflow extracted from baccio-tech-architect expertise.
+
+## Purpose
+Design scalable, maintainable, and secure system architectures using proven patterns, with emphasis on Domain-Driven Design, Clean Architecture, and cloud-native principles.
+
+## When to Use
+- New system or feature architecture design
+- Legacy system modernization planning
+- Technology stack selection
+- Scalability assessment and planning
+- Microservices architecture design
+- Cloud migration strategy
+- Technical debt evaluation
+- Architecture review and validation
+
+## Workflow Steps
+
+1. **Requirements Analysis**
+   - Gather functional requirements
+   - Define non-functional requirements (NFRs)
+   - Identify constraints (budget, timeline, team skills)
+   - Understand scale requirements (users, data, traffic)
+   - Document compliance requirements
+
+2. **Domain Modeling**
+   - Apply Domain-Driven Design (DDD)
+   - Identify bounded contexts
+   - Define domain entities and aggregates
+   - Map ubiquitous language
+   - Establish context boundaries
+
+3. **Architecture Pattern Selection**
+   - Evaluate architecture styles (monolith, microservices, serverless)
+   - Choose appropriate patterns (CQRS, Event Sourcing, Saga)
+   - Apply Clean Architecture principles
+   - Define layers and dependencies
+   - Establish communication patterns
+
+4. **Technology Stack Selection**
+   - Evaluate technology options against requirements
+   - Consider team expertise and learning curve
+   - Assess vendor lock-in risks
+   - Evaluate cost implications
+   - Check compliance with organizational standards
+
+5. **Scalability & Performance Design**
+   - Design for horizontal and vertical scaling
+   - Plan caching strategy (application, CDN, database)
+   - Define load balancing approach
+   - Design database sharding/partitioning if needed
+   - Plan for geographic distribution
+
+6. **Security Architecture**
+   - Apply Zero-Trust principles
+   - Design authentication/authorization
+   - Plan data encryption (at rest, in transit)
+   - Define security boundaries
+   - Implement defense in depth
+
+7. **Observability Design**
+   - Design logging strategy (structured logging)
+   - Plan metrics collection (Prometheus, CloudWatch)
+   - Define distributed tracing approach
+   - Create monitoring dashboards
+   - Establish alerting thresholds
+
+8. **Documentation & ADRs**
+   - Create Architecture Decision Records (ADRs)
+   - Document architecture diagrams (C4 model)
+   - Define API contracts and versioning
+   - Document deployment architecture
+   - Create capacity planning guidelines
+
+## Inputs Required
+- **Business requirements**: What problem are we solving?
+- **Non-functional requirements**: Performance, security, compliance needs
+- **Scale expectations**: Current and projected users, data volume, traffic
+- **Constraints**: Budget, timeline, team skills, existing systems
+- **Compliance**: Regulatory requirements (GDPR, HIPAA, SOC2, etc.)
+
+## Outputs Produced
+- **Architecture Blueprint**: Comprehensive system design documentation
+- **ADR (Architecture Decision Records)**: Documented design decisions with rationale
+- **Technology Stack Recommendation**: Selected technologies with justification
+- **Scalability Plan**: Scaling strategy with capacity planning
+- **Security Architecture**: Security patterns and implementation guide
+- **Deployment Diagrams**: Infrastructure and deployment architecture
+- **Migration Roadmap**: Phased implementation or migration plan
+
+## Architecture Patterns Catalog
+
+### Architectural Styles
+- **Monolithic Architecture**: Single deployable unit, simpler but less scalable
+- **Microservices**: Independent services, complex but highly scalable
+- **Serverless**: Event-driven, pay-per-use, highly elastic
+- **Modular Monolith**: Compromise between monolith and microservices
+- **Service-Oriented Architecture (SOA)**: Enterprise service bus pattern
+
+### Design Patterns
+- **Domain-Driven Design (DDD)**: Bounded contexts, aggregates, entities
+- **Clean Architecture**: Dependency inversion, layers, boundaries
+- **CQRS**: Command Query Responsibility Segregation
+- **Event Sourcing**: Event log as source of truth
+- **Saga Pattern**: Distributed transactions
+- **API Gateway**: Single entry point for clients
+- **Backend for Frontend (BFF)**: API per client type
+
+### Communication Patterns
+- **Synchronous**: REST, GraphQL, gRPC
+- **Asynchronous**: Message queues, event streams (Kafka, RabbitMQ)
+- **Pub/Sub**: Event-driven communication
+- **Request-Reply**: RPC-style communication
+
+## Trade-Off Analysis Template
+
+```markdown
+## Decision: [Technology/Pattern Choice]
+
+### Context
+[What problem are we solving? What are the constraints?]
+
+### Options Considered
+1. **Option A**: [Description]
+   - Pros: [Benefits]
+   - Cons: [Drawbacks]
+   - Cost: [Time/Money/Complexity]
+
+2. **Option B**: [Description]
+   - Pros: [Benefits]
+   - Cons: [Drawbacks]
+   - Cost: [Time/Money/Complexity]
+
+### Decision
+[Chosen option with rationale]
+
+### Consequences
+- Positive: [Expected benefits]
+- Negative: [Known drawbacks]
+- Mitigation: [How we address drawbacks]
+```
+
+## Non-Functional Requirements Checklist
+
+### Performance
+- [ ] Response time SLA defined (e.g., P95 < 200ms)
+- [ ] Throughput requirements specified
+- [ ] Scalability targets identified
+- [ ] Performance testing strategy defined
+
+### Availability
+- [ ] Uptime SLA defined (e.g., 99.9%)
+- [ ] Redundancy strategy planned
+- [ ] Failover mechanisms designed
+- [ ] Disaster recovery plan created
+
+### Security
+- [ ] Authentication mechanism selected
+- [ ] Authorization model defined
+- [ ] Data encryption strategy planned
+- [ ] Security boundaries identified
+- [ ] Penetration testing planned
+
+### Observability
+- [ ] Logging strategy defined
+- [ ] Metrics collection planned
+- [ ] Distributed tracing implemented
+- [ ] Dashboards designed
+- [ ] Alerting configured
+
+### Maintainability
+- [ ] Code organization standards defined
+- [ ] Testing strategy established
+- [ ] Documentation requirements specified
+- [ ] Deployment automation planned
+
+## Example Usage
+
+```
+Input: Design architecture for e-commerce platform
+Expected: 10K concurrent users, 99.9% uptime, PCI DSS compliant
+
+Workflow Execution:
+1. Requirements: User accounts, product catalog, shopping cart, checkout
+2. Domain Model: User, Product, Cart, Order bounded contexts
+3. Pattern: Microservices with API Gateway, Event-driven for orders
+4. Tech Stack:
+   - Backend: Node.js + TypeScript
+   - Database: PostgreSQL (products/users), Redis (cart/sessions)
+   - Message Bus: Kafka for order events
+   - Cloud: AWS with ECS + RDS + ElastiCache
+5. Scalability: Horizontal scaling via ECS, database read replicas, CDN
+6. Security: OAuth2 + JWT, PCI-compliant payment gateway, encryption at rest
+7. Observability: CloudWatch logs/metrics, X-Ray tracing, Grafana dashboards
+8. Documentation: ADRs created, C4 diagrams, API documentation
+
+Output: Comprehensive architecture blueprint with ADRs and diagrams
+```
+
+## Tech Stack Selection Criteria
+
+### Evaluation Matrix
+| Criterion | Weight | Option A | Option B | Option C |
+|-----------|--------|----------|----------|----------|
+| Team expertise | 20% | 8/10 | 5/10 | 6/10 |
+| Scalability | 25% | 9/10 | 7/10 | 8/10 |
+| Cost | 15% | 6/10 | 9/10 | 7/10 |
+| Community support | 10% | 9/10 | 8/10 | 6/10 |
+| Compliance fit | 15% | 8/10 | 7/10 | 9/10 |
+| Vendor lock-in | 15% | 7/10 | 5/10 | 8/10 |
+| **Total** | 100% | **7.9** | **6.9** | **7.5** |
+
+## Related Agents
+- **baccio-tech-architect** - Full agent with reasoning and decision-making
+- **luca-security-expert** - Security architecture validation
+- **dan-engineering-gm** - Engineering leadership alignment
+- **marco-devops-engineer** - Infrastructure and deployment architecture
+- **domik-mckinsey-strategic-decision-maker** - Strategic technology decisions
+
+## ISE Engineering Fundamentals Alignment
+- Document Architecture Decision Records (ADRs)
+- Apply proven design patterns
+- Conduct trade studies before major decisions
+- Use technical spikes for high-risk unknowns
+- Design for NFRs from day one (availability, scalability, security)
+- Infrastructure as Code for all infrastructure
+- GitOps workflows for deployments

package/.claude/skills/code-review/SKILL.md

@@ -0,0 +1,140 @@
+# Code Review Skill
+
+> Reusable workflow extracted from rex-code-reviewer expertise.
+
+## Purpose
+Perform comprehensive code review with focus on quality, security, design patterns, and best practices to prevent bugs before merge.
+
+## When to Use
+- Pull request reviews before merge
+- Code quality assessment for legacy code
+- Security vulnerability identification
+- Design pattern evaluation
+- Pre-release code audits
+- Technical debt quantification
+
+## Workflow Steps
+
+1. **Context Understanding**
+   - Understand the purpose and scope of the code change
+   - Review related issue/ticket context
+   - Identify affected components and dependencies
+
+2. **Architecture Review**
+   - Verify alignment with overall system architecture
+   - Check adherence to SOLID principles
+   - Validate design pattern usage
+   - Assess maintainability impact
+
+3. **Logic & Security Review**
+   - Validate business logic correctness
+   - Check edge case handling
+   - Scan for OWASP Top 10 vulnerabilities
+   - Verify input validation and sanitization
+   - Check authentication/authorization
+
+4. **Performance & Quality Check**
+   - Identify potential bottlenecks
+   - Check algorithmic complexity
+   - Verify database query optimization
+   - Assess resource management
+
+5. **Style & Standards**
+   - Verify adherence to team coding standards
+   - Check naming conventions
+   - Validate documentation quality
+   - Review test coverage adequacy
+
+6. **Generate Feedback**
+   - Categorize issues by severity (CRITICAL/HIGH/MEDIUM/SUGGESTION)
+   - Provide file:line references
+   - Include concrete fix recommendations
+   - Acknowledge good patterns
+
+## Inputs Required
+- **Code to review**: Pull request diff, file paths, or commit range
+- **Context**: Purpose of changes, related requirements
+- **Standards**: Team coding standards, style guides
+- **Scope**: Full review vs focused review (security, performance, etc.)
+
+## Outputs Produced
+- **Review Report**: Detailed findings by severity with file:line references
+- **Security Issues**: Vulnerabilities flagged with severity levels
+- **Pattern Assessment**: Design pattern usage evaluation
+- **Refactoring Roadmap**: Prioritized improvements with effort estimates
+- **Decision**: Approve / Request Changes / Comment
+
+## Review Categories
+
+### Severity Levels
+- **🔴 CRITICAL**: Must fix before merge - security issues, data loss risks, breaking bugs
+- **🟠 HIGH**: Should fix - significant maintainability or performance issues
+- **🟡 MEDIUM**: Consider fixing - code smell, minor inefficiencies
+- **🟢 SUGGESTION**: Nice to have - style improvements, minor optimizations
+- **💡 LEARNING**: Educational - explaining why certain patterns are preferred
+
+## Checklist Format
+
+### Security Checklist
+- [ ] No hardcoded secrets or credentials
+- [ ] Input validation and sanitization present
+- [ ] SQL injection prevention (parameterized queries)
+- [ ] XSS prevention (output encoding)
+- [ ] Authentication/authorization properly implemented
+- [ ] Sensitive data encrypted at rest and in transit
+- [ ] No security misconfigurations
+
+### Quality Checklist
+- [ ] Code without tests is incomplete - tests present
+- [ ] Edge cases and error conditions handled
+- [ ] No hardcoded values - configuration used
+- [ ] Logging comprehensive with context
+- [ ] No TODO/FIXME comments without tickets
+- [ ] Documentation updated for public APIs
+- [ ] No scope creep - focused on specific change
+
+### Performance Checklist
+- [ ] No N+1 query patterns
+- [ ] Appropriate indexing for queries
+- [ ] Efficient algorithms (check Big O)
+- [ ] Proper connection pooling
+- [ ] Caching strategy implemented where appropriate
+- [ ] Resource cleanup (connections, files, memory)
+
+## Example Usage
+
+```
+Input: Review pull request #123 adding user authentication
+
+Workflow Execution:
+1. Context: New OAuth2 implementation for user login
+2. Architecture: Clean separation of auth logic, follows existing patterns
+3. Security: ✅ Tokens stored securely, ❌ Missing rate limiting
+4. Performance: ✅ Cached token validation
+5. Standards: ✅ Tests present, ❌ Missing API documentation
+
+Output:
+🔴 CRITICAL: Add rate limiting to prevent brute force attacks
+   File: src/auth/oauth.py:45
+   Fix: Implement token bucket rate limiter with Redis
+
+🟠 HIGH: Missing API documentation for new endpoints
+   File: src/api/auth.py:12-67
+   Fix: Add OpenAPI/Swagger documentation
+
+🟢 APPROVE with changes required
+```
+
+## Related Agents
+- **rex-code-reviewer** - Full agent with reasoning and adaptation
+- **thor-quality-assurance-guardian** - Quality standards enforcement
+- **luca-security-expert** - Deep security analysis
+- **baccio-tech-architect** - Architecture pattern validation
+- **dario-debugger** - Root cause analysis support
+
+## ISE Engineering Fundamentals Alignment
+- Every PR must be reviewed before merge
+- Improve code quality by identifying defects early
+- Foster learning through knowledge sharing
+- Build shared understanding of codebase
+- "Value quality and precision over completing fast"