v0.1.0 is a movable tag in an unprotected repo, and four repos pin it

[mairas]

Found independently by the adversarial and security reviewers on hatlabs/halpi2#49, and reproduced by both.

Four repositories now pin halos-docs-tools @ git+https://github.com/halos-org/docs-tools@v0.1.0. That names an ordinary annotated tag in a repository with no branch protection and no rulesets (gh api repos/halos-org/docs-tools/rulesets → []), so nothing stops the tag being force-moved or deleted. By contrast halos-org/shared-workflows already carries a "Protect main branch" ruleset with enforce_admins.

uv sync --locked holds — reproduced on a cold cache with a git package tagged v0.1.0 at commit A, the tag then force-moved to commit B: --locked still installed A. The lock is doing that work, not the tag.

Two ways it stops holding:

• Re-resolution. uv lock --upgrade, a pin bump, or a dependency bot re-reads the tag and adopts whatever it points at. Reproduced: the lock changed to ?rev=v0.1.0#<commit B> — same rev string, different content, no other diff. The entire visible evidence of a checker behaviour change is 40 hex characters in a lock fragment, and these checkers decide whether merges are allowed in four repositories.
• Deletion. If the tag goes and the commit is orphaned, uv sync --locked fails in all four consumers at once, plus every developer clone.

Fix: add a tag-protection ruleset covering v* — block deletion and non-fast-forward — matching what shared-workflows has on its default branch. Then re-cut v0.1.1 for any fix rather than moving v0.1.0, and say so next to the release instructions in AGENTS.md.

Optionally also name the commit in each consumer's pyproject.toml (...docs-tools@7f09d05...) so the reviewed artifact and the lock agree without depending on tag discipline. The tag then serves as documentation.

Related: #14 covers the other half of the version story — the shared workflow floats on @main while the CLI it calls is pinned, and neither side records which versions are compatible.

[mairas]

Tag protection is in place: a Protect release tags ruleset over refs/tags/v*, active, blocking deletion and non_fast_forward, with no bypass actors.

Verified rather than assumed — git push --delete origin v0.2.0 is rejected:

 ! [remote rejected] v0.2.0 (push declined due to repository rule violations)

That closes both routes this issue described. A tag can no longer be force-moved, so uv lock --upgrade cannot silently adopt different code under an unchanged rev string; and it cannot be deleted, so uv sync --locked cannot break in every consumer at once.

Fixes go out as a new tag. v0.2.0 is released and is what the four adoption pull requests will pin.

Commit-pinning in pyproject.toml stays available if the tag ever proves not to be enough, but with the ruleset it buys little and costs readability.