A tela interna do projeto e o formulário de proposta apresentam diversos pequenos problemas de UX, formatação e validação que comprometem a experiência: nível de experiência exibido em minúsculo, identificação do dono por texto quando há foto disponível, data de cadastro com horário desnecessário, ausência de máscara monetária no campo de preço, falta de preview ao anexar arquivos e ausência de validação consistente de valor da proposta (frontend e backend). O objetivo é polir esses pontos e estabelecer guardrails de valor, não permitindo propostas zeradas, negativas, muito baixas ou muito altas em relação ao orçamento. O que precisa ser feito: - Capitalizar o nível de experiência exibido na tela interna do projeto ("Pleno" em vez de "pleno") - Exibir a foto do cliente dono do projeto quando houver imagem; manter o fallback de texto/iniciais somente se não houver foto - Normalizar a data de "Membro desde..." removendo o horário (exibir apenas dia, mês e ano) - Aplicar máscara de moeda em reais (R$ 1.234,56) no input de preço do form de proposta - Implementar preview de upload de anexos no form de proposta: - thumbnail para imagens - ícone + nome do arquivo para outros tipos - Validar valor da proposta no frontend (bloqueia submit) e no backend (rejeita com erro 400): - não pode ser zero ou negativo - não pode ser menor que 10% do orçamento do projeto - não pode ser maior que 80% do orçamento do projeto - Exibir mensagens de erro claras em pt-BR explicando o limite violado Stack: - Backend: Python / Django 5.0 - Frontend: Django Templates / Tailwind CSS / HTMX / JavaScript Vanilla - Forms: Django ModelForm com clean_<field> para validação server-side Requisitos técnicos: - 100% Tailwind CSS — sem CSS customizado, sem inline style, sem Bootstrap em código novo - Sem inline JS (onclick, onchange) — eventos em arquivos .js - Máscara de moeda em JS vanilla ou biblioteca leve já presente no projeto - Preview de upload via FileReader API (sem upload prévio ao servidor) - Validação backend no clean_price do form de proposta e/ou no service - Filtros de capitalize/date no template via Django built-ins: - |capfirst - |date:"d/m/Y" - Textos de UI em pt-BR - Identificadores de código em inglês Critérios de aceite: - Nível de experiência aparece capitalizado em todas as renderizações da tela interna do projeto - Quando o cliente tem foto, ela é exibida; quando não tem, o fallback textual é usado - "Membro desde" não exibe horário - Input de preço da proposta formata automaticamente como R$ enquanto o usuário digita - Ao selecionar arquivos no form de proposta, aparece preview imediato antes do submit - Submissão de proposta com valor zero/negativo é bloqueada no frontend e rejeitada no backend - Submissão de proposta abaixo de 10% do orçamento é bloqueada com mensagem clara - Submissão de proposta acima de 80% do orçamento é bloqueada com mensagem clara - Mensagens de erro citam o valor mínimo e máximo calculados para o projeto em questão Informações adicionais: - Nível de experiência esperado: Pleno/Sênior

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

Pelo menos um endpoint do Kanban usa @csrf_exempt, removendo a proteção CSRF. Isso expõe o endpoint a ataques onde um site malicioso pode fazer requisições em nome do usuário autenticado sem seu consentimento. O que precisa ser feito: - Remover todos os decoradores `@csrf_exempt` das views de kanban - Garantir que o frontend envie `X-CSRFToken` header nas requisições JavaScript fetch - Para HTMX, configurar o token CSRF via meta tag no template base - Escrever teste verificando que requisição sem CSRF token retorna 403 Stack: Python / Django 5.0 + JavaScript vanilla Requisitos técnicos: - Sem @csrf_exempt em nenhuma view do módulo de kanban - Funcionalidade de kanban sem nenhuma regressão - CSRF token obtido da cookie via JavaScript Critérios de aceite: - Zero @csrf_exempt nas views de kanban - Requisições AJAX incluem X-CSRFToken header - Requisição sem CSRF token retorna 403 - Teste automatizado cobrindo o cenário

Campos de valor monetário usam FloatField em vez de DecimalField. Operações com ponto flutuante geram erros de arredondamento (0.1 + 0.2 = 0.30000000000000004), o que é inaceitável para cálculos financeiros. O que precisa ser feito: - Migrar todos os campos monetários para `DecimalField(max_digits=12, decimal_places=2)` nos models de projetos e propostas - Verificar e migrar campos financeiros em outros módulos se necessário - Criar migration limpa e reversível - Atualizar forms e views que dependem desses campos Stack: Python / Django 5.0 / PostgreSQL Requisitos técnicos: - Migration deve ser reversível - Sem perda de dados existentes - Verificar se forms de criação de projeto precisam de ajuste de validação Critérios de aceite: - Zero FloatField em campos monetários em toda a codebase - Cálculo de taxa (price * 0.15) retorna valor exato sem floating-point drift - Migration executa sem erros - Sem regressão em forms e templates que exibem valores

