`wheels deploy server bootstrap` is interpreted as LuCLI server command instead of deploy subcommand

[zainforbjs]

Describe the bug
The documentation describes the command wheels deploy server bootstrap as the way to bootstrap Docker on deployment hosts.

However, running the command does not execute any deploy/bootstrap logic. Instead, the CLI falls through to the LuCLI server command help output.

Documentation URL:
Deployment -> first-deploy -> #walk-through -> Part 5

To Reproduce
Steps to reproduce the behavior:

1. Create a new Wheels application:

wheels new myapp

2. Run:

wheels deploy server bootstrap

3. Observe output.

Expected behavior

• Runs:

  which docker || curl -fsSL https://get.docker.com | sh
  

• Executes on remote hosts
• Safe/idempotent
• Validates SSH/sudo access

Actual behavior

• Instead of executing deployment bootstrap logic, the CLI displays the LuCLI server help output:

Usage: server [-hV] [COMMAND]
Manage Lucee server instances

followed by the standard LuCLI server command list.

• No deployment/bootstrap action occurs.

Scrneeshot

Desktop:

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

[wheels-bot]

Wheels Bot — Triage

Classified as bug.

The reporter shows a concrete reproduction (wheels new myapp → wheels deploy server bootstrap) and a clear expected-vs-actual: instead of running the deploy server bootstrap verb (which should drive which docker || curl -fsSL https://get.docker.com | sh on remote hosts per CLAUDE.md § Deploy Quick Reference), the CLI prints LuCLI's top-level server help (Usage: server [-hV] [COMMAND] — Manage Lucee server instances). That's the lifecycle command for Lucee server instances (wheels start/stop/status), not anything in the deploy port.

Suspected layer

cli — see .ai/wheels/cli/ for canonical patterns (the directory isn't materialized yet; deploy CLI source lives at cli/lucli/services/deploy/cli/).

Fix sketch

The deploy subcommand dispatcher isn't routing wheels deploy server <verb> to cli/lucli/services/deploy/cli/DeployServerCli.cfc; the server token is being consumed by LuCLI's top-level server command (the Lucee instance lifecycle one) instead of staying inside the deploy namespace. Likely change is in cli/lucli/services/deploy/cli/DeployMainCli.cfc (and/or wherever LuCLI registers subcommand groups for deploy) to make sure deploy's child command table includes server and that the parser doesn't fall through to the global command tree when a deploy group claims a same-named child. Worth checking whether other namespace-colliding deploy subcommands (e.g. build, which also exists as a LuCLI verb) route correctly — if they do, diff their wiring against server. Verb table for deploy server per CLAUDE.md: exec, bootstrap.

Confidence: medium

The report and layer are unambiguous, but the deploy subsystem is on the auto-downgrade list (deploy port is sensitive), so confidence is capped at medium.

<!-- wheels-bot:triage:2677 -->
<!-- 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 correctly identified the root cause (wheels deploy server <verb> falling through to LuCLI's top-level server command instead of routing to DeployServerCli.cfc), and the fix is plausibly a small change to the deploy subcommand dispatcher. But because the deploy port is in the auto-downgrade list — and because the wrong fix here could silently break other wheels deploy <verb> namespaces that may collide with global LuCLI verbs (build, secrets, etc.) — the bot is standing down.

Suggested next steps for a human:

1. Reproduce locally: wheels deploy server bootstrap should hit DeployServerCli.cfc::bootstrap(); instead it falls through to the Lucee instance lifecycle server command.
2. Diff how wheels deploy build <verb> routes vs wheels deploy server <verb> in the LuCLI subcommand registration. The triage's hypothesis is that deploy's child command table isn't claiming server exclusively.
3. Once a fix is in hand, also audit the other deploy verbs flagged in CLAUDE.md § Deploy Quick Reference for the same name-collision class of bug.