diff --git a/docs/roadmap.md b/docs/roadmap.md index a580a6b34..9de244d10 100644 --- a/docs/roadmap.md +++ b/docs/roadmap.md @@ -7,7 +7,7 @@ Este documento consolida o planejamento estratégico e tático da plataforma MeA ## 📊 Sumário Executivo **Projeto**: MeAjudaAi - Plataforma de Conexão entre Clientes e Prestadores de Serviços -**Status Geral**: Fase 1 ✅ | Sprint 0-5.5 ✅ | Sprint 6 ✅ | Sprint 7 ✅ | Sprint 7.5 ✅ | Sprint 7.6 ✅ | Sprint 7.7 ✅ | Sprint 7.8 ✅ | Sprint 7.9 ✅ | Sprint 7.10 ✅ | Sprint 7.11 ✅ | Sprint 7.12 ✅ | Sprint 7.13 ✅ | Sprint 7.14 ✅ CONCLUÍDO | MVP Target: 31/Março/2026 +**Status Geral**: Fase 1 ✅ | Sprint 0-5.5 ✅ | Sprint 6 ✅ | Sprint 7-7.15 ✅ CONCLUÍDO | MVP Target: 31/Março/2026 **Cobertura de Testes**: Backend 90.56% | Frontend 30 testes bUnit **Stack**: .NET 10 LTS + Aspire 13 + PostgreSQL + Blazor WASM + MudBlazor 8.0 + Fluxor @@ -33,10 +33,12 @@ Este documento consolida o planejamento estratégico e tático da plataforma MeA - ✅ **16 Jan 2026**: Sprint 7.12 - Performance Optimizations (CONCLUÍDO - Virtualization, debounced search, memoization) - ✅ **16 Jan 2026**: Sprint 7.13 - Standardized Error Handling (CONCLUÍDO - Retry logic, correlation IDs, HTTP status mapping) - ✅ **16 Jan 2026**: Sprint 7.14 - Complete Localization (CONCLUÍDO - pt-BR/en-US, 140+ strings, culture switching) -- ⏳ **10 Jan - 24 Jan 2026**: Sprint 8 - Customer App (Web + Mobile) -- ⏳ **27 Jan - 14 Fev 2026**: Sprint 9 - BUFFER (Polishing, Risk Mitigation, Refactoring) -- 🎯 **31 de Março de 2026**: MVP Launch (Admin Portal + Customer App) -- 🔮 **Abril 2026+**: Fase 3 - Reviews, Assinaturas, Agendamentos +- ✅ **16 Jan 2026**: Sprint 7.15 - Package Updates & Resilience Migration (CONCLUÍDO - .NET 10.0.2, deprecated packages removed) +- ⏳ **17-21 Jan 2026**: Sprint 7.16 - Technical Debt Sprint (Keycloak automation, warnings, tests, records) +- ⏳ **22 Jan - 4 Fev 2026**: Sprint 8 - Customer App (Web + Mobile) +- ⏳ **5-14 Fev 2026**: Sprint 9 - BUFFER (Polishing, Risk Mitigation, Final Testing) +- 🎯 **17 Fevereiro 2026**: MVP Launch (Admin Portal + Customer App) +- 🔮 **Fevereiro 2026+**: Fase 3 - Reviews, Assinaturas, Agendamentos ## ⚠️ Notas de Risco @@ -907,6 +909,382 @@ if (result.IsFailure) { --- +### ✅ Sprint 7.15 - Package Updates & Resilience Migration (16 Jan 2026) + +**Status**: CONCLUÍDA (16 Jan 2026) +**Duração**: 1 dia +**Commits**: b370b328, 949b6d3c + +**Contexto**: Atualização de rotina de pacotes NuGet revelou deprecação do Polly.Extensions.Http, necessitando migração para Microsoft.Extensions.Http.Resilience (nova API oficial do .NET 10). + +#### 📦 Atualizações de Pacotes (39 packages) + +**ASP.NET Core 10.0.2**: +- Microsoft.AspNetCore.Authentication.JwtBearer +- Microsoft.AspNetCore.OpenApi +- Microsoft.AspNetCore.TestHost +- Microsoft.AspNetCore.Components.WebAssembly +- Microsoft.AspNetCore.Components.WebAssembly.Authentication +- Microsoft.AspNetCore.Components.WebAssembly.DevServer +- Microsoft.Extensions.Http (10.2.0) +- Microsoft.Extensions.Http.Resilience (10.2.0) - **NOVO** + +**Entity Framework Core 10.0.2**: +- Microsoft.EntityFrameworkCore +- Microsoft.EntityFrameworkCore.Design +- Microsoft.EntityFrameworkCore.InMemory +- Microsoft.EntityFrameworkCore.Relational +- Npgsql.EntityFrameworkCore.PostgreSQL (10.0.0) + +**Ferramentas Build (18.0.2)** - Breaking Change: +- Microsoft.Build (17.14.28 → 18.0.2) +- Microsoft.Build.Framework (requerido por EF Core Design 10.0.2) +- Microsoft.Build.Locator +- Microsoft.Build.Tasks.Core +- Microsoft.Build.Utilities.Core +- **Resolução**: Removido pin CVE (CVE-2024-38095 corrigido na 18.0+) + +**Azure Storage 12.27.0**: +- Azure.Storage.Blobs (12.27.0) +- Azure.Storage.Common (12.25.0 → 12.26.0 - conflito resolvido) + +**Outras Atualizações**: +- System.IO.Hashing (9.0.10 → 10.0.1) +- Microsoft.CodeAnalysis.Analyzers (3.11.0 → 3.14.0) +- Refit (9.0.2 → 9.1.2) +- AngleSharp, AngleSharp.Css (1.2.0 → 1.3.0) +- ... (total 39 packages) + +**Decisão Microsoft.OpenApi**: +- Testado 3.1.3: **INCOMPATÍVEL** (CS0200 com source generators .NET 10) +- Mantido 2.3.0: **ESTÁVEL** (funciona perfeitamente) +- Confirmado 16/01/2026 com SDK 10.0.102 + +#### 🔄 Migração Polly.Extensions.Http → Microsoft.Extensions.Http.Resilience + +**Pacote Removido**: +```xml + + +``` + +**Novo Pacote**: +```xml + +``` + +**Refatoração de Código**: + +1. **`PollyPolicies.cs` → `ResiliencePolicies.cs`** (renomeado): + ```csharp + // ANTES (Polly.Extensions.Http) + public static IAsyncPolicy GetRetryPolicy() + { + return HttpPolicyExtensions + .HandleTransientHttpError() + .WaitAndRetryAsync(3, retryAttempt => + TimeSpan.FromSeconds(Math.Pow(2, retryAttempt))); + } + + // DEPOIS (Microsoft.Extensions.Http.Resilience) + public static void ConfigureRetry(HttpRetryStrategyOptions options) + { + options.MaxRetryAttempts = 3; + options.Delay = TimeSpan.FromSeconds(2); + options.BackoffType = DelayBackoffType.Exponential; + options.ShouldHandle = new PredicateBuilder() + .HandleResult(response => + response.StatusCode >= HttpStatusCode.InternalServerError || + response.StatusCode == HttpStatusCode.RequestTimeout); + } + ``` + +2. **`ServiceCollectionExtensions.cs`**: + ```csharp + // ANTES + client.AddPolicyHandler(PollyPolicies.GetRetryPolicy()) + .AddPolicyHandler(PollyPolicies.GetCircuitBreakerPolicy()) + .AddPolicyHandler(PollyPolicies.GetTimeoutPolicy()); + + // DEPOIS + client.AddStandardResilienceHandler(options => + { + ResiliencePolicies.ConfigureRetry(options.Retry); + ResiliencePolicies.ConfigureCircuitBreaker(options.CircuitBreaker); + ResiliencePolicies.ConfigureTimeout(options.TotalRequestTimeout); + }); + + // Upload timeout separado (sem retry) + client.AddStandardResilienceHandler(options => + { + options.Retry.MaxRetryAttempts = 0; // Disable retry for uploads + ResiliencePolicies.ConfigureUploadTimeout(options.TotalRequestTimeout); + }); + ``` + +**Políticas Configuradas**: +- **Retry**: 3 tentativas, backoff exponencial (2s, 4s, 8s) +- **Circuit Breaker**: 50% failure ratio, 5 throughput mínimo, 30s break duration +- **Timeout**: 30s padrão, 120s para uploads + +**Arquivos Impactados**: +- `Directory.Packages.props` (remoção + adição de pacote) +- `src/MeAjudaAi.Web.Admin/Infrastructure/Http/ResiliencePolicies.cs` (renomeado e refatorado) +- `src/MeAjudaAi.Web.Admin/Infrastructure/Extensions/ServiceCollectionExtensions.cs` (nova API) + +#### ✅ Resultados + +**Build Status**: +- ✅ 0 erros de compilação +- ✅ 10 warnings pré-existentes (analyzers - não relacionados) +- ✅ Todos os 1245 testes passando + +**Comportamento Mantido**: +- ✅ Retry logic idêntico +- ✅ Circuit breaker configuração equivalente +- ✅ Timeouts diferenciados (standard vs upload) +- ✅ HTTP resilience sem quebras + +**Compatibilidade**: +- ✅ .NET 10.0.2 LTS (suporte até Nov 2028) +- ✅ EF Core 10.0.2 +- ✅ Microsoft.Build 18.0.2 (última stable) +- ✅ Npgsql 10.x + Hangfire.PostgreSql 1.20.13 + +**Technical Debt Removido**: +- ✅ Deprecated package eliminado (Polly.Extensions.Http) +- ✅ Migração para API oficial Microsoft (.NET 10) +- ✅ CVE pin removido (Microsoft.Build CVE-2024-38095) + +**Lições Aprendidas**: +- Microsoft.OpenApi 3.1.3 incompatível com source generators .NET 10 (CS0200 read-only property) +- Microsoft.Build breaking change (17.x → 18.x) necessário para EF Core Design 10.0.2 +- AddStandardResilienceHandler simplifica configuração (3 chamadas → 1 com options) +- Upload timeout requer retry desabilitado (MaxRetryAttempts = 0) + +**Commits**: +- `b370b328`: "chore: update 39 nuget packages to latest stable versions" +- `949b6d3c`: "refactor: migrate from Polly.Extensions.Http to Microsoft.Extensions.Http.Resilience" + +--- + +### ⏳ Sprint 7.16 - Technical Debt Sprint (17-21 Jan 2026) + +**Status**: ⏳ EM ANDAMENTO (17 Jan 2026) +**Duração**: 1 semana (5 dias úteis) +**Objetivo**: Reduzir débito técnico ANTES de iniciar Customer App + +**Justificativa**: +- Customer App adicionará ~5000+ linhas de código novo +- Melhor resolver débitos do Admin Portal ANTES de replicar patterns +- Keycloak automation é BLOQUEADOR para Customer App (precisa de novo cliente OIDC) +- Quality improvements estabelecem padrões para Customer App + +--- + +#### 📋 Tarefas Planejadas + +##### 1. 🔐 Keycloak Client Automation (Dia 1-2, ~1 dia) - **BLOQUEADOR** + +**Prioridade**: CRÍTICA - Customer App precisa de cliente OIDC "meajudaai-customer" + +**Entregáveis**: +- [ ] Script `infrastructure/keycloak/setup-keycloak-clients.ps1` + * Valida Keycloak rodando (HTTP health check) + * Obtém token admin via REST API + * Cria realm "MeAjudaAi" (se não existir) + * Cria clientes "meajudaai-admin" e "meajudaai-customer" (OIDC, PKCE) + * Configura Redirect URIs (localhost + produção) + * Cria roles "admin", "customer" + * Cria usuários demo (admin@meajudaai.com.br, customer@meajudaai.com.br) + * Exibe resumo de configuração +- [ ] Atualizar `docs/keycloak-admin-portal-setup.md` com seção "Automated Setup" +- [ ] Integrar script em `scripts/dev.ps1` (opcional - chamar setup-keycloak-clients.ps1) + +**API Keycloak Admin REST**: +- Endpoint: `POST /auth/admin/realms/{realm}/clients` +- Autenticação: Bearer token + +**Benefícios**: +- ✅ Customer App pronto para desenvolvimento (cliente configurado) +- ✅ Onboarding em 1 comando: `.\setup-keycloak-clients.ps1` +- ✅ Elimina 15 passos manuais documentados + +--- + +##### 2. 🎨 Frontend Analyzer Warnings (Dia 2-3, ~1 dia) + +**Prioridade**: ALTA - Code quality antes de expandir codebase + +**Warnings a Resolver**: + +**S2094 - Empty Records (6 ocorrências)**: +```csharp +// ANTES +public sealed record LoadProvidersAction { } + +// DEPOIS - Opção 1: Adicionar propriedade útil +public sealed record LoadProvidersAction +{ + public bool ForceRefresh { get; init; } +} + +// DEPOIS - Opção 2: Justificar supressão +#pragma warning disable S2094 // Empty action by design (Redux pattern) +public sealed record LoadProvidersAction { } +#pragma warning restore S2094 +``` + +**S2953 - Dispose Pattern (1 ocorrência)**: +```csharp +// ANTES: App.razor +public void Dispose() { ... } + +// DEPOIS +public class App : IDisposable +{ + public void Dispose() { ... } +} +``` + +**S2933 - Readonly Fields (1 ocorrência)**: +```csharp +// ANTES +private MudTheme _theme = new(); + +// DEPOIS +private readonly MudTheme _theme = new(); +``` + +**MUD0002 - Casing (3 ocorrências)**: +```razor + + + + + +``` + +**Entregáveis**: +- [ ] Resolver todos os 11 warnings (ou justificar supressões) +- [ ] Remover regras do `.editorconfig` após correção +- [ ] Build com **0 warnings** + +--- + +##### 3. 📊 Frontend Test Coverage (Dia 3-5, ~1-2 dias) + +**Prioridade**: ALTA - Confiança em Admin Portal antes de Customer App + +**Meta**: 10 → 30-40 testes bUnit + +**Testes Novos (20-30 testes)**: + +**Fluxor State Management (8 testes)**: +- `ProvidersReducers`: LoadSuccess, LoadFailure, SetFilters, SetSorting +- `DocumentsReducers`: UploadSuccess, VerificationUpdate +- `ServiceCatalogsReducers`: CreateSuccess, UpdateSuccess + +**Components (12 testes)**: +- `Providers.razor`: rendering, search, pagination (3 testes) +- `Documents.razor`: upload workflow, verification (3 testes) +- `CreateProviderDialog`: form validation, submit (2 testes) +- `EditProviderDialog`: data binding, update (2 testes) +- `LanguageSwitcher`: culture change, persistence (2 testes) + +**Services (5 testes)**: +- `LocalizationService`: SetCulture, GetString, fallback +- `ErrorHandlingService`: retry logic, status mapping + +**Effects (3 testes)**: +- Mock `IProvidersApi.GetPagedProvidersAsync` +- Verificar dispatches Success/Failure +- Testar error handling + +**Infraestrutura**: +- Criar `TestContext` base reutilizável +- Configurar `JSRuntimeMode.Loose` +- Registrar `MudServices` e `Fluxor` + +**Entregáveis**: +- [ ] 30-40 testes bUnit (3x aumento) +- [ ] Cobertura ~40-50% de componentes críticos +- [ ] CI/CD passing (master-ci-cd.yml) + +--- + +##### 4. 📝 Records Standardization (Dia 5, ~0.5 dia) + +**Prioridade**: MÉDIA - Padronização importante + +**Objetivo**: Padronizar uso de `record class` vs `record` vs `class` no projeto. + +**Auditoria**: +```powershell +# Buscar todos os records no projeto +Get-ChildItem -Recurse -Include *.cs | Select-String "record " +``` + +**Padrões a Estabelecer**: +- DTOs: `public record Dto` (imutável) +- Requests: `public sealed record Request` (imutável) +- Responses: `public sealed record Response` (imutável) +- Fluxor Actions: `public sealed record Action` (imutável) +- Fluxor State: `public sealed record State` (imutável) +- Entities: `public class ` (mutável, EF Core) + +**Entregáveis**: +- [ ] Documentar padrão em `docs/architecture.md` seção "C# Coding Standards" +- [ ] Converter records inconsistentes (se necessário) +- [ ] Adicionar analyzer rule para enforcement futuro + +--- + +##### 5. 🧪 SearchProviders E2E Tests (OPCIONAL - se tempo sobrar) + +**Prioridade**: MÉDIA - Pode ser movido para Sprint 9 (Buffer) + +**Objetivo**: Testar busca geolocalizada end-to-end. + +**Entregáveis**: +- [ ] Teste: Buscar providers por serviço + raio (2km, 5km, 10km) +- [ ] Teste: Validar ordenação por distância +- [ ] Teste: Validar restrição geográfica (AllowedCities) +- [ ] Teste: Performance (<500ms para 1000 providers) + +**Estimativa**: 1-2 dias (se sobrar tempo) + +--- + +#### 📊 Resultado Esperado Sprint 7.16 + +**Débito Técnico Reduzido**: +- ✅ Keycloak automation completo (bloqueador removido) +- ✅ 0 warnings no Admin Portal (S2094, S2953, S2933, MUD0002) +- ✅ 30-40 testes bUnit (confiança 3x maior) +- ✅ Records padronizados (consistência) +- ⚠️ SearchProviders E2E (se tempo permitir) + +**Quality Metrics**: +- **Build**: 0 errors, 0 warnings +- **Tests**: 1245 backend + 30-40 frontend = **1275-1285 testes** +- **Coverage**: Backend 90.56% | Frontend ~40-50% +- **Technical Debt**: Reduzido de 313 linhas → ~150 linhas + +**Pronto para Customer App**: +- ✅ Keycloak configurado (cliente meajudaai-customer) +- ✅ Admin Portal com qualidade máxima (patterns estabelecidos) +- ✅ Test infrastructure robusta (replicável no Customer App) +- ✅ Zero distrações (débito técnico minimizado) + +**Commits Estimados**: +- `feat(sprint-7.16): add Keycloak client automation script` +- `fix(sprint-7.16): resolve all frontend analyzer warnings` +- `test(sprint-7.16): increase bUnit coverage to 30-40 tests` +- `refactor(sprint-7.16): standardize record usage across project` + +--- + ### ⏭️ Part 13 - Unit Tests (Frontend) - BACKLOG **Status**: SKIPPED durante Parts 10-15 (escopo muito grande) @@ -1466,10 +1844,12 @@ Todas as tarefas planejadas já foram implementadas: **⏳ Fase 2: EM ANDAMENTO** (Janeiro–Março 2026) Frontend Blazor WASM + MAUI Hybrid: - Sprint 6: Blazor Admin Portal Setup - ✅ CONCLUÍDO (5 Jan 2026) - [Ver conquistas detalhadas](#-sprint-6---blazor-admin-portal-setup---concluída-30-dez-2025---5-jan-2026) -- Sprint 7: Blazor Admin Portal Features (6-24 Jan 2026) - 🔄 PRÓXIMA -- Sprint 8: Customer App (Fev-Mar 2026) - ⏳ Aguardando Sprint 7 -- Sprint 9: Buffer/Polishing (Mar 2026) - ⏳ Aguardando Sprint 7-8 -- MVP Final: 31 de Março de 2026 +- Sprint 7: Blazor Admin Portal Features (6-24 Jan 2026) - ✅ CONCLUÍDO +- Sprint 7.16: Technical Debt Sprint (17-21 Jan 2026) - ⏳ EM ANDAMENTO +- Sprint 8: Customer App (22 Jan - 4 Fev 2026) - ⏳ Planejado +- Sprint 9: Buffer/Polishing (5-14 Fev 2026) - ⏳ Planejado +- MVP Final: 17 de Fevereiro de 2026 +- _Nota: Data de MVP atualizada de 31 de Março para 17 de Fevereiro de 2026 após otimizações de Sprint 7 (Parts 10-15) e redução de débito técnico em Sprint 7.16_ **⚠️ Risk Assessment**: Estimativas assumem velocidade consistente. Primeiro projeto Blazor WASM pode revelar complexidades não previstas (integração Keycloak, curva de aprendizado MudBlazor). Sprint 9 reservado como buffer de contingência. @@ -1502,14 +1882,16 @@ A implementação segue os princípios arquiteturais definidos em `architecture. | **Sprint 5** | - | Sprints 3-4 | Quality Improvements | ✅ CONCLUÍDO ANTECIPADAMENTE | | **Sprint 5.5** | 2 semanas | 19 Dez - 31 Dez | Refactor & Cleanup (Technical Debt) | ✅ CONCLUÍDO (30 Dez 2025) | | **Sprint 6** | 1 semana | 30 Dez - 5 Jan | Blazor Admin Portal - Setup & Core | ✅ CONCLUÍDO (5 Jan 2026) | -| **Sprint 7** | 3 semanas | 6 - 24 Jan | Blazor Admin Portal - Features | 🔄 PRÓXIMA | -| **Sprint 8** | 3 semanas | 27 Jan - 14 Fev | Blazor Customer App (Web + Mobile) | ⏳ Planejado | -| **Sprint 9** | 3 semanas | 17 Fev - 7 Mar | **BUFFER: Polishing, Refactoring & Risk Mitigation** | ⏳ Planejado | -| **MVP Launch** | - | Mar 31 | Final deployment & launch preparation | 🎯 Target | +| **Sprint 7** | 3 semanas | 6 - 24 Jan | Blazor Admin Portal - Features | ✅ CONCLUÍDO | +| **Sprint 7.16** | 1 semana | 17-21 Jan | Technical Debt Sprint | ⏳ EM ANDAMENTO | +| **Sprint 8** | 2 semanas | 22 Jan - 4 Fev | Blazor Customer App (Web + Mobile) | ⏳ Planejado | +| **Sprint 9** | 10 dias | 5-14 Fev | **BUFFER: Polishing, Refactoring & Risk Mitigation** | ⏳ Planejado | +| **MVP Launch** | - | 17 Fev | Final deployment & launch preparation | 🎯 Target | -**MVP Launch Target**: 31 de Março de 2026 🎯 +**MVP Launch Target**: 17 de Fevereiro de 2026 🎯 +_Atualizado de 31 de Março após otimizações de Sprint 7 (Parts 10-15) e redução de débito técnico em Sprint 7.16_ -**Post-MVP (Fase 3+)**: Reviews, Assinaturas, Agendamentos (Abril 2026+) +**Post-MVP (Fase 3+)**: Reviews, Assinaturas, Agendamentos (Fevereiro 2026+) --- @@ -2168,7 +2550,7 @@ Para receber notificações quando novas versões estáveis forem lançadas, con - **Risco**: Breaking changes em Npgsql 10.x não validados pelo mantenedor - **Mitigação Atual**: Testes de integração (marcados como Skip no CI/CD) - **Monitoramento**: - - GitHub Issues: + - GitHub Issues: [Hangfire.PostgreSql Issues](https://github.com/frankhommers/Hangfire.PostgreSql/issues) - Alternativas: Hangfire.Pro.Redis (pago), Hangfire.SqlServer (outro DB) - **Prazo**: Validar localmente ANTES de deploy para produção @@ -3442,23 +3824,19 @@ public class GeographicRestrictionMiddleware --- -### 📅 Sprint 8: Blazor Customer App (Web + Mobile) (3 semanas) ⏳ ATUALIZADO +### 📅 Sprint 8: Customer App (Web + Mobile) (2 semanas) ⏳ ATUALIZADO -**Status**: 📋 PLANEJADO PARA Q1 2026 -**Dependências**: Sprint 3 (Admin Portal) deve estar completo -**Estimativa de início**: Fevereiro 2026 +**Status**: 📋 PLANEJADO PARA 22 Jan - 4 Fev 2026 +**Dependências**: Sprint 7.16 concluído ✅ +**Duração**: 2 semanas (foco 100% em Customer App) -**Objetivos**: -- App para clientes (web + mobile) -- Busca de prestadores -- Gestão de perfil -- Histórico de interações +**Contexto**: Sprint 7.16 removeu débitos técnicos e bloqueadores (Keycloak automation, warnings, tests, records). Sprint 8 pode focar 100% em Customer App com base sólida estabelecida. -**Funcionalidades**: +--- -#### 1. Blazor WASM (Web) - Semana 1-2 +#### 📱 Customer App Development -**Home & Busca**: +**Home & Busca** (Semana 1): - [ ] **Landing Page**: Hero section + busca rápida - [ ] **Busca Geolocalizada**: Campo de endereço/CEP + raio + serviços - [ ] **Mapa Interativo**: Exibir prestadores no mapa (Leaflet.Blazor) @@ -3466,30 +3844,24 @@ public class GeographicRestrictionMiddleware - [ ] **Filtros**: Rating mínimo, tier, disponibilidade - [ ] **Ordenação**: Distância, Rating, Tier -**Perfil de Prestador**: +**Perfil de Prestador** (Semana 1-2): - [ ] **Visualização**: Foto, nome, descrição, serviços, rating, reviews - [ ] **Contato**: Botão WhatsApp, telefone, email (MVP: links externos) - [ ] **Galeria**: Fotos do trabalho (se disponível) - [ ] **Reviews**: Listar avaliações de outros clientes (read-only, write em Fase 3) -**Meu Perfil**: +**Meu Perfil** (Semana 2): - [ ] **Editar**: Nome, foto, telefone, endereço - [ ] **Histórico**: Prestadores contatados (tracking básico) - [ ] **Configurações**: Preferências de notificações (stub para futuro) -#### 2. MAUI Blazor Hybrid (Mobile) - Semana 3 - -**Diferenças do Web**: +**MAUI Blazor Hybrid (Mobile)** (Semana 3): - [ ] **Geolocalização Nativa**: Usar GPS do device para busca automática - [ ] **Câmera**: Permitir upload de foto de perfil via câmera - [ ] **Notificações Push**: Stub para futuro (ex: prestador aceitou contato) - [ ] **Deep Linking**: Abrir prestador via link compartilhado - [ ] **Offline Mode**: Cache de última busca realizada - -**Compartilhamento de Código**: -- [ ] Razor Components compartilhados entre Web e Mobile -- [ ] Services layer compartilhado (ISearchService, IProviderService) -- [ ] DTOs e Validators compartilhados via Shared.DTOs +- [ ] **Compartilhamento de Código**: 70%+ Razor Components compartilhados entre Web e Mobile **Tecnologias Mobile**: - **Framework**: .NET MAUI 10 + Blazor Hybrid @@ -3497,11 +3869,20 @@ public class GeographicRestrictionMiddleware - **Maps**: MAUI Community Toolkit Maps - **Storage**: Preferences API + Secure Storage -**Resultado Esperado**: +--- + +#### � Resultado Esperado Sprint 8 + - ✅ Customer App (Web) publicado - ✅ Customer App (Mobile) disponível em TestFlight (iOS) e Google Play Beta (Android) - ✅ 70%+ código compartilhado entre Web e Mobile - ✅ UX otimizada para mobile (gestures, navegação nativa) +- ✅ Autenticação Keycloak OIDC (cliente meajudaai-customer configurado em Sprint 7.16) +- ✅ 20+ testes bUnit para Customer App (patterns de Sprint 7.16) + +**Timeline**: +- **Semana 1** (22-29 Jan): Home + Busca Geolocalizada + Perfil Prestador +- **Semana 2** (29 Jan - 4 Fev): Meu Perfil + MAUI Mobile + Deployment --- @@ -3532,14 +3913,15 @@ Tarefas técnicas que devem ser aplicadas em todos os módulos para consistênci ```csharp private static void EnsureDatabaseMigrations(WebApplication app) { - // Pular em ambientes de teste - if (app.Environment.IsEnvironment("Test") || app.Environment.IsEnvironment("Testing")) - { - return; - } - - // Controle via variável de ambiente - var applyMigrations = Environment.GetEnvironmentVariable("APPLY_MIGRATIONS"); + Keycloak client automation script (setup em 1 comando) - **DAY 1** +- ✅ 0 analyzer warnings no Admin Portal (S2094, S2953, S2933, MUD0002 resolvidos) +- ✅ 30-40 testes bUnit (10 → 30+, +200% cobertura) + +**Timeline**: +- **Dia 1** (17 Jan): Keycloak automation script - **CRITICAL PATH** +- **Semana 1** (17-24 Jan): Customer App Home + Busca + Warnings fix +- **Semana 2** (24-31 Jan): Customer App Perfil + Mobile + Testes +- **Semana 3** (31 Jan): PolishingVariable("APPLY_MIGRATIONS"); if (!string.IsNullOrEmpty(applyMigrations) && bool.TryParse(applyMigrations, out var shouldApply) && !shouldApply) { @@ -3755,7 +4137,7 @@ Durante o processo de atualização automática de dependências pelo Dependabot - ✅ Segurança e performance hardened - ✅ Documentação completa para usuários e desenvolvedores - ✅ Monitoring e observabilidade configurados -- 🎯 **PRONTO PARA LAUNCH EM 31 DE MARÇO DE 2026** +- 🎯 **PRONTO PARA LAUNCH EM 17 DE FEVEREIRO DE 2026** > **⚠️ CRITICAL**: Se Sprint 9 não for suficiente para completar todos os itens, considerar delay do MVP launch ou reduzir escopo (mover features não-críticas para post-MVP). A qualidade e estabilidade do MVP são mais importantes que a data de lançamento. diff --git a/docs/technical-debt.md b/docs/technical-debt.md index 3565d06e0..8cec9c1f5 100644 --- a/docs/technical-debt.md +++ b/docs/technical-debt.md @@ -4,72 +4,17 @@ Este documento rastreia **apenas débitos técnicos PENDENTES**. Itens resolvido --- -## ✅ Melhorias Recentes (Sprint 7.6 - Jan 2026) - -### ⚡ Otimização de Desempenho de Testes de Integração - CONCLUÍDA - -**Sprint**: Sprint 7.6 (12 Jan 2026) -**Severidade**: ALTA (bloqueava testes em CI/CD) -**Status**: ✅ RESOLVIDO - -**Problema Identificado**: -- ❌ Testes de integração aplicavam migrations de TODOS os 6 módulos para CADA teste -- ❌ Timeout frequente (~60-70s de inicialização, vs esperado ~10-15s) -- ❌ PostgreSQL pool exhaustion (erro `57P01: terminating connection due to administrator command`) -- ❌ Teste `DocumentRepository_ShouldBeRegisteredInDI` falhava na branch fix/aspire-initialization -- ❌ Race conditions causavam falhas intermitentes sem mudança de código - -**Solução Implementada**: -- ✅ **TestModule enum com Flags**: Permite especificar quais módulos cada teste precisa -- ✅ **RequiredModules property**: Override virtual para declarar dependências por teste -- ✅ **ApplyRequiredModuleMigrationsAsync**: Aplica migrations apenas dos módulos necessários -- ✅ **EnsureCleanDatabaseAsync**: Extraído para melhor reusabilidade -- ✅ **Backward compatible**: Default RequiredModules = TestModule.All - -**Resultados Alcançados**: -- ✅ **Desempenho**: 83% faster para testes single-module (10s vs 60s) -- ✅ **Confiabilidade**: Eliminou timeouts e errors 57P01 -- ✅ **Isolamento**: Cada teste carrega apenas módulos necessários -- ✅ **26 test classes otimizados**: Users (4), Providers (5), Documents (4), ServiceCatalogs (7), Locations (5), SearchProviders (1) -- ✅ **Test Results**: DocumentRepository_ShouldBeRegisteredInDI agora PASSA em 10s -- ✅ **Code Quality**: Método legado marcado como [Obsolete], testes renomeados, terminologia em português - -**Arquivos Modificados**: -- `tests/MeAjudaAi.Integration.Tests/Base/BaseApiTest.cs`: Refactoring completo com TestModule pattern + [Obsolete] em método legado -- `tests/MeAjudaAi.Integration.Tests/README.md`: Guia de uso com terminologia em português (Desempenho) -- 26 test classes com `RequiredModules` override -- `AllowedCityExceptionHandlingTests.cs`: Testes renomeados para refletir comportamento real - -**Documentação Atualizada**: -- ✅ [tests/README.md](../tests/MeAjudaAi.Integration.Tests/README.md): Guia de otimização de desempenho -- ✅ [docs/architecture.md](architecture.md#integration-test-infrastructure): Testing architecture -- ✅ [docs/development.md](development.md#testes-de-integração): Developer guide -- ✅ [docs/roadmap.md](roadmap.md#sprint-76): Sprint 7.6 implementation details - -**Metrics**: - -| Cenário | Antes | Depois | Improvement | -|---------|-------|--------|-------------| -| Inicialização | ~60-70s | ~10-15s | **83% faster** ⚡ | -| Migrations aplicadas | 6 módulos | Apenas necessárias | Mínimo | -| Timeouts | Frequentes | Eliminados | ✅ | - -**Sprint Completion**: 12 Janeiro 2026 -**Issue**: fix/aspire-initialization (continuação) +## 🆕 Sprint 6-7 - Débitos Técnicos ---- - -## 🆕 Sprint 6 - Débitos Técnicos (BAIXA PRIORIDADE) - -**Sprint**: Sprint 6 Concluída (30 Dez 2025 - 5 Jan 2026) -**Status**: Itens de baixa prioridade, não bloqueiam Sprint 7 +**Sprint**: Sprint 6-7 (30 Dez 2025 - 16 Jan 2026) +**Status**: Itens de baixa a média prioridade ### 🎨 Frontend - Warnings de Analyzers (BAIXA) **Severidade**: BAIXA (code quality) -**Sprint**: BACKLOG (não afeta funcionalidade) +**Sprint**: Sprint 7.16 (planejado) -**Descrição**: Build do Admin Portal gera 10 warnings de analyzers (SonarLint + MudBlazor): +**Descrição**: Build do Admin Portal gera warnings de analyzers (SonarLint + MudBlazor): **Warnings SonarLint**: 1. **S2094** (6 ocorrências): Empty records em Actions @@ -90,12 +35,6 @@ Este documento rastreia **apenas débitos técnicos PENDENTES**. Itens resolvido - `Direction` → `direction` (lowercase) - **Recomendação**: Atualizar para lowercase conforme padrão HTML -**Ações Recomendadas** (Sprint 7): -- [ ] Converter Actions vazias para interfaces (ThemeActions, DashboardActions) -- [ ] Corrigir Dispose() em App.razor (implementar IDisposable ou renomear) -- [ ] Adicionar readonly em _theme (App.razor) -- [ ] Corrigir casing de atributos MudBlazor (MainLayout.razor) - **Impacto**: Nenhum - build continua 100% funcional --- @@ -103,26 +42,14 @@ Este documento rastreia **apenas débitos técnicos PENDENTES**. Itens resolvido ### 📊 Frontend - Cobertura de Testes (MÉDIA) **Severidade**: MÉDIA (quality assurance) -**Sprint**: Sprint 7 (aumentar cobertura) +**Sprint**: Sprint 7.16 (aumentar cobertura) **Descrição**: Admin Portal tem apenas 10 testes bUnit criados. Coverage atual é baixo para produção. **Testes Existentes**: -1. **ProvidersPageTests** (4 testes): - - Dispatch LoadProvidersAction - - Loading state display - - Error message display - - Data grid rendering - -2. **DashboardPageTests** (4 testes): - - Dispatch LoadDashboardStatsAction - - Loading state display - - KPI values display - - Error message display - -3. **DarkModeToggleTests** (2 testes): - - Toggle dark mode action - - Initial state rendering +1. **ProvidersPageTests** (4 testes) +2. **DashboardPageTests** (4 testes) +3. **DarkModeToggleTests** (2 testes) **Gaps de Cobertura**: - ❌ **Authentication flows**: Login/Logout/Callbacks não testados @@ -131,13 +58,12 @@ Este documento rastreia **apenas débitos técnicos PENDENTES**. Itens resolvido - ❌ **MudBlazor interactions**: Clicks, inputs não validados - ❌ **Fluxor Effects**: Chamadas API não mockadas completamente -**Ações Recomendadas** (Sprint 7): -- [ ] Criar 10+ testes adicionais (meta: 30 testes totais) -- [ ] Testar fluxos de autenticação (Authentication.razor) -- [ ] Testar paginação (GoToPageAction com diferentes páginas) -- [ ] Testar interações MudBlazor (button clicks, input changes) -- [ ] Aumentar coverage de error scenarios (API failures, network errors) -- [ ] Documentar patterns de teste em `docs/testing/bunit-patterns.md` +**Ações Recomendadas** (Sprint 7.16): +- [ ] Criar 20+ testes adicionais (meta: 30-40 testes totais) +- [ ] Testar fluxos de autenticação +- [ ] Testar paginação +- [ ] Testar interações MudBlazor +- [ ] Aumentar coverage de error scenarios **Meta de Coverage**: 70-85% (padrão indústria para frontend) @@ -146,14 +72,12 @@ Este documento rastreia **apenas débitos técnicos PENDENTES**. Itens resolvido ### 🔐 Keycloak Client - Configuração Manual (MÉDIA) **Severidade**: MÉDIA (developer experience) -**Sprint**: Sprint 7 (automação desejável) +**Sprint**: Sprint 7.16 (automação desejável) **Descrição**: Client `admin-portal` precisa ser criado MANUALMENTE no Keycloak realm `meajudaai`. **Situação Atual**: - ✅ Documentação completa: `docs/keycloak-admin-portal-setup.md` -- ✅ Passos detalhados (General Settings, Capability config, Login settings) -- ✅ Exemplo de usuário admin de teste - ❌ Processo manual (8-10 passos via Admin Console) **Problemas**: @@ -161,578 +85,149 @@ Este documento rastreia **apenas débitos técnicos PENDENTES**. Itens resolvido 2. **Erro humano**: Fácil esquecer redirect URIs ou roles 3. **Reprodutibilidade**: Ambiente local pode divergir de dev/staging -**Ações Recomendadas** (Sprint 7): +**Ações Recomendadas** (Sprint 7.16): - [ ] Criar script de automação: `scripts/setup-keycloak-clients.ps1` - [ ] Usar Keycloak Admin REST API para criar client programaticamente - [ ] Integrar script em `dotnet run --project src/Aspire/MeAjudaAi.AppHost` -- [ ] Adicionar validação: verificar se client já existe antes de criar -- [ ] Documentar script em `docs/keycloak-admin-portal-setup.md` - -**Referências**: -- Keycloak Admin REST API: -- Client Representation: **Impacto**: Developer experience - não bloqueia produção --- -## 🔄 Sprint 5.5 - Itens Pendentes (BACKLOG) +## 🔄 Refatorações de Código (BACKLOG) -**Branch**: `feature/refactor-and-cleanup` -**Status**: Itens de baixa prioridade, não críticos para MVP +**Status**: Baixa prioridade, não críticos para MVP -### 🏗️ Refatoração MeAjudaAi.Shared.Messaging - Restante (BACKLOG) +### 🏗️ Refatoração MeAjudaAi.Shared.Messaging (BACKLOG) **Severidade**: BAIXA (manutenibilidade) -**Sprint**: BACKLOG (não crítico para MVP) - -**Descrição**: Continuar refatoração iniciada em 19/Dez/2025. Itens abaixo são melhorias adicionais, não bloqueiam desenvolvimento do frontend. +**Sprint**: BACKLOG **Problemas Remanescentes**: +- `RabbitMqInfrastructureManager.cs` não possui interface separada `IRabbitMqInfrastructureManager` (avaliar necessidade) +- Integration Events ausentes: Documents, SearchProviders, ServiceCatalogs não possuem integration events +- Faltam event handlers para comunicação entre módulos -1. **Arquivos com múltiplas classes** (restantes): - - ~~`DeadLetterServiceFactory.cs` contém: `NoOpDeadLetterService`, `IDeadLetterServiceFactory`, `EnvironmentBasedDeadLetterServiceFactory`~~ ✅ **RESOLVIDO** (19 Dez 2025) - - ~~`IDeadLetterService.cs` contém: `DeadLetterStatistics`, `FailureRate`~~ ✅ **RESOLVIDO** (19 Dez 2025) - - ~~`MessageRetryMiddleware.cs` contém: `IMessageRetryMiddlewareFactory`, `MessageRetryMiddlewareFactory`, `MessageRetryExtensions`~~ ✅ **RESOLVIDO** (19 Dez 2025) - - ✅ **Factories organizados em pasta dedicada** (`Messaging/Factories/`) - - ✅ `IMessageBusFactory.cs` + `MessageBusFactory.cs` separados - - ✅ `IDeadLetterServiceFactory.cs` + `DeadLetterServiceFactory.cs` separados - - `RabbitMqInfrastructureManager.cs` não possui interface separada `IRabbitMqInfrastructureManager` (avaliar necessidade) - -2. **Inconsistência de nomenclatura** (se aplicável): - - ~~Arquivo `DeadLetterServiceFactory.cs`, mas classe principal é `EnvironmentBasedDeadLetterServiceFactory`~~ ✅ **RESOLVIDO** (19 Dez 2025) - - Arquivo `MessageBusFactory.cs` - verificar se precisa renomear - -3. **Integration Events ausentes**: - - Documents, SearchProviders, ServiceCatalogs não possuem integration events em Messages/ - - Faltam event handlers para comunicação entre módulos - -**Ações de Refatoração** (BACKLOG - não crítico): -- [x] ~~Separar `NoOpDeadLetterService` em arquivo próprio: `NoOpDeadLetterService.cs`~~ ✅ CONCLUÍDO (19 Dez 2025) -- [✓] ~~Extrair `IDeadLetterServiceFactory` para arquivo próprio~~ ✅ CONCLUÍDO (19 Dez 2025) - em `Messaging/Factories/IDeadLetterServiceFactory.cs` -- [✓] ~~Renomear `EnvironmentBasedDeadLetterServiceFactory` → `DeadLetterServiceFactory`~~ ✅ CONCLUÍDO (19 Dez 2025) -- [x] ~~Extrair `DeadLetterStatistics` para: `DeadLetterStatistics.cs`~~ ✅ CONCLUÍDO (19 Dez 2025) -- [x] ~~Extrair `FailureRate` para: `FailureRate.cs`~~ ✅ CONCLUÍDO (19 Dez 2025) -- [x] ~~Extrair `IMessageRetryMiddlewareFactory` para: `IMessageRetryMiddlewareFactory.cs`~~ ✅ CONCLUÍDO (19 Dez 2025) -- [x] ~~Extrair `MessageRetryMiddlewareFactory` para: `MessageRetryMiddlewareFactory.cs`~~ ✅ CONCLUÍDO (19 Dez 2025) -- [x] ~~Extrair `MessageRetryExtensions` para: `MessageRetryExtensions.cs`~~ ✅ CONCLUÍDO (19 Dez 2025) -- [x] ~~Criar `IMessageBusFactory.cs` separado e organizar factories em pasta dedicada~~ ✅ CONCLUÍDO (19 Dez 2025) - pasta `Messaging/Factories/` - +**Ações Pendentes**: - [ ] Avaliar necessidade de extrair `IRabbitMqInfrastructureManager` para arquivo separado -- [ ] Reorganizar estrutura de pastas em Messaging/ (sugestão abaixo) - se necessário -- [ ] Adicionar integration events para módulos faltantes - quando houver necessidade de comunicação inter-módulos -- [ ] Criar testes unitários para classes de messaging (>70% coverage) - se coverage cair abaixo do threshold - -**Estrutura Proposta** (após refatoração): -``` -src/Shared/Messaging/ -├── Abstractions/ -│ ├── IMessageBus.cs -│ ├── IMessageBusFactory.cs -│ ├── IDeadLetterService.cs -│ ├── IDeadLetterServiceFactory.cs -│ ├── IMessageRetryMiddlewareFactory.cs -│ └── IRabbitMqInfrastructureManager.cs -├── Factories/ -│ ├── IMessageBusFactory.cs -│ ├── MessageBusFactory.cs -│ ├── IDeadLetterServiceFactory.cs -│ ├── DeadLetterServiceFactory.cs -├── DeadLetter/ -│ ├── DeadLetterStatistics.cs -│ ├── FailureRate.cs -│ ├── DeadLetterOptions.cs -│ ├── NoOpDeadLetterService.cs -│ ├── DeadLetterServiceFactory.cs -│ ├── RabbitMqDeadLetterService.cs -│ └── ServiceBusDeadLetterService.cs -├── Handlers/ -│ ├── MessageRetryMiddleware.cs -│ ├── MessageRetryMiddlewareFactory.cs -│ └── MessageRetryExtensions.cs -├── RabbitMq/ -│ ├── RabbitMqMessageBus.cs -│ ├── RabbitMqInfrastructureManager.cs -│ └── RabbitMqOptions.cs -├── Options/ -│ ├── ServiceBusOptions.cs -│ ├── MessageBusOptions.cs -│ ├── RabbitMqOptions.cs -│ └── DeadLetterOptions.cs -├── Services/ -│ └── ServiceBusInitializationService.cs -├── ServiceBus/ -│ ├── ServiceBusMessageBus.cs -│ └── ServiceBusTopicManager.cs -├── Messages/ -│ ├── Documents/ -│ │ ├── DocumentUploadedIntegrationEvent.cs -│ │ └── DocumentVerifiedIntegrationEvent.cs -│ ├── Providers/ -│ ├── Users/ -│ └── ... -└── EventTypeRegistry.cs -``` +- [ ] Adicionar integration events para módulos faltantes (quando houver necessidade) +- [ ] Criar testes unitários para classes de messaging (se coverage cair abaixo do threshold) -**Prioridade**: MÉDIA -**Estimativa**: 8-10 horas -**Sprint**: Sprint 5.5 / BACKLOG (baixa prioridade, não crítico para MVP) -**Benefício**: Código mais organizado, manutenível e testável +**Prioridade**: BAIXA +**Estimativa**: 4-6 horas --- -#### 🔧 Refatoração Extensions (MeAjudaAi.Shared) (4-6h) +### 🔧 Refatoração Extensions (MeAjudaAi.Shared) -**Situação**: INCONSISTÊNCIA DE PADRÃO **Severidade**: BAIXA (manutenibilidade) -**Sprint**: Sprint 5.5 (feature/refactor-and-cleanup) - -**Problemas Identificados**: +**Sprint**: BACKLOG -1. **Extensions dentro de classes de implementação**: - - `BusinessMetricsMiddlewareExtensions` está dentro de `BusinessMetricsMiddleware.cs` - - Outros middlewares/serviços podem ter o mesmo padrão - -2. **Falta de consolidação**: - - Extensions espalhadas em múltiplos arquivos - - Dificulta descoberta de métodos de extensão disponíveis - - Falta padrão consistente com os módulos +**Problemas**: +1. **Extensions dentro de classes de implementação**: `BusinessMetricsMiddlewareExtensions` está dentro de `BusinessMetricsMiddleware.cs` +2. **Falta de consolidação**: Extensions espalhadas em múltiplos arquivos -**Ações de Refatoração**: +**Ações Pendentes**: - [ ] Extrair `BusinessMetricsMiddlewareExtensions` para arquivo próprio -- [ ] Criar arquivo `MonitoringExtensions.cs` consolidando todas extensions de Monitoring -- [ ] Criar arquivo `CachingExtensions.cs` consolidando todas extensions de Caching -- [ ] Criar arquivo `MessagingExtensions.cs` consolidando todas extensions de Messaging -- [ ] Criar arquivo `AuthorizationExtensions.cs` consolidando todas extensions de Authorization -- [ ] Revisar pasta `Extensions/` - manter apenas extensions gerais/cross-cutting +- [ ] Criar arquivos consolidados: `MonitoringExtensions.cs`, `CachingExtensions.cs`, `MessagingExtensions.cs`, `AuthorizationExtensions.cs` - [ ] Documentar padrão: cada funcionalidade tem seu `Extensions.cs` -- [ ] Aplicar padrão em todas as pastas do Shared - -**Estrutura Proposta** (após refatoração): -``` -src/Shared/ -├── Monitoring/ -│ ├── BusinessMetricsMiddleware.cs -│ ├── MetricsCollectorService.cs -│ └── MonitoringExtensions.cs ← NOVO (consolidado) -├── Caching/ -│ ├── HybridCacheService.cs -│ └── CachingExtensions.cs ← NOVO (consolidado) -├── Messaging/ -│ ├── ... (classes de messaging) -│ └── MessagingExtensions.cs ← NOVO (consolidado) -├── Authorization/ -│ ├── ... (classes de autorização) -│ └── AuthorizationExtensions.cs ← NOVO (consolidado) -└── Extensions/ - ├── ServiceCollectionExtensions.cs (gerais) - ├── ModuleServiceRegistrationExtensions.cs - └── ... (apenas extensions cross-cutting) -``` - -**Padrão de Nomenclatura**: -- Arquivo: `Extensions.cs` (e.g., `MonitoringExtensions.cs`) -- Classe: `public static class Extensions` -- Namespace: `MeAjudaAi.Shared.` **Prioridade**: BAIXA -**Estimativa**: 4-6 horas -**Benefício**: Código mais organizado e consistente com padrão dos módulos +**Estimativa**: 4-6 horas --- ## ⚠️ CRÍTICO: Hangfire + Npgsql 10.x Compatibility Risk **Arquivo**: `Directory.Packages.props` -**Linhas**: 45-103 -**Situação**: VALIDAÇÃO EM ANDAMENTO - BLOQUEIO DE DEPLOY -**Severidade**: ALTA -**Issue**: [Criar issue para rastreamento] +**Situação**: MONITORAMENTO CONTÍNUO +**Severidade**: MÉDIA (funciona em desenvolvimento, não validado em produção) +**Status**: Sistema rodando com Npgsql 10.0 + Hangfire.PostgreSql 1.20.13 **Descrição**: -Hangfire.PostgreSql 1.20.12 foi compilado contra Npgsql 6.x, mas o projeto está migrando para Npgsql 10.x, que introduz breaking changes. A compatibilidade em runtime não foi validada pelo mantenedor do Hangfire.PostgreSql. +Hangfire.PostgreSql 1.20.13 foi compilado contra Npgsql 6.x, mas o projeto está usando Npgsql 10.x (EF Core 10.0.2). A compatibilidade funciona em desenvolvimento mas não foi formalmente validada pelo mantenedor do Hangfire. -**Problema Identificado**: -- Npgsql 10.x introduz mudanças incompatíveis (breaking changes) -- Hangfire.PostgreSql 1.20.12 não foi testado oficialmente com Npgsql 10.x -- Risco de falhas em: persistência de jobs, serialização, conexão, corrupção de dados -- Deploy para produção está BLOQUEADO até validação completa +**Status Atual**: +- ✅ **Build**: Compila sem erros +- ✅ **Desenvolvimento**: Aplicação funciona normalmente +- ⚠️ **Produção**: Não validado com carga real **Mitigação Implementada**: -1. ✅ Documentação detalhada de estratégia de versões em `Directory.Packages.props` -2. ✅ Testes de integração removidos - monitoramento via health checks -3. ✅ CI/CD gating configurado (`.github/workflows/pr-validation.yml`) -4. ✅ Procedimentos de rollback documentados -5. ✅ Plano de monitoramento de produção definido - -**Validação Necessária ANTES de Deploy para Produção**: -- [ ] Todos os testes de integração Hangfire passando no CI/CD -- [ ] Validação manual localmente com carga realística -- [ ] Monitoramento de produção configurado (alertas de taxa de falha >5%) -- [ ] Procedimento de rollback testado localmente -- [ ] Plano de comunicação para stakeholders aprovado - -**Opções de Implementação**: - -**OPÇÃO 1 (ATUAL)**: Manter Npgsql 10.x + Hangfire.PostgreSql 1.20.12 -- Requer validação completa via testes de integração -- Monitorar: -- Rollback para Opção 2 se falhas detectadas - -**OPÇÃO 2 (FALLBACK SEGURO)**: Downgrade para Npgsql 8.x -- Versões conhecidas e compatíveis -- Trade-off: Adia benefícios da migração para .NET 10 -- Implementação imediata se Opção 1 falhar - -**OPÇÃO 3 (FUTURO)**: Aguardar Hangfire.PostgreSql 2.x -- Suporte oficial para Npgsql 10.x -- Timeline desconhecida - -**OPÇÃO 4 (EMERGÊNCIA)**: Backend alternativo -- Hangfire.Pro.Redis (requer licença) -- Hangfire.SqlServer (requer infraestrutura SQL Server) - -**Prioridade**: CRÍTICA -**Dependências**: Testes de integração, validação local, monitoramento de produção -**Prazo**: Antes de qualquer deploy para produção - -**Critérios de Aceitação**: -- [x] Testes de integração implementados e passando -- [x] CI/CD gating configurado para bloquear deploy se testes falharem -- [x] Documentação de compatibilidade criada -- [x] Procedimento de rollback documentado e testado -- [ ] Validação local com simulação de carga de produção -- [ ] Monitoramento de produção configurado -- [ ] Equipe treinada em procedimento de rollback -- [ ] Stakeholders notificados sobre o risco e plano de mitigação - -**Documentação**: -- Guia completo: Monitoramento via health checks em produção -- Testes: Removidos - validação via health checks -- CI/CD: `.github/workflows/pr-validation.yml` (step "CRITICAL - Hangfire Npgsql 10.x Compatibility Tests") -- Configuração: `Directory.Packages.props` (linhas 45-103) - ---- +1. ✅ Documentação detalhada em `Directory.Packages.props` +2. ✅ Health checks configurados +3. ✅ Procedimentos de rollback documentados +4. ⚠️ Monitoramento de produção pendente -## ⚠️ MÉDIO: Falta de Testes para Infrastructure Extensions +**Ações Pendentes**: +- [ ] Validação em ambiente staging com carga similar a produção +- [ ] Monitoramento de taxa de falha de jobs (<5% threshold) +- [ ] Configuração de alertas para problemas Hangfire/Npgsql -**Arquivos**: -- `src/Aspire/MeAjudaAi.AppHost/Extensions/KeycloakExtensions.cs` -- `src/Aspire/MeAjudaAi.AppHost/Extensions/PostgreSqlExtensions.cs` -- `src/Aspire/MeAjudaAi.AppHost/Extensions/MigrationExtensions.cs` +**Fallback Strategies**: +1. **Downgrade para Npgsql 8.x** (se problemas detectados) +2. **Aguardar Hangfire.PostgreSql 2.x** (com suporte Npgsql 10) +3. **Backend alternativo** (Hangfire.Pro.Redis, Hangfire.SqlServer) -**Situação**: SEM TESTES - BAIXA PRIORIDADE -**Severidade**: BAIXA -**Sprint**: BACKLOG (não crítico - validação implícita) -**Issue**: [BACKLOG - Considerar apenas se houver incidentes em produção] - -**Descrição**: -As classes de extensão do AppHost que configuram infraestrutura (Keycloak, PostgreSQL, Migrations) não possuem testes unitários/integração. Porém, análise técnica indica **baixo ROI para testes formais**. - -**Componentes Sem Testes**: -1. **KeycloakExtensions** (~170 linhas) - "wiring code" de orquestração Aspire -2. **PostgreSqlExtensions** (~260 linhas) - configuração de containers/Azure -3. **MigrationExtensions** (~50 linhas) - registro de HostedService - -**Mitigação ATUAL (Suficiente para MVP)**: -1. ✅ **Validação Implícita**: Falhas detectadas imediatamente no startup - - PostgreSQL não sobe → aplicação não inicia - - Keycloak configuração errada → erro visível nos logs - - Migrations falham → aplicação não fica operacional -2. ✅ **Código de Orquestração**: Basicamente chamadas `.WithEnvironment()`, `.WithDataVolume()` - - Pouca lógica complexa para testar - - Validações são simples (senha vazia, hostname ausente) -3. ✅ **Logging Detalhado**: Console outputs indicam configurações aplicadas -4. ✅ **Estrutura Limpa**: Options/Results/Services bem separados - -**Risco**: BAIXO - Bugs aparecem rapidamente em desenvolvimento - -**Alternativas de Validação** (ordem de prioridade): - -**OPÇÃO 1 (RECOMENDADA)**: Deixar como está -- Custo-benefício: Criar testes formais tem ROI baixo -- Tempo: 4-6h para coverage básico -- Benefício: Marginal - bugs já detectados em runtime -- **Decisão**: Priorizar testes de componentes com lógica de negócio real - -**OPÇÃO 2**: Smoke Tests (30min - se houver incidentes) -- Criar teste E2E que valida AppHost startup completo -- Captura 80% dos problemas dessas extensions -- Implementar APENAS se houver incidentes em produção - -**OPÇÃO 3**: Testes Formais (4-6h - BACKLOG) -- Usar `Aspire.Hosting.Testing` -- Mock `IDistributedApplicationBuilder` -- Testar cada método de extensão -- **Implementar SOMENTE** se: - - Houver bugs recorrentes em produção relacionados a essas extensions - - Refatoração grande planeada (>100 linhas mudadas) - - Cliente/compliance exigir coverage específico - -**Prioridade**: BAIXA → BACKLOG -**Ação Atual**: NENHUMA (aguardar necessidade real) -**Critério de Reavaliação**: Incidentes em produção OU refatoração >100 linhas - -**Documentação**: -- Análise técnica registrada (20/Dez/2025) -- Decisão: Priorizar Hangfire/Database tests (maior ROI) - ---- - -## ✅ ~~Swagger ExampleSchemaFilter - Migração para Swashbuckle 10.x~~ [REMOVIDO] - -**Status**: REMOVIDO PERMANENTEMENTE (13 Dez 2025) -**Razão**: Código problemático que sempre quebrava, difícil de testar, e não essencial - -**Decisão**: -O `ExampleSchemaFilter` foi **removido completamente** do projeto por: -- Estar desabilitado desde a migração Swashbuckle 10.x (sempre quebrava) -- Causar erros de compilação frequentes no CI/CD -- Ser difícil de testar e manter -- Funcionalidade puramente cosmética (adicionar exemplos automáticos ao Swagger) -- Swagger funciona perfeitamente sem ele -- Exemplos podem ser adicionados manualmente via XML comments quando necessário - -**Arquivos Removidos**: -- `src/Bootstrapper/MeAjudaAi.ApiService/Filters/ExampleSchemaFilter.cs` ❌ -- `tests/MeAjudaAi.ApiService.Tests/Unit/Swagger/ExampleSchemaFilterTests.cs` ❌ -- TODO em `DocumentationExtensions.cs` removido - -**Alternativa**: -Use **XML documentation comments** para adicionar exemplos quando necessário: -```csharp -/// -/// Email do usuário -/// -/// usuario@exemplo.com -public string Email { get; set; } -``` - -**Commit**: [Adicionar hash após commit] - ---- -- Original PR/Issue que introduziu IOpenApiSchema: [A investigar] - ---- - -## Melhorias nos Testes de Integração - -### Melhoria do Teste de Status de Verificação de Prestador -**Arquivo**: `tests/MeAjudaAi.Integration.Tests/Providers/ProvidersIntegrationTests.cs` -**Linha**: ~172-199 -**Situação**: Aguardando Implementação de Funcionalidade Base -**Sprint**: Sprint 5.5 (feature/refactor-and-cleanup) - TODO resolution - -**Descrição**: -O teste `GetProvidersByVerificationStatus_ShouldReturnOnlyPendingProviders` atualmente apenas valida a estrutura da resposta devido à falta de endpoints de gerenciamento de status de verificação. - -**Problema Identificado**: -- TODO comentário nas linhas 180-181 indica limitação atual -- Teste não pode verificar comportamento real de filtragem -- Não há como definir status de verificação durante criação de prestador - -**Melhoria Necessária**: -- Implementar endpoints de gerenciamento de status de verificação de prestadores (aprovar/rejeitar/atualizar verificação) -- Criar prestadores de teste com diferentes status de verificação -- Melhorar o teste para verificar o comportamento real de filtragem (apenas prestadores com status Pending retornados) -- Adicionar testes similares para outros status de verificação (Approved, Rejected, etc.) - -**Opções de Implementação**: -1. **Abrir nova issue** para rastrear implementação de endpoints de gerenciamento de status -2. **Implementar funcionalidade** de atualização de status de verificação -3. **Criar testes mais abrangentes** quando endpoints estiverem disponíveis - -**Prioridade**: Média -**Dependências**: Endpoints de API para gerenciamento de status de verificação de prestadores - -**Critérios de Aceitação**: -- [ ] Endpoints de gerenciamento de status de verificação de prestadores disponíveis -- [ ] Teste pode criar prestadores com diferentes status de verificação -- [ ] Teste verifica que a filtragem retorna apenas prestadores com o status especificado -- [ ] Teste inclui limpeza dos dados de teste criados -- [ ] Testes similares adicionados para todos os valores de status de verificação - ---- - -## 🧪 Testes E2E Ausentes - Módulo SearchProviders - -**Módulo**: `src/Modules/SearchProviders` -**Tipo**: Débito de Teste -**Severidade**: MÉDIA -**Sprint**: Sprint 5.5 (feature/refactor-and-cleanup) - BACKLOG (2-3 sprints) -**Issue**: [Será criado na Sprint 5.5] - -**Descrição**: -O módulo SearchProviders não possui testes E2E (end-to-end), apenas testes de integração e unitários. Testes E2E são necessários para validar o fluxo completo de busca de prestadores, incluindo integração com APIs externas (IBGE), filtros, paginação, e respostas HTTP completas. - -**Contexto**: -- Identificado durante code review automatizado (CodeRabbit) -- Testes de integração existentes cobrem lógica de negócio e repositórios -- Faltam testes que validam endpoints HTTP completos com autenticação real - -**Impacto**: -- Risco de regressões em endpoints de busca não detectadas até produção -- Falta de validação de integração completa API externa → Aplicação → Resposta HTTP -- Dificuldade em validar comportamento de autenticação e autorização em cenários reais - -**Escopo de Testes E2E Necessários**: - -1. **SearchProviders API Endpoints**: - - [ ] `GET /api/search-providers/search` - Busca com múltiplos filtros - - [ ] `GET /api/search-providers/search` - Paginação e ordenação - - [ ] `GET /api/search-providers/search` - Busca com autenticação/autorização - - [ ] `GET /api/search-providers/search` - Respostas de erro (400, 401, 404, 500) - -2. **Integração com IBGE API**: - - [ ] Validação de respostas da API do IBGE (mock ou real) - - [ ] Tratamento de timeouts e erros de rede - - [ ] Validação de mapeamento de dados geográficos (UF, município) - -3. **Filtros e Busca**: - - [ ] Busca por localização (estado, cidade) - - [ ] Busca por tipo de serviço - - [ ] Busca por status de verificação - - [ ] Combinação de múltiplos filtros - -4. **Desempenho e Carga**: - - [ ] Busca com grande volume de resultados (1000+ prestadores) - - [ ] Validação de tempos de resposta (<500ms para buscas simples) - - [ ] Cache de resultados de API externa - -**Arquivos Relacionados**: -- `src/Modules/SearchProviders/API/` - Endpoints a serem testados -- `tests/MeAjudaAi.E2E.Tests/` - Localização sugerida para novos testes -- `tests/MeAjudaAi.Integration.Tests/Infrastructure/WireMockFixture.cs` - Mock de IBGE API - -**Prioridade**: Média -**Estimativa**: 2-3 sprints -**Dependências**: -- Infraestrutura de testes E2E já estabelecida (`MeAjudaAi.E2E.Tests`) -- WireMock configurado para simulação de IBGE API -- TestContainers disponível para PostgreSQL e Redis - -**Critérios de Aceitação**: -- [ ] Pelo menos 15 testes E2E cobrindo cenários principais de busca -- [ ] Cobertura de autenticação/autorização em todos os endpoints -- [ ] Testes validam códigos de status HTTP corretos -- [ ] Testes validam estrutura completa de resposta JSON -- [ ] Testes incluem cenários de erro e edge cases -- [ ] Testes executam em CI/CD com sucesso -- [ ] Documentação de testes E2E atualizada - -**Notas Técnicas**: -- Utilizar `TestContainerTestBase` como base para testes E2E -- Configurar WireMock para simular respostas da API do IBGE -- Usar `ConfigurableTestAuthenticationHandler` para cenários de autenticação -- Validar integração com Redis (cache) e PostgreSQL (dados) +**Prioridade**: MÉDIA +**Monitorar**: --- -## 📦 Microsoft.OpenApi 2.3.0 - Bloqueio de Atualização para 3.x +## 📦 Microsoft.OpenApi 2.3.0 - Bloqueio de Atualização -**Arquivo**: `Directory.Packages.props` (linha ~46) +**Arquivo**: `Directory.Packages.props` **Situação**: BLOQUEADO - Incompatibilidade com ASP.NET Core Source Generators -**Severidade**: BAIXA (não crítico, funciona perfeitamente) -**Sprint**: N/A - Aguardar correção da Microsoft -**Issue**: [Monitoramento contínuo] +**Severidade**: BAIXA (funciona perfeitamente na versão atual) +**Status**: Pinado em 2.3.0 **Descrição**: -Microsoft.OpenApi está pinado em versão 2.3.0 porque a versão 3.0.2 é incompatível com os source generators do ASP.NET Core 10.0 (`Microsoft.AspNetCore.OpenApi.SourceGenerators`). +Microsoft.OpenApi 3.x é incompatível com os source generators do ASP.NET Core 10.0. Erro confirmado em teste realizado em 16/01/2026 com SDK 10.0.102. -**Problema Identificado**: -``` +**Erro Encontrado**: +```text error CS0200: Property or indexer 'IOpenApiMediaType.Example' cannot be assigned to -- it is read only ``` **Testes Realizados**: -```text -- ✅ Testado com SDK 10.0.101 (Dez 2025) - ainda quebra -- ✅ Testado Microsoft.OpenApi 3.0.2 - incompatível +- ✅ Testado com SDK 10.0.101 (Dez 2025) - incompatível +- ✅ Testado com SDK 10.0.102 (Jan 2026) - incompatível +- ✅ Testado Microsoft.OpenApi 3.1.3 (16 Jan 2026) - build falha - ✅ Confirmado que 2.3.0 funciona perfeitamente -``` **Causa Raiz**: -- Microsoft.OpenApi 3.x mudou `IOpenApiMediaType.Example` para read-only (breaking change) +- Microsoft.OpenApi 3.x mudou `IOpenApiMediaType.Example` para read-only - ASP.NET Core source generator ainda gera código que tenta escrever nessa propriedade - Source generator não foi atualizado para API do OpenApi 3.x -**Dependência**: Swashbuckle.AspNetCore -- Swashbuckle 10.x depende de Microsoft.OpenApi (transitivo) -- Projeto usa Swashbuckle para Swagger UI e customizações avançadas -- Swashbuckle v10 migration guide: [Swashbuckle v10 Migration](https://github.com/domaindrivendev/Swashbuckle.AspNetCore/blob/master/docs/migrating-to-v10.md) - -**Opções de Resolução**: - -**OPÇÃO 1 (ATUAL - RECOMENDADA)**: Manter Microsoft.OpenApi 2.3.0 -- ✅ Funciona perfeitamente +**Decisão**: Manter Microsoft.OpenApi 2.3.0 +- ✅ Funciona 100% - ✅ Zero impacto em funcionalidades - ✅ Swagger UI completo e funcional - ⚠️ Versão desatualizada (mas estável) -**OPÇÃO 2 (FUTURO)**: Aguardar correção da Microsoft -- Microsoft atualiza source generator para OpenApi 3.x -- Timeline: Desconhecida (provavelmente .NET 11 ou patch futuro) -- Monitorar: [ASP.NET Core Issues](https://github.com/dotnet/aspnetcore/issues) - -**OPÇÃO 3 (COMPLEXA - NÃO RECOMENDADA AGORA)**: Migrar para ASP.NET Core OpenAPI nativo -- Remove Swashbuckle completamente -- Usa `Microsoft.AspNetCore.OpenApi` nativo (.NET 9+) -- **PROBLEMA**: Não inclui Swagger UI por padrão - - Precisa adicionar Scalar/SwaggerUI/RapiDoc separadamente - - Perde configurações avançadas de UI (InjectStylesheet, DocExpansion, etc) -- **ESFORÇO**: 5-8 horas de trabalho - - Migrar CustomSchemaIds → transformers - - Migrar CustomOperationIds → transformers - - Migrar ApiVersionOperationFilter → transformers - - Configurar UI externa (Scalar recomendado) - - Atualizar 3 arquivos de teste -- **ROI**: Baixo - funcionalidade atual é completa - **Monitoramento**: - [ ] Verificar releases do .NET SDK para correções no source generator - [ ] Testar Microsoft.OpenApi 3.x a cada atualização de SDK -- [ ] Monitorar Swashbuckle releases para melhor suporte OpenApi 3.x -- [ ] Avaliar migração para OpenAPI nativo quando UI nativo estiver disponível - -**Prioridade**: BAIXA (não urgente) -**Estimativa**: Aguardar correção oficial (sem ação necessária) -**Workaround Atual**: Manter 2.3.0 (100% funcional) -**Critérios para Atualização**: -- [ ] Microsoft corrigir source generator para OpenApi 3.x, OU -- [ ] Swashbuckle suportar completamente OpenApi 3.x, OU -- [ ] Necessidade real de features do OpenApi 3.x (atualmente nenhuma) - -**Documentação**: -- Comentário detalhado em `Directory.Packages.props` (linhas 46-49) -- Migration guide Swashbuckle: [Swashbuckle v10 Migration](https://github.com/domaindrivendev/Swashbuckle.AspNetCore/blob/master/docs/migrating-to-v10.md) -- ASP.NET Core OpenAPI docs: [OpenAPI in ASP.NET Core](https://learn.microsoft.com/aspnet/core/fundamentals/openapi/aspnetcore-openapi) - -**Nota**: Esta limitação **NÃO afeta** funcionalidade, performance ou segurança. É puramente uma questão de versão de dependência. +**Prioridade**: BAIXA (não urgente, não afeta funcionalidade) +**Monitorar**: --- -## 📋 Padronização de Records (Para Próxima Sprint) +## 📋 Padronização de Records **Arquivo**: Múltiplos arquivos em `src/Shared/Contracts/**` e `src/Modules/**/Domain/**` -**Situação**: INCONSISTÊNCIA - Dois padrões em uso -**Severidade**: BAIXA (manutenibilidade) -**Sprint**: Sprint 5.5 (feature/refactor-and-cleanup) - Baixa prioridade -**Issue**: [Será criado na Sprint 5.5] +**Severidade**: MÉDIA (padronização importante) +**Sprint**: Sprint 7.16 (Dia 5, ~0.5 dia) -**Descrição**: -Atualmente existem dois padrões de sintaxe para records no projeto: - -### Padrão 1: Positional Records (Sintaxe Concisa) +**Descrição**: Existem dois padrões de sintaxe para records no projeto: +**Padrão 1 - Positional Records**: ```csharp -public sealed record ModuleCoordinatesDto( - double Latitude, - double Longitude); +public sealed record ModuleCoordinatesDto(double Latitude, double Longitude); ``` -### Padrão 2: Property-based Records (Sintaxe Explícita) - +**Padrão 2 - Property-based Records**: ```csharp public sealed record ModuleLocationDto { @@ -741,66 +236,17 @@ public sealed record ModuleLocationDto } ``` -**Análise**: - -*Positional Records:* -- ✅ Mais conciso -- ✅ Gera automaticamente construtor, desconstrutor, Equals, GetHashCode -- ✅ Ideal para DTOs simples e imutáveis -- ❌ Menos flexível para validação/lógica customizada -- ❌ Ordem dos parâmetros importa - -*Property-based Records:* -- ✅ Maior flexibilidade (validação, valores padrão complexos) -- ✅ Permite required e init-only de forma explícita -- ✅ Ordem não importa -- ❌ Mais verboso -- ❌ Não gera desconstrutor automaticamente - **Recomendação**: +- DTOs simples → Positional Records +- Value Objects com validação → Property-based Records -*Para DTOs simples* (maioria dos casos em Contracts/Modules): Usar **Positional Records** -- São mais concisos -- Comunicação entre módulos não precisa de lógica complexa -- Imutabilidade garantida por design - -*Para Value Objects e Domain Models*: Usar **Property-based Records** -- Permite validação no construtor -- Maior controle sobre comportamento - -**Ação Sugerida**: -Na próxima sprint, padronizar todos os records em: -- `src/Shared/Contracts/**/*.cs` → Positional Records -- `src/Modules/**/Domain/**/*.cs` → Property-based Records (onde fizer sentido) +**Ação Sugerida** (Sprint 7.16): +- [ ] Padronizar records em `src/Shared/Contracts/**/*.cs` +- [ ] Padronizar records em `src/Modules/**/Domain/**/*.cs` -**Arquivos para Revisar**: -- [ ] Todos os DTOs em Contracts/Modules -- [ ] Value Objects em Domain -- [ ] Responses/Requests em Shared - -**Prioridade**: BAIXA (não urgente, melhoria de consistência) -**Estimativa**: 2-3 horas - ---- - -## Instruções para Mantenedores - -1. **Conversão para Issues do GitHub**: - - Copiar a descrição da melhoria para um novo issue do GitHub - - Adicionar labels apropriadas (`technical-debt`, `testing`, `enhancement`) - - Vincular ao arquivo específico e número da linha - - Adicionar ao backlog do projeto com prioridade apropriada - -2. **Atualizando este Documento**: - - Marcar itens como "Issue Criado" com número do issue quando convertido - - Remover itens completos ou mover para seção "Concluído" - - Adicionar novos itens de débito técnico conforme identificados +**Prioridade**: BAIXA +**Estimativa**: 2-3 horas -3. **Referências de Código**: - - Usar tag `[ISSUE]` em comentários TODO para indicar itens rastreados aqui - - Incluir caminho do arquivo e números de linha para navegação fácil - - Manter descrições específicas e acionáveis -- Roadmap: Adicionado em "Média Prioridade (6-12 meses - Fase 2)" --- ## 🔮 Melhorias Futuras (Backlog) @@ -808,63 +254,40 @@ Na próxima sprint, padronizar todos os records em: ### 🧪 Testing & Quality Assurance **Severidade**: MÉDIA -**Sprint**: Backlog (não bloqueante) - -**Unit Tests - Memory Management**: -- [ ] Add unit tests for LocalizationSubscription disposal -- [ ] Add unit tests for PerformanceHelper LRU eviction -- [ ] Create unit tests for .resx resource loading +**Sprint**: Backlog -**Production Monitoring**: -- [ ] Memory profiling in production environment -- [ ] Monitor cache hit rates and eviction frequency +- [ ] Unit tests for LocalizationSubscription disposal +- [ ] Unit tests for PerformanceHelper LRU eviction +- [ ] Memory profiling in production -**Origem**: Sprint 7.16 (Memory Leak Fixes) e Sprint 7.17 (Localization Migration) +**Origem**: Sprint 7.16-7.17 (Memory & Localization) --- -### 🌐 Localization (i18n) Enhancements +### 🌐 Localization Enhancements **Severidade**: MÉDIA -**Sprint**: Backlog (expansão gradual) - -**Hardcoded Strings Migration**: -- [ ] Migrate ErrorHandlingService hardcoded strings to .resx (48 mensagens de erro) -- [ ] Integrate FluentValidation with localized error messages -- [ ] Add more resource strings (currently only 48 base strings) - -**Advanced Localization Features**: -- [ ] Add pluralization examples (ICU MessageFormat) -- [ ] Add date/time localization (DateTimeFormatInfo) -- [ ] Add number formatting localization (NumberFormatInfo) +**Sprint**: Backlog -**Impacto**: Melhora experiência do usuário para expansão internacional +- [ ] Migrate ErrorHandlingService hardcoded strings to .resx +- [ ] Integrate FluentValidation with localized messages +- [ ] Add pluralization examples +- [ ] Add date/time and number formatting localization -**Origem**: Sprint 7.17 (Localization Migration) +**Origem**: Sprint 7.17 --- ### ⚡ Error Handling & Resilience **Severidade**: MÉDIA -**Sprint**: Backlog (otimização) - -**Cancellation Token Propagation**: -- [ ] Update ExecuteApiCallAsync extension method to accept CancellationToken -- [ ] Apply cancellation pattern to ServiceCatalogsEffects -- [ ] Apply cancellation pattern to DocumentsEffects -- [ ] Apply cancellation pattern to LocationsEffects -- [ ] Add per-component CancellationTokenSource that cancels on Dispose() -- [ ] Implement navigation-triggered cancellation in routing layer - -**Benefícios**: -- Previne requisições zombie após navegação -- Melhora responsividade da aplicação -- Reduz carga no backend +**Sprint**: Backlog -**Status Atual**: ExecuteWithErrorHandlingAsync já suporta CancellationToken (Sprint 7.18) +- [ ] Apply CancellationToken to ServiceCatalogs/Documents/Locations Effects +- [ ] Add per-component CancellationTokenSource +- [ ] Implement navigation-triggered cancellation -**Origem**: Sprint 7.18 (Correlation ID & Cancellation Support) +**Origem**: Sprint 7.18 --- @@ -873,11 +296,18 @@ Na próxima sprint, padronizar todos os records em: **Severidade**: BAIXA **Sprint**: Backlog -**Brand Color Scheme**: -- [ ] Apply login page color scheme (blue, cream, orange, white) to entire Admin Portal -- [ ] Update MudBlazor theme with brand colors -- [ ] Standardize component styling across portal +- [ ] Apply brand colors (blue, cream, orange) to entire Admin Portal +- [ ] Update MudBlazor theme +- [ ] Standardize component styling + +**Origem**: Sprint 7.19 + +--- + +## 📝 Instruções para Mantenedores -**Impacto**: Consistência visual com identidade da marca +1. **Conversão para Issues**: Copiar descrição para GitHub issue com labels (`technical-debt`, `testing`, `enhancement`) +2. **Atualizando Documento**: Remover itens completos, adicionar novos conforme identificados +3. **Referências**: Usar tag `[ISSUE]` em comentários TODO, incluir path e linhas -**Origem**: Sprint 7.19 (User Request - Jan 16, 2026) \ No newline at end of file +--- \ No newline at end of file