## Release

Say **"Release"** (or "Release X.Y.Z") and the `release` skill runs it: commit, push, tag,
wait for the pipeline, then open the wrapper-chart PR against `Ryuvia/charts`. It stops
there — merging and the Flux reconcile stay manual, deliberately.

Preconditions and the plan, without side effects:

```sh
~/.claude/skills/release/scripts/release-preflight          # state + suggested version
~/.claude/skills/release/scripts/release-preflight vX.Y.Z   # validate that release
```

Config is `.release.conf` here plus `make release-vars`. The process itself lives in
`~/.claude/skills/release/`; why it is shaped this way is in README.md §Releasing.

Two things about this repo specifically:

- **The pipeline has no image scan.** `.gitea/workflows/release.yaml` runs `test`,
  `binaries`, `image` and `chart`. A green release run is not evidence the image is
  CVE-clean, and a release note must not imply it is.
- **The wrapper chart has two `tag:` lines** — the app image and the python backup sidecar —
  so `chart-bump` needs `--image "$IMAGE"` to know which one moves.

## Checks

`make fmt lint test helm-lint` **is** what the pipeline runs — `ci.yaml` and `release.yaml`
call these targets rather than restating them, the way riksdata and rd-web do. A green gate
here and a green pipeline are the same code, not two descriptions of it. `test` adds `-race`,
which the workflows do not have to ask for since they call the target; see the comment on it
for why.

`make release` (build + push the multi-arch image, package + push the chart) is what
`release.yaml` invokes. Do not run it by hand — it refuses `VERSION=dev` for that reason, and
publishing happens by pushing a tag.