wheels-cli-lucli 4.x module not published — blocks 4.0.1-SNAPSHOT install

[orcpac7]

Summary

Unable to use scoop, I've attempted to install the Wheels LUCLI and Wheels manually.

The Wheels 4.0.1-SNAPSHOT installation docs at https://guides.wheels.dev/v4-0-1-snapshot/start-here/installing/ direct users to install the LuCLI wheels module using:

lucli modules install wheels@be

However, LuCLI 0.3.7 (current release) does not recognise the @be tag and returns:

modules install currently requires --url=<url> or a known repository entry for 'wheels@be'.

Steps to Reproduce

1. Install LuCLI 0.3.7 on Windows following https://lucli.dev/docs/installation/installation/
2. Run lucli modules install wheels@be as directed by the 4.0.1-SNAPSHOT docs
3. Observe the error above

Investigation

Falling back to lucli modules install wheels installs version 3.1.0 from the registry, which causes a TemplateException at Module.cfc:1510 when running lucli wheels new hello.

Inspecting module.json in the installed module revealed the correct source repo is wheels-dev/wheels-cli-lucli. Attempting to install directly from that repo:

lucli modules install wheels --url=https://github.com/wheels-dev/wheels-cli-lucli/archive/refs/heads/main.zip --force

...installs successfully but still results in version 3.1.0, because wheels-cli-lucli has only a single commit on main and has not yet been synced from the cli/lucli/ directory on the develop branch of wheels-dev/wheels.

Expected Behaviour

• lucli modules install wheels@be should resolve and install the 4.x version of the wheels LuCLI module, OR
• The wheels-cli-lucli repo should be synced from develop so that installing via --url gets the correct 4.x module

Actual Behaviour

No path currently exists for a user to install the 4.x wheels LuCLI module as directed by the 4.0.1-SNAPSHOT docs.

Environment

• OS: Windows
• LuCLI: 0.3.7 (Lucee 7.0.4.18-SNAPSHOT)
• Java: OpenJDK 21.0.2
• wheels-cli-lucli installed version: 3.1.0

Suggested Fix

Either sync wheels-cli-lucli from develop so it reflects the 4.x module, or register wheels@be in the LuCLI module registry pointing to the correct source. The docs should also be updated to reflect whichever install path actually works.

[wheels-bot]

Wheels Bot — Triage

Classified as bug.

Suspected layer

cli — see .ai/wheels/cli/ for canonical patterns, plus cli/lucli/module.json and .github/workflows/ for the CLI release surface.

Fix sketch

