Update

CONTRIBUTING.en.md

@@ -31,6 +31,30 @@ This flow guarantees control, equity in the distribution and traceability of res
 
 ---
 
+## 🧭 Task tracking flow
+
+After the task is assigned, keep the card updated so the team knows the real state of the work.
+
+### ✔️ Card status:
+- **In progress:** use this when you start implementing or reviewing the task.
+- **Blocked:** use this when you need a decision, access, scope adjustment or technical help to continue.
+- **Done:** use this only after opening the Pull Request, validating locally and leaving the PR link on the card.
+
+### ✔️ Communication on the card:
+- Share the agreed deadline before starting.
+- Record deadline changes on the card itself.
+- Explain blockers with enough context for another person to help.
+- When opening the PR, share the link and list which validations were executed.
+
+### ✔️ Branch and PR flow:
+- Create the branch from `develop`.
+- Use a prefix that matches the type of work: `feat`, `fix`, `docs`, `test`, `refactor`, `style` or `chore`.
+- Make small and clear commits.
+- Always open the Pull Request against `develop`.
+- Link the PR to the issue with a closing keyword, for example `Fixes: #123`, when the PR completes the task.
+
+---
+
 ## 🗂️ Rules and Organization
 
 ### ✔️ When showing interest in a task (card):

CONTRIBUTING.md

@@ -31,6 +31,30 @@ Esse fluxo garante controle, equidade na distribuição e rastreabilidade das re
 
 ---
 
+## 🧭 Fluxo de acompanhamento da tarefa
+
+Depois que a tarefa for atribuída, mantenha o card sempre atualizado para que a equipe saiba o estado real do trabalho.
+
+### ✔️ Status do card:
+- **Em andamento:** use quando começar a implementar ou revisar a tarefa.
+- **Bloqueado:** use quando precisar de uma decisão, acesso, ajuste de escopo ou ajuda técnica para continuar.
+- **Concluído:** use apenas depois de abrir o Pull Request, validar localmente e deixar o link do PR no card.
+
+### ✔️ Comunicação no card:
+- Informe o prazo combinado antes de iniciar.
+- Registre mudanças de prazo no próprio card.
+- Explique bloqueios com contexto suficiente para outra pessoa ajudar.
+- Ao abrir o PR, informe o link e diga quais validações foram executadas.
+
+### ✔️ Fluxo de branch e PR:
+- Crie a branch a partir de `develop`.
+- Use um prefixo coerente com o tipo de trabalho: `feat`, `fix`, `docs`, `test`, `refactor`, `style` ou `chore`.
+- Faça commits pequenos e claros.
+- Abra o Pull Request sempre apontando para `develop`.
+- Relacione o PR com a issue usando uma palavra de fechamento, por exemplo `Fixes: #123`, quando o PR concluir a tarefa.
+
+---
+
 ## 🗂️ Regras e Organização
 
 ### ✔️ Ao demonstrar interesse em uma tarefa (card):

docs/04 - processo/ci-e-validacao.md

@@ -2,7 +2,7 @@
 
 **Classificação:** Documento de Processo\
 **Camada:** 4 --- Processo\
-**Status:** Versão inicial
+**Status:** Fluxo oficial documentado
 
 ------------------------------------------------------------------------
 
@@ -22,7 +22,42 @@ Ele deve ajudar novos contribuidores a entender:
 
 ------------------------------------------------------------------------
 
-## 2. O que é CI
+## 2. Resumo rápido para contribuidores
+
+Antes de abrir um Pull Request, siga este fluxo:
+
+1.  Crie a branch a partir de `develop`.
+2.  Faça a mudança mantendo o escopo da issue.
+3.  Rode as validações locais:
+
+```bash
+npm ci
+npm run format
+npm run lint
+npm run test
+npm run test:push
+npm run build
+```
+
+4.  Abra o PR com destino para `develop`.
+5.  Inclua na descrição o que mudou, como foi validado e a issue
+    relacionada.
+6.  Se algum check falhar, corrija na mesma branch e envie novo commit.
+
+Para mudanças apenas em documentação, rode pelo menos:
+
+```bash
+npm ci
+npm run format
+npm run lint
+```
+
+Se a mudança tocar código TypeScript, rotas, componentes, Prisma ou
+dependências, rode o fluxo completo.
+
+------------------------------------------------------------------------
+
+## 3. O que é CI
 
 CI, ou Integração Contínua, é o processo automatizado que executa
 validações sempre que uma mudança é enviada para revisão.
