CIPA — Microserviço de Gestão — Painel de Acompanhamento

Visão Geral

Valor central do projeto

Produzir e preservar a prova legal da CIPA — atas assinadas e imutáveis (hash SHA-256 + auditoria) e eleições com voto secreto real e apuração determinística — conforme a NR-5 e a Lei 14.457/2022, sem depender do banco da Livon.

80% concluído

Progresso geral

77/91

Requisitos concluídos

85%

6/8

Fases concluídas

75%

Decisões registradas

11 validadas

163

Eventos na timeline

desde 2026-06-26

O que é

Microserviço em Go, com banco de dados próprio (PostgreSQL), que gere o ciclo de vida completo da CIPA (Comissão Interna de Prevenção de Acidentes — segurança do trabalho) em conformidade com a NR-5 e a Lei 14.457/2022. Roda fora do monólito da Livon (plataforma EHS Django/Nuxt) e integra com ela 100% via API REST: o dado da CIPA (eleições, atas, reuniões, riscos, denúncias) é do microserviço; quem é o usuário, de qual empresa e a lista de colaboradores vêm da Livon pela API. É um backend (API); as telas pertencem à camada Livon/Nuxt.

Contexto

Plataforma Livon: EHS/saúde ocupacional brasileira, monólito Django 4.1 + DRF + PostgreSQL (backend) e Nuxt 2/Vue 2 (frontend), auth Keycloak OIDC, multi-tenant (Tenant/appGH Company→Unit). A CIPA é greenfield na Livon — não existe módulo CIPA/NR-5 hoje (só duas flags is_candidate_to_cipa/is_elected_to_cipa em appUser.User).
Origem do domínio: um protótipo Lovable (React/Supabase, livon-cipa-hub, ~30 tabelas, RLS) foi submetido a engenharia reversa (_reversa_sdd/). O protótipo é fonte derivada e incompleta — as regras autoritativas NR-5 + Lei 14.457 prevalecem sobre ele.
Realidade da integração (sem achismo): "100% via API puro" não é totalmente viável hoje. A auth de sistema da Livon (ClientIntegrationAuthentication) só cobre poucos endpoints; as leituras que a CIPA precisa exigem usuário logado. Padrão que funciona: pass-through do token Keycloak do usuário. A integração é bidirecional (consumir + legar) e exige construir endpoints no lado da Livon (mapeada e rodando local; merge/UAT oficial é o passo final).
Lei 14.457/2022: área inteira (canal de denúncia anônimo + treinamento anual de assédio) que o protótipo não tinha — adicionada às regras autoritativas.
Estado atual do código: Fases 0–3, 5 e 6 prontas e verificadas (fundação, observabilidade, auth/ACL/RBAC, riscos/sugestões, reuniões/atas, o ciclo eleitoral completo, e comunicação/SIPAT/canal de denúncia). Fase 4 (integração Livon) implementada do lado CIPA, gated pelos endpoints reais da Livon: ListEligibleVoters, GetCompanyHeadcount e GetUnit retornam ErrLivonEndpointNotAvailable — gate real para a integração end-to-end das Fases 4–5, não para o código do lado CIPA. Falta apenas a Fase 7 (IA) para completar o roadmap v1.
Gate de processo (regra dura): nenhuma execução de código de feature começa antes de o Bruno revisar e aprovar a visão geral consolidada das fases. As Fases 0–1 ficam como estão.

Especificação Funcional

Todos os 91 requisitos da v1, agrupados por categoria. 77 já entregues e verificados (Fases 0–1).

Authentication AUTH

4/4

✓ AUTH-01 O serviço valida localmente o token Keycloak (Bearer JWT) por JWKS — assinatura, iss, aud e exp; token inválido/expirado retorna 401
✓ AUTH-02 O serviço extrai um Principal (livon_user_id=sub, email, empresa, unidade, roles) do token e o expõe em GET /api/v1/me
✓ AUTH-03 O token do usuário é repassado (pass-through) às chamadas da API da Livon (GET /api/v1/livon/me resolve o colaborador via ACL)
✓ AUTH-04 Em modo dev (AUTH_ENABLED=false), o serviço injeta um Principal sintético (admin) sem validar token

Authorization / RBAC RBAC

4/5

✓ RBAC-01 O serviço combina papéis do token (realm_access.roles) com o RBAC próprio persistido (cipa_role_assignments: admin, it_admin, cipa_member, president, secretary, auditor)
✓ RBAC-02 Endpoints protegidos exigem papel via middleware RequireRole; acesso é negado por padrão (defesa no servidor, não cosmética)
✓ RBAC-03 Toda autorização é escopada por empresa/unidade (tenant); um usuário só acessa recursos da própria empresa/unidade
✓ RBAC-04 Papéis funcionais (presidente, secretário, membro) são derivados do mandato vigente (cipa_members) e concedem permissões operacionais (criar reunião/ata, triar sugestões)
○ RBAC-05 Auditor tem acesso somente-leitura às trilhas (atas, eleições, acessos), sem escrita em nenhum recurso

Livon Integration INTEG

11/13

✓ INTEG-01 Todo acesso à Livon passa pela camada anticorrupção (LivonClient); DTOs da Livon nunca vazam ao domínio
✓ INTEG-02 O cliente HTTP da Livon tem circuit breaker, retry, timeout, cache efêmero (~60s) e singleflight; nenhum dado da Livon é persistido
✓ INTEG-03 GetEmployee consome GET /users/user_information com pass-through do Bearer do usuário
✓ INTEG-04 ListEligibleVoters retorna colaboradores elegíveis por empresa/unidade com campos eleitorais (endpoint a construir na Livon)
✓ INTEG-05 GetCompanyHeadcount retorna nº de empregados + grau de risco (NR-4) por empresa/unidade, base do dimensionamento (endpoint a construir na Livon)
✓ INTEG-06 GetUnit retorna dados da unidade/estabelecimento (endpoint a construir na Livon)
○ INTEG-07 Trilha de auth de sistema para leituras sem usuário logado (rotinas/jobs) — bloqueador, a construir na Livon
✓ INTEG-08 A CIPA enfileira no outbox idempotente o resultado da eleição/mandato para gravar de volta na Livon (flags is_candidate_to_cipa/is_elected_to_cipa ou recurso de "mandato CIPA"); publisher reenvia sozinho quando o endpoint existir
○ INTEG-09 Registro do módulo CIPA + entitlement por empresa (CompanyLinkedModule) e permissões na Livon
✓ INTEG-10 Webhook de admissão/desligamento mantém a elegibilidade/membros atualizados (sem dado defasado)
✓ INTEG-11 Operações autoritativas (homologar eleição) não travam se a Livon estiver indisponível — homologação roda local/atômica e o outbox idempotente reenvia sozinho (V-4); decisão de design: "falha aberta localmente, nunca perde o registro", documentada no Plan 05-06/05-07
✓ INTEG-12 Toda chamada à Livon padroniza o tenant via X-Company-Id
✓ INTEG-13 Documento "Contrato de Integração Livon" lista todos os endpoints consumidos e gravados (existentes vs a construir), servindo de spec do lado da Livon

