fix(release): bump to 0.4.0, and make the tag and the version agree

[dmarx]

0.4.0 is not on PyPI — the publish failed. pip install luria==0.4.0 reports available versions 0.1.0, 0.1.1, 0.1.2, 0.2.0, 0.3.0.

What happened

The 0.4.0 tag points at f61282e (the #92 merge), whose pyproject.toml still says version = "0.3.0". So python -m build produced luria-0.3.0-py3-none-any.whl, and PyPI rejected it:

400 File already exists ('luria-0.3.0-py3-none-any.whl', with blake2_256 hash 'ec35b7…')

after the GitHub release was already published. Both existing gates passed on the way through: twine check dist/* validates metadata, not identity, and the cold-install smoke test exercises luria init/index/new/lint on a wheel that installs perfectly well — it's simply the wrong version.

Why it's a DP-5 instance

The version lives in two places — pyproject.toml and the git tag — with nothing making them agree. That is the hand-maintained projection DP-5 says will drift, and it drifted on the first release after the pattern was set. Nicely, it's the same principle #710 downstream was just annotated with.

Rung 2 is what this PR does — guard the property rather than trust the copy:

- name: The built version is the released version
  if: github.event_name == 'release'
  env:
    TAG: ${{ github.event.release.tag_name }}
  run: |
    built=$(ls dist/*.whl | head -1 | sed -E 's/.*luria-([^-]+)-py3.*/\1/')
    if [ "$built" != "${TAG#v}" ]; then … exit 1; fi

It runs in build, so it fails before the publish job and its environment gate are reached.

Rung 1 would be better — derive the version from the tag with hatch-vcs, so there is only one source. Deliberately not bundled here: the publish checkout is actions/checkout@v4 at the default fetch-depth: 1 with no tags fetched, so switching without also setting fetch-depth: 0 would resolve to a 0.1.dev… version and fail the release a second time. Worth its own PR.

Verified

Fired the guard against all three cases before trusting it (DP-6):

dist	tag	result
luria-0.3.0-…whl	0.4.0	exit 1 — the real failure
luria-0.4.0-…whl	0.4.0	pass
luria-0.4.0-…whl	v0.4.0	pass

421 tests pass; luria lint clean.

To actually ship 0.4.0

The 0.4.0 tag points at a commit without the bump, so re-running the failed workflow rebuilds the same 0.3.0 wheel. After merging, either delete the 0.4.0 tag and release and re-cut them at the new main (safe — nothing was ever published under it), or cut 0.4.1 if you'd rather never move a tag. Your call; I haven't touched the tag.

---

Generated by Claude Code