Development setup and make check

A local environment

Clone the repository and use a local, non-production configuration (TLS off with accept_insecure_http: true, the renderer on loopback, the master key outside the data directory). The repository's README has the exact local-dev steps; the shape is: create the data directories, run the rendering sidecar in a Python virtualenv, then migrate and run.

make migrate        # apply migrations to the local database
make seed           # optional: populate a demo engagement
make run            # the internal surface (:8080)
make run-portal     # the portal (:8081), optional

make run on first access asks you to create the administrator with TOTP, exactly like a real install. This local path is for development only; it omits the renderer's network isolation that the systemd units carry, so never treat it as production.

make check equals CI

The one command that matters is make check: it runs the same gates CI enforces (build, vet, golangci-lint with gosec, gitleaks, govulncheck, the JS syntax gate, line-length, gofmt, i18n-check, and the tests). If make check is green locally, CI will be green, and a change that would fail CI fails on your machine first. Run it before you send anything.

The build is pure Go, no build step

There is no Node and no front-end build in the release: the interface is static pages served by go:embed, with Lit vendored under web/vendor/. So a full build is go build, and the browser tests need a Chrome or Chromium available. Keep it that way; the absence of a build step is an architectural choice, not an omission.