T4sk — Task Manager

Task Manager desenvolvido para o desafio técnico de Backend da Revelatio Studio. O foco é uma API segura e bem estruturada para autenticar usuários, gerenciar tarefas e anexar arquivos; o portal é uma interface mínima para demonstrar o fluxo ponta a ponta.

Acesso rápido

• Solução publicada
• Documentação da API (Swagger)
• Fluxo de uma requisição autenticada (FigJam)
• Vídeo do desafio técnico (até 7 min)
• Vídeo técnico extendido/completo (~8 min)

O deploy do commit fd73937 foi validado no Coolify em 19/07/2026. A API publicada está em https://api.r0b14.com/api.

O que a solução entrega

Capacidade	Implementação
Autenticação	Cadastro público e login com JWT.
Tarefas	Criar, listar, detalhar, editar, concluir e excluir.
Organização	Status, prioridade, prazo, busca, filtros, paginação e ordenação.
Anexos	Upload, listagem, download e remoção de arquivos permitidos.
Autorização	USER acessa seus recursos; ADMIN pode operar no escopo global com all=true.

O escopo obrigatório do desafio está detalhado em Desafio Técnico – Backend.pdf e foi conferido em aderência ao desafio.

Como a solução foi estruturada

Cliente → guards JWT/roles + DTOs → controllers → services → Prisma → PostgreSQL
                                             └─ anexos → volume local + metadados no banco

O backend é um monólito modular em NestJS. Os módulos auth, users, tasks, attachments e prisma têm responsabilidades separadas: controllers recebem HTTP, services concentram regras de negócio e autorização, e o Prisma isola a persistência. Essa escolha mantém o projeto simples para o escopo, sem abrir mão de separação para evolução.

Modelagem de dados

User (1) ──< Task (1) ──< Attachment

• User: e-mail único, senha com hash bcrypt e papel USER ou ADMIN.
• Task: título, descrição, prazo, status, prioridade e ownerId.
• Attachment: metadados do arquivo e vínculo com uma tarefa; o arquivo físico fica fora do banco.

UUIDs e timestamps são usados em todas as entidades. onDelete: Cascade evita órfãos, e índices em ownerId e status atendem aos filtros mais frequentes. O schema está em backend/prisma/schema.prisma.

Decisões técnicas e trade-offs

Decisão	Por quê
PostgreSQL + Prisma	Modelo explícito, migrations versionadas e consultas tipadas.
JWT stateless	Integração simples para o portal; não há revogação imediata de token.
Autorização no service	A regra de proprietário/ADMIN não depende só da rota HTTP. ownerId vem do JWT, nunca do corpo da requisição.
DTOs e validação	Contrato explícito e entrada validada antes das regras de negócio.
Docker multi-stage	Imagem de runtime menor e ambiente de entrega reproduzível; migrations rodam no boot.
Volume local para anexos	Proporcional a uma réplica; produção horizontal exigiria storage compartilhado.

Arquitetura, ADRs e o fluxo no FigJam registram os detalhes dessas decisões.

Qualidade, segurança e estado da entrega

• Testes unitários, E2E e smoke Docker cobrem autenticação, tarefas, anexos, persistência e autorização. Veja testes.
• O smoke publicado validou portal, Swagger, CORS, login, CRUD, anexos, isolamento de usuário (403) e operações administrativas: evidência #12.
• Segredos ficam fora do repositório; há exemplos de .env, CORS explícito e limites/configuração para uploads. Veja segurança.
• O comportamento reproduzível de execução e deploy está em desenvolvimento e deploy.

Limitações deliberadas para o prazo: JWT não possui refresh token ou revogação imediata; anexos locais não escalam horizontalmente; banco e filesystem não compartilham uma transação única. Rate limiting, métricas, logs estruturados, antivírus de upload e redefinição segura de senha são próximos passos — esta última está registrada na issue #32.

Uso de IA

IA foi usada como apoio, não como substituta de decisão técnica:

• Claude ajudou no scaffold inicial, em módulos NestJS, DTOs, guards e rascunhos de testes/documentação.
• Codex apoiou revisão de requisitos e arquitetura, identificação de riscos, validações e organização da documentação.
• Lovable foi usado para prototipar, publicar e evoluir o portal integrado à API; o código-fonte do frontend também está versionado neste repositório.
• OpenAI é o assistente opcional de tarefas configurado no ambiente do Lovable.

Toda sugestão foi revisada e integrada manualmente. Modelagem, autorização, persistência, infraestrutura e trade-offs foram decididos e validados no projeto, com testes e documentação como evidência.

Executar localmente

Pré-requisitos: Node.js 20+, npm, Docker Compose e Bun 1+ (portal).

cd backend
cp .env.example .env
docker compose up -d db
npm ci
npm run prisma:generate
npm run prisma:deploy
npm run prisma:seed
npm run start:dev

Em outro terminal:

cd frontend
cp .env.example .env
# Para API local: VITE_API_URL=http://localhost:3000/api
bun install --frozen-lockfile
bun run dev

• API local: http://localhost:3000/api
• Swagger: http://localhost:3000/api/docs.
• Credenciais de demonstração são apenas locais; consulte desenvolvimento.

Referências

• Swagger — Documentando suas APIs
• Prisma documentation
• PostgreSQL 16 documentation
• Vídeo de referência

Licença

MIT.