Grupo 04 - Sprint 3

.gitignore

@@ -0,0 +1,90 @@
+# See https://help.github.com/articles/ignoring-files for more about ignoring files.
+#
+# If you find yourself ignoring temporary files generated by your text editor
+# or operating system, you probably want to add a global ignore instead.
+#   git config --global core.excludesfile '~/.gitignore_global'
+
+# Ignore bundler config.
+/.bundle
+/src/.bundle
+
+# Ignore all logfiles and tempfiles.
+/log/*
+/src/log/*
+/tmp/*
+/src/tmp/*
+!/log/.keep
+!/src/log/.keep
+!/tmp/.keep
+!/src/tmp/.keep
+
+# Ignore pidfiles, but keep the directory.
+/tmp/pids/*
+/src/tmp/pids/*
+!/tmp/pids/
+!/src/tmp/pids/
+!/tmp/pids/.keep
+!/src/tmp/pids/.keep
+
+# Ignore storage (uploaded files in development and any SQLite databases).
+/storage/*
+/src/storage/*
+!/storage/.keep
+!/src/storage/.keep
+/tmp/storage/*
+/src/tmp/storage/*
+!/tmp/storage/
+!/src/tmp/storage/
+!/tmp/storage/.keep
+!/src/tmp/storage/.keep
+
+/public/assets
+/src/public/assets
+.byebug_history
+
+# Ignore master key for decrypting credentials and more.
+/config/master.key
+/src/config/master.key
+
+/db/*.sqlite3
+/src/db/*.sqlite3
+*.sqlite3-journal
+*.sqlite3-wal
+*.sqlite3-shm
+
+# Ignore all environment files (except templates).
+/.env
+/src/.env
+/.env.production
+/src/.env.production
+/.env.development
+/src/.env.development
+/.env.test
+/src/.env.test
+
+# Ignore some generated files
+/coverage
+/src/coverage
+/public/packs
+/src/public/packs
+/public/packs-test
+/src/public/packs-test
+/node_modules
+/src/node_modules
+/yarn-error.log
+/src/yarn-error.log
+.yarn/
+/src/.yarn/
+.yarnrc.yml
+/src/.yarnrc.yml
+
+# Ignore Mac and Linux file system files
+*.swp
+.DS_Store
+
+# Ignore vendor/bundle
+/vendor/bundle
+/src/vendor/bundle
+
+# Ignore simplecov
+coverage

CONTRIBUTING.md

@@ -0,0 +1,137 @@
+# Guia de Contribuição - Projeto CAMAAR (Grupo 4)
+
+### Integrantes: 
+- Guilherme Fornari
+- João Magno
+- Pedro Conti
+- Rodrigo Rafik
+
+Este documento define as regras e o fluxo de trabalho que todos os membros do grupo devem seguir para garantir a organização e a qualidade do nosso projeto.
+
+## 1. Papéis (Scrum)
+
+Teremos dois papéis rotativos:
+
+* **Product Owner (PO):** Responsável por ser a "voz do cliente", priorizar as User Stories (Issues) no backlog e validar as entregas.
+* **ScrumMaster (SM):** Responsável por remover impedimentos, garantir que o time siga o processo (incluindo este guia) e proteger a equipe de distrações.
+
+## 2. Nomenclatura de Branches
+
+Toda nova tarefa, seja ela um BDD, uma feature ou um bugfix, **deve** ser feita em sua própria branch. **Nunca faça commits diretamente na `master` ou em branches de sprint**.
+
+**Padrão:** `tipo/nome-da-tarefa`
+
+### Tipos de Branch
+
+* **`bdd/`**: Usado para escrever arquivos de especificação (`.feature`) do Cucumber.
+    * *Exemplo:* `bdd/login-de-usuario`
+    * *Exemplo:* `bdd/gerar-relatorio`
+
+* **`feature/`**: Usado para implementar novas funcionalidades (o código da aplicação).
+    * *Exemplo:* `feature/login-de-usuario`
+
+* **`fix/`**: Usado para corrigir bugs em funcionalidades existentes.
+    * *Exemplo:* `fix/erro-no-login-com-email`
+
+* **`docs/`**: Usado para alterações na documentação (Wiki, README, etc.).
+    * *Exemplo:* `docs/atualiza-instrucoes-do-guia`
+
+## 3. Nomenclatura de Commits
+
+Para manter o histórico do Git limpo e legível, usaremos prefixos nos nossos commits.
+
+**Padrão:** `prefixo: Mensagem clara do que foi feito.`
+
+### Prefixos de Commit
+
+* **`spec:`**: (Para Sprint 1) Adição ou modificação de arquivos de especificação BDD (`.feature`).
+    * *Exemplo:* `spec: Adiciona cenários feliz e triste para login de usuário`
+
+* **`feat:`**: (Sprints futuras) Adição de uma nova funcionalidade (código).
+    * *Exemplo:* `feat: Implementa rota e controller para login`
+
+* **`fix:`**: (Sprints futuras) Correção de um bug.
+    * *Exemplo:* `fix: Corrige validação de senha no login`
+
+* **`refac:`**: Alteração de código que não corrige bug nem adiciona feature.
+    * *Exemplo:* `refact: Remove código duplicado do controller de usuário`
+
+* **`docs:`**: Alterações na documentação.
+    * *Exemplo:* `docs: Atualiza wiki com novo fluxo de PR`
+
+* **`style:`**: Alterações de formatação, lint, etc. (sem mudança lógica).
+    * *Exemplo:* `style: Aplica formatação do RuboCop`
+
+## 4. Fluxo de Trabalho (Workflow)
+
+Este é o processo-padrão para **todas** as contribuições.
+
+### Passo 1: Início da Tarefa
+
+1.  **Sincronize sua `master` local** com a `master` do fork do grupo:
+    ```bash
+    git checkout main
+    git pull origin main
+    ```
+2.  **Crie sua nova branch** a partir da `master` usando a nomenclatura correta:
+    ```bash
+    git checkout -b bdd/nome-da-minha-tarefa
+    ```
+
+### Passo 2: Trabalho Local
+
+1.  Faça seu trabalho.
+2.  Faça seus commits usando a nomenclatura correta:
+    ```bash
+    git add .
+    git commit -m "spec: Adiciona cenário feliz para minha tarefa"
+    ```
+3.  Envie sua branch para o repositório (fork do grupo):
+    ```bash
+    git push origin spec/nome-da-minha-tarefa
+    ```
+
+### Passo 3: Pull Request (PR)
+
+1.  No GitHub, abra um **Pull Request**.
+2.  Preencha o template do PR (veja seção 6).
+3.  **Importante:** Atribua pelo menos **um colega** do grupo como "Reviewer".
+4.  O PR **não deve** ser "mergeado" até que o Reviewer aprove.
+
+## 5. Fluxo Específico: Sprint 1 (Entrega BDD)
+
+Para a entrega da Sprint 1, o fluxo tem uma particularidade:
+
+1.  O **ScrumMaster (SM)** criará uma branch chamada `sprint-1` a partir da `main` do fork do grupo.
+2.  **Todos os membros** seguem o **Passo 1 e 2** da seção 4 (criando suas branches `bdd/` a partir da `main`).
+3.  **Pull Request (Interno):** Ao abrir o Pull Request (Passo 3), a **base** (branch de destino) **NÃO** será a `main`, mas sim a branch `sprint-1`.
+    * **De:** `bdd/login-de-usuario`
+    * **Para:** `sprint-1`
+4.  Após todos os PRs serem revisados e mergeados na `sprint-1`, um membro (ex: SM) fará o **Pull Request Final** para o professor:
+    * **De:** `nosso-fork/sprint-1`
+    * **Para:** `EngSwCIC/CAMAAR:main`
+
+## 6. Fluxo Específico: Sprints Futuras (Implementação)
+
+Após a Sprint 1, nosso fluxo voltará ao normal:
+
+* **De:** `feature/nome-da-feature`
+* **Para:** `main` (do fork do grupo)
+
+A `main` do nosso fork será a nossa base de código estável.
+
+## 7. Template de Pull Request
+
+Ao criar um Pull Request, use este template na descrição.
+
+```markdown
+### O que foi feito?
+(Descreva em poucas linhas o que este PR entrega. Ex: "Implementa os cenários BDD para a feature de Login de Usuário".)
+
+### Como testar?
+(Descreva os passos para o "Reviewer" validar seu trabalho. Ex: "1. Leia o arquivo `features/login.feature` e verifique se os cenários feliz e triste estão presentes.")
+
+### Issue Relacionada
+(Link para a User Story/Issue do GitHub que este PR resolve.)
+
+- Resolve #[número_da_issue]

README.md

@@ -1,2 +1,111 @@
-# CAMAAR
-Sistema para avaliação de atividades acadêmicas remotas do CIC
+# CAMAAR - Sistema de Gestão Acadêmica
+
+Este projeto utiliza **Ruby on Rails 8** e **SQLite**.
+
+## Pré-requisitos
+
+* **Ruby:** Versão 3.2.0 ou superior (Requisito do Rails 8).
+* **Bundler:** Para gerenciar as dependências.
+* **SQLite3:** Banco de dados utilizado.
+
+## Instalação
+
+1.  **Instale as dependências:**
+    ```bash
+    bundle install
+    ```
+
+2.  **Configuração do Banco de Dados:**
+    Execute o comando para criar o banco e rodar as migrações:
+    ```bash
+    rails db:setup
+    ```
+
+---
+
+## ⚠️ Configuração do Usuário Administrador
+
+Para acessar o sistema como administrador, você deve verificar se já existe um usuário criado ou criar um manualmente via terminal, conforme os cenários abaixo.
+
+### Passo 1: Acesse o Console do Rails
+No terminal, na raiz do projeto, execute:
+```bash
+rails console
+````
+
+### Passo 2: Verifique se já existe um Admin
+
+Dentro do console, execute o comando abaixo para buscar um administrador:
+
+```ruby
+admin = Usuario.where(ocupacao: 'admin').first
+puts admin ? "Email encontrado: #{admin.email}" : "Nenhum admin encontrado."
+```
+
+### Passo 3: Decida o fluxo com base no resultado
+
+#### **Cenário A: Nenhum admin encontrado**
+
+Ainda dentro do console, copie e cole o código abaixo para criar um novo administrador:
+
+```ruby
+Usuario.create!(
+  nome: "Administrador",
+  email: "admin@test.com",
+  usuario: "admin",
+  matricula: "000000",
+  password: "password123",
+  password_confirmation: "password123",
+  ocupacao: :admin,
+  status: true
+)
+```
+
+*Agora você pode logar com o email `admin@test.com` e a senha `password123`.*
+
+#### **Cenário B: Admin encontrado (Recuperação de Senha)**
+
+Se o console retornou um usuário (ex: `admin@test.com`) mas você não sabe a senha:
+
+1.  Copie o e-mail retornado no console.
+2.  Saia do console (digite `exit`).
+3.  Inicie o servidor (veja a seção "Rodando a Aplicação" abaixo).
+4.  Acesse a tela de login no navegador.
+5.  Clique em **"Esqueci minha senha"**.
+6.  Insira o e-mail do administrador.
+7.  O sistema utiliza a gem `letter_opener`. Uma nova aba abrirá automaticamente no seu navegador contendo o e-mail simulado com o link de redefinição.
+8.  Clique no link, defina uma nova senha e faça o login.
+
+-----
+
+## Rodando a Aplicação
+
+Para iniciar o servidor web:
+
+```bash
+rails s
+```
+
+Acesse a aplicação em: [http://localhost:3000](https://www.google.com/search?q=http://localhost:3000)
+
+## Rodando os Testes
+
+O projeto conta com testes unitários (RSpec) e de aceitação (Cucumber).
+
+  * **RSpec:**
+
+    ```bash
+    bundle exec rspec
+    ```
+
+  * **Cucumber:**
+
+    ```bash
+    bundle exec cucumber
+    ```
+
+  * **Verificar Qualidade (RubyCritic):**
+
+    ```bash
+    bundle exec rubycritic
+    ```