Risk Map RISK

5/5

✓ RISK-01 Usuário (admin/cipa_member) pode criar áreas de risco e itens de risco vinculados a empresa/unidade
✓ RISK-02 Item de risco tem severidade (baixo/médio/alto/crítico) × probabilidade (raro…certo); o nível de risco (1–20) é calculado automaticamente
✓ RISK-03 Item de risco tem tipo (físico/químico/biológico/ergonômico/acidente)
✓ RISK-04 Item de risco transiciona por estados (identificado → sob controle → mitigado → eliminado)
✓ RISK-05 Usuário pode visualizar o mapa de riscos com bandas por nível

Suggestions SUGG

6/6

✓ SUGG-01 Colaborador pode enviar sugestão identificada ou anônima (anônima = sem vínculo ao autor)
✓ SUGG-02 Sugestão tem categoria e segue máquina de estados (nova → em análise → em deliberação → concluída → arquivada) com transições válidas impostas
✓ SUGG-03 Nova sugestão notifica os membros CIPA ativos sem vazar o autor
✓ SUGG-04 Membro/admin pode triar a sugestão (categoria, prioridade, resposta) e o revisor (reviewed_by) é registrado
✓ SUGG-05 Colaborador vê apenas as próprias sugestões na visão pública
✓ SUGG-06 Sugestão pode ser vinculada a uma deliberação de ata (opcional)

Meetings MEET

6/8

✓ MEET-01 Usuário (admin/cipa_member) pode agendar reunião (ordinária/extraordinária) com data futura, pauta e participantes
✓ MEET-02 Reunião segue estados agendada → em andamento → concluída, com ramo cancelada
○ MEET-03 O sistema alerta o compliance de periodicidade: ordinária mensal (bimestral para ME/EPP grau 1–2); ata assinada pelos presentes
✓ MEET-04 O quórum da reunião é configurável (Regimento Interno; default maioria absoluta = membros ativos/2 + 1) e calculado pelos presentes
✓ MEET-05 O quórum pode ser dispensado com justificativa registrada
○ MEET-06 Agendar reunião gera convocação/notificação a cada participante
✓ MEET-07 Usuário registra presença (presente/ausente/atrasado/justificado); ausência de titular exige justificativa
✓ MEET-08 Reunião tem plano de ação com responsável, prazo, prioridade e status

Minutes / Atas ATA

7/12

✓ ATA-01 Usuário pode criar uma ata a partir de reunião concluída/em andamento que ainda não tem ata (relação 1:1)
○ ATA-02 A ata é pré-preenchida com pauta e participantes presentes/ausentes (com justificativa) da reunião
✓ ATA-03 A ata recebe numeração automática única ATA-<UNIDADE>-<ANO>-<SEQ> por unidade+ano (sem corrida)
✓ ATA-04 A ata é máquina de estados rica: rascunho → em revisão → em aprovação → assinado → publicado → arquivado, com → retificado (nova versão); transições são métodos com invariantes
✓ ATA-05 A ata não pode ser assinada sem número + quórum atingido + ≥1 deliberação
✓ ATA-06 Ao assinar, o serviço calcula o hash SHA-256 do conteúdo canônico e registra a assinatura (minute_signatures: signed_at, IP, user_agent); a ata assinada torna-se imutável
○ ATA-07 A ata pode ser enviada para aprovação e o presidente é notificado
○ ATA-08 A ata assinada não pode ser editada — apenas retificada (nova versão com parent_version_id, version++; a anterior vira retificado; ambas acessíveis)
✓ ATA-09 Toda transição/edição/assinatura/publicação grava ata_audit_log
○ ATA-10 A ata tem retenção legal de 5 anos (retention_until); ao vencer é arquivada, nunca deletada
✓ ATA-11 Toda deliberação segue 5W2H (what/who/when/where/why/how/howMuch) com status; concluir deliberação com evidence_required exige anexo
○ ATA-12 A ata publicada gera PDF com o hash no rodapé e um resumo

Elections ELEC

10/10

✓ ELEC-01 Admin pode abrir eleição que segue o ciclo NR-5: convocação (edital) → inscrição → campanha → votação → apuração → posse
✓ ELEC-02 O edital é publicado ≥45 dias antes do fim do mandato; votação ≥30 dias antes; inscrição de candidatos ≥15 dias; posse até o fim do mandato anterior; o sistema alerta os prazos
✓ ELEC-03 O dimensionamento usa o Quadro I da NR-5 (nº de empregados × grau de risco 1–4) para titulares + suplentes; override exige justificativa
✓ ELEC-04 Colaborador elegível pode se candidatar (1 candidatura por pessoa por eleição); a elegibilidade valida ≥90 dias de casa, ativo (sem aviso prévio) e não-chefia
✓ ELEC-05 Candidatura nasce pendente; admin aprova ou rejeita (motivo obrigatório)
✓ ELEC-06 Eleitor apto vota uma única vez por eleição (voto único garantido por unicidade no log de votantes)
✓ ELEC-07 O voto é secreto de verdade: o log de votantes (quem votou) é desvinculado da cédula (sem identidade); a cédula não é auditada
✓ ELEC-08 A apuração é serviço de domínio determinístico: contagem → desempate NR-5 (tempo de casa/idade/sorteio auditável) → atribuição titular/suplente → homologação
✓ ELEC-09 A homologação cria os cipa_members (mandato) e enfileira o resultado no outbox idempotente para gravar de volta na Livon
✓ ELEC-10 Toda operação de eleição/candidatura é auditada; o voto não é auditado (sigilo)

Members / Mandate MEMB

8/8

✓ MEMB-01 Mandato = 1 ano, com 1 reeleição (máx. 2 consecutivos); 2 anos só via convenção coletiva
✓ MEMB-02 O sistema rastreia a estabilidade do membro: da candidatura até 1 ano após o fim do mandato (titulares e suplentes que exerceram)
✓ MEMB-03 A posse é bloqueada até o membro concluir o treinamento NR-5 (8/12/16/20h conforme grau de risco), antes da posse (até 30 dias após, se eleição extraordinária)
✓ MEMB-04 Membro segue estados ativo → inativo/suspenso/substituído; vacância convoca o suplente
✓ MEMB-05 O sistema alerta a expiração de mandato (faixas 30/60/90 dias)
✓ MEMB-06 A composição é paritária (representantes do empregador × dos empregados)
✓ MEMB-07 Empresa ≤19 empregados (ou ≤20 grau 1–2) designa 1 responsável (designado), sem eleição, mas com treinamento e atribuições
✓ MEMB-08 Em registros com valor jurídico (participante de ata assinada, candidato homologado), grava-se um snapshot de nome/matrícula do momento do evento