@@ -38,7 +73,7 @@ No TryCatch, a CI protege a branch de desenvolvimento contra:
 
 ------------------------------------------------------------------------
 
-## 3. Quando a pipeline roda
+## 4. Quando a pipeline roda
 
 O projeto possui dois workflows que atuam em conjunto:
 
@@ -50,11 +85,12 @@ O **CI Pipeline** roda em:
 
 -   Pull Requests direcionados para `main`;
 -   Pull Requests direcionados para `develop`;
--   Pushes na branch `test/tests-ci`.
+-   Pushes diretos em `main`;
+-   Pushes diretos em `develop`.
 
-A branch `test/tests-ci` é usada para validar alterações no próprio
-workflow. Para contribuições comuns, o fluxo esperado é abrir PR para
-`develop`.
+Para contribuições comuns, o fluxo esperado é abrir PR para `develop`.
+Push direto em `main` ou `develop` deve ser reservado para mantenedores e
+casos autorizados.
 
 O **SonarCloud** não roda diretamente em `pull_request`. Ele é disparado
 pelo gatilho `workflow_run`, ou seja, **somente depois que a CI Pipeline
@@ -68,9 +104,9 @@ termina com sucesso**. O motivo dessa separação está explicado na seção
 
 ------------------------------------------------------------------------
 
-## 4. Validações executadas pela CI
+## 5. Validações executadas pela CI
 
-### 4.1 Build and Prepare Environment
+### 5.1 Build and Prepare Environment
 
 Objetivo: garantir que a aplicação consiga compilar em ambiente limpo.
 
@@ -82,7 +118,7 @@ Passos principais:
 -   Cria arquivo `.env` com secrets configurados no GitHub;
 -   Executa `npm run build`.
 
-### 4.2 Lint Codebase
+### 5.2 Lint Codebase
 
 Objetivo: verificar padrões de código e regras do Next.js/ESLint.
 
@@ -92,7 +128,7 @@ Comando executado:
 npm run lint
 ```
 
-### 4.3 Run Tests (Jest)
+### 5.3 Run Tests (Jest)
 
 Objetivo: garantir que os testes automatizados continuem passando.
 
@@ -102,7 +138,7 @@ Comando executado:
 npm run test
 ```
 
-### 4.4 Run Tests with Coverage
+### 5.4 Run Tests with Coverage
 
 Objetivo: gerar cobertura de testes e impedir queda abaixo do mínimo
 definido.
@@ -117,12 +153,12 @@ npx jest --coverage \
 O relatório de cobertura é enviado como artefato do workflow
 (`coverage-report`). Em Pull Requests, o job também publica um artefato
 `pr-metadata` (número do PR, branch de origem e branch de destino). Esses
-artefatos são consumidos pelo workflow SonarCloud (seção 4.5).
+artefatos são consumidos pelo workflow SonarCloud (seção 5.5).
 
 O padrão oficial de testes backend está documentado em
 `docs/04 - processo/testes-backend.md`.
 
-### 4.5 SonarCloud Scan (workflow separado)
+### 5.5 SonarCloud Scan (workflow separado)
 
 Objetivo: executar análise de qualidade e segurança via SonarCloud.
 
@@ -178,7 +214,7 @@ como secret no repositório base.
 > que os demais checks estejam verdes; o Sonar passa a decorar o PR
 > quando o `SONAR_TOKEN` está configurado no repositório base.
 
-### 4.6 Audit Dependencies
+### 5.6 Audit Dependencies
 
 Objetivo: bloquear dependências com vulnerabilidades de severidade alta
 ou superior.
@@ -191,7 +227,7 @@ npm audit --audit-level=high
 
 ------------------------------------------------------------------------
 
-## 5. Validação local antes de abrir PR
+## 6. Validação local antes de abrir PR
 
 Antes de abrir um Pull Request, o contribuidor deve rodar as validações
 principais localmente.
@@ -202,6 +238,7 @@ Fluxo recomendado:
 git checkout develop
 git pull origin develop
 npm ci
+npm run format
 npm run lint
 npm run test
 npm run test:push
@@ -219,7 +256,7 @@ Observações:
 
 ------------------------------------------------------------------------
 
