fix(cli): close 0.0.0-dev version display gap on installed Wheels apps

[bpamiri]

Summary

Two compounding bugs caused the dev toolbar / /wheels/info to report Wheels Version: 0.0.0-dev on installed (brew/chocolatey) apps even though every release artifact already carries the precise SNAPSHOT build version. Both are fixed here. Closes #2326.

Bug 1 — wheels-module tarball never substitutes module.json

release.yml's Build Wheels Module Tarball step tars cli/lucli/ directly with no version substitution, while wheels-core / wheels-base (which run through prepare-*.sh) get @build.version@ properly replaced. As a result every wheels-module-*.tar.gz on the GitHub releases page ships with module.json carrying the hardcoded "version": "4.0.0" — even though the tag itself is v4.0.0-SNAPSHOT+1625. Verified against the published 1624 and 1625 tarballs.

That hardcoded value is then read by BaseModule.version() at runtime and fed into FrameworkInstaller.rewriteVersionPlaceholder as the cliVersion fallback (added in #2343 / #2333), so on installs whose vendor/wheels/box.json went through that fallback path, the framework version is the imprecise 4.0.0 instead of 4.0.0-SNAPSHOT+1625.

Fix: change cli/lucli/module.json to use "version": "@build.version@" (matching every other manifest in the repo), and add the same find + sed substitution every other build step already does, in the Build Wheels Module Tarball step before tar/zip. Uses an env: block to satisfy the workflow-injection lint and avoid inlining the version into shell commands.

Bug 2 — runtime fallback only recognizes the monorepo's box.json

When vendor/wheels/box.json's @build.version@ leaks through scaffold-time substitution (user's CLI is pre-#2343, or any other gap in the install pipeline), Global.cfc:$readFrameworkVersion's fallback walks two levels up looking for the wheels-dev/wheels monorepo's box.json — and only synthesizes <rootversion>-dev when slug=="wheels" or name=="Wheels.fw". An installed app's app-root box.json comes from wheels-base-template (slug=wheels-base-template), which carries the precise framework SNAPSHOT version stamped at release time — but the fallback rejects it because the monorepo signal is absent. Fall-through returns the bare 0.0.0-dev sentinel.

Fix: extend the fallback so when the monorepo signal is missing and the parent's box.json self-identifies as wheels-base-template (slug or name match), use its version verbatim — no -dev suffix, since that version is the actual installed framework version, not an upcoming dev build. The monorepo signal still wins when both could match; both signals are ignored if their version is itself the unreplaced placeholder.

Source identified	Returned version
Real box.json version	<box.version>
Placeholder + monorepo (Wheels.fw)	<rootversion>-dev
Placeholder + base template (wheels-base-template)	<rootversion> (verbatim)
Placeholder + neither signal	0.0.0-dev (sentinel, unchanged)

Test plan

• Framework suite — bash tools/test-local.sh → 3333 passed (no regressions). Three new specs in frameworkVersionSpec.cfc:
  • uses wheels-base-template's version verbatim when the framework's own box.json placeholder slipped through (#2326)
  • ignores wheels-base-template when its own version is also the unreplaced placeholder (#2326)
  • prefers the monorepo signal over the base-template signal when both could match (#2326)
• CLI suite — bash tools/test-cli-local.sh → 452 pass, 3 fail. Three failures are pre-existing DoctorSpec issues (#2260), unrelated to this PR.
• Release.yml dry-run — copied cli/lucli/ to a tmpdir and ran the same find + sed locally with MODULE_VERSION=4.0.0-SNAPSHOT+9999. module.json picks up the version; no false positives in any other file.
• Reviewer: when this lands and a new release is cut, verify wheels-module-*.tar.gz on the GitHub release page contains the precise SNAPSHOT version in module.json — that's the proof the build pipeline is fixed.

🤖 Generated with Claude Code