Communication COMM

4/4

✓ COMM-01 Usuário (admin/cipa_member) pode criar comunicado (nasce rascunho) e publicá-lo (ação separada)
✓ COMM-02 Usuário confirma ciência por ação afirmativa ("Li e estou ciente"); a leitura é idempotente (1 por usuário+comunicado)
✓ COMM-03 Comunicado tem visibilidade (aberto/cipa_only) e segmentação de público
✓ COMM-04 O dashboard mostra a taxa de leitura (derivada dos registros de leitura)

SIPAT SIPAT

2/2

✓ SIPAT-01 Usuário pode planejar e gerir a SIPAT anual, com mínimo de 5 dias consecutivos
✓ SIPAT-02 Comunicados podem ser agrupados em campanha (SIPAT / mês temático)

Harassment — Lei 14.457/2022 HARASS

4/4

✓ HARASS-01 O sistema oferece um canal de denúncia anônimo de assédio/violência, com proteção anti-retaliação
✓ HARASS-02 As regras de conduta sobre assédio são divulgadas e incluídas no regimento da CIPA
✓ HARASS-03 O sistema gerencia o treinamento anual sobre assédio/violência/diversidade (registro + alerta)
✓ HARASS-04 A denúncia segue um fluxo de triagem confidencial, com acesso restrito

Observability OBS

6/6

✓ OBS-01 O serviço expõe GET /healthz (liveness) e GET /readyz (readiness, checa banco; Livon é dependência soft)
✓ OBS-02 O serviço exporta traces via OTLP; cada request HTTP vira um trace com spans de banco (visível no Grafana/Tempo)
✓ OBS-03 Logs em slog JSON com trace_id/span_id (stdout; pipeline OTLP→Loki pré-configurado)
✓ OBS-04 A stack (Prometheus/Loki/Tempo/Grafana) sobe via docker compose com dashboards/datasources provisionados
✓ OBS-05 O serviço exporta métricas RED + de domínio (atas pendentes, estado do breaker Livon, p95 da apuração) via MeterProvider
✓ OBS-06 Logs são enviados via OTLP (log bridge) ao Loki

AI AI

0/4

○ AI-01 A IA gera rascunho de ata (entra como rascunho; humano revisa; IA nunca assina/aprova)
○ AI-02 A IA classifica sugestões
○ AI-03 A IA apoia a análise de risco
○ AI-04 PII é pseudonimizada antes do prompt; acesso é registrado; opt-out por empresa; saída marcada como "sugestão de IA"; provedor com no-train/zero-retention

Especificação Técnica

Pilares da arquitetura

⬡

Arquitetura Hexagonal

Ports & adapters: o domínio (regras legais) fica no centro e não depende de banco, web ou Livon. Tudo aponta para dentro.

⇄

100% via API

Zero acesso ao banco da Livon. Identidade e colaboradores vêm por API REST (bidirecional); o dado da CIPA é do microserviço.

📡

Observabilidade dia 1

Traces, logs e métricas desde a Fase 0 (OpenTelemetry → Grafana/Tempo/Loki/Prometheus). Cada request é rastreável ponta a ponta.

🔒

Prova legal

Ata com hash SHA-256, imutável e auditável; voto secreto real. A peça jurídica é blindada por design, não por confiança.

Decisões técnicas (Key Decisions)

Validada

Microserviço Go + banco Postgres próprio

Independência de deploy/evolução; stack escolhida; regras legais explícitas (sem ORM mágico)

✓ Good (Fase 0 roda)

Revisar

Integração 100% via API com a Livon (bidirecional)

Não acoplar ao banco da Livon; respeitar LGPD; consumir + legar

⚠️ Revisit (depende de endpoints a construir + contrato/SLA)

Validada

Pass-through do token Keycloak do usuário

Auth de sistema da Livon só cobre poucos endpoints; pass-through resolve identidade+papel+empresa de uma vez, continua "via API"

✓ Good (Fase 1)

Validada

Observabilidade desde o dia 1

Operação e diagnóstico de fluxos críticos (apuração, ata) desde o início

✓ Good (traces ponta a ponta; métricas/logs OTLP pendentes)

Pendente

IA isolada (Anthropic) na camada `app`, nunca no domínio

IA assistiva, nunca autoritativa (não assina/aprova); LGPD (pseudonimização, no-train)

— Pending (Fase 7)

Validada

Quórum configurável (Regimento Interno)

A NR-5 não fixa percentual; resolve o conflito de quórum do protótipo (não hardcodar)

✓ Good (Fase 3)

Validada

Regras NR-5 / Lei 14.457 acima do protótipo

Protótipo é fonte derivada e incompleta (errou estabilidade, ignorou grau de risco, sem assédio)

✓ Good (fundação Fases 0–1 é agnóstica de regra)

Validada

Voto secreto real — `election_voter_log` (quem votou) desvinculado de `election_ballots` (cédula sem identidade)

Supera o protótipo, que só escondia por RLS

✓ Good (Fase 5; voto atômico sem FK cruzada também na persistência)

Validada

Ata como máquina de estados com hash SHA-256 + auditoria + imutabilidade + retificação versionada

Materializa a prova legal que o protótipo prometia mas não implementava

✓ Good (Fase 3; retificação completa e PDF diferidos)

Validada

SIPAT ≥5 dias é regra de produto, não legal

Nem a Lei 14.457 (Art. 23) nem a NR-5 fixam número de dias — confirmado lendo o texto oficial; "5 dias" é convenção de mercado. Manter sem alegar base legal falsa

✓ Good (Fase 6, decisão D-04b)

Validada

Canal de denúncia com sigilo estrutural (não criptografia)

Mesmo padrão já comprovado em suggestions (Fase 2) e elections (Fase 5): ausência de campo de correlação, não cifragem

✓ Good (Fase 6)

Validada

Auth via Keycloak com validação local (JWKS) + RBAC próprio escopado por empresa

Autenticação na Livon; autorização na CIPA (papéis funcionais via cipa_members)

✓ Good (Fase 1)

Validada

Dimensionamento via Quadro I (nº empregados × grau de risco NR-4)

Protótipo ignorava o grau de risco; depende de headcount + grau vindos da Livon

✓ Good (Fase 5; Quadro I codificado célula a célula contra NR05-QUADRO-I-VERIFICADO.md)

Pendente

Snapshots legais de PII (nome/matrícula no momento do evento)

Blinda registros jurídicos contra anonimização LGPD futura na Livon; não é cópia/sync

— Pending

Restrições & arquitetura

Tech stack

Go (net/http Go 1.22 + chi, pgx/v5 + sqlc, goose, go-oidc+jwx, gobreaker+go-retryablehttp, anthropic-sdk-go) — decisão de stack e ausência de ORM mágico (regras legais explícitas)

Banco

