Daevix has no stable release yet. Three pre-release tags exist
(`v0.0.1-rc1` through `v0.0.1-rc3`), and the first stable tag is pending.

## How a release is cut

A release is a git tag that starts with `v`. Pushing such a tag triggers the
release workflow in `.tangled/workflows/build.yaml`. That workflow also runs on
manual dispatch. Nothing else in CI ships an artifact: the lint workflow only
lints, and the release workflow proves a property. It publishes nothing.

The canonical distributable is what a user gets from `go install`:

```sh
go install go.daevix.com/daevix/cmd/dvx@<tag>
```

There is no separate release pipeline that produces a different binary. The
release workflow verifies the bytes of that exact command.

## The reproducible build workflow

On a `v*` tag push, the release workflow installs the tagged module twice,
into two independent module caches and install roots, and compares the two
SHA-256 digests. A mismatch fails the run. The workflow pins each input that
could change the bytes:

- The exact Go toolchain, parsed from the `toolchain` line in `go.mod`
  (currently `go1.27.1`). `GOTOOLCHAIN=auto` would let a newer runner Go
  change the bytes.
- `CGO_ENABLED=0`, `GOOS=linux`, `GOARCH=amd64`, so the host C toolchain and
  target never leak in.
- `-trimpath`, so the build path does not leak in. Two install roots show that the
  build does not depend on the path.

The release workflow prints the digest and the binary's self-reported version,
then
discards the binaries. The binary self-reports the tag with no linker flags:
`internal/version` reads Go's build info. A plain `go build` of a working tree
reports `(devel)` and can never match the tagged install.

You can verify a published digest yourself with the same toolchain and target:

```sh
export GOTOOLCHAIN=go1.27.1 CGO_ENABLED=0 GOOS=linux GOARCH=amd64
GOBIN="$PWD/out" go install -trimpath \
  go.daevix.com/daevix/cmd/dvx@<tag>
sha256sum out/dvx
```

Compare the output against the digest in the release notes. The full
explanation, including why each source of non-determinism is pinned the way it
is, is in
`docs/reproducible-builds.md` in the repository.

## Container images and deploys

There is no automated deploy. Container images are built locally with
`make image`, which passes the `git describe` version, commit, and date into
the image as build arguments. Loading that image into a development cluster is
separate (`make kind-load`). No CI workflow pushes images or deploys to any
environment.

## Where the docs site version comes from

The version in the site footer is never hard-coded. The layout reads
`site.Params.version`, which Hugo receives as the environment variable
`HUGO_PARAMS_VERSION`. The Makefile target `gen-site-scripts` sets that
variable from `git describe --tags --abbrev=0` and regenerates the two hero
Script SVG partials with the same tag as their seed and message. The target
`check-site-scripts` verifies that the committed SVGs still decode to the
tag-sourced message. A local `hugo` build with no `HUGO_PARAMS_VERSION` set
falls back to the branch label in the footer.