--- title: Repository Policies last_modified: 2026-11-09 --- This document covers repository structure, tooling, and workflow standards. Code style conventions are in separate documents: - [Code Styleguide](https://git.eeqj.de/sneak/prompts/raw/branch/main/prompts/CODE_STYLEGUIDE.md) (general, bash, Docker) - [Go](https://git.eeqj.de/sneak/prompts/raw/branch/main/prompts/CODE_STYLEGUIDE_GO.md) - [JavaScript](https://git.eeqj.de/sneak/prompts/raw/branch/main/prompts/CODE_STYLEGUIDE_JS.md) - [Python](https://git.eeqj.de/sneak/prompts/raw/branch/main/prompts/CODE_STYLEGUIDE_PYTHON.md) - [Go HTTP Server Conventions](https://git.eeqj.de/sneak/prompts/raw/branch/main/prompts/GO_HTTP_SERVER_CONVENTIONS.md) - [API Policies](https://git.eeqj.de/sneak/prompts/raw/branch/main/prompts/API_POLICIES.md) # Pin external references by hash **External references must be pinned by cryptographic hash.** This is the single most important rule in this document. It covers what we download and install ourselves in scripts and Dockerfiles. Reference each by its content hash: - Docker base images: `@sha256:...` - Go modules: the module hash in `go.sum` - Python packages from PyPI: the package hash in `Pipfile.lock` - npm packages: the `checksum` in `yarn.lock` - GitHub Actions: `@` - release archives fetched with `curl` or `wget`: a hash hardcoded in the Dockerfile or script Packages from the distribution's own package manager are outside this rule. They need no version and no hash, because the distribution is trusted. In a `Dockerfile`, it is the pinned base image's distribution. On a host, it is the host's. The host's package manager stands for its distribution, and that includes nix and brew. Updating the package index and upgrading installed packages are fine too. This command, for example, is allowed: ```sh apt update && apt upgrade -y && apt install -y build-essential ``` A package source that a `Dockerfile` adds itself is not the distribution's own, so its packages are pinned like any other download. - A version tag such as `@v4`, `@latest` or `:3.21` is server-mutable, and therefore a remote code execution vulnerability. - An unverified install script is arbitrary remote code execution. Never `curl | bash` to install a tool such as rustup. Instead, download a specific release archive from GitHub, verify its hash, and only then install. - Docker Hub, PyPI, the npm registry and `go get` are not trusted, so everything from them stays pinned by hash. - Above each image or package pinned by hash, add a comment with the version and date (YYYY-MM-DD). - Double-check every external reference in every file before committing. node, yarn, npm, python, pip and venv come from the distribution wherever possible: - node means the distribution's newest Node package, such as `nodejs-current` on Alpine 3.24. - pip and venv are the installer tools bundled with python. - If the distribution's version is too old, use a newer distribution, never a download. That rules out nvm, pyenv, corepack and `npm install -g yarn`. - yarn's release file is third-party code, and git pins it. `yarn set version` writes it to `.yarn/releases/` once, given an exact version. # Git and secrets - Never commit secrets. `.env` files, credentials, API keys, and private keys must be in `.gitignore`. No exceptions. - Make all changes on a feature branch. You can do whatever you want on a feature branch. - Never force-push to `main`. - Never use `git add -A` or `git add .`. Always stage files explicitly by name. - **No build artifacts in version control.** Code-derived data must never be committed to the repository if it can be avoided. Code-derived data includes: - compiled bundles - minified output - generated assets The build process (e.g. Dockerfile, Makefile) should generate these at build time. Notable exception: Go protobuf generated files (`.pb.go`) ARE committed, because repos need to work with `go get`, which downloads code but does not execute code generation. # Entrypoints Repos follow the [Scripts to Rule Them All](https://github.com/github/scripts-to-rule-them-all) pattern. Every repo with software must have a root `Makefile` with the targets below. Each target is a thin shim that calls an executable script in `script/`, where its implementation lives: - `make bootstrap`: `script/bootstrap` installs all dependencies. - `make setup`: `script/setup` readies a fresh clone for development. It runs `bootstrap`, then `install-precommit`, plus any repo-specific initialization. - `make test`: `script/test` - `make lint`: `script/lint` - `make fmt`: `script/fmt` (writes) - `make fmt-check`: `script/fmt-check` (read-only) - `make check`: `script/check` runs `script/test`, `script/lint` and `script/fmt-check`. - `make docker`: `script/docker` - `make hooks`: `script/install-precommit` installs the git pre-commit hook. - `make update-policy` (fetches the vendored policy files, commits and pushes) Three more scripts have no required target: - `script/precommit` is what the pre-commit hook runs. It calls `script/check`. Repo-type-specific extras belong in it, not in the hook itself; `go mod tidy` verification in Go repos is one. If local testing is not possible in the repo, it may skip `script/test` and run only `script/lint` and `script/fmt-check`. - `script/cibuild` runs the CI build, and the Gitea workflow calls it. - `script/projectname` (literally that filename) outputs the project's name. Scripts that need the name call it, so they stay byte-identical across all repos. `script/docker`, for example, assembles its image tag from it. `script/update-policy` fetches the vendored policy files from the `prompts` repo, commits them and pushes. The `make update-policy` target shims to it. From the standard's canonical set we use `bootstrap`, `setup`, `test`, and `cibuild`. `check`, `precommit`, `install-precommit`, `update-policy` and `projectname` are our own extensions to the standard. The scripts must be POSIX sh (`#!/bin/sh`, `set -eu`, no bashisms) so they run in minimal containers; alpine images, for example, have no bash. Locate the repo root with `$(cd "$(dirname "$0")/.." && pwd -P)`, and `cd` there before acting. A model Makefile is at `https://git.eeqj.de/sneak/prompts/raw/branch/main/Makefile`. Model scripts are at `https://git.eeqj.de/sneak/prompts/raw/branch/main/script/`. Run the repo's own entrypoints, never the underlying tools directly. The `script/` scripts are the single source of truth for how each operation runs. Calling them directly is fine, and so is calling the Makefile targets. The Makefile targets must still exist, as the thin shims described above. An agent whose work is confined to one package may run `go test` directly on that package's suite, or on individual tests in it, while iterating. This is the only exception to this rule. `go build`, `go vet` and the linter still go through the entrypoints. A run while iterating is not a gate, so the full `make check` is still required before every push. The Makefile is authoritative documentation for how the repo is used. Beyond the required targets above, it should have targets for every common operation: - running a local development server (`make run`, `make dev`) - re-initializing or migrating the database (`make db-reset`, `make migrate`) - building artifacts (`make build`) - generating code - seeding data - anything else a developer would do regularly Typing `make` in a checkout should show every meaningful operation. A new contributor should be able to understand the entire development workflow by reading the Makefile. A repo updates its policy files with one command: `make update-policy`. It runs `script/update-policy`, which fetches each vendored file the repo carries from the `prompts` repo, commits them and pushes. It uses the head of `main`, or the commit given by a full hash: `script/update-policy `. The list of vendored files is at the top of that script. The script replaces each file and keeps only the repo's own entries: - in `.gitignore`, `.editorconfig` and `.dockerignore`: the lines below the comment that ends the canonical file - in `.golangci.yml`: the entries the repo added to the `deny` list of the `test-support` depguard rule # Tests and checks - All repos with software must have tests that run via the platform-standard test framework (`go test`, `pytest`, `jest`/`vitest`, etc.). There is no excuse for `make test` to be a no-op. If no meaningful tests exist yet, add the most minimal one: importing the module under test to verify it compiles/parses, for example. - `make test` must complete in under 60 seconds. That is the hard cap, and a suite that exceeds it fails. Under 20 seconds is the target. A suite between 20 and 60 seconds is still green, but the overage must be filed as an improvement bug against that repo. - Add a 90-second timeout to the test invocation (`go test -timeout 90s`). This backstop sits above the hard cap on purpose: it catches a hung test, not a merely slow one. `-timeout` applies to each package, so several hung packages can each use it. - Docker builds must complete in under 5 minutes. - `make check` must not modify any files in the repo. Tests may use temporary directories. - `main` must always pass `make check`, no exceptions. **The test command should use the conditional verbose rerun pattern.** Run tests without `-v` (verbose) first. If they fail, rerun automatically with `-v`. Success then leaves CI logs and `docker build` output clean, with just package/suite summaries. Failure shows every test case and every assertion. - The rerun always ends in `exit 1`. The first run already proved the tests are broken, so the build must not pass even if a flaky test succeeds on the second attempt. The rerun exists solely for diagnostic output. - A first run that timed out gets no rerun, which would only wait for the same hang. A hung package therefore uses the 90-second backstop once. The command lives in the `test` phase of the `Dockerfile`, since `script/test` builds that phase. `examples/go.Dockerfile` and `examples/python-test-phase.Dockerfile` in the `prompts` repo carry it. The Makefile form below is the same pattern for any repo-local invocation. In a Makefile, each `$` of those two commands is written `$$`. ```makefile test: @ || \ { echo "--- Rerunning with -v for details ---"; \ ; exit 1; } ``` # `script/bootstrap` `script/bootstrap` installs all dependencies idempotently and assumes nothing is present. - A tool from the distribution has no pin, so it is installed only when it is missing. make, git, node and yarn are such tools. They come from nix, apt, brew, or apk, detected in that order; apt runs noninteractive. - A tool from outside the distribution is never installed as "latest" or "lts"; it is always an exact version. ## node and yarn Use `yarn`, not `npm`. - `script/bootstrap` installs node, yarn and the node packages only when `yarn.lock` is in the tree. A `Dockerfile` stage that needs no yarn copies no `yarn.lock` before it runs `script/bootstrap`, so `script/bootstrap` installs no node and no yarn there. The stages in the `prompts` repo's `examples/go.Dockerfile` and `examples/python-test-phase.Dockerfile` are such stages. - It installs the node packages with `yarn install --immutable`, which fails when a package's `checksum` is wrong, or when `package.json` is out of step with `yarn.lock`. - Each repository commits the yarn that runs. `yarnPath` in `.yarnrc.yml` points at the release file in `.yarn/releases/`. The distribution's yarn only starts that file, and that file does the work. So Alpine's yarn 1 and Debian 13's yarn 4.1 run the same committed yarn. Corepack never runs, and no yarn is downloaded. - `.yarnrc.yml` holds `yarnPath`, `nodeLinker: node-modules` and `enableTelemetry: false`. Without the last, yarn sends usage reports from any host that is not CI. - By default, yarn runs no dependency's install script. A dependency that must run one is named in `package.json`, as `"dependenciesMeta": { "": { "built": true } }`. - `.gitattributes` carries `.yarn/releases/** binary`, so diffs and merges treat the release file as one opaque file. - yarn 1 ignores `--immutable` and exits 0, so on a tree with no `.yarnrc.yml` the install is not frozen. A repository therefore re-vendors `script/bootstrap` and converts its `yarn.lock` in one commit. - Debian and Ubuntu name the yarn command `yarnpkg`. `script/bootstrap`, `script/fmt` and `script/fmt-check` each carry the same small function that runs whichever name is present. With neither name on `PATH`, `script/fmt` and `script/fmt-check` print one line saying to run `script/bootstrap`, and exit 1. - A `Dockerfile` stage that needs yarn may start from any distribution that packages node and yarn. Before it runs `script/bootstrap`, it copies `package.json`, `yarn.lock`, `.yarnrc.yml` and `.yarn/releases/`. With only the first two, the install fails, and Alpine's yarn 1 says to enable corepack. Never do that; copy the missing files instead. ## Pinned tools **`script/bootstrap` installs a pinned tool by comparing versions, never by testing presence.** An `if ! command -v ; then install; fi` guard tests `PATH` only. On an already-provisioned machine the pin is then inert, and a version bump is a silent no-op. The Dockerfile's clean image still gets the pinned version, so a local `make check` and `make docker` can disagree about what the tool even is. The canonical form: - compares the installed version against the pin over the **whole** version token. A parser that stops at the first `-` reports `2.12.2` for a host running `2.12.2-rc1` and skips the install. - treats `--version` output as a mismatch when it is any of these: - absent - non-zero - empty - unrecognised So a failure causes a redundant install, never a skipped one. - after installing, re-resolves the binary the way callers do: `hash -r`, then `PATH`, not the directory the installer wrote to. A shadowing binary can hide an install that reported success. In that case it fails and names the resolved path. - is actually called, and prints the version on both success paths. A function defined and never invoked has the same exit status and the same empty output as one that worked. - stays POSIX sh: no arrays, no `[[`, no `grep -P`. A Go tool a repo needs on the host is installed with `go install` pinned to a commit hash (`go install @`). It is never tracked as a `go.mod` tool dependency or through a `tools.go` file, either of which pulls the tool's own dependencies into the repo's `go.mod` and `go.sum`. # Dockerfile Every repo should have a `Dockerfile`, and it carries the repo's gates: a `lint` phase and a `test` phase. The final stage depends on both, so the image cannot be built unless they pass. For non-server repos the final stage brings up a development environment; for server repos it is the runtime image. **The lint and test gates run in Docker, as phases of the `Dockerfile`.** There is no separate lint file. `script/lint` and `script/test` each build one phase and nothing else: ```sh docker build --build-arg CACHEBUST="$(date +%s)-$$" \ --target lint --output type=cacheonly . docker build --build-arg CACHEBUST="$(date +%s)-$$" \ --target test --output type=cacheonly . ``` - **A stage that is not the last one in the file is built only when the final stage's chain depends on it, or when `--target` names it.** That is why the two gates are always invoked by name here, and why the final stage carries a `COPY --from=` of a harmless file from each of them. Without those copies, a plain `docker build .` builds the last stage's chain alone and exits 0 having linted and tested nothing. Keep the stage that ships last: the runtime image, or the development environment in a non-server repo. If you add a stage after it, give it the same two copies. - **The gate builds write no image.** With `--output type=cacheonly` the phase runs and a failing step fails the build, but the result is not exported. Nothing uses those images, and writing one out is slow. A build given neither `--output` nor `-t` leaves an untagged image dangling on every developer host and CI runner. `script/cibuild` and `script/docker` tag the image that ships, so each build replaces the previous image. - **Inside a phase the tool is invoked directly:** `golangci-lint`, `go test`, `eslint`, `prettier`. It is never invoked through `make lint` or `script/test`, which are themselves a `docker build` and would recurse into a daemon that does not exist in a build step. - **Formatting is the exception and stays on the host.** `script/fmt` writes the working tree, and `script/fmt-check` is its read-only twin. - **No lint verdict may come from a host invocation of the linter.** On a shared host golangci-lint reads a result cache keyed on file content rather than location. A second checkout of the same content is therefore served the first one's findings. A host-global lock in `$TMPDIR` also makes concurrent runs exit non-zero with `parallel golangci-lint is running`, which a caller cannot tell from real findings. A container has its own `TMPDIR`, out of the lock's reach. The lint phase does keep golangci-lint's cache between check builds, but it lints every checkout at `/src`. It reuses a finding only on the conditions listed under the canonical Go `Dockerfile` below. What each stage installs: - The gate phases and the build stage start from their pinned base images. They install what those images lack in either of these ways: - inline, as the `prompts` repo's `examples/go.Dockerfile` does for `git` - by running `script/bootstrap`, as the `prompts` repo's own `Dockerfile` does for its yarn packages - The development environment stage installs development prerequisites by running `script/bootstrap`. Only system packages may be installed inline above it, so that check builds keep them; the `prompts` repo's own `Dockerfile` does this. - A stage that runs `script/bootstrap` first COPYs `script/` and the dependency manifests it needs: `go.mod` and `go.sum`, for example, or the four yarn files named above. ## `CACHEBUST` **Any build that runs checks is given a new `CACHEBUST` value.** On an unchanged tree Docker otherwise serves the check `RUN` from cache: nothing executes, and the build still exits 0. Every `docker build` in `script/` therefore passes `--build-arg CACHEBUST="$(date +%s)-$$"`, the time and the script's process id. So no two builds share a value, not even the three in one `script/cibuild`. Four scripts do this, and there is no fifth: `script/lint`, `script/test`, `script/cibuild` and `script/docker`. `script/check` builds no image of its own. In every stage of the `Dockerfile`, every step that lints, tests or compiles comes after `ARG CACHEBUST`. `ARG CACHEBUST` comes right after these steps: - the steps that install system packages - the steps that download Go's modules - the step that runs `script/bootstrap` to install a Python `test` phase's packages from `Pipfile.lock` A stage with none of these steps declares `ARG CACHEBUST` right after `FROM`. A step that also installs anything else comes after `ARG CACHEBUST` too. A `script/bootstrap` that also installs node packages is one. - A new value reruns every `RUN` step after that line; `COPY` steps are compared by content and need nothing. Docker keeps the layers above the line until one of these changes: - the base image - their own lines - the files they copy - A stage without the `ARG` line is served from cache on an unchanged tree, so a repository re-vendors the scripts and adds the `ARG` lines in one commit. - The scripts do not pass `--no-cache`. That flag reruns every step too, but it also rebuilds the layers above the line and empties every cache mount. The `prompts` repo's `examples/go.Dockerfile` mounts Go's build cache and golangci-lint's so that they survive between check builds. - A bare `docker build .` is not evidence that anything ran: a sub-second build reporting success is a cache hit, not a result. - Never invalidate by pruning: `docker builder prune` and friends destroy a build cache shared with every other build on the host. - When a check is added or changed, prove it works: plant a defect it must catch, watch the run fail on it, then revert the defect. A green run alone shows neither that the check ran nor that it covers what it should. ## Canonical Go `Dockerfile` **The gate phases are separate stages, and the build stage depends on both.** The lint phase is based on the `golangci/golangci-lint` image (pinned by hash), so lint failures surface in seconds rather than after a full compile. That image has both Go and the linter, so nothing needs installing. The test phase is based on the Debian Go image. The canonical Go `Dockerfile` is at `https://git.eeqj.de/sneak/prompts/raw/branch/main/examples/go.Dockerfile`. Key points: - Check builds keep these, and none of them can hand back a stale result: - The layers above `ARG CACHEBUST`: the system packages and Go's modules. Go checks every module against `go.sum` as it downloads it, and no later build can change a kept layer. - Go's build cache (`/root/.cache/go-build`, where Go keeps it for root), mounted on the steps that compile: `golangci-lint run`, both `go test` runs and `go build`. Go reuses a compiled package only when all its inputs are unchanged. - golangci-lint's cache (`/root/.cache/golangci-lint`, where the pinned image keeps it), mounted on `golangci-lint run`. golangci-lint reuses a package's findings only when all of these are unchanged: - the package's files and those of every package it imports - `go.mod` - the linters and their settings in `.golangci.yml` - the golangci-lint version - The modules are kept in a layer rather than a cache mount. A cache mount is shared by every build on the host, and Go builds from whatever files the mount holds without checking them again (only `go mod verify` does). A file changed there would go unnoticed. - The test command keeps the first run's output, to look in it for what Go prints for a hang. `panic: test timed out` means the test's own timer fired. `*** Test killed` means `go test` stopped a test that ignored that timer, about a minute later. Go prints the goroutine stacks with either line, as long as the test can still respond. On either line the command exits 1 without a rerun. A failure with neither line reruns with `-v`. The kept output prints when the first run ends, not while it runs. - `-count=1` is required on both `go test` invocations. Go stores a passing result in its cache directory (`GOCACHE`). When the same tests run again on unchanged code, it prints that result, marked `(cached)`, without running them. That directory lasts between runs on a developer's machine, and in the `test` phase, which mounts it to keep compiled packages. - `-count=1` defeats only that test _result_ cache. It leaves the build cache alone, so it costs the runtime of the suite and no recompilation. The cache is Go's own, separate from Docker's layer cache, which `CACHEBUST` handles. - If the project uses `//go:embed` directives that reference build artifacts, the lint phase must create placeholder files so the embed directives resolve. A web frontend compiled in a separate stage is such an artifact. Example: `RUN mkdir -p web/dist && touch web/dist/index.html web/dist/style.css`. - If the project requires CGO or system libraries for linting, install them in the lint phase. The `golangci/golangci-lint` image is Debian-based and has no `apk`. So install with `apt-get` under the Debian package name (`libvips-dev`, where alpine says `vips-dev`), and delete the package lists in the same `RUN`, so the layer does not keep them. The test phase, on the Debian Go image, installs the libraries its tests need the same way. Either install goes right after `FROM`, above `ARG CACHEBUST`. The first lines of a lint phase that installs system libraries are at `https://git.eeqj.de/sneak/prompts/raw/branch/main/examples/go-lint-system-libraries.Dockerfile`. ## Python `test` phase **A Python `test` phase that installs its packages from `Pipfile.lock` does it above `ARG CACHEBUST`, so check builds keep them.** The steps are `COPY script/ script/`, `COPY Pipfile Pipfile.lock ./` and `RUN script/bootstrap`, with `ARG CACHEBUST` right after them. Docker keeps what that `RUN` installed until one of these changes: - the base image - `script/` - `Pipfile` - `Pipfile.lock` - a line up to and including the `RUN` The tests run after `ARG CACHEBUST`, on every check build. In every other stage, a step that installs Python packages comes after `ARG CACHEBUST`. In that step, `script/bootstrap`: - installs nothing beyond these: - system packages - pipenv and its dependencies - the packages from `Pipfile.lock` If it installs anything else there, the step goes after `ARG CACHEBUST`. - installs no Python: the tests use the distribution's Python, which a step above it installs. A Python repository's `script/bootstrap`: - puts pipenv in a virtual environment at `$HOME/.pipenv`, because Debian's Python refuses a system-wide `pip install`. It creates the environment with `python3 -m venv` when it is missing, then uses that environment's `pip` and `pipenv`. On a host, it first installs the distribution's python and venv packages when they are missing. One script then works on a host and in a `Dockerfile`. - installs pipenv and its dependencies by hash, because PyPI is not trusted. It runs `pip install --require-hashes -r` on a requirements file in `script/` that lists each of them with `==` and its `--hash`. pip refuses to install a dependency the file does not list. - then runs `pipenv install --deploy`, with `--dev` when the tests need the development packages. `--deploy` does all of these: - installs only what `Pipfile.lock` names - checks every package against the lockfile's hashes - fails when the lockfile is out of date with `Pipfile` - sets `PIP_ONLY_BINARY=:all:` for both installs, and pipenv passes it on to pip. A package with no ready-built wheel for the image then stops the install. Without the setting, pip builds that package from source and downloads the build tools without a hash check. `Pipfile` names no `python_version`, because `pipenv install --deploy` stops when the distribution's Python differs from it. A kept layer holds nothing a new install would refuse. pip checked the hashes of pipenv and its dependencies, and pipenv checked the hashes of the lockfile's packages. pipenv creates its virtual environment with the `virtualenv` package. The packages that `virtualenv` adds come from wheels inside it, so the hash pip checked for it covers them. System packages, Python among them, are not fixed by a hash. They keep the versions the package manager gave when the layer was built; a new install may get newer ones. As with Go's modules, the packages are kept in a layer, not a cache mount, which every build on the host shares and nothing checks again. A Python repository's `script/bootstrap` adds these lines in `main`, above the last `echo`. The `ensurepip` test fails when python is missing, and also when Debian's venv package is missing: ```sh if [ ! -x "$HOME/.pipenv/bin/pip" ]; then if ! python3 -m ensurepip --version >/dev/null 2>&1; then pkg_install python3 python3-venv python3 python3 fi python3 -m venv "$HOME/.pipenv" fi export PIP_ONLY_BINARY=:all: "$HOME/.pipenv/bin/pip" install --require-hashes -r script/requirements.txt "$HOME/.pipenv/bin/pipenv" install --dev --deploy ``` Make `script/requirements.txt` once, with `echo pipenv | pip-compile --generate-hashes --allow-unsafe -o script/requirements.txt -`. `pip-compile` comes from Alpine's `py3-pip-tools` package; Debian and Ubuntu do not package `pip-tools`. Make the first `Pipfile.lock` with `$HOME/.pipenv/bin/pipenv lock`, after the `pip install` line has installed pipenv. In `examples/python-test-phase.Dockerfile`, `script/bootstrap` finds `make`, `git`, python and venv already installed. The Python `test` phase example is at `https://git.eeqj.de/sneak/prompts/raw/branch/main/examples/python-test-phase.Dockerfile`. Run from a `make test` target on a host, the test command in `examples/python-test-phase.Dockerfile`: - does not stop on Ctrl-C. It goes on until the tests end or the 90 seconds run out. - fails on a Mac without `timeout`, until it is installed. - needs `$HOME/.pipenv/bin` on `PATH`. ## Version **A plain `docker build .` of a clone stamps the version that `git describe --tags --always` gives.** That gives: - the tag, on a tagged commit - the tag, the number of commits since it and the short commit (`v1.2.3-4-gabc1234`), on a later commit - the short commit, when no tag is reachable The stage that compiles derives it from the `.git` in the build context, as the `prompts` repo's `examples/go.Dockerfile` shows: - It takes the version from the `VERSION` build argument when one is given, otherwise from `git describe`. `ARG VERSION` is declared in that stage, because `ARG` is stage-scoped. It has no default. - It has `git`: the Debian Go image has it, and an alpine one needs `apk add --no-cache git`. - It marks its working directory safe for git (`git config --system --add safe.directory /src`). A context sent as a tar stream keeps the sender's file owners, and git refuses a checkout owned by another user, so the version would come out empty. - The build fails if the context carries `.git` and the version still comes out empty, `dev` or `unknown`. Without that check, a missing `git` or an unreadable checkout would leave `-X main.Version=` empty, and the build would still exit 0. - A plain `docker build .` with no build arguments must succeed; a Dockerfile that refuses an empty build argument drops that refusal and keeps the argument. - A checkout whose `.git` is a file is the exception: a linked worktree, or a repository checked out as a submodule. That file points to a git directory outside the build context, so the build cannot read the version and a plain `docker build .` fails. Pass the version with `--build-arg VERSION=...`, as `script/docker` and `script/cibuild` already do. `.dockerignore` lets `.git` into the build context. It keeps out every git `config` at any depth (`**/.git/config`, `**/.git/modules/**/config`): - the repository's own - each submodule's under `.git/modules/` - that of a submodule keeping its own `.git` directory `git describe` does not need them, and each can hold a credential: a password in a remote URL, or the token the CI checkout step stores there. Some submodule names have a `config` segment, as in `config`, `deploy/config` or `config/lib`. Such a submodule loses its whole git directory to `**/.git/modules/**/config`, and Go's version stamping then fails the build. Give it a name without that segment (`git submodule add --name`). `script/docker` and `script/cibuild` pass the version they compute on the host; it takes precedence. They do this byte-identically across repos: ```sh # The version and the tag each get their own line: a failing command # substitution inside an argument does not trip `set -e`, so the inline # form degrades to an empty constant. version="$(git describe --tags --always --dirty 2>/dev/null || true)" [ -n "$version" ] || version="unknown" tag="$(script/projectname)" docker build --build-arg CACHEBUST="$(date +%s)-$$" \ --build-arg VERSION="$version" \ -t "$tag" . ``` - `--always` makes an untagged repo yield an abbreviated commit hash rather than failing. - The `[ -n "$version" ]` line is the single place the fallback is applied. It is a live check that fires on a build from an export with no `.git`, and on a repository with no commits yet. Do not fold it into the substitution as `|| echo unknown`, which makes the guard unreachable. - Passing `VERSION` to a repo whose Dockerfile declares no such `ARG` is ignored and costs nothing, which is why the scripts stay byte-identical. # CI Every repo should have a Gitea Actions workflow (`.gitea/workflows/`) that runs `script/cibuild` on push. The workflow's only other step checks out the repo. The workflow sets these: - `persist-credentials: false` on the checkout step. `script/cibuild` needs no token, and without that setting the checkout leaves the job's token in `.git/config` for every later step. - `fetch-depth: 0` on the checkout step, which fetches the tags `git describe` needs. The default is a shallow clone with no tags, and a tagged repository's CI build would then stamp a bare short commit id. - a `concurrency` block that groups runs by workflow and branch (`${{ github.workflow }}-${{ github.ref }}`) with `cancel-in-progress: true`. A new push then cancels the older run on the same branch, queued or running, and no other: runs for replaced commits do not hold up the shared runner. - `timeout-minutes: 20` on the `check` job, so a hung build frees the shared runner after 20 minutes. That allows for the bootstrap and three Docker builds, each held to the 5-minute limit. `script/cibuild` changes to the repo root, runs `script/bootstrap`, runs `script/check`, and builds the image with the version: - **`script/cibuild` runs `script/bootstrap` first**, because the workflow checks out the repo and runs nothing else, while `script/fmt-check` runs the formatter on the host. Without it, a pristine checkout dies there, after the containerised gates have passed. - Its three Docker builds are the test phase, the lint phase, then the image. So a successful run means every check passed, which a bare `docker build .` does not show. - The image build gets a `CACHEBUST` value of its own and so runs the gate phases a second time. That price is worth paying: the image that ships is built from a run of its own gates rather than from a cache entry. A separate workflow limited to `main` by a `branches` list under `on: push` cannot be checked by review. To try a change to it, add the feature branch to that list and push, then remove the branch from the list again before merging. Keep any job in it that publishes behind `if: github.ref_name == 'main'`, so the run from the feature branch publishes nothing. # `.gitignore` and `.dockerignore` `.gitignore` should be comprehensive from the start: - OS files (`.DS_Store`) - editor files (`.swp`, `*~`) - in-repo agent scratch directories (`.claude/`) - `node_modules/` - `.yarn/*`, with `!.yarn/releases` so that git keeps yarn's release file - the repo's own build outputs Fetch the standard `.gitignore` from `https://git.eeqj.de/sneak/prompts/raw/branch/main/.gitignore` when setting up a new repo. A repo's `.gitignore` is the standard file followed by the repo's own entries, such as its binaries. A re-vendor replaces the standard part and keeps those entries. **`.dockerignore` does not use `.gitignore` semantics, and copying patterns across unmodified leaves secrets in the build context.** The standard `.gitignore` patterns are written to `.gitignore`'s own semantics, in which an unanchored pattern already matches at every depth. They must not be transplanted into a `.dockerignore` unmodified. Docker matches with `moby/patternmatcher`: `filepath.Match` semantics plus a `**` extension. So `*` does not cross `/`, and a pattern without a leading `**/` is anchored at the build-context root. - A `.dockerignore` listing `.env`, `*.pem` and `*.key` therefore excludes only the copies at the repository root. `config/.env` and `certs/server.key` still reach the context and can land in an image layer. Such a `.dockerignore` is more dangerous than a short file with no secret patterns at all, because it reads as solved and stops anyone looking. - Give every depth-independent pattern the `**/` prefix, and leave only genuinely root-anchored entries unprefixed. Those are `.claude`, `.yarn/*`, `!.yarn/releases`, and the repo's own host-built binary. The binary is written `/myapp` and never `**/myapp`, which would also match `cmd/myapp/` and delete the package directory from the context. - Matching is case-sensitive, and an all-caps copy of each pattern still misses `Server.Key`. So secret names use character ranges: `**/*.[kK][eE][yY]`, `**/*.[pP][eE][mM]`, and likewise for `.envrc` and the extensionless SSH keys. - Where such a pattern also catches something the build needs, re-include it with a negation (`!docs/example.env`). Deleting the pattern reopens the exposure for every other file it covers. - Fetch the standard `.dockerignore` from `https://git.eeqj.de/sneak/prompts/raw/branch/main/.dockerignore` and extend it with the repo's own artifacts. **In-repo agent scratch belongs in both files, written to each file's own semantics.** `.claude/` holds one worktree per in-flight agent, an entire additional checkout of the repo. Under `COPY . .` the build context therefore inflates by a multiple of the repo, and another session's unreviewed work can be copied into an image layer. - In `.gitignore` the entry is `.claude/`, unanchored. - In `.dockerignore` it is `.claude`, anchored and with **no** `**/` prefix, because the prefixed form would also delete any nested directory of that name from the build. - Anchoring carries a known gap, which the canonical `.dockerignore` states in its own comment. The directory is created in the agent's working directory. A repo running agents in subdirectories therefore still ships `services/api/.claude/` and must add its own anchored entry there. **Verify `.dockerignore` by enumerating the image, not by reading the patterns.** Plant files at the root _and_ at least two directories deep. Build a probe image that does `COPY . .`, and list what actually landed (`docker run --rm --entrypoint find IMAGE /app`). The `transferring context` size is not a substitute: a nested secret is a few bytes, and BuildKit transfers only the delta from the previous build. # `.golangci.yml` `.golangci.yml` is standardized. The vendored copy in a consuming repo must _NEVER_ be modified by an agent. Fetch it from `https://git.eeqj.de/sneak/prompts/raw/branch/main/.golangci.yml` and keep it byte-identical, so that no repo can quietly loosen its own linting. - Linter configuration changes are made to the canonical copy in the `prompts` repo and reach consuming repos by re-vendoring. An agent may open a PR against canonical, which only the user merges. - One list is exempt from byte-identity, because it cannot be written once for every repo: the `deny` list of the `test-support` depguard rule. There a repo names its own test-support packages by full import path. A repo adds entries there and changes nothing else, and a re-vendor carries its entries forward. - The canonical golangci-lint version is v2.15.0 (released 2026-10-16). The version is pinned as the digest of the lint phase's base image, `golangci/golangci-lint@sha256:fbfcfd12a6f8d7f1b97b3362ca80fc2a244d46863148c73cb88e7793af96c481`, which reports `2.15.0 built with go1.27.0 from 25c5369a`. That digest is the only pin, since no repo installs golangci-lint on the host. - A module's `go` directive must not name a newer Go minor version than the one golangci-lint was built with, or golangci-lint refuses to lint it. This release lints `go 1.27.1` but not `go 1.28`. - A repo sets the lint phase digest to the one named here and re-vendors `.golangci.yml` in the same commit, whichever of the two prompted the change. The canonical copy can name linters that an older golangci-lint rejects. A newer golangci-lint can add linters that `default: all` switches on until the canonical copy disables them. # Formatting Use platform-standard formatters: - `black` for Python - `prettier` for JS/CSS/Markdown/HTML - `gofmt`, then `golines -m 77`, for Go Always use default configuration, with three exceptions: - four-space indents (except Go) - `proseWrap: always` for Markdown (hard-wrap at 80 columns) - a 77-column limit for Go, set by `golines -m 77` `script/fmt` runs `gofmt` and then `golines -m 77` on Go code. `script/fmt-check` fails when either of them would change a file. `golines` comes from `github.com/segmentio/golines`. `script/bootstrap` installs it with `go install`, pinned to a commit hash as below: ```sh # golines v0.13.0, 2025-08-21 go install github.com/segmentio/golines@8f32f0f7e89c30f572c7f2cd3b2a48016b9d8bbf ``` `script/bootstrap` reads the installed version from the `mod` line of `go version -m "$(command -v golines)"`, which reports `v0.13.0`. It does not use `golines --version`, which prints `golines vdev` for a binary that `go install` built. `golines` cannot shorten every line: long string literals and comments stay as they are. golangci-lint's `lll` limit therefore stays at 88 columns, so it fails only lines far past the formatter's limit. Documentation and writing repos (Markdown, HTML, CSS) should also have `.prettierrc` and `.prettierignore`. All repos should have an `.editorconfig` enforcing the project's indentation settings. It is the standard file from `https://git.eeqj.de/sneak/prompts/raw/branch/main/.editorconfig`, followed by the repo's own sections, such as one for another language it uses. The standard file sets tabs for `Makefile` and Go files. A re-vendor replaces the standard part and keeps those sections. # Web services Dockerized web services listen on port 8080 by default, overridable with `PORT`. **HTTP/web services must be hardened for production internet exposure before tagging 1.0.** This means full compliance with security best practices including, without limitation, all of the following: - **Security headers** on every response: - `Strict-Transport-Security` (HSTS) with `max-age` of at least one year and `includeSubDomains`. - `Content-Security-Policy` (CSP) with a restrictive default policy (`default-src 'self'` as a baseline, tightened per-resource as needed). Never use `unsafe-inline` or `unsafe-eval` unless unavoidable, and document the reason. - `X-Frame-Options: DENY` (or `SAMEORIGIN` if framing is required). Prefer the `frame-ancestors` CSP directive as the primary control. - `X-Content-Type-Options: nosniff`. - `Referrer-Policy: strict-origin-when-cross-origin` (or stricter). - `Permissions-Policy` restricting access to browser features the application does not use (camera, microphone, geolocation, etc.). - **Request and response limits:** - Maximum request body size enforced on all endpoints (e.g. Go `http.MaxBytesReader`). Choose a sane default per-route; never accept unbounded input. - Maximum response body size where applicable (e.g. paginated APIs). - `ReadTimeout` and `ReadHeaderTimeout` on the `http.Server` to defend against slowloris attacks. - `WriteTimeout` and `IdleTimeout` on the `http.Server`. - Per-handler execution time limits via `context.WithTimeout` or chi/stdlib `middleware.Timeout`. - **Authentication and session security:** - Rate limiting on password-based authentication endpoints. API keys are high-entropy and not susceptible to brute force, so they are exempt. - CSRF tokens on all state-mutating HTML forms. API endpoints authenticated via `Authorization` header (Bearer token, API key) are exempt because the browser does not attach these automatically. - Passwords stored using bcrypt, scrypt, or argon2 — never plain-text, MD5, or SHA. - Session cookies set with `HttpOnly`, `Secure`, and `SameSite=Lax` (or `Strict`) attributes. - **Reverse proxy awareness:** True client IP detection when behind a reverse proxy (`X-Forwarded-For`, `X-Real-IP`). The application must accept forwarded headers only from a configured set of trusted proxy addresses, never unconditionally. - **CORS:** Authenticated endpoints must restrict `Access-Control-Allow-Origin` to an explicit allowlist of known origins. Wildcard (`*`) is acceptable only for public, unauthenticated read-only APIs. - **Error handling:** Internal errors must never leak implementation details to the client. Those details include: - stack traces - SQL queries - file paths Return generic error messages in production; detailed errors only when `DEBUG` is enabled. - **TLS:** Services never terminate TLS directly. They are always deployed behind a TLS-terminating reverse proxy. The service itself listens on plain HTTP. However, HSTS headers and `Secure` cookie flags must still be set by the application so that the browser enforces HTTPS end-to-end. Apply defense-in-depth: if a standard security hardening measure exists for HTTP services and is not listed here, it is still expected. When in doubt, harden. # Database migrations Database migrations live in `internal/db/migrations/` and must be embedded in the binary. - `000_migration.sql` — contains ONLY the creation of the migrations tracking table itself. Nothing else. - `001_schema.sql` — the full application schema. - **Pre-1.0.0:** never add additional migration files (002, 003, etc.). There is no installed base to migrate. Edit `001_schema.sql` directly. - **Post-1.0.0:** add new numbered migration files for each schema change. Never edit existing migrations after release. # README `README.md` is the primary documentation. Required sections: - **Description**: First line must include: - the project name - purpose - category (web server, SPA, CLI tool, etc.) - license - author Example: "µPaaS is an MIT-licensed Go web application by @sneak that receives git-frontend webhooks and deploys applications via Docker in realtime." - **Getting Started**: Copy-pasteable install/usage code block. - **Entrypoints**: Opens by stating that the repo adheres to the [Scripts to Rule Them All](https://github.com/github/scripts-to-rule-them-all) standard (with that link), then documents each provided `script/` entrypoint and its purpose. - **Rationale**: Why does this exist? - **Design**: How is the program structured? - **TODO**: Update meticulously, even between commits. When planning, put the todo list in the README so a new agent can pick up where the last one left off. - **License**: MIT, GPL, or WTFPL. Ask the user for new projects. Include a `LICENSE` file in the repo root. - **Author**: [@sneak](https://sneak.berlin). # Repository layout Avoid putting files in the repo root unless necessary. Root should contain only project-level config files: - `README.md` - `AGENTS.md` - `Makefile` - `Dockerfile` - `LICENSE` - `.gitignore` - `.editorconfig` - `REPO_POLICIES.md` - language-specific config Everything else goes in a subdirectory. Canonical subdirectory names: - `bin/` — executable scripts and tools - `cmd/` — Go command entrypoints; thin only: one `main.go` per binary whose body is a single call into `internal/` or `pkg/`, no project logic in `cmd/` - `configs/` — configuration templates and examples - `deploy/` — deployment manifests (k8s, compose, terraform) - `docs/` — documentation and markdown (README.md stays in root) - `internal/` — Go internal packages - `internal/db/migrations/` — database migrations - `pkg/` — Go library packages - `share/` — systemd units, data files - `static/` — static assets (images, fonts, etc.) - `web/` — web frontend source Guidance for coding agents lives in one `AGENTS.md` at the repository root. It is never committed under a file or directory named after one agent tool, such as `CLAUDE.md` or `.claude/`, and never split into separate memory files. New repos must contain at minimum: - `README.md`, `.git`, `.gitignore`, `.editorconfig` - `LICENSE`, `REPO_POLICIES.md` (copy from the `prompts` repo) - `Makefile` - `script/` entrypoints (`bootstrap`, `setup`, `projectname`, `test`, `lint`, `fmt`, `fmt-check`, `check`, `docker`, `cibuild`, `precommit`, `install-precommit`, `update-policy`) - `Dockerfile`, `.dockerignore` - `.gitea/workflows/check.yml` - Go: `go.mod`, `go.sum`, `.golangci.yml` - JS: `package.json`, `yarn.lock`, `.yarnrc.yml`, `.yarn/releases/`, `.gitattributes`, `.prettierrc`, `.prettierignore` - Python: `pyproject.toml` When setting up a new repo, files from the `prompts` repo may be used as templates. Fetch them from `https://git.eeqj.de/sneak/prompts/raw/branch/main/`. First commit of a new repo should contain only `README.md`. # Other conventions - Write all dates as YYYY-MM-DD (ISO 8601). - Cross-project documentation (such as this file) must include `last_modified: YYYY-MM-DD` in the YAML front matter so it can be kept in sync with the authoritative source as policies evolve. - Use SemVer. - Go module root: `sneak.berlin/go/`. Always run `go mod tidy` before committing. - Simple projects should be configured with environment variables.