# Divergências conhecidas

Última atualização: 20/08/2026 · Origem: `docs/bugs/2026-08-13-grill-with-docs-arquitetura.md`

Resumo operacional dos bugs/divergências reais já diagnosticados neste
stack. Para a auditoria completa (com referências de linha), ver o documento
de origem.

## `evo-crm` fica `unhealthy` — `db/schema.rb` dessincronizado

Após `up -d`, o `evo-crm` pode subir `unhealthy` com
`ActiveRecord::PendingMigrationError`, mesmo com o schema já carregado. Causa:
uma entrada com versão inválida em `schema_migrations` (typo de ano no
`schema.rb` do submodule) mascarava dezenas de migrations reais como "não
aplicadas". O `Makefile` já tem o workaround de "carimbar" migrations como
aplicadas para `evo-auth`, mas não para `evo-crm`.

**Contorno**: rodar manualmente o mesmo carimbo de migrations para `evo-crm`
que o `make seed-crm` já faz para `evo-auth`.

## `evo-auth-sidekiq` sempre `unhealthy` (falso alarme)

A imagem do `evo-auth-service-community` tem um `HEALTHCHECK` fixo no
Dockerfile (`curl localhost:3001/health`) que não se aplica a um worker sem
porta HTTP. Ruído cosmético — nada depende desse healthcheck hoje — mas
confunde monitoramento.

**Contorno sugerido**: `healthcheck: disable: true` no bloco do serviço no
compose (ainda não aplicado no submodule/imagem).

## Boot do Rails falha com `RAILS_SERVE_STATIC_FILES=false`

Um initializer do CRM (`facebook_webhook_logger.rb`) insere um middleware
`before ActionDispatch::Static` incondicionalmente. Quando
`RAILS_SERVE_STATIC_FILES=false` (padrão recomendado atrás de proxy/Traefik),
esse middleware não existe na stack e o boot do Rails aborta.

**Impacto**: deploys de produção atrás de Traefik não sobem sem esse fix
aplicado na imagem.

## Gateway nginx não documentado nos docs raiz

`nginx/README.md` descreve um API Gateway de produção
(`evoapicloud/evo-crm-gateway`) que roteia para os 5 serviços backend — real,
mas ausente do README.md/AGENTS.md raiz.

## Provisionamento de Postgres externo

Quando o Postgres é externo (gerenciado fora do stack Docker), o usuário de
aplicação normalmente não tem `SUPERUSER`/`CREATEDB` — extensões e criação de
schema exigem um script rodado por um usuário com privilégio elevado (ver
`docs/bugs/2026-08-13-provisionar-postgres-producao.sql` para o script de
referência, sem valores reais de host/credenciais).