✂️ Sistema de Gerenciamento de Barbearia

Sistema de gerenciamento de agendamentos, serviços e clientes para barbearias, desenvolvido como parte de um Trabalho de Conclusão de Curso. O sistema tem como foco principal a organização das atividades do barbeiro, permitindo o controle centralizado de todos os atendimentos de forma simples e eficiente.

---

📱 Sobre o Projeto

Esta API foi projetada para facilitar o gerenciamento interno de uma barbearia. O sistema é utilizado exclusivamente pelo barbeiro, que pode controlar clientes, serviços oferecidos, agendamentos e extrair relatórios com base em filtros de data.

O sistema não possui acesso para clientes, sendo voltado exclusivamente para uso administrativo do profissional responsável.

---

✅ Funcionalidades

• Login de usuário (barbeiro/administrador)
• Cadastro e gerenciamento de:
  • Usuários
  • Clientes
  • Serviços
  • Agendamentos
• Filtros e paginação para todas as listagens
• Controle de conflitos de horário nos agendamentos
• Inativação de registros (clientes, serviços e agendamentos)
• Geração de relatórios com indicadores baseados em data

---

🔐 Permissões de Acesso

Perfil	Permissões
Administrador	Acesso total a todas as rotas: usuários, clientes, serviços, agendamentos

---

⚙️ Tecnologias Utilizadas

• Linguagem: Node.js
• Framework: Express.js
• Banco de Dados: MongoDB
• ORM: Mongoose
• Autenticação: JWT
• Hash de senhas: bcrypt
• Controle de versão: Git / GitHub

---

📝 Requisitos Funcionais

Login

• RF01: O sistema deve permitir o login de usuários cadastrados com autenticação via JWT.

---

Gerenciamento de Usuários

• RF02: O sistema deve permitir o cadastro de novos usuários.
• RF03: O sistema deve permitir a edição dos dados dos usuários.
• RF04: O sistema deve permitir a inativação de usuários.
• RF05: Usuários inativos não devem conseguir realizar login.

---

Gerenciamento de Clientes

• RF06: O sistema deve permitir o cadastro de clientes com nome, telefone e observações, impedindo o cadastro se ja existir nome + telefone no banco.
• RF07: O sistema deve permitir a edição dos dados dos clientes.
• RF08: O sistema deve permitir a inativação de clientes, sem excluir os dados do banco.
• RF09: O sistema deve permitir a busca de clientes por nome, telefone ou ID.
• RF10: Clientes inativos não devem aparecer nas listagens de agendamento.

---

Gerenciamento de Serviços

• RF11: O sistema deve permitir o cadastro de serviços com nome e valor, impedindo o cadastro se ja existir nome + valor no banco.
• RF12: O sistema deve permitir a edição dos dados dos serviços.
• RF13: O sistema deve permitir a inativação de serviços.
• RF14: Serviços inativos não devem poder ser vinculados a novos agendamentos.

---

Gerenciamento de Agendamentos

• RF15: O sistema deve permitir o agendamento de um ou mais serviços para um cliente em um horário específico.
• RF16: O sistema deve impedir agendamentos com horários que conflitam com agendamentos existentes.
• RF17: O sistema deve calcular automaticamente o horário de término com base na duração do agendamento.
• RF18: O sistema deve permitir a edição e desmarcação de agendamentos.
• RF19: O sistema deve permitir aplicar filtros por cliente, data inicial e final.

---

Relatórios e Indicadores

• RF20: O sistema deve permitir a geração de relatórios com base em uma faixa de datas.
• RF21: O relatório deve conter indicadores como:
  • Quantidade de agendamentos
  • Quantidade de clientes únicos atendidos
  • Faturamento total no período
  • Tempo médio por agendamento (opcional)
  • Serviço mais executado (opcional)

---

📄 Observações Finais

• Todos os registros (clientes, serviços, agendamentos e usuários) seguem a política de inativação, ou seja, não são excluídos do banco.
• O sistema valida automaticamente a disponibilidade de horários para novos agendamentos.
• O objetivo é garantir o uso exclusivo pelo barbeiro, com foco na praticidade e organização do negócio.

---

Regras do GitFlow - Sistema de Gerenciamento de Barbearia

Este repositório segue uma abordagem simplificada do GitFlow para organizar o desenvolvimento das funcionalidades, correções e lançamentos do sistema. As regras abaixo definem como as branches devem ser nomeadas e usadas.

Branches

main

• A branch principal do projeto.
• Contém o código estável e pronto para produção.
• Alterações nesta branch só devem ser feitas após testes completos.

develop

• A branch de desenvolvimento.
• Todos os novos recursos, correções e melhorias devem ser mesclados aqui primeiro.
• Antes de cada entrega, a branch develop será mesclada com a main para a criação de uma nova versão estável.

feature/<nome-da-funcionalidade>

• Utilizada para o desenvolvimento de novas funcionalidades.
• Deve ser criada a partir da branch develop.
• Exemplo: feature/login-api, feature/cadastro-usuario.

fix/<nome-do-bug>

• Utilizada para correções de bugs.
• Deve ser criada a partir da branch develop ou diretamente da main caso seja um hotfix.
• Exemplo: fix/corrige-calculo, fix/erro-login.

refactor/<nome-da-alteracao>

• Utilizada para refatorações de código sem alterar o comportamento da aplicação.
• Exemplo: refactor/organiza-rotas, refactor/otimiza-queries.

style/<nome-da-alteracao>

• Utilizada para alterações de estilo ou ajustes no layout (UI/UX), sem modificar a lógica.
• Exemplo: style/pagina-servicos, style/correcoes-layout.

hotfix/<nome-do-hotfix>

• Utilizada para correções urgentes em produção.
• Deve ser criada a partir da branch main.
• Exemplo: hotfix/erro-producao, hotfix/corrige-pagamento.

release/<nome-da-versao>

• Utilizada para preparar uma versão para produção.
• Mescla develop para a criação da versão final.
• Exemplo: release/v1.0, release/v1.1.

docs/<tipo-de-documentacao>

• Utilizada para alterações em documentação (README, Wiki, etc).
• Exemplo: docs/update-readme, docs/adiciona-descricao.

Fluxo de Trabalho

1. Desenvolvimento de funcionalidades:

   • Crie uma nova branch feature a partir de develop.
   • Após concluir a funcionalidade, faça o merge de volta para develop.

2. Correções de bugs:

   • Crie uma branch fix a partir de develop ou main (dependendo da urgência).
   • Após corrigir o bug, faça o merge de volta para develop (ou main se for um hotfix).

3. Lançamento de versão:

   • Antes de lançar uma versão, crie uma branch release a partir de develop.
   • Prepare a versão e teste.
   • Após os testes, faça o merge de release em main e develop.

4. Hotfix:

   • Se houver necessidade de um hotfix urgente, crie uma branch hotfix a partir de main.
   • Após corrigir o problema, faça o merge de volta para main e develop.

5. Documentação:

   • Para atualizações na documentação (como o README.md), crie uma branch docs a partir de develop.
   • Após a alteração, faça o merge de volta para develop.

Comandos Básicos

Para criar uma branch de feature:

git checkout -b feature/nome-da-funcionalidade develop