O endpoint de atualização de card do Kanban não verifica se o usuário tem permissão para editar o board antes de processar a requisição. Qualquer usuário logado pode modificar cards de outros usuários — falha IDOR (Insecure Direct Object Reference). O que precisa ser feito: - Adicionar verificação de permissão em TODAS as views mutáveis do kanban: atualizar card, deletar card, adicionar coluna, deletar coluna - Verificação: owner do board OU participante autorizado - Criar Mixin ou decorator reutilizável para verificação de permissão de board - Retornar HTTP 403 (não 404) para acesso não autorizado - Escrever teste unitário cobrindo o cenário de acesso não autorizado Stack: Python / Django 5.0 Requisitos técnicos: - Mixin reutilizável em todas as views do kanban - Sem mudança de models ou migrations Critérios de aceite: - Requisição com card de outro usuário retorna HTTP 403 - Teste automatizado cobre cenário de acesso não autorizado - Permissão verificada em todas as views mutáveis do kanban

A listagem de projetos e a view de detalhe com propostas apresentam N+1 queries: para cada projeto renderizado, queries separadas são feitas para o dono e skills requeridas. Com 20 projetos por página, isso resulta em 40+ queries onde deveriam ser 2-3. O que precisa ser feito: - Adicionar `select_related` para campos FK nas views de listagem e detalhe de projetos - Adicionar `prefetch_related` para propostas com dados do freelancer - Corrigir queryset de participantes do kanban que não usa prefetch - Verificar com Django Debug Toolbar: listagem ≤ 5 queries, detalhe ≤ 8 queries Stack: Python / Django 5.0 / PostgreSQL Requisitos técnicos: - Apenas otimizações de queryset — sem mudança de models, migrations ou frontend - Nenhum prefetch redundante Critérios de aceite: - Listagem executa ≤ 5 queries - Detalhe com propostas executa ≤ 8 queries - Sem regressão funcional

O Service Worker de notificações push existe mas não possui tratamento de erros. Falhas silenciosas causam usuários sem notificações sem saberem. Não há feedback visual ao usuário nem retry logic. O que precisa ser feito: - Adicionar try-catch em todos os event handlers do Service Worker - Feedback visual quando usuário nega permissão de notificações - Retry automático em falha de subscription por erro de rede - Log de erros para o console - Não criar novo sistema — apenas hardening do existente Requisitos técnicos: - JavaScript vanilla (Service Worker API) - Sem quebrar funcionalidade de push existente - UX de negação deve ser discreta (não modal bloqueante) Critérios de aceite: - Nenhuma exceção silenciosa no Service Worker - Usuário vê mensagem clara ao negar permissão - Falha de subscription loga no console - Retry automático após falha transitória de rede

Os templates de projetos possuem texto hardcoded em português sem uso das tags de internacionalização do Django. Isso impede futura expansão internacional e viola a convenção de i18n do projeto. O que precisa ser feito: - Auditar todos os templates na seção de projetos - Adicionar `{% load i18n %}` em todos os templates alterados - Envolver textos visíveis ao usuário com `{% trans "..." %}` - Executar `python manage.py makemessages -l pt_BR` - Atualizar e compilar o arquivo de tradução pt-BR Requisitos técnicos: - Django i18n nativo (sem libs externas) - `compilemessages` deve executar sem erros - Funcionalidade idêntica após a mudança Critérios de aceite: - Zero texto visible-to-user hardcoded nos templates de projetos - Arquivo .po atualizado e compilado - Nenhuma regressão visual ou funcional

O módulo de gamificação existe no backend mas a interface pode carecer de elementos visuais que maximizam engajamento: countdown para fim do desafio, ranking com avatares, badges com animação de unlock, progress bars. O que precisa ser feito: - Countdown timer JS (vanilla) para desafios com prazo - Ranking visual com medalhas: ouro/prata/bronze para top-3 - Animação CSS de 'unlock' para badges recém conquistados (keyframes) - Progress bar animada refletindo score do participante - Não alterar nada no backend Requisitos técnicos: - JavaScript vanilla para o countdown - Animações via CSS keyframes (sem libs externas) - 100% Tailwind - Responsivo e dark mode Critérios de aceite: - Countdown exibe horas:minutos:segundos e some quando encerra - Top-3 com ícones de ouro/prata/bronze - Badge com animação de unlock ao conquistar - Progress bar reflete score / 100 visualmente

A plataforma não possui um sistema de toast/notificação global reutilizável. Feedback de ações importantes (salvar projeto, enviar proposta, erro de rede) é feito de forma inconsistente — alguns templates usam alerts, outros não dão feedback. O que precisa ser feito: - Criar arquivo JS com API simples: `Toast.show({message, type, duration})` - Container de toasts injetado no DOM uma vez, toasts empilhados verticalmente - Integrar com HTMX via evento `htmx:afterRequest` e headers de resposta - Integrar em pelo menos 3 ações existentes (salvar projeto, enviar proposta, atualizar kanban) Requisitos técnicos: - JavaScript vanilla, zero dependências - Tipos: success, error, warning, info - Auto-dismiss após 4s com opção de fechar manualmente - Múltiplos toasts empilhados sem sobreposição Critérios de aceite: - Toast aparece no canto inferior direito com animação - Full-width na base em mobile - Dark mode compatível - Integrado em mínimo 3 ações reais da plataforma