PostgreSQL próprio do microserviço, um schema por bounded context; IDs externos opacos da Livon (livon_user_id/livon_company_id/livon_unit_id, sem FK física) — independência do banco da Livon

Integração

100% via API REST com a Livon, bidirecional; sem DB direto, sem cópia persistente — independência e LGPD

Compliance

NR-5 (vigente 2023) + Lei 14.457/2022 + LGPD são regras autoritativas acima do protótipo — risco legal/trabalhista

Dependência

endpoints a construir no lado da Livon + contrato/SLA por escrito antes da Fase 4 — bloqueia a apuração eleitoral (dados de colaboradores/headcount/grau de risco)

Segurança (Livon)

exigir JWT_SECRET separado do SECRET_KEY (P838), JWT com iss/aud/nbf/iat (P839), aplicar quota (P840) antes de produção

Infra/Deploy

Docker + Portainer na VPS Contabo; 3 ambientes (local / dev-VPS / banco estável p/ versionamento); futuro: plugar na Livon (AWS/Keycloak)

Fases técnicas

0Fundação, Observabilidade e DockerConcluída

Esqueleto hexagonal roda em containers com observabilidade ponta a ponta desde o dia 1 (CONCLUÍDA)

OBS-01OBS-02OBS-03OBS-04

1Autenticação, ACL Livon e RBACConcluída

Usuário autentica via Keycloak e o serviço autoriza por papel, falando com a Livon pela camada anticorrupção (CONCLUÍDA)

AUTH-01AUTH-02AUTH-03AUTH-04RBAC-01RBAC-02INTEG-01INTEG-02INTEG-03

2Mapa de Riscos e SugestõesConcluída

Entregar valor cedo com módulos de baixo acoplamento à Livon (só livon_user_id), escopados por tenant

RISK-01RISK-02RISK-03RISK-04RISK-05SUGG-01SUGG-02SUGG-03SUGG-04SUGG-05SUGG-06RBAC-03OBS-06

3Reuniões e AtasConcluída

Produzir e preservar a prova legal — atas assinadas, imutáveis e auditáveis a partir de reuniões com quórum

MEET-01MEET-02MEET-03MEET-04MEET-05MEET-06MEET-07MEET-08ATA-01ATA-02ATA-03ATA-04ATA-05ATA-06ATA-07ATA-08ATA-09ATA-10ATA-11ATA-12RBAC-05

4Contrato de Integração Livon (bidirecional)Planejada

Firmar e implementar o contrato bidirecional com a Livon (consumir + legar) que destrava a apuração eleitoral

INTEG-04INTEG-05INTEG-06INTEG-07INTEG-08INTEG-09INTEG-10INTEG-11INTEG-12INTEG-13

5Eleições, Apuração e Membros/MandatoConcluída

Conduzir eleições NR-5 com voto secreto real, apuração determinística e gestão completa de mandato (incluindo designado)

ELEC-01ELEC-02ELEC-03ELEC-04ELEC-05ELEC-06ELEC-07ELEC-08ELEC-09ELEC-10MEMB-01MEMB-02MEMB-03MEMB-04MEMB-05MEMB-06MEMB-07MEMB-08RBAC-04OBS-05

6Comunicação, SIPAT e Canal de Denúncia (Lei 14.457)Concluída

Engajamento e conformidade com a Lei 14.457 — comunicados com ciência afirmativa, SIPAT anual e canal anônimo de assédio

COMM-01COMM-02COMM-03COMM-04SIPAT-01SIPAT-02HARASS-01HARASS-02HARASS-03HARASS-04

7IA (Anthropic)Planejada

IA assistiva isolada na camada app, nunca autoritativa, com salvaguardas LGPD

AI-01AI-02AI-03AI-04

Visão Unificada

A mesma engenharia, em linguagem simples — o lado funcional (o que faz) e o técnico (como faz), com analogias do dia a dia.

🛡️

O que é a CIPA?

É a comissão eleita pelos próprios colegas para cuidar da segurança no trabalho. Pense num 'conselho de segurança' interno, obrigatório por lei (NR-5), que se reúne, registra atas e propõe melhorias.

🏠

Por que um sistema separado?

Em vez de mexer na casa principal (a plataforma Livon), construímos um puxadinho especializado ao lado, com sua própria fechadura e seu próprio armário (banco). Os dois conversam por uma ponte (API) — mais seguro e fácil de evoluir.

🗄️

A ata como cofre lacrado

Quando a ata é assinada, o sistema gera um 'lacre digital' (hash SHA-256). A partir daí vira documento de cartório: ninguém edita. Se precisar corrigir, anexa-se uma nova versão e a antiga fica preservada.

🗳️

Voto secreto de verdade

São duas urnas separadas: uma lista de quem votou (para garantir voto único) e outra com os votos sem nome. Ninguém consegue juntar as duas — o sigilo é real, não só uma tela escondida.

📐

Eleição por tamanho da empresa

O Quadro I da NR-5 é uma tabela que decide quantos membros a CIPA terá, conforme o número de funcionários e o grau de perigo do ramo. O sistema calcula isso automaticamente.

✈️

Caixa-preta do avião

Como a caixa-preta registra tudo num voo, a observabilidade grava cada passo do sistema (rastros, logs, métricas). Se algo falhar numa apuração ou ata, dá para reconstituir o que aconteceu.

📮

Canal de denúncia anônimo

A Lei 14.457/2022 exige um canal anônimo contra assédio. É como uma caixa de correio lacrada: a pessoa denuncia sem se identificar e fica protegida de retaliação.

🤝

IA como estagiário

A inteligência artificial escreve rascunhos (de ata, de classificação), mas nunca assina nem aprova nada. Um humano sempre revisa e decide — a IA é assistente, jamais autoridade.

Tecnologias

Stack do microserviço e das ferramentas de engenharia que o produziram.

Linguagens & Core

Gonet/http 1.22 + chi

Node.jsgerador do painel

Dados & Persistência

PostgreSQLbanco próprio

pgx/v5driver

sqlcSQL tipado

goosemigrations embutidas

Observabilidade

OpenTelemetrytraces OTLP

Grafanadashboards

Prometheusmétricas

Lokilogs

Tempotracing

slogJSON estruturado

IA & LLM

Anthropic / Claudeanthropic-sdk-go

Langfuseobservabilidade de LLM

Auth & Segurança

Keycloak / OIDCidentidade

JWKSgo-oidc + jwx

RBAC próprioescopado por empresa

gobreakercircuit breaker

go-retryablehttpretry/timeout

Infra & Deploy

Dockerdistroless não-root

Portainerdeploy de stacks

VPS Contabo3 ambientes

GitHub ActionsCI/CD

Meta-tools (engenharia)

Claude Codeagente de engenharia

GSDplanejamento por fases

Reversaengenharia reversa

graphifyknowledge graph

Timeline

Linha do tempo do projeto — etapas, decisões e builds com data e hora.

⚙

2026-06-26 · 09:00SetupSetup

