A plataforma não possui um endpoint /health/ padronizado para uso com load balancers e monitoramento externo. Um health check bem estruturado verifica o estado de cada dependência crítica e retorna resposta estruturada. O que precisa ser feito: - Criar `GET /health/` retornando JSON com status de cada componente: banco de dados, Redis, Celery, Storage - HTTP 200 quando tudo OK, HTTP 503 quando qualquer componente crítico falha - Criar `GET /ready/` mais leve (apenas banco de dados) para liveness probe - Endpoint sem autenticação mas com rate limiting básico - Tempo de resposta < 200ms Stack: Python / Django 5.0 Requisitos técnicos: - Checks: DB (SELECT 1), Redis (ping), Celery (inspect), Storage (head) - Registrar URLs sem autenticação - Testes unitários com mock das dependências Critérios de aceite: - GET /health/ retorna JSON com status de cada componente em < 200ms - HTTP 503 quando qualquer componente crítico falha - GET /ready/ responde apenas com status do banco - Testes unitários cobrindo cenário de falha de cada componente

A plataforma tem Web Push mas não possui notificações in-app (sininho no header). Usuários sem permissão de push perdem atualizações de propostas aceitas, mensagens e contratos. O que precisa ser feito: - Criar model de Notificação genérico: usuário, tipo, mensagem, url, lida, criado_em - Signals nos eventos chave: proposta aceita, mensagem recebida, projeto iniciado - Endpoint HTMX polling a cada 30s para atualizar badge do sininho - Dropdown com últimas 10 notificações e link para a ação - Marcar todas como lidas via HTMX Stack: Python / Django 5.0 + HTMX (backend + frontend) Requisitos técnicos: - Model de notificação na app de usuários - Polling com hx-trigger no header - Badge com contagem de não lidas - Sem duplicação de notificação para o mesmo evento Critérios de aceite: - Notificação criada ao: proposta aceita, mensagem recebida, projeto iniciado - Badge atualiza a cada 30s sem reload de página - Dropdown lista últimas 10 com link para ação - Marcar como lida funciona via HTMX

Os endpoints de busca de projetos e freelancers são públicos e não possuem rate limiting. Isso permite scraping massivo da base de dados e ataques de enumeração de usuários cadastrados. O que precisa ser feito: - Implementar rate limiting via decorator ou middleware - Limites: 60 req/min para autenticados, 20 req/min para anônimos - Retornar HTTP 429 com header `Retry-After` ao exceder limite - Contador baseado em IP para anônimos, user_id para autenticados Stack: Python / Django 5.0 Requisitos técnicos: - Não bloquear usuários legítimos em uso normal - Configurável via settings (não hardcoded) - Logging dos bloqueios para monitoramento Critérios de aceite: - Exceder limite retorna HTTP 429 com Retry-After header - Limites diferentes para autenticados vs anônimos - Não impacta usuários legítimos navegando normalmente - Teste automatizado verificando o comportamento de 429

Views que retornam listas de propostas e freelancers não possuem paginação adequada via HTMX, forçando full page reload para navegar. Isso é um problema de performance e UX. O que precisa ser feito: - Criar endpoint de partial HTML para lista de propostas de um projeto (10/página) - Implementar scroll infinito na lista de freelancers via hx-trigger revealed - URL deve atualizar com `?page=N` via hx-push-url - Adicionar loading indicator entre páginas Stack: Python / Django 5.0 + HTMX (frontend + backend) Requisitos técnicos: - Django Paginator nativo - Retornar apenas HTML da lista + paginação (não página completa) - hx-swap correto para append (scroll infinito) ou replace (paginação clássica) Critérios de aceite: - Lista de propostas pagina sem reload - Lista de freelancers carrega próxima página ao scroll - URL atualiza com ?page=N - Loading indicator visível entre páginas

Listagens públicas de projetos e freelancers são acessadas por todos os visitantes mas não utilizam o Redis cache configurado no projeto. Cada pageview executa queries desnecessárias no banco, aumentando latência e carga. O que precisa ser feito: - Implementar cache com chaves baseadas nos parâmetros de query (filtros, página, categoria) - TTL de 5 minutos para listagens - Invalidar cache ao criar/editar projeto via signal Django - Cache não deve servir dados personalizados de usuários autenticados para visitantes anônimos Stack: Python / Django 5.0 / Redis (django-redis já instalado no projeto) Requisitos técnicos: - Apenas Redis (não cache em memória) - Filtros diferentes geram chaves de cache diferentes - Invalidação via signal ao salvar projeto Critérios de aceite: - Segunda requisição idêntica não executa queries ao banco - Cache invalida em ≤ 1s após criação de projeto - Cache não vaza dados de usuário autenticado para anônimos