Setup de desenvolvimento e make check

Um ambiente local

Clone o repositório e use uma configuração local, não de produção (TLS desligado com accept_insecure_http: true, o renderizador no loopback, a chave mestra fora do diretório de dados). O README do repositório tem os passos exatos de dev local; o formato é: criar os diretórios de dados, rodar o sidecar de renderização num virtualenv Python, depois migrar e rodar.

make migrate        # aplica as migrações ao banco local
make seed           # opcional: popula um engajamento de demonstração
make run            # a superfície interna (:8080)
make run-portal     # o portal (:8081), opcional

O make run no primeiro acesso pede para criar o administrador com TOTP, exatamente como uma instalação real. Esse caminho local é só para desenvolvimento; ele omite o isolamento de rede do renderizador que as units de systemd carregam, então nunca o trate como produção.

make check é igual ao CI

O único comando que importa é o make check: ele roda os mesmos gates que o CI impõe (build, vet, golangci-lint com gosec, gitleaks, govulncheck, o gate de sintaxe JS, comprimento de linha, gofmt, i18n-check, e os testes). Se o make check está verde localmente, o CI vai estar verde, e uma mudança que reprovaria no CI reprova antes na sua máquina. Rode antes de enviar qualquer coisa.

O build é Go puro, sem etapa de build

Não há Node nem build de front-end no release: a interface são páginas estáticas servidas por go:embed, com o Lit vendorizado sob web/vendor/. Então um build completo é go build, e os testes de navegador precisam de um Chrome ou Chromium disponível. Mantenha assim; a ausência de etapa de build é uma escolha arquitetural, não uma omissão.