This is a release/distribution defect, not a code defect in cli/lucli/Module.cfc. The CLI source lives at cli/lucli/ in this repo, but LuCLI installs it from the standalone wheels-dev/wheels-cli-lucli repo (per cli/lucli/module.json's repository field), which currently has a single stale commit at v3.1.0. Two converging gaps:

1. No sync pipeline. There is no GitHub Actions workflow that mirrors cli/lucli/** from wheels-dev/wheels develop to wheels-dev/wheels-cli-lucli. The 4.x CLI source exists here but never gets published. Likely fix: a new .github/workflows/sync-cli-lucli.yml that pushes cli/lucli/ contents to the standalone repo (and/or tags releases).
2. @be tag unknown to LuCLI registry. lucli modules install wheels@be requires the LuCLI module registry to recognize the be (bleeding-edge) tag for the wheels module. That registry is external to this repo. Either the tag needs registering with the LuCLI project, or the install docs at web/sites/guides/src/content/docs/v4-0-1-snapshot/start-here/installing.mdx (or equivalent) need updating to direct users to a working command (--url=... against a real published release).

A single-PR fix in this repo can plausibly land #1 (the sync workflow) and update docs to a working install command; #2 requires coordination outside this repo.

Confidence: low

Fix spans release infrastructure (CI workflow), external systems (LuCLI registry), and docs across multiple repos — the right path isn't obvious from the issue body alone, and an auto-generated PR is unlikely to land a coherent end-to-end fix.

<!-- wheels-bot:triage:2758 -->
<!-- wheels-bot:triage-class:bug -->

[bpamiri]

@orcpac7 I was actually working on this as you posted this. I'm trying to wrap up 4.0.1 for some of the bugs that cropped up last week after launch. But I'm trying to fix the linux apt/yum repositories as well as the scoop install fixed. I'll update this issue as soon as I have that working.

[bpamiri]

Investigated this thread alongside two additional reports of the same install path — internal report from a colleague and wheels-dev/scoop-wheels#2 (Zain). The "lucli modules install wheels@be" symptom you hit was actually downstream of a different breakage in the recommended Scoop install path. Root cause writeup:

Three converging bugs

1. Stable Scoop manifest never got the post-GA sha512 hashes. wheels-dev/scoop-wheels/bucket/wheels.json shipped pre-GA with zero-filled placeholders, intended to be populated by Scoop's autoupdate after the first GA tag. The bucket has no .github/workflows/ and isn't registered with Excavator, so the zeros persisted six days post-GA. Every scoop install wheels from a fresh shell failed with Hash check failed!. Fix: wheels-dev/scoop-wheels#3 (real hashes pulled from the .sha512 sidecars on the v4.0.0 release).
2. Release workflow emits the wrong sidecar filename for non-module artifacts. Even with autoupdate wired up, it would 404 on wheels-core-X.X.X.zip.sha512 because the workflow emits wheels-core-X.X.X.sha512 (no .zip. segment). wheels-module was correct; the other four artifacts weren't. Fix: #2761 makes all five artifacts emit the consistent .zip.sha512 / .zip.md5 shape.
3. Install docs missed scoop bucket add java. Scoop's depends: java/openjdk21 declaration does not auto-add the dependency bucket, so first-time installers hit Couldn't find manifest for 'openjdk21' from 'java' bucket before even reaching the hash check. Both real-user reports confirmed this step. Fix: #2761 updates the Windows install steps in installing.mdx and command-line-tools/installation.mdx for both v4-0-0 and v4-0-1-snapshot doc trees.

About your specific report

The lucli modules install wheels@be command isn't actually documented anywhere in this repo or on guides.wheels.dev — it's an inferred path from how Wheels' channel naming works on Scoop/Homebrew. The fundamentals here:

• The LuCLI bundled registry has no @be tag concept — it's a flat name-to-URL map.
• The bare wheels entry currently points at the wheels-cli-lucli mirror, which hasn't been synced from develop since 2026-04-04 (still at v3.1.0).
• The release wheels-module-X.X.X.zip artifact is correctly shaped for direct LuCLI install via --url=.

#2761 adds a new "Advanced: existing LuCLI install" section in the CLI installation docs documenting the lucli modules install wheels --force --url=… path with an Aside enumerating what you give up vs. the Scoop/Homebrew/.deb/.rpm paths.

Once both PRs merge, the working Windows install is

scoop bucket add java
scoop bucket add wheels https://github.com/wheels-dev/scoop-wheels
scoop install wheels      # stable
# OR
scoop install wheels-be   # bleeding-edge — works today, hashes were already correct

The wheels-be channel works today (real hashes already in wheels-be.json), so if you want to validate on your Windows box right now, that path is unblocked. Sorry for the friction — these were three real bugs stacked on top of each other and the failure modes pointed at each other.

Open follow-ups

• Decide whether to register scoop-wheels with Excavator (community autoupdate, set-and-forget) or self-host a cron workflow in the bucket. Either prevents this from recurring on 4.0.1+.
• Coordinate with the LuCLI maintainer on whether the bundled registry entry for wheels should point at wheels-dev/wheels directly (so bare lucli modules install wheels lands current code) or stay on wheels-cli-lucli with a sync workflow.

[bpamiri]

End-to-end validated from a fresh Windows shell — the full campaign is now closed out.

Working install sequence (today)

```powershell
Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser
Invoke-RestMethod -Uri https://get.scoop.sh | Invoke-Expression
scoop install git
scoop bucket add wheels https://github.com/wheels-dev/scoop-wheels
scoop install wheels
wheels --version
```

Verified on ARM64 Windows. `wheels --version` reports cleanly. The OpenJDK is bundled in the manifest, so no `scoop bucket add java` or `JAVA_HOME` setup needed.

What got fixed across the campaign

1. Stable Scoop manifest had zero-filled hash placeholders post-GA — fixed in scoop-wheels#3 (immediate) and scoop-wheels#4 (systemic).
2. Release workflow emitted inconsistent `.sha512` sidecar filenames — `wheels-module` was `.zip.sha512` but the other four artifacts were just `.sha512`. Scoop's autoupdate substitution would have 404'd on the non-module hashes. Fixed in #2761.
3. No autoupdate workflow in the Scoop bucket — added a self-hosted `autoupdate.yml` chained to upstream `release.yml` via `repository_dispatch` (scoop-wheels#4). End-to-end latency from upstream tag to user-installable manifest is now ~5-7 min, with a daily cron fallback at 08:30 UTC.
4. `scoop install wheels` required pre-adding the `java` bucket — fixed by inlining OpenJDK 21 directly in the Scoop manifest (scoop-wheels#4).
5. Scoop's `auto-pr.ps1` hard-requires `hub` (not `gh`) even in `-Push` mode — fixed in scoop-wheels#5.
6. Docs lacked the `scoop install git` prerequisite (Scoop's installer doesn't ship git, but `scoop bucket add` needs it to clone the bucket repo) — fixed in #2762 and #2763.
7. `lucli modules install wheels@be` referenced an invented tag — replaced with a documented `lucli modules install wheels --force --url=…` flow in the "Advanced: existing LuCLI install" section (#2761).
8. Chocolatey path retired — chocolatey-wheels archived with a deprecation README pointing at Scoop. Dispatch chain in upstream `release.yml` updated to fire at `scoop-wheels` instead.

Going forward

Future releases auto-publish to the Scoop bucket. The bucket's autoupdate workflow handles hash refresh; you'll just run `scoop update wheels` or `scoop update wheels-be` on your machine. Standalone LuCLI users have a documented `--url=` path for installing the module directly.

Thanks for the original report — three real-user breakages chained into this one issue and the campaign that followed cleaned up a lot of latent infrastructure debt. Closing.