[Bug] v0.8.0 tag ships autocomplete-types.ts stamped 0.7.0

[gtchax]

Description

The v0.8.0 tag's artifacts/autocomplete-types.ts is stamped as version 0.7.0, even though the file carries the full 0.8.0 method set (including the keymap_put / keymap_lookup verbs added in #23). Only main has the artifact correctly stamped.

This makes the tag actively misleading: anything resolving artifacts/autocomplete-types.ts at v0.8.0 gets a file that behaves as 0.8.0 but reports itself as 0.7.0.

Evidence

At the v0.8.0 tag (ada2251):

$ git show v0.8.0:artifacts/autocomplete-types.ts | grep -nE 'Generated from version|SDK_VERSION'
3:// Generated from version 0.7.0
52:export const SDK_VERSION = "0.7.0";

...yet the same file contains the 0.8.0 verbs:

$ git show v0.8.0:artifacts/autocomplete-types.ts | grep -n 'label: "keymap_put"'
736:    label: "keymap_put",

On main (ea13b0d) the stamp is correct:

$ git show main:artifacts/autocomplete-types.ts | grep -nE 'Generated from version|SDK_VERSION'
3:// Generated from version 0.8.0
52:export const SDK_VERSION = "0.8.0";

pyproject.toml is correct at the tag (version = "0.8.0") — only the generated artifact is stale.

Root cause

.github/workflows/generate-autocomplete.yml regenerates the artifact and pushes it as a follow-up commit to main. The release tag is cut at the Bump version to 0.8.0 commit (ada2251), and the regeneration commit (ea13b0d, 🤖 Auto-generate autocomplete types [skip ci]) lands on main after the tag already exists:

ea13b0d  🤖 Auto-generate autocomplete types [skip ci]   <-- main only, correct stamp
ada2251  Bump version to 0.8.0                           <-- v0.8.0 tag points here, stale stamp

Because tags are immutable refs, the corrected artifact can never reach v0.8.0. The workflow's release: [published] trigger doesn't rescue this either — it regenerates from a detached tag checkout and pushes to the branch, so the tag object still never moves.

Note this is a race, not a guaranteed off-by-one: v0.7.0 happens to be self-consistent (artifact and pyproject.toml both read 0.7.0). It goes wrong whenever the version bump and the artifact regeneration land in separate commits with the tag cut between them.

Impact

Blocks pinning the runtime autocomplete-types.ts fetch to a tagged version. That pin was deferred in automators-com/loop#2825 for exactly this reason — the file is currently sourced from main instead, since pinning to v0.8.0 would fetch a misleadingly-labeled artifact.

Suggested fix

Make the version stamp correct at tag time rather than repairing it afterwards. Options, roughly in order of preference:

1. Generate before tagging — have the version-bump step regenerate the artifact and commit both in a single commit, so the tag lands on an already-correct tree. Removes the race entirely.
2. Verify in CI — add a release-time check that fails if SDK_VERSION in the artifact doesn't match pyproject.toml's version. Catches drift instead of shipping it.
3. Derive rather than bake — have the artifact read its version from a single source of truth so there's nothing to keep in sync.

Retagging v0.8.0 would fix this instance, but it's a published release — worth deciding separately whether to move the tag or let 0.8.0 stand and fix forward from 0.9.0.