Wheels CLI commands on Windows result in Lucee error

[teleotic]

Describe the bug
Using the Wheels CLI on Windows results in a Lucee error for most commands. Running wheels new or wheels start give the following error:

PS C:\Users\tim\Projects> wheels new hello
[ERROR] Error: lucee.runtime.exp.NativeException: there is no Resource provider available with the name [c], available resource providers are [ftp, zip, tar, tgz, http, https, ram, s3]

To Reproduce
Steps to reproduce the behavior:

1. Install wheels on Windows through scoop, per website directions.
2. Run wheels new hello to create new project
3. See error

Expected behavior
The wheels command should run successfully. In the case of wheels new hello, a new wheels project with the name hello should be generated.

Desktop (please complete the following information):

• OS: Windows 11
• Version: Windows 11 Pro 25H2

Additional context
Error appears in Powershell, Git Bash, and Command Prompt. Closed and re-opened Powershell in case the environment variables needed to be updated. Rebooted Windows. No change.

wheels --version runs correctly, giving "Wheels Version: 4.0.2 (stable)" and displaying the Wheels ASCII art.

[wheels-bot]

Wheels Bot — Triage

Classified as bug.

Suspected layer

cli — see cli/lucli/ (no .ai/wheels/cli/ doc exists; ground reasoning in cli/lucli/Module.cfc and the LuCLI runtime). The error there is no Resource provider available with the name [c] is Lucee's Resource-API error when a path beginning with C:\... is interpreted as a URI whose scheme is c. Lucee's registered providers are [ftp, zip, tar, tgz, http, https, ram, s3] — none of which is a Windows drive letter — so the first colon in the CWD is being treated as a scheme separator.

Fix sketch

The CLI bootstrap is passing a Windows path through a Lucee Resource API (e.g. getCanonicalPath() against a raw string, fileExists() on an un-normalized path, or a directoryExists() call where the argument hasn't been routed through expandPath() / java.io.File). The fix likely lives in cli/lucli/Module.cfc around the early CWD / variables.projectRoot resolution (see Module.cfc:31 getDirectoryFromPath(getCurrentTemplatePath()) and Module.cfc:5011 java.io.File canonical-CWD logic — the latter is the right pattern, the former area is suspect on Windows). Normalize any path that may originate from Windows (forward-slash-conversion, or wrap through java.io.File(path).getCanonicalPath() before handing to Lucee Resource calls). Reproduction will require a Windows host or Wine — propose-fix should call this out.

Confidence: medium

Report is clear and reproducible on the user's side, but the fix is environment-specific (Windows-only) and the suspect code paths span CLI startup; the right correction may need a Windows reproduction before landing.

<!-- wheels-bot:triage:2841 -->
<!-- wheels-bot:triage-class:bug -->
<!-- wheels-bot:triage-confidence:medium -->

[wheels-bot]

Wheels Bot — Fix proposed

Draft PR: #2843

Spec: cli/lucli/tests/specs/services/HelpersSpec.cfc — five new normalizePath() cases under a regression-tagged describe() block (failing → passing).

Implementation:

• cli/lucli/services/Helpers.cfc — new public normalizePath() helper.
• cli/lucli/Module.cfc — bootstrap-safe $normalizePath() applied to variables.cwd, variables.moduleRoot, every interim candidate in resolveProjectRoot(), the fallback return value, and the targetDir in scaffoldNewApp().

bash tools/test-cli-local.sh is the canonical CLI test runner per CLAUDE.md, but the bot sandbox didn't permit invoking it. The failing-then-passing transition was verified by spec construction and a manual trace; CI will exercise both suites on every engine and database.

A human review is required before merge. Reviewer A and Reviewer B will weigh in shortly. Doc updates (MDX guides, .ai/wheels/, CLAUDE.md) are handled separately by bot-update-docs.yml.

[teleotic]

My apologies. This issue is already addressed in pull request #2835. I didn't see anything relevant in the Issues tab before posting.