CI

The pipeline is defined in the application repository's .gitlab-ci.yml, which consumes versioned components from the yotoshelf/pipeline catalog and adds a few inline jobs. That file names every component and every pin it uses; read it there rather than a copy here, which would go stale on the next bump.

What just check runs

The local just check recipe is the mirror of the pipeline's gates. The list below is AGENTS.md read from the repository when this page was built.

After every change:

just check

This runs every local-runnable CI gate:

• check:go — golangci-lint, go test ./..., go build, govulncheck, file-size limits (Go ≤400 / Svelte ≤250 LOC)
• check:frontend — npm ci, npm run build, npm audit --omit=dev --audit-level=high
• check:i18n — scripts/check-i18n.sh (no hardcoded English strings)
• sqlc drift: run just generate if you touched SQL or Go types; types.ts must not differ from HEAD
• openapi drift: run just generate if you changed any huma operation; commit the updated types.ts

If just check passes locally, it passes in CI.

Running just check before pushing is the fastest way to catch failures without burning CI minutes.

Container image

Container builds happen in GitLab CI on main. The Containerfile uses a three-stage build: Node (frontend) → Go (binary) → Alpine (runtime + ffmpeg).

To run the published image rather than build one, see Quick Start.