graphify e reversa instalados no projeto

Ferramentas de knowledge graph e engenharia reversa habilitadas no repositório CIPA.

◎

2026-06-26 · 09:30PesquisaReversa

Engenharia reversa do protótipo (reversa)

Scout → 11 Arqueólogos em paralelo → Data Master → Design System → Detetive → Arquiteto → 11 Redatores → Revisor. Saída: _reversa_sdd/ (198 docs).

◆

2026-06-26 · 10:00DecisãoReversa

Nível de documentação: Detalhado

Specs por módulo, execução em paralelo.

◆

2026-06-26 · 11:00DecisãoReversa

Escavação dos módulos → paralelo

11 módulos analisados simultaneamente por arqueólogos dedicados.

◆

2026-06-27 · 09:00DecisãoArquitetura

Arquitetura: microserviço Go independente

Banco próprio, integração 100% via API com a Livon (bidirecional).

◆

2026-06-27 · 09:30DecisãoArquitetura

Dados da CIPA → banco próprio

PostgreSQL do microserviço, um schema por bounded context; IDs opacos da Livon sem FK física.

▤

2026-06-27 · 10:30BuildFase 0

Fase 0 (Fundação) concluída

Esqueleto hexagonal + observabilidade (Grafana/OTel/Loki/Tempo/Prometheus) + Docker. Testada.

▤

2026-06-27 · 13:00BuildFase 1

Fase 1 (Auth+ACL+RBAC) concluída

Validação token Keycloak (JWKS) + ACL Livon mockada + RBAC próprio. 20 testes verdes.

◎

2026-06-27 · 15:00PesquisaRegras

Explore de regras autoritativas

NR-5 (2023) + Lei 14.457/2022 (assédio) + mercado.

★

2026-06-27 · 17:49MarcoGSD

GSD iniciado

config + PROJECT.md + REQUIREMENTS.md (91 requisitos) + ROADMAP.md (8 fases).

●

2026-06-27 · 17:49Commit

chore: add project config

commit 152bbc1

●

2026-06-27 · 17:55Commit

docs: define v1 requirements

commit 1ca8dab

●

2026-06-27 · 17:55Commit

docs: initialize project

commit f8cc6d2

◆

2026-06-28 · 10:00DecisãoPainel

Painel → VPS Contabo + HTML único

Dashboard auto-contido publicado via Portainer para acompanhamento em tempo real.

▤

2026-06-28 · 11:00BuildPainel

Painel de acompanhamento (gsd-dashboard) construído