A paginação da listagem de projetos não possui aria-label, não marca a página atual como aria-current e os links não são descritivos para leitores de tela. Usuários com tecnologias assistivas têm experiência degradada. O que precisa ser feito: - Adicionar `<nav aria-label="Paginação">` na paginação - Marcar página atual com `aria-current="page"` - Adicionar `aria-label` ou `<span class="sr-only">` nos botões anterior/próximo - Adicionar skiplink 'Ir para o conteúdo' na navegação principal - Verificar contraste de cores nos estados hover/focus Requisitos técnicos: - Padrão WCAG 2.1 AA - Navegação por teclado (Tab, Enter, Space) - Sem alterações visuais para usuários sem tecnologia assistiva Critérios de aceite: - Navegação por teclado funciona completamente na paginação - Skiplink presente e funcional - Roles ARIA corretos em toda a navegação principal

A página de configuração de aparência do usuário usa classes Bootstrap (form-label, btn, btn-outline-secondary) e atributos style inline — violando as regras do projeto que exigem Tailwind exclusivo e proíbem style inline e Bootstrap em código novo. O que precisa ser feito: - Reescrever o template de aparência em Tailwind puro - Remover todos os atributos `style=` inline - Remover todas as classes Bootstrap - Migrar qualquer script inline para arquivo .js separado - Os toggles de tema (light/dark/system) devem usar radio buttons estilizados com Tailwind Requisitos técnicos: - Zero Bootstrap no template - Zero style inline - Zero scripts inline - Visual consistente com restante das páginas de perfil Critérios de aceite: - Toggle de tema funciona identicamente ao comportamento atual - Aparência consistente em dark/light mode

O filtro de projetos não possui debounce na busca textual, gerando múltiplas requisições por keystroke. O script de filtro contém código inline (onchange, onkeyup) que viola as regras do projeto. O que precisa ser feito: - Remover todos os scripts inline do template de filtro - Usar `hx-trigger="keyup changed delay:300ms"` nativo do HTMX para debounce - Criar endpoint Django para retornar partial HTML da lista de projetos - Adicionar `hx-indicator` com loading durante a busca - URL deve atualizar com query params via `hx-push-url` Requisitos técnicos: - Zero inline JS nos templates - Filtros combinados devem funcionar (categoria + nível + busca textual) - Backend: view que retorna partial da lista de projetos Critérios de aceite: - Requisição só dispara após 300ms de inatividade - URL reflete filtros aplicados (compartilhável) - Indicador de loading durante busca

Páginas de detalhe (projeto, proposta, kanban, perfil) possuem apenas um botão 'voltar' sem contexto de localização. Não existe breadcrumb navigation, dificultando a orientação do usuário em fluxos com múltiplos níveis. O que precisa ser feito: - Criar componente `templates/_template/components/breadcrumb.html` reutilizável via `{% include %}` com `with` - Integrar nas páginas: detalhe do projeto, página de proposta, kanban board - Adicionar schema JSON-LD BreadcrumbList para SEO - Último item deve ser o título da página atual (não clicável) Requisitos técnicos: - 100% Tailwind CSS - Trunca com ellipsis em mobile quando necessário - Dark mode compatível Critérios de aceite: - Breadcrumb em pelo menos 3 páginas de detalhe - Schema JSON-LD presente - Navegação por teclado funcional

Botões de submit em formulários chave da plataforma (criar projeto, enviar proposta, sacar) não possuem estado de loading. O usuário pode clicar múltiplas vezes sem saber que a ação está em progresso. O que precisa ser feito: - Adicionar listener genérico em formulários com atributo `data-loading-btn` - Ao submeter: desabilitar botão, inserir spinner SVG inline, trocar texto - Restaurar estado original em caso de erro - Compatível com HTMX via eventos `htmx:beforeRequest` / `htmx:afterRequest` Requisitos técnicos: - JavaScript vanilla (sem jQuery) - Funcionar em forms HTMX e forms tradicionais - Double-submit deve ser impossível Critérios de aceite: - Botão fica disabled imediatamente após clique e exibe spinner - Em caso de erro, texto original é restaurado - Segundo clique não dispara nova requisição

A listagem de projetos não possui estado de carregamento visual. Quando o usuário acessa a página ou aplica filtros, há um período em branco sem feedback. O que precisa ser feito: - Criar skeleton card com Tailwind puro (animate-pulse, bg-slate-200, rounded) em `templates/_template/components/card_loading.html` - Integrar com HTMX `hx-indicator` na listagem de projetos - Garantir que o skeleton tenha o mesmo layout do card real - Funcionar em dark mode com dark:bg-slate-700 Requisitos técnicos: - 100% Tailwind CSS (sem Bootstrap, sem inline style) - Compatível com HTMX hx-indicator - Responsivo (mobile e desktop) Critérios de aceite: - Skeleton aparece durante carregamento antes dos cards reais - Não há flash de conteúdo vazio em rede lenta - Funciona em dark mode