Keep changes deterministic, reviewable, and owned by the narrowest package or repository surface that can prove them.
Run the template initializer once, before the first service change:
make template-init \
MODULE=github.com/your-org/your-service \
CODEOWNER=@your-org/backendThe command rewrites the Go module and module-qualified lint rules, updates
CODEOWNERS, preserves an existing .env, creates it from .env.example only
when absent, and rejects invalid input before mutation. Verify that contract
with ALLOW_HEAVY=1 make template-init-check.
Use the smallest command that proves the claim. Completion is one surface-aware route:
make verifymake prove PKG=./internal/<package> FILES='internal/<package>/*.go' is optional
iteration for a package-sized change. Skip it when the change is already ready
for make verify. make plan only explains that route; do not run it as a
required gate.
ALLOW_FULL=1 make check is the one full-repository owner. Do not also run
fmt-check, lint-all, or test-all beside it. make test and make lint
require PKG and do not default to ./....
Heavy commands remain available with an explicit grant:
ALLOW_HEAVY=1 make test-race
ALLOW_HEAVY=1 make test-integration
make mod-check
make openapi-check
make sqlc-check
ALLOW_HEAVY=1 make migration-validate
ALLOW_HEAVY=1 make govulncheck
ALLOW_HEAVY=1 make gosec
make secret-scan
ALLOW_HEAVY=1 make secret-scan-historyDocker-backed focused commands require a reachable Docker daemon. Do not describe a host-only result as container or migration evidence.
make root-mod-check owns the service module. make tools-mod-check owns the
tool module. make mod-check runs both and remains the explicit combined gate.
Use make secret-scan for local and pull-request changes. Main and release use
make secret-scan-history; do not replace the historical gate with
a faster scan or a broader baseline.
For performance work, follow Benchmarking and run only the benchmark level that matches the claim.
- Keep PR scope focused and reversible.
- Include exact validation evidence and any unverified remainder.
- Update docs with behavior, contract, CI, or operational changes.
- Configure required reviews and status checks with GitHub Rulesets or organization policy. The repository does not mutate its own GitHub settings.
- Treat
.github/workflows/ci.ymlas the source of truth for current check names instead of copying a permanent list into scripts or docs.
For Railway policy changes:
- keep
railway.tomlnon-secret and PR-reviewed; - keep the canonical build path in
build/docker/Dockerfile; - validate the affected migration, runtime-image, and deployment surfaces;
- reopen the relevant design before changing rollout timing, retry, replica, or capacity policy.
- Format Go through
make fmt; verify withmake fmt-checkormake check. - Prefer explicit Go and existing repository seams over new framework layers.
- Use the placement guide in Project Structure & Module Organization.
- Keep business logic in
internal/<feature>, HTTP mapping ininternal/infra/http, persistence adapters ininternal/infra/postgres, configuration ininternal/config, and composition incmd/service/internal/bootstrap. - Regenerate OpenAPI and SQLC output through their owning targets. Never edit generated output by hand.
Do not open public issues for undisclosed vulnerabilities; follow
SECURITY.md. Before enabling required code-owner reviews in a derived
repository, confirm .github/CODEOWNERS names real users or teams with access.