Skill reutilizável gera dashboard executivo a partir da estrutura .planning/*.

●

2026-06-29 · 10:16Commit

docs(state): record phase 2 context session

commit fe10b60

●

2026-06-29 · 10:16Commit

docs(02): capture phase context

commit b1f6a32

●

2026-06-29 · 10:38Commit

docs(phase-02): research mapa de riscos e sugestões

commit 9fdec45

●

2026-06-29 · 10:39Commit

docs(phase-2): add validation strategy

commit 3368331

●

2026-06-29 · 11:00Commit

docs(phase-2): add 6 plans for risk map and suggestions

commit eb5e45f

●

2026-06-29 · 11:09Commit

feat(02-01): migration 00003 — tabelas risk_areas e risk_items com GENERATED risk_level

commit 8a57597

●

2026-06-29 · 11:10Commit

test(02-01): add failing tests for BandFromLevel, RiskLevel, Transition, TransitionInvalid

commit 5408f14

●

2026-06-29 · 11:12Commit

feat(02-01): domínio risk — Severity, Probability, RiskType, BandFromLevel, Transition

commit acf094f

●

2026-06-29 · 11:14Commit

docs(02-01): complete risk domain foundation plan — migration + domain TDD

commit 57096fd

●

2026-06-29 · 11:27Commit

feat(02-03): migration 00004_suggestions — suggestions + cipa_notifications com anonimato por design

commit 2532739

●

2026-06-29 · 11:28Commit

test(02-03): add failing tests for suggestions domain (RED)

commit 629f7d1

●

2026-06-29 · 11:29Commit

feat(02-03): domínio suggestions — máquina de estados + construtores anonimato (GREEN)

commit cec7530

●

2026-06-29 · 11:31Commit

docs(02-03): complete suggestions domain plan — SUMMARY, STATE e ROADMAP atualizados

commit 0044ada

●

2026-06-29 · 11:34Commit

feat(02-05): estender Setup com LoggerProvider + bridge otelslog (OBS-06)

commit 358620b

●

2026-06-29 · 11:35Commit

test(02-05): adicionar testes do Setup — no-op sem endpoint e drenagem do LoggerProvider

commit bb187ea

●

2026-06-29 · 11:37Commit

docs(02-05): complete observability LoggerProvider plan — SUMMARY, STATE, ROADMAP atualizados

commit 84aaef7

●

2026-06-29 · 11:41Commit

feat(02-02): portas RiskAreaRepository/RiskItemRepository + adaptador pgx escopado por tenant

commit ad39854

●

2026-06-29 · 11:42Commit

feat(02-02): casos de uso app/risk — CreateArea, CreateItem, TransitionItem, ListRiskMap

commit 42afa1d

●

2026-06-29 · 11:45Commit

feat(02-02): handlers HTTP Mapa de Riscos — mountRiskRoutes, leitura escopada, escrita RBAC-gated

commit 27884b6

●

2026-06-29 · 11:47Commit

docs(02-02): complete risk outer-layers plan — SUMMARY, STATE, ROADMAP, REQUIREMENTS atualizados

commit 590339b

●

2026-06-29 · 11:57Commit

feat(02-04): porta SuggestionRepository + adaptador pgx tenant-scoped

commit 517a69a

●

2026-06-29 · 11:59Commit

feat(02-04): casos de uso app/suggestions — Create/Triage/ListMine/ListInbox

commit 1e7cfcc

●

2026-06-29 · 12:01Commit

feat(02-04): handlers HTTP de Sugestões + DTOs separados (público × inbox gated)

commit 0544989

●

2026-06-29 · 12:04Commit

docs(02-04): SUMMARY + STATE + ROADMAP — Sugestões camadas externas completo

commit 18017d6

●

2026-06-29 · 12:08Commit

feat(02-06): extend RouterDeps and mountAPI with risk/suggestion modules

commit 1b35542

●

2026-06-29 · 12:09Commit

feat(02-06): wire risk/suggestion repos → services → RouterDeps in main.go

commit 71d2178

●

2026-06-29 · 12:10Commit

test(02-06): integration smoke tests for mounted routes and RBAC gate

commit ad71903

●

2026-06-29 · 12:12Commit

docs(02-06): complete final wiring plan — router/main/smoke-tests

commit 0ac4c3c

●

2026-06-29 · 12:20Commit

docs(02): add code review report — 1 critical (IDOR), 3 warnings, 3 info

commit e8036c2

▤

2026-06-29 · 17:03BuildFase 2

Fase 2 (Mapa de Riscos + Sugestões) verificada

Mapa de riscos com banda de severidade automática e canal de sugestões anônimas. 21/21 requisitos verificados; vulnerabilidades de segurança (IDOR + escrita silenciosa WR-01/02/03) fechadas com prova (faff811).

●

2026-06-29 · 17:14Commit

docs(phase-02): marcar fase 2 completa — 13 requisitos entregues e verificados

commit d47bf1b

●

2026-06-29 · 17:14Commit

fix(02): corrigir CR-01 IDOR + WR-01/02/03 e adicionar VERIFICATION.md (21/21 verified)

commit faff811

▤

2026-06-29 · 17:15BuildFase 3

Fase 3 (Reuniões + Atas) concluída

Reuniões com quórum/presença e atas imutáveis (lacre SHA-256, assinatura, máquina de estados, auditoria). 17/19 verificados; ATA-08 (retificação versionada) e ATA-12 (PDF) diferidos para a Fase 6.

●

2026-06-29 · 17:15Commit

feat: domínios extras (comms, compliance, elections, members) + artefatos de planejamento (implementado via Codax)

commit 0b8dcba

●

2026-06-29 · 17:15Commit

feat(phase-04): contrato integração Livon — client HTTP, webhook handler, mock (implementado via Codax)

commit cc3db38

●

2026-06-29 · 17:15Commit

feat(phase-03): reuniões e atas — domínio, repositórios pgx, handlers HTTP, migrations 00005-00006 (implementado via Codax)

commit e930806

▤

2026-06-29 · 17:16BuildFase 4

Fase 4 (Contrato de Integração Livon) implementada

Cliente HTTP + mock do contrato com a Livon (elegíveis, headcount, unidade, publicar mandato), com circuit breaker e retry. 6/6 verificados e 6/6 ameaças de segurança fechadas; aguardando endpoints reais da Livon (gated).

●

2026-06-29 · 17:16Commit

chore: arquivos de infra e CI do cipa-service (Dockerfile, Makefile, deploy, golangci)

commit 670e618

●

2026-06-29 · 17:27Commit

docs(04): add code review report — 2 critical (DoS + SSRF), 4 warnings

commit 9dda12f

●

2026-06-29 · 17:33Commit

fix(04): CR-02 WR-02 WR-03 WR-04 validate BaseURL, no retry on 4xx, ctx check before cache, unconditional tenant check

commit c77df4e

●

2026-06-29 · 17:33Commit

fix(04): CR-01 WR-01 limit webhook body size and use constant-time token compare

commit 349bd07

●

2026-06-29 · 17:34Commit

docs(04): add code review fix report

commit 46204f3

●

2026-06-29 · 17:46Commit

docs(phase-4): add/update security threat verification

commit 4cf24c9

●

2026-06-29 · 20:08Commit

docs(state): record phase 5 context session

commit 4638ea7

●

2026-06-29 · 20:08Commit

docs(05): capture phase context

commit 1d9b3a8

◆

2026-06-29 · 23:08DecisãoFase 5

Fase 5 (Eleições, Apuração e Mandato) discutida

Contexto e 16 decisões definidos: voto secreto real (duas urnas), dimensionamento pelo Quadro I da NR-5, desempate auditável com sorteio reconferível, posse condicionada a treinamento. Pronta para planejar.

●

2026-06-30 · 09:49Commit

docs(02-04): restaurar SUMMARY órfão da migração de caminho

commit e0b50a9

★

2026-06-30 · 10:24MarcoGSD

Documentação reconciliada + registro único de pendências

STATE/REQUIREMENTS/ROADMAP alinhados à realidade (50% · 4 fases concluídas) e criado o OPEN-ITEMS.md como fonte única de pendências — nada silenciosamente aberto, cada item com dono. Commit d2e69ca.

●

2026-06-30 · 10:24Commit

docs(planning): reconciliar STATE/REQUIREMENTS/ROADMAP à realidade + registro OPEN-ITEMS

commit d2e69ca

●

2026-06-30 · 13:51Commit

docs(05): research phase 5 — elections, apuração, membros/mandato

commit 8bfa0a2

●

2026-06-30 · 14:09Commit

docs(05): research + Quadro I NR-5 verificado na fonte oficial + validação

commit fd3caa7

●

2026-06-30 · 14:11Commit

docs(roadmap): alinhar success criteria da Fase 5 aos fatos NR-5 verificados

commit e64d95b

●

2026-06-30 · 14:32Commit

docs(05): completar planos 06 (homologação/RBAC/OBS) e 07 (wiring/smoke)

commit b9fcb3a

●

2026-06-30 · 14:50Commit

docs(05): resolver findings do plan-checker — split do Plan 06, refs e validação

commit 454562f

●

2026-06-30 · 15:05Commit

feat(05-01): migration 00007 — schema elections com voto secreto estrutural

commit da6c230

●

2026-06-30 · 15:08Commit

chore(05-01): restaurar arquivos de planejamento deletados acidentalmente pelo reset --soft

commit 7b54697

●

2026-06-30 · 15:10Commit

feat(05-01): migration 00008 — schema members com mandato, treinamento e outbox

commit e843526

●

2026-06-30 · 15:14Commit

test(05-01): testes RED Wave 0 — sizing, tally, vote, election, training, member

commit 7531fd3

●

2026-06-30 · 15:16Commit

docs(05-01): SUMMARY do plan 01 — migrations elections/members + testes RED Wave 0

commit a7410cb

●

2026-06-30 · 15:18Commit

chore(05-01): restore orchestrator STATE.md and ROADMAP.md after worktree merge

commit 10e7939

●

2026-06-30 · 15:36Commit

feat(05-02): dimensionamento Quadro I (sizing.go)

commit a8177c3

●

2026-06-30 · 15:37Commit

feat(05-03): gate de treinamento NR-5 por grau de risco (training.go)

commit 57846d7

●

2026-06-30 · 15:38Commit

feat(05-03): máquina de estados do membro e snapshots legais (member.go)

commit d5d5474

●

2026-06-30 · 15:40Commit

feat(05-02): máquina de estados, candidatura e voto secreto estrutural

commit f0ba5e8

●

2026-06-30 · 15:40Commit

feat(05-03): mandato, estabilidade, reeleição e designado (mandate.go, designated.go)

commit 5b85184

●

2026-06-30 · 15:41Commit

docs(05-03): SUMMARY do plan 03 — domínio de membros e mandato (NR-5)

commit b57dc62

●

2026-06-30 · 15:43Commit

feat(05-02): apuração determinística com desempate auditável (tally.go)

commit 4035d4c

●

2026-06-30 · 15:45Commit

docs(05-02): SUMMARY do plan 02 — domínio de eleições (sizing/election/candidate/vote/tally)

commit 655dcd2

●

2026-06-30 · 15:46Commit

chore: merge executor worktree (worktree-agent-a47935c073dfc78ed)

commit 6a5c554

●

2026-06-30 · 15:47Commit

docs(05): Wave 1 concluída — planos 05-02 (eleições) e 05-03 (membros) GREEN

commit db47bef

●

2026-06-30 · 16:09Commit

feat(05-05): porta MemberRepository + casos de uso de membros/mandato

commit ca88ed5

●

2026-06-30 · 16:11Commit

feat(05-05): repositório Postgres de membros (MemberRepo)

commit 0c709a1

●

2026-06-30 · 16:11Commit

feat(05-04): porta ElectionRepository + casos de uso de eleicoes (app/elections)

commit ca61847

●

2026-06-30 · 17:33Commit

chore(05-04): gofmt em arquivos pré-existentes

commit 5efc684

●

2026-06-30 · 17:33Commit

feat(05-04): handlers HTTP de eleição com RBAC e voto preso ao Principal (election_handler.go)

commit cdb7682

●

2026-06-30 · 17:33Commit

feat(05-04): repositório Postgres com voto atômico sem FK cruzada (election_repository.go)

commit 5739f35

●

2026-06-30 · 17:34Commit

docs(05-04): SUMMARY do plan 04 — eleições conectadas (ports/app/postgres/http)

commit 74128de

●

2026-06-30 · 17:36Commit

feat(05-05): handlers HTTP de membros com gate de posse 422 e alertas de mandato (member_handler.go)

commit eff0974

●

2026-06-30 · 17:37Commit

chore: merge executor worktree (worktree-agent-a9b8863177e2eed3c)

commit dd0d841

●

2026-06-30 · 17:37Commit

docs(05-05): SUMMARY do plan 05 — membros/mandato conectados (ports/app/postgres/http)

commit 4a4e6ce

●

2026-06-30 · 17:46Commit

feat(05-06): MeterProvider + métricas de apuração e outbox (metrics.go)

commit f175b89

●

2026-06-30 · 17:49Commit

feat(05-06): porta HomologationRepository + homologação atômica no Postgres

commit 1f01a48

●

2026-06-30 · 17:55Commit

feat(05-06): caso de uso HomologateElection + Service estendido (ELEC-08/ELEC-09/MEMB-06/MEMB-08)

commit 5be7f02

●

2026-06-30 · 17:57Commit

docs(05-06): SUMMARY do plan 06 — homologação atômica (apuração/membros/outbox)

commit 468d975

●

2026-06-30 · 18:37Commit

feat(05-07): publisher do outbox — reenvia PublishMandate/Result por kind

commit 38a23bf

●

2026-06-30 · 18:38Commit

feat(05-07): RBAC-04 — RoleResolver derivado do mandato + resolver composto

commit 367b29c

●

2026-06-30 · 18:39Commit

feat(05-07): endpoint de homologação — POST /elections/{id}/homologate

commit bc83a4c

●

2026-06-30 · 18:40Commit

docs(05-07): SUMMARY do plan 07 — plumbing da homologação (publisher/RBAC-04/endpoint)

commit d0a6cb9

●

2026-06-30 · 18:43Commit

feat(05-08): RouterDeps + mountAPI montam eleições e membros

commit 6d14ce3

●

2026-06-30 · 18:44Commit

feat(05-08): wiring main.go — Fase 5, resolver composto e publisher do outbox

commit a467e9e

●

2026-06-30 · 18:51Commit

test(05-08): smoke E2E do ciclo eleitoral no router real

commit 869bd46

●

2026-06-30 · 18:52Commit

chore(05-08): ignorar graphify-out/ (artefato gerado pelo hook do graphify)

commit 2e1bac2

●

2026-06-30 · 18:53Commit

docs(05-08): SUMMARY do plan 08 — wiring final da Fase 5 + smoke E2E

commit c65447f

●

2026-06-30 · 19:04Commit

docs(05): add code review report

commit 2729079

●

2026-06-30 · 19:08Commit

docs(05): add phase verification report (gaps found)

commit 6310554

●

2026-06-30 · 19:25Commit

docs(05-09): create gap-closure plan (CR-01 CastVote validation, WR-01 representation)

commit 9e0dd86

●

2026-06-30 · 19:29Commit

fix(05-09): CastVote valida pertencimento e aprovação do candidato (CR-01)

commit 6c60a52

●

2026-06-30 · 19:32Commit

fix(05-09): homologação usa a representação real do candidato (WR-01)

commit 13939e1

●

2026-06-30 · 19:33Commit

docs(05-09): SUMMARY do gap-closure CR-01 + WR-01

commit 9458c47

●

2026-06-30 · 19:37Commit

test(05): persist human verification items as UAT

commit b91ed34

●

2026-06-30 · 19:55Commit

docs(phase-05): complete phase execution

commit 93e8bbb

●

2026-06-30 · 19:55Commit

docs(05): registrar decisão de aceitar WR-02/WR-03/WR-05 como dívida técnica

commit be9b32d

●

2026-06-30 · 19:58Commit

docs(phase-05): evolve PROJECT.md after phase completion

commit 631de85

●

2026-06-30 · 20:16Commit

docs(05): update code review report after gap-closure (CR-01/WR-01 confirmed fixed)

commit 169f202

●

2026-06-30 · 20:23Commit

fix(05): WR-02 restrict OverrideSizing to phases before voting

commit f1e4192

●

2026-06-30 · 20:24Commit

fix(05): WR-03 guard candidate approve/reject by election phase and prior status

commit 661fee4

●

2026-06-30 · 20:25Commit

fix(05): WR-04 validate sizing/risk_degree at HTTP boundary to avoid leaking raw DB errors

commit 7c85b62

●

2026-06-30 · 20:26Commit

fix(05): WR-05 exclude already-called suplentes from NextSuplente to avoid repeat convocation

commit bf6e9a4

●

2026-06-30 · 20:27Commit

docs(05): add code review fix report

commit 8cbb97b

●

2026-06-30 · 20:35Commit

docs(05): reconciliar ROADMAP/STATE/REQUIREMENTS com a conclusão real da Fase 5

commit d0954e3

●

2026-06-30 · 20:43Commit

docs(state): record phase 6 context session

commit 5d99486

●

2026-06-30 · 20:43Commit

docs(06): capture phase context

commit 19aca66

●

2026-06-30 · 20:50Commit

docs(06): research phase domain — Lei 14.457/2022 verified, SIPAT day-count gap found

commit a976f31

●

2026-06-30 · 20:57Commit

docs(06): registrar decisão sobre duração mínima da SIPAT (D-04b)

commit ce87d94

●

2026-06-30 · 20:58Commit

docs(06): add validation strategy

commit c246381

●

2026-06-30 · 21:07Commit

docs(06): create phase plan

commit 604961a

●

2026-06-30 · 21:10Commit

docs(06): approve validation strategy after plan-checker pass

commit b8a95a2

●

2026-06-30 · 21:16Commit

feat(06-01): migration 00010 — schema comms com ciência idempotente e SIPAT D-04b

commit d38d2ac

●

2026-06-30 · 21:17Commit

feat(06-01): migration 00011 — schema compliance com denúncia anônima e trilha de acesso

commit b80d685

●

2026-06-30 · 21:19Commit

test(06-01): testes RED Wave 1 — comunicado, campaign/SIPAT, report, training

commit c08929b

●

2026-06-30 · 21:20Commit

docs(06-01): SUMMARY do plan 01 — migrations comms/compliance + testes RED Wave 1

commit 072b9be

●

2026-06-30 · 21:25Commit

feat(06-02): comunicado.go — entidade, máquina de estados, visibilidade, taxa de leitura

commit 77bcfcf

●

2026-06-30 · 21:26Commit

feat(06-02): campaign.go + acknowledgement.go — SIPAT (D-04b) e ciência

commit 228809b

●

2026-06-30 · 21:27Commit

docs(06-02): SUMMARY do plan 02 — domínio comms (Comunicado, Campaign, Acknowledgement) GREEN

commit 1344384

●

2026-06-30 · 21:27Commit

feat(06-03): training.go + papel RBAC RoleComplianceOfficer

commit b600e44

●

2026-06-30 · 21:27Commit

feat(06-03): report.go + triage.go — denúncia anônima e máquina de estados

commit dd6f2f4

●

2026-06-30 · 21:29Commit

docs(06-03): SUMMARY do plan 03 — domínio compliance/RBAC Wave 2

commit bedc89a

●

2026-06-30 · 21:31Commit

chore: merge executor worktree (worktree-agent-a39a12a061f36dfa0)

commit a4ae34c

●

2026-06-30 · 21:35Commit

feat(06-05): ports + app service de compliance (denúncia, triagem auditada, treinamento)

commit 3eb4f6a

●

2026-06-30 · 21:35Commit

feat(06-04): ports + app service de comms — casos de uso

commit a14d57b

●

2026-06-30 · 21:38Commit

feat(06-04): repositório pgx + handlers HTTP de comms (com teste de rota)

commit bcc1d02

●

2026-06-30 · 21:39Commit

docs(06-04): SUMMARY do plan 04 — comms conectado ao mundo (Wave 3)

commit 5a3835c

●

2026-06-30 · 21:39Commit

feat(06-05): repositório pgx + handlers HTTP de compliance (acesso restrito + RBAC)

commit e22a080

●

2026-06-30 · 21:41Commit

chore: merge executor worktree (worktree-agent-a13fa5ed710c13d73)

commit 3b31993

●

2026-06-30 · 21:41Commit

docs(06-05): SUMMARY do plan 05 — ports/app/postgres/http de compliance conectados

commit 4e74af0

●

2026-06-30 · 21:46Commit

feat(06-06): wiring de comms/compliance em RouterDeps/mountAPI/main.go

commit cbe4d3e

●

2026-06-30 · 21:49Commit

test(06-06): smoke E2E COMM (ciência idempotente) e HARASS (RBAC + auditoria)

commit f08e6cd

●

2026-06-30 · 21:51Commit

docs(06-06): SUMMARY do plan 06 — wiring final de comms/compliance + smoke E2E (Fase 6 completa)

commit 577f474

●

2026-06-30 · 21:56Commit

docs(06): add code review report

commit b9b06ab

●

2026-06-30 · 21:58Commit

fix(06): WR-01 audit log per item in ListReports (D-08 anti-retaliation)

commit 8e30215

●

2026-06-30 · 22:00Commit

fix(06): WR-02 map not-found errors to 404 instead of 422

commit c13cd93

●

2026-06-30 · 22:01Commit

fix(06): WR-03 add validation and length caps to NewComunicado and validateReportCommon

commit 82785d9

●

2026-06-30 · 22:02Commit

fix(06): WR-04 return 400 for invalid visibility in readRateHandler

commit 7ce00d0

●

2026-06-30 · 22:03Commit

docs(06): add code review fix report

commit 62b9eb8

●

2026-06-30 · 22:03Commit

docs(06): mark all 6 plans complete in ROADMAP

commit bb3f0b0

●

2026-06-30 · 22:07Commit

docs(06): add phase verification report (passed)

commit 1d12793

●

2026-06-30 · 22:09Commit

docs(06): reconciliar ROADMAP/STATE/REQUIREMENTS com a conclusão real da Fase 6

commit 65f02e3

●

2026-06-30 · 22:10Commit

docs(phase-06): evolve PROJECT.md after phase completion (+ fix Fase 2/3 tracking drift)

commit 065d058

Progresso

Progresso geral do projeto

80%

77/91 requisitos (85%) 6/8 fases (75%)

Requisitos — feito × pendente

Requisitos por categoria

Status das fases

Atividade por dia

Decisões por situação

Visão Geral

Produzir e preservar a prova legal da CIPA — atas assinadas e imutáveis (hash SHA-256 + auditoria) e eleições com voto secreto real e apuração determinística — conforme a NR-5 e a Lei 14.457/2022, sem depender do banco da Livon.

Especificação Funcional

Especificação Técnica

Arquitetura Hexagonal

100% via API

Observabilidade dia 1

Prova legal

Microserviço Go + banco Postgres próprio

Integração 100% via API com a Livon (bidirecional)

Pass-through do token Keycloak do usuário

Observabilidade desde o dia 1

IA isolada (Anthropic) na camada app, nunca no domínio

Quórum configurável (Regimento Interno)

Regras NR-5 / Lei 14.457 acima do protótipo

Voto secreto real — election_voter_log (quem votou) desvinculado de election_ballots (cédula sem identidade)

Ata como máquina de estados com hash SHA-256 + auditoria + imutabilidade + retificação versionada

SIPAT ≥5 dias é regra de produto, não legal

Canal de denúncia com sigilo estrutural (não criptografia)

Auth via Keycloak com validação local (JWKS) + RBAC próprio escopado por empresa

Dimensionamento via Quadro I (nº empregados × grau de risco NR-4)

Snapshots legais de PII (nome/matrícula no momento do evento)

Tech stack

Banco

Integração

Compliance

Dependência

Segurança (Livon)

Infra/Deploy

Visão Unificada

O que é a CIPA?

Por que um sistema separado?

A ata como cofre lacrado

Voto secreto de verdade

Eleição por tamanho da empresa

Caixa-preta do avião

Canal de denúncia anônimo

IA como estagiário

Tecnologias

Linguagens & Core

Dados & Persistência

Observabilidade

IA & LLM

Auth & Segurança

Infra & Deploy

Meta-tools (engenharia)

Timeline

Progresso

IA isolada (Anthropic) na camada `app`, nunca no domínio

Voto secreto real — `election_voter_log` (quem votou) desvinculado de `election_ballots` (cédula sem identidade)