sidney
/
edumanagerpro2
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs: update memory log and project rules with recent developments
Build and Deploy (Gitea) / build-and-deploy (push) Successful in 2m31s Details

This commit is contained in:
Sidney 2026-05-27 09:05:47 -03:00
parent 4a922f43ec
commit 37d89d690c
2 changed files with 86 additions and 77 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

10
GEMINI.md
View File

@ -71,7 +71,11 @@
41. **Database Schema Sync**: Sempre garanta que as tabelas de destino possuam colunas como `is_deleted` e demais modificadores antes de habilitar rotas PUT/DELETE, pois a ausência do schema falhará silenciosamente no Express 5.
42. **Cronological Display Standard**: Consultas a cadastros secundários (como Disciplinas e Categorias) DEVEM utilizar `ORDER BY created_at ASC` no SQL para manter a mesma ordem de listagem original do sistema (evitando reordenação alfabética não-intencional).
43. **Mass Contracts Update**: A edição de um "Modelo de Contrato" dispara atualizações em massa (PUT `/api/contratos/:id`) recalcularizando as variáveis de todos os contratos já emitidos para os alunos vinculados àquele modelo, garantindo atualização em tempo real no Portal do Aluno via SQL.
44. **Biometria SQL-First Parcial**: A biometria (faceDescriptor) já está preparada para persistência nativa na coluna jsonb 'face_descriptor' do PostgreSQL (com mapeamento camelCase na API). Contudo, o cadastro de alunos via Manager ainda não utiliza a API SQL em sua plenitude no handleSave. Até a refatoração do Students.tsx, os alunos novos continuarão dependendo do fallback do school_data.json.
45. **Forçar Fuso Horário Brasileiro na Origem**: Ao gerar datas ou horários locais no frontend para envio ao banco PostgreSQL (como registros de biometria ou ponto), é OBRIGATÓRIO forçar o cálculo no fuso 'America/Sao_Paulo' (ex: \
ew Date().toLocaleString('en-US', { timeZone: 'America/Sao_Paulo' })\). Isso evita que instâncias rodando em UTC no Windows Server ou celulares com fuso errado enviem horários defasados, o que causaria quebra em lógicas de restrição de janela de tempo (ex: horário de aula).
44. **Biometria SQL-First Parcial**: A biometria (faceDescriptor) já está preparada para persistência nativa na coluna jsonb 'face_descriptor' do PostgreSQL (com mapeamento camelCase na API). Contudo, o cadastro de alunos via Manager ainda não utiliza a API SQL em sua plenitude no handleSave. Até a refatoração do Students.tsx, os alunos novos continuarão dependendo do fallback do school_data.json.
45. **Forçar Fuso Horário Brasileiro na Origem**: Ao gerar datas ou horários locais no frontend para envio ao banco PostgreSQL (como registros de biometria ou ponto), é OBRIGATÓRIO forçar o cálculo no fuso 'America/Sao_Paulo' (ex: \
ew Date().toLocaleString('en-US', { timeZone: 'America/Sao_Paulo' })\). Isso evita que instâncias rodando em UTC no Windows Server ou celulares com fuso errado enviem horários defasados, o que causaria quebra em lógicas de restrição de janela de tempo (ex: horário de aula).
46. **Geração de Contratos Automáticos (Fase SQL-First)**: A geração de contratos no cadastro de alunos deve sincronizar diretamente no banco de dados com `POST /api/contratos` e manter fallbacks no `updateData`. Além disso, para evitar contratos duplicados acidentais, o checkbox `generateContract` deve ser desmarcado por padrão ao editar um aluno, mas marcado por padrão ao cadastrar um novo aluno. O checkbox de "Gerar Taxa" foi removido.
47. **Ficha de Frequência Geral (Roster de Turma) em PDF**: O botão de exportação de PDF na lista de alunos da turma no módulo Registro de Frequência do Manager deve exportar um relatório de frequência geral de todos os alunos ativos da turma, com a contagem total acumulada de presenças (P), faltas (F), justificadas (J) e porcentagem de frequência (%) de forma a bater perfeitamente com os dados exibidos na tela, evitando PDFs vazios ou em branco para datas sem aulas.

5
MEMORY.md
View File

@ -63,3 +63,8 @@ Nesta sessão de trabalho, realizamos o "core" da transição do sistema EduMana
1. **Reverse Sync (Mão Dupla)**: Frontend salva no SQL via API e mantém backup no JSON.
2. **Fallback Gradual**: Portal prioriza SQL, invoca JSON apenas se banco retornar vazio.
3. **Migração de Dados**: Executada via script Node.js conectando diretamente ao PostgreSQL de produção (host: `150.230.87.131`, user: `edumanager`).
### Fase 8: Consolidação de Frequência, Registro de Matrículas e Contratos Relacionais
- **Justificativa Única Rígida (Portal)**: Implementação de regra de validação rígida impedindo que o aluno envie mais de uma justificativa por aula. O Portal do Aluno agora exibe um aviso dinâmico informando que a aula já possui justificativa e desativa o envio. O backend valida a existência e retorna erro HTTP 400.
- **Sincronização Direta de Contratos (Manager)**: O fluxo de salvamento de matrículas foi aprimorado para disparar uma chamada de `POST /api/contratos` em tempo real ao salvar o aluno, escrevendo a emissão do contrato diretamente no PostgreSQL na VPS.
- **Refinamento do Modal de Alunos (Manager)**: O checkbox "Gerar Taxa" foi inteiramente removido do modal de matrícula. O checkbox "Gerar Contrato Automático" agora vem selecionado (`true`) por padrão em novos cadastros e desmarcado (`false`) ao editar matrículas para prevenir duplicações acidentais.
- **Relatório de Frequência Geral em PDF (Manager)**: Refatoração do exportador de PDF no módulo Registro de Frequência para gerar uma Ficha de Frequência Geral (Roster de todos os alunos ativos da turma, com contagem acumulada de presenças, faltas, justificativas e porcentagem de frequência de cada um) de modo a corresponder perfeitamente ao que o administrador visualiza na modal, eliminando downloads vazios.