`wheels deploy init` fails in newly generated app due to missing deploy template path

[zainforbjs]

Describe the bug
Running wheels deploy init inside a freshly generated Wheels application fails with:

[ERROR] Error: lucee.runtime.exp.ExpressionException: file or directory
[/Users/mac/Desktop/wwwroot/installer/myapp/cli/lucli/templates/deploy/init/deploy.yml.mustache]
does not exist

The command appears to look for deployment templates inside the generated application directory myapp/cli/lucli/templates/deploy/init/ but those template files do not exist in a newly scaffolded application.

To Reproduce
Steps to reproduce the behavior:

1. Create a new application:

wheels new myapp

2. Enter the project directory:

cd myapp

3. Run:

wheels deploy init

4. Observe the error.

Expected behavior
wheels deploy init should:

• successfully generate deployment configuration files
• resolve templates from the CLI installation/bundled templates
• or include the required deploy templates in the generated app

Actual behavior
The command fails because it attempts to resolve cli/lucli/templates/deploy/init/deploy.yml.mustache from inside the application directory, where the path does not exist.

Desktop

• OS: macOS
• CLI: Wheels 4.0.0 (development)

[wheels-bot]

Wheels Bot — Triage

Classified as bug.

Suspected layer

cli — see .ai/wheels/cli/ for canonical patterns. The affected code lives in the deploy subsystem under cli/lucli/services/deploy/.

Fix sketch

The error originates at cli/lucli/services/deploy/cli/DeployMainCli.cfc:333, which resolves the init templates with:

var tplDir = expandPath("/cli/lucli/templates/deploy/init");

expandPath() resolves against the running application's mapping root, so inside a freshly generated user app it produces <app>/cli/lucli/templates/deploy/init/ — a path that doesn't exist in user projects. The templates ship inside the CLI install at cli/lucli/templates/deploy/init/{deploy.yml.mustache,secrets.mustache}, which is the right physical location; what's wrong is the path resolution. The fix should resolve the template directory relative to the CLI installation root (the same anchor other CLI generators use to find their templates/ directory), not via expandPath() from the user app's mapping. Likely a one-file change in DeployMainCli.cfc (and a quick audit of any other expandPath("/cli/lucli/templates/...") usage in the deploy services for the same bug).

Confidence: medium

Fix shape is mechanical and one-file, but the auto-downgrade rule for the deploy subsystem caps this at medium; propose-fix's safety net will decide whether to open a draft PR or hold for human review.

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

[wheels-bot]

Wheels Bot — Fix on hold for human review

The proposed fix touches a sensitive area (cli/lucli/services/deploy/**) and the bot's safety net requires a human in the loop before any code is written.

The triage comment correctly identifies the root cause at cli/lucli/services/deploy/cli/DeployMainCli.cfc:333 — expandPath("/cli/lucli/templates/deploy/init") resolves against the user app's mapping root instead of the CLI install root. A human reviewer should choose the right anchor (CLI install root vs. a per-command template lookup helper) and audit other expandPath("/cli/lucli/templates/...") call sites in the deploy services for the same bug.