-## 6. Requisitos para abrir Pull Request
+## 7. Requisitos para abrir Pull Request
 
 Antes de abrir o PR:
 
@@ -241,6 +278,8 @@ Resumo objetivo da mudança.
 
 ## Validação
 
+- npm ci
+- npm run format
 - npm run lint
 - npm run test
 - npm run test:push
@@ -254,7 +293,7 @@ issue.
 
 ------------------------------------------------------------------------
 
-## 7. O que fazer quando um check falhar
+## 8. O que fazer quando um check falhar
 
 Quando a CI falhar:
 
@@ -274,7 +313,7 @@ aguarde orientação de um mantenedor.
 
 ------------------------------------------------------------------------
 
-## 8. Requisitos para merge
+## 9. Requisitos para merge
 
 Um PR só deve ser considerado pronto para merge quando:
 
@@ -288,7 +327,7 @@ Um PR só deve ser considerado pronto para merge quando:
 
 ------------------------------------------------------------------------
 
-## 9. Relação com Husky
+## 10. Relação com Husky
 
 O projeto usa Husky para validações locais antes de commits e pushes.
 
@@ -305,9 +344,9 @@ executadas manualmente.
 
 ------------------------------------------------------------------------
 
-## 10. Prisma Client e `package-lock.json`
+## 11. Prisma Client e `package-lock.json`
 
-### 10.1 Geração do Prisma Client (`postinstall`)
+### 11.1 Geração do Prisma Client (`postinstall`)
 
 A partir do Prisma 7, o pacote `@prisma/client` só fica utilizável depois
 que o client é gerado. Sem isso, jobs que rodam testes falham com:
@@ -326,7 +365,7 @@ local), existe o script `postinstall` no `package.json`:
 Ele roda automaticamente após `npm ci` / `npm install`. Não é necessário
 rodar `npx prisma generate` manualmente após instalar dependências.
 
-### 10.2 Lockfile e diferenças entre sistemas operacionais
+### 11.2 Lockfile e diferenças entre sistemas operacionais
 
 Algumas dependências nativas opcionais (por exemplo bindings de
 `@unrs/resolver-binding-*` e `@tailwindcss/oxide-*`, que embarcam
@@ -355,7 +394,7 @@ Diretrizes para evitar esse problema:
 
 ------------------------------------------------------------------------
 
-## 11. Responsabilidades
+## 12. Responsabilidades
 
 Contribuidor:
 

package.json

@@ -10,7 +10,7 @@
     "lint": "eslint . --no-cache",
     "lint:fix": "eslint . --no-cache --fix",
     "format": "prettier --write .",
-    "seed": "node scripts/createTestUser.js",
+    "seed": "tsx scripts/createTestUser.ts",
     "test": "jest  --passWithNoTests --maxWorkers=50%",
     "test:watchAll": "jest --watchAll",
     "test:watch": "jest --watch --maxWorkers=25%",

scripts/createTestUser.ts

@@ -0,0 +1,45 @@
+import bcrypt from 'bcryptjs';
+import { prisma } from '../src/lib/prisma';
+
+export async function createTestUser() {
+  const password = 'teste123';
+  const hashedPassword = await bcrypt.hash(password, 10);
+
+  return prisma.user.upsert({
+    where: { email: 'admin@admin.com' },
+    update: {},
+    create: {
+      name: 'Usuário Admin',
+      email: 'admin@admin.com',
+      password: hashedPassword,
+      avatar: '',
+      bio: 'Usuário admin para testes da API',
+      linkedin: 'https://www.linkedin.com/in/trycatch-app',
+      github: 'https://github.com/TryCatch-ForMatch/trycatch',
+      role: 'ADMIN',
+    },
+  });
+}
+
+function isDirectRun() {
+  return process.argv[1]
+    ?.replaceAll('\\', '/')
+    .endsWith('/scripts/createTestUser.ts');
+}
+
+/* c8 ignore start */
+if (isDirectRun()) {
+  createTestUser()
+    .then(async (user) => {
+      console.log('Usuário criado ou já existente:', user);
+      console.log('✅ Script finalizado.');
+      await prisma.$disconnect();
+      process.exit(0);
+    })
+    .catch(async (error) => {
+      console.error('❌ Ocorreu um erro:', error);
+      await prisma.$disconnect();
+      process.exit(1);
+    });
+}
+/* c8 ignore stop */