[falbany]

Implements docs/superpowers/specs/2026-11-05-hatch-vcs-versioning-design.md (plan: docs/superpowers/plans/2026-11-05-hatch-vcs-versioning.md).

What

The git tag becomes the single source of truth for the version. pyproject.toml no longer carries version — hatch-vcs derives a PEP 440 version from git describe at build time and generates src/profiles/_version.py.

• git tag v0.12.0 && git push origin v0.12.0 is the only release act — no version-bump edit
• Non-tag builds report lineage versions (0.11.0rc3.dev87+g<hash>, +dirty when the tree is dirty)
• The release.yml guard shrinks to the SemVer-format check (the tag↔pyproject comparison is tautological now)
• All build checkouts (release.yml ×3, build-windows.yml ×1) use fetch-depth: 0 — a shallow checkout would silently build a fallback version

Resolution order in _resolve_version()

profiles._version (generated, regenerated on every build/install) → importlib.metadata (legacy installs without the module) → "0.0.0-dev" (git-less source trees).

Note: this inverts the spec's original 'metadata stays primary' wording, ruled during implementation — the full suite caught dist-info staleness after a mid-session uv build (dist-info updates only at install time; the generated module never goes stale relative to the tree). Metadata fallback is retained and tested.

Release note

The next release tag must be pushed manually as before — nothing else to edit. PyPI publishing (if ever) needs local-scheme = "no-local-version" first.

Verification

• uv build --wheel → profiles_app-0.11.0rc3.dev87+gb82465d25...whl, wheel contains profiles/_version.py
• ruff / pylint 9.88 / pyright 0 errors / pytest 1507 passed, 1 skipped, cov 88.95%