diff --git a/backend b/backend
index 39842015516aef6e94cd53e70aa7820d54743b83..e88f1a25d4a7cc1ce16e2fd1fefe57e98160d6e8 160000
--- a/backend
+++ b/backend
@@ -1 +1 @@
-Subproject commit 39842015516aef6e94cd53e70aa7820d54743b83
+Subproject commit e88f1a25d4a7cc1ce16e2fd1fefe57e98160d6e8
diff --git a/c3sl-treinamento-2025-1-backend_issues_2025-03-12.csv b/c3sl-treinamento-2025-1-backend_issues_2025-03-12.csv
new file mode 100644
index 0000000000000000000000000000000000000000..9a96c8b8b9a401a31716a2a3984d582cb0f65178
--- /dev/null
+++ b/c3sl-treinamento-2025-1-backend_issues_2025-03-12.csv
@@ -0,0 +1,209 @@
+Title,Description,Issue ID,URL,State,Author,Author Username,Assignee,Assignee Username,Confidential,Locked,Due Date,Created At (UTC),Updated At (UTC),Closed At (UTC),Milestone,Weight,Labels,Time Estimate,Time Spent
+Criar um schema para o usuário,"# Onde
+
+
+
+Na pasta `src/db/schema.ts`. 
+
+
+
+# O que deve ter?
+
+
+
+O schema deve bater com esse (em SQL)
+
+
+
+```SQL
+CREATE TABLE users (
+  id SERIAL PRIMARY KEY UNIQUE NOT NULL,
+  name VARCHAR(255) NOT NULL,
+  password VARCHAR(255) NOT NULL,
+  email VARCHAR(255) UNIQUE NOT NULL,
+  birthday TIMESTAMP NOT NULL,
+  cpf VARCHAR(11) UNIQUE NOT NULL,
+  money NUMERIC NOT NULL DEFAULT 0,
+  cyberpsychosis NUMERIC NOT NULL DEFAULT 0,
+  cyberLimit NUMERIC NOT NULL DEFAULT 100,
+  created_at TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP,
+  updated_at TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP
+);
+```",1,https://gitlab.c3sl.ufpr.br/c3sl/treinamento-2025.1-backend/-/issues/1,Open,Richard Fernando Heise Ferreira,rfhferreira,"","",No,No,,2025-03-12 00:34:24,2025-03-12 00:34:24,,,,,0,0
+Criar um schema para implantes,"# Onde
+
+Na pasta `src/db/schema.ts`.
+
+# O que deve ter?
+
+O schema deve bater com esse (em SQL)
+
+```SQL
+CREATE TABLE implants (
+  id SERIAL PRIMARY KEY UNIQUE NOT NULL,
+  name VARCHAR(255) NOT NULL,
+  created_at TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP,
+  price NUMERIC NOT NULL,
+  cyberCost NUMERIC NOT NULL DEFAULT 5,
+  bodyPart VARCHAR(255) NOT NULL,
+  updated_at TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP
+);
+```",2,https://gitlab.c3sl.ufpr.br/c3sl/treinamento-2025.1-backend/-/issues/2,Open,Richard Fernando Heise Ferreira,rfhferreira,"","",No,No,,2025-03-12 00:36:22,2025-03-12 00:36:22,,,,,0,0
+Criar uma rota de inserção de usuário,"# Onde
+
+
+A rota é definida no `index.ts`. Mas deve ser criada na pasta `handlers.ts`, em um arquivo `userHandlers.ts`.
+
+
+# O que deve ser feito?
+
+
+
+Deve ser possível inserir um usuário na base de dados através da interface do Express pelo backend. Primeiro, validamos a requisição do usuário através do Zod; depois criamos uma hash para a senha do usuário (senhas jamais devem ser guardadas diretamente no banco) e, por fim, inserimos o usuário no banco. Qualquer erro deve ser tratado apropriadamente com uma resposta adequada para quem fez a requisição (incluindo código HTTP apropriado).",3,https://gitlab.c3sl.ufpr.br/c3sl/treinamento-2025.1-backend/-/issues/3,Open,Richard Fernando Heise Ferreira,rfhferreira,"","",No,No,,2025-03-12 00:43:05,2025-03-12 00:43:05,,,,,0,0
+Criar uma rota de deleção de um usuário,"# Onde
+
+A rota é definida no `index.ts`. Mas deve ser criada na pasta `handlers.ts`, em um arquivo `userHandlers.ts`.
+
+# O que deve ser feito?
+
+Deve ser possível remover um usuário da base de dados.  
+Primeiro, validamos a requisição do usuário através do Zod.  
+Em seguida, verificamos se o usuário existe antes de tentar excluí-lo.  
+Caso o usuário não seja encontrado, retornamos um erro (`404 Not Found`).  
+Se encontrado, removemos o usuário da base e retornamos uma resposta adequada (`200`).",4,https://gitlab.c3sl.ufpr.br/c3sl/treinamento-2025.1-backend/-/issues/4,Open,Richard Fernando Heise Ferreira,rfhferreira,"","",No,No,,2025-03-12 00:44:33,2025-03-12 00:44:33,,,,,0,0
+Criar rota de atualização de um usuário,"# Onde
+
+A rota é definida no `index.ts`. Mas deve ser criada na pasta `handlers.ts`, em um arquivo `userHandlers.ts`.
+
+# O que deve ser feito?
+
+Deve ser possível atualizar os dados de um usuário existente na base de dados.  
+Primeiro, validamos a requisição do usuário através do Zod para garantir que os dados enviados são válidos.  
+Caso o usuário tente atualizar a senha, criamos uma nova hash antes de armazená-la.  
+Depois, atualizamos apenas os campos enviados na requisição.  
+Caso o usuário não seja encontrado, retornamos um erro adequado (`404 Not Found`).  
+Se houver sucesso, retornamos uma resposta apropriada (`200 OK`).",5,https://gitlab.c3sl.ufpr.br/c3sl/treinamento-2025.1-backend/-/issues/5,Open,Richard Fernando Heise Ferreira,rfhferreira,"","",No,No,,2025-03-12 00:45:40,2025-03-12 00:45:40,,,,,0,0
+Criar rota de leitura de um usuário,"# Onde
+
+A rota é definida no `index.ts`. Mas deve ser criada na pasta `handlers.ts`, em um arquivo `userHandlers.ts`.
+
+# O que deve ser feito?
+
+Deve ser possível obter os dados de um usuário específico através da interface do Express pelo backend.  
+Primeiro, validamos a requisição do usuário através do Zod, garantindo que os parâmetros recebidos são válidos.  
+Em seguida, buscamos o usuário no banco de dados.  
+Caso o usuário não seja encontrado, uma resposta apropriada deve ser retornada com um código HTTP adequado (`404 Not Found`).  
+Se encontrado, retornamos os dados do usuário (exceto a senha) em uma resposta JSON.",6,https://gitlab.c3sl.ufpr.br/c3sl/treinamento-2025.1-backend/-/issues/6,Open,Richard Fernando Heise Ferreira,rfhferreira,"","",No,No,,2025-03-12 00:46:34,2025-03-12 00:46:34,,,,,0,0
+Criar um CRUD de implantes,"# Onde
+
+A rota é definida no `index.ts`. Mas deve ser criada na pasta `handlers.ts`, em um arquivo `implantHandler.ts`.
+
+# O que deve ser feito?
+
+## Leitura de um implante
+
+Deve ser possível obter os dados de um implante específico através da interface do Express pelo backend.  
+Primeiro, validamos a requisição utilizando o Zod, garantindo que os parâmetros recebidos são válidos.  
+Em seguida, buscamos o implante no banco de dados.  
+Caso o implante não seja encontrado, uma resposta apropriada deve ser retornada com um código HTTP adequado (`404 Not Found`).  
+Se encontrado, retornamos os dados do implante em uma resposta JSON.  
+
+## Atualização de um implante
+
+Deve ser possível atualizar os dados de um implante existente na base de dados.  
+Primeiro, validamos a requisição utilizando o Zod para garantir que os dados enviados são válidos.  
+Depois, atualizamos apenas os campos informados na requisição.  
+Caso o implante não seja encontrado, retornamos um erro adequado (`404 Not Found`).  
+Se houver sucesso, retornamos uma resposta apropriada (`200 OK`).  
+
+## Deleção de um implante
+
+Deve ser possível remover um implante da base de dados.  
+Primeiro, validamos a requisição utilizando o Zod.  
+Em seguida, verificamos se o implante existe antes de tentar excluí-lo.  
+Caso o implante não seja encontrado, retornamos um erro (`404 Not Found`).  
+Se encontrado, removemos o implante da base e retornamos uma resposta adequada (`200 OK`).  
+
+Qualquer erro deve ser tratado apropriadamente com uma resposta adequada para quem fez a requisição, incluindo código HTTP apropriado.",7,https://gitlab.c3sl.ufpr.br/c3sl/treinamento-2025.1-backend/-/issues/7,Open,Richard Fernando Heise Ferreira,rfhferreira,"","",No,No,,2025-03-12 00:48:02,2025-03-12 00:48:02,,,,,0,0
+Atualizar banco de dados com tabela de compras e partes do corpo,"# Parte 1
+## Onde
+
+No arquivo `src/db/schema.ts`. 
+
+## O que deve ser feito?
+
+Precisamos fazer uma alteração na tabela de implantes para indicar que as partes do corpo são, na verdade, um Enum no banco: dessa forma não há como se referir a uma parte do corpo inválida. Para isso, adicionem um enum no `schema.ts` de forma que o SQL bata com este: 
+
+
+```SQL
+CREATE TYPE bodyParts AS ENUM (
+  'FrontalCortex',
+  'OperatingSystem',
+  'Arms',
+  'Skeleton',
+  'NervousSystem',
+  'IntegumentarySystem',
+  'Face',
+  'Hands',
+  'CirculatorySystem',
+  'Legs'
+);
+```
+
+# Parte 2
+
+## Onde
+
+No arquivo `src/db/schema.ts`.
+
+## O que deve ser feito?
+
+Agora que temos usuários e implantes, essas são nossas *entidades*, para que um usuário possa realizar uma compra, precisamos de uma tabela de chaves estrangeiras que realize esse tipo de representação, para tanto vamos criar uma tabela de compras chamada `purchases`.
+
+Ela deve bater com esse SQL:
+
+```SQL
+CREATE TABLE purchases (
+  id SERIAL PRIMARY KEY UNIQUE NOT NULL,
+
+  -- Chaves estrangeiras
+  user_id INTEGER NOT NULL REFERENCES users(id) ON DELETE CASCADE,
+  implant_id INTEGER NOT NULL REFERENCES implants(id) ON DELETE CASCADE,
+
+  created_at TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP
+);
+```",8,https://gitlab.c3sl.ufpr.br/c3sl/treinamento-2025.1-backend/-/issues/8,Open,Richard Fernando Heise Ferreira,rfhferreira,"","",No,No,,2025-03-12 00:53:45,2025-03-12 00:53:45,,,,,0,0
+"Criar função de validação de usuário, usando Zod","# Onde 
+
+No arquivo `src/validators/userValidator.ts`.
+
+# O que deve ser feito?
+
+É necessário validar nossos dados de entrada, pois não podemos aceitar qualquer coisa na nossa plataforma. Para isso, a biblioteca Zod fornece-nos uma interface simples e eficaz para validar nossos dados. Crie um validador para esses dados de modo que ele retorne erros apropriados para violações de restrições.",9,https://gitlab.c3sl.ufpr.br/c3sl/treinamento-2025.1-backend/-/issues/9,Open,Richard Fernando Heise Ferreira,rfhferreira,"","",No,No,,2025-03-12 00:56:09,2025-03-12 00:56:09,,,,,0,0
+Criar um validador para implantes com Zod,"# Onde 
+
+No arquivo `src/validators/implantsValidator.ts`.
+
+# O que deve ser feito?
+
+É necessário validar nossos dados de entrada, pois não podemos aceitar qualquer coisa na nossa plataforma. Para isso, a biblioteca Zod fornece-nos uma interface simples e eficaz para validar nossos dados. Crie um validador para esses dados de modo que ele retorne erros apropriados para violações de restrições.",10,https://gitlab.c3sl.ufpr.br/c3sl/treinamento-2025.1-backend/-/issues/10,Open,Richard Fernando Heise Ferreira,rfhferreira,"","",No,No,,2025-03-12 00:56:38,2025-03-12 00:56:38,,,,,0,0
+Criar uma rota de login de usuário,"# Onde
+
+
+No arquivo `src/handlers/userHandler.ts`.
+
+
+# O que deve ser feito?
+
+
+O login de um usuário consiste em validar sua senha e seu email/nome. Uma vez validado, um token (JSON web token, JWT) deve ser criado e enviado para quem fez a requisição. Esse token é que, efetivamente, garante que o usuário está ""logado"" no site. Para garantir seu login deve ser feito um middleware de autenticação, que será outra issue.",11,https://gitlab.c3sl.ufpr.br/c3sl/treinamento-2025.1-backend/-/issues/11,Open,Richard Fernando Heise Ferreira,rfhferreira,"","",No,No,,2025-03-12 13:29:49,2025-03-12 13:29:49,,,,,0,0
+Criar middleware de autenticação,"# Onde
+
+
+No arquivo `src/middleware/auth.ts`.
+
+
+# O que deve ser feito?
+
+
+Middlewares são funções especiais que rodam antes de alguma função em uma determinada rota. Ou seja, digamos que meu usuário quer acessar seu perfil e editá-lo, outro usuário não pode editar meu perfil para edição, correto? Essa validação é feita através do token de login, que deve ser passado como uma espécie de ""cartão de checagem"" para algumas rotas que não são públicas (como edição de perfil). Dessa forma, o middleware de autenticação serve justamente para garantir que nem toda rota seja pública. Ele deve realizar uma checagem do token e retornar um erro caso o usuário não tenha autorização para acessar aquela rota.",12,https://gitlab.c3sl.ufpr.br/c3sl/treinamento-2025.1-backend/-/issues/12,Open,Richard Fernando Heise Ferreira,rfhferreira,"","",No,No,,2025-03-12 13:38:01,2025-03-12 13:38:01,,,,,0,0