Consolidate product version onto Cargo.toml and stage the VSIX during packaging

[logbie]

Deferred slice of the approved repository hygiene design (Engineering/designs/2026-07-28-repository-hygiene-design.md §"Single sources of truth" and §"Packaging"). The hygiene migration declared these as transitional [[generated]] exceptions in .repo-hygiene.toml, with the checker's version-drift rule keeping every mirror in agreement until this lands.

Remaining work (R3 under testing.md — needs Windows packaging evidence):

• Runtime version via env!("CARGO_PKG_VERSION"); retire the hand-maintained src/version.rs constant.
• Retire .build_meta.json; nightly.yml/ci.yml/versioning.yml read the version from Cargo.toml instead of src/version.rs/.build_meta.json.
• Retire root wix.toml after characterization tests prove the effective cargo-wix inputs; move still-required settings into Cargo.toml metadata or wix/main.wxs, preserving UpgradeCode and component identities.
• Generate the VSIX during packaging, stage it at target/package/windows/vscode-wfl.vsix, update scripts/install_vscode_extension.ps1 and WiX consumers atomically, then delete the tracked vscode-extension/vscode-wfl-0.1.0.vsix and drop its exceptions from .repo-hygiene.toml.
• Verify MSI ProductVersion, release filenames, the WFL CLI, and the embedded VSIX all carry the canonical version; record the independently versioned bundled wfl-lsp and prove the extension's compatibility range accepts it.

Evidence per testing.md §15: clean install, optional-extension install, upgrade, uninstall, PATH/config behavior, and artifact-version checks on Windows.

[logbie]

Triaged against current main (4178714a, v26.8.2). Verdict: valid, still entirely outstanding, correctly classified R3. Every artefact this issue proposes to retire is present and unchanged:

• src/version.rs (44 bytes — the hand-maintained constant)
• .build_meta.json ({"year": 26, "month": 8, "build": 2})
• wix.toml at the root
• vscode-extension/vscode-wfl-0.1.0.vsix, still tracked

and .repo-hygiene.toml still carries all four as transitional exceptions naming this issue as the follow-up ([[generated]] records at lines 145 and 154, the .vsix suffix exception at line 70, plus the line 131 entry). So the checker's version-drift rule is doing its job and nothing has quietly rotted — Cargo.toml reads 26.8.2 and .build_meta.json agrees.

One observation that raises the priority slightly above "someday": the tracked VSIX is still pinned at 0.1.0 while the product is at 26.8.2, and the nightly MSI embeds that stale-versioned extension. That mismatch has been a carry-forward annoyance for a while, and the VSIX-staging bullet here is the thing that actually resolves it rather than papering over it.

A sequencing suggestion, since the four bullets are not equally coupled. The env!("CARGO_PKG_VERSION") + .build_meta.json retirement is the low-risk half — it is Linux-verifiable, touches nightly.yml/ci.yml/versioning.yml, and needs no Windows packaging evidence beyond confirming the workflows still read a version. The wix.toml retirement and VSIX staging are the R3 half that genuinely needs the full clean-install / upgrade / uninstall matrix on Windows and the UpgradeCode-and-component-identity characterization. Splitting this issue along that seam would let the first half land now and leave a smaller, honestly-scoped R3 remainder — right now the R3 label on the whole thing is what keeps it parked.

Worth noting the CI dependency: any change to how nightly.yml reads the version has to be validated by an actual nightly run, and the nightly is currently blocked on the Actions-allowlist outage in #695. Not a blocker for starting, but it gates the evidence.

Suggested labels: enhancement, build, packaging, tech-debt.

Posted by the WFL repo warden (automated triage pass).

[logbie]

Adding a finding from today's automated pass that lands squarely on this issue's "release filenames" bullet, because it turns the version-only naming from a tidiness problem into an operational one.

publish_spaces.sh publishes three immutable keys, and only one of them is scoped by commit:

#	key	scoped by
1	releases/wfl-<version>-linux-x86_64-<short-sha>.tar.gz	version and sha
2	releases/wfl-<version>.msi	version only
3	releases/vscode-wfl-<version>.vsix	version only

publish_immutable() (scripts/publish_spaces.sh L151-173) no-ops when the bytes are byte-identical and hard-aborts — refusing to overwrite … already published with different bytes — when they differ. So the advertised repair path, re-running a nightly to fix a half-landed publish, only works if every artifact rebuilds byte-identically from the same commit.

That is exactly what killed the 2026-08-19 workflow_dispatch nightly (run 32235610626, sha 36de4fa7, v26.8.8): it aborted on key #1 because the tarball's bytes differed from the already-published copy of the same commit.

Two consequences worth recording here:

1. fix(ci): package the Linux tarball reproducibly so a nightly can be re-run #718 fixes key Configure Mend Bolt for GitHub #1 only. It pins SOURCE_DATE_EPOCH from git show -s --format=%ct HEAD and normalises the tar (--sort=name --mtime=@EPOCH --owner=0 --group=0 --numeric-owner). Nothing analogous exists for the MSI (cargo wix, nightly.yml L378-382 — a Windows Installer database embeds a fresh package-code GUID and build timestamps per build) or the VSIX (vsce package, L284 — a zip recording checkout mtimes). After fix(ci): package the Linux tarball reproducibly so a nightly can be re-run #718 merges, a same-commit re-run gets past the tarball and aborts at the MSI key instead. fix(ci): package the Linux tarball reproducibly so a nightly can be re-run #718 is still strictly progress — key Configure Mend Bolt for GitHub #1 is the one Linux users pin — but its "so a nightly can be re-run" promise is not yet true end-to-end.

2. Version-only keys collide across commits. Any two builds sharing a version number contend for keys feat: Add lexer and parser implementation #2 and docs: update README with project overview #3 regardless of which commit produced them. This is the same trap as the nightly-2026-07-27 release, which shipped a wfl-26.7.52.msi built from a different sha than the earlier 26.7.52.

A third option this issue is well placed to take, alongside "make the MSI/VSIX reproducible" and "relax the immutability guard to warn-and-skip on a same-sha re-run": give the MSI and VSIX immutable keys the same -<short-sha> suffix the tarball already has. publish_spaces.sh already receives both SHORT_SHA ($3) and COMMIT_SHA ($4), and the rolling pointers (releases/wfl-latest-windows-x86_64.msi, releases/SHA256SUMS, status.json) are written separately in Phase 2 — so installers that fetch wfl-latest-* are unaffected. That sidesteps binary determinism entirely rather than trying to make cargo wix and vsce reproducible, which is a much larger fight.

I have not changed anything; this is analysis only, verified by reading main @36de4fa7 and branch warden/reproducible-linux-tarball plus the run logs. No local build was possible in this environment (no cargo/Windows toolchain), so the MSI/VSIX non-determinism is argued from the tools' documented behaviour, not from a reproduced diff.

Posted by the WFL repo warden (automated triage pass).