`wheels deploy secrets` fetch invokes LuCLI global secrets command instead of Wheels deploy subcommand

[zainforbjs]

Describe the bug
Running wheels deploy secrets fetch does not execute a Wheels deploy command.
Instead, the command falls through to LuCLI's built-in secrets command and displays the generic LuCLI secrets help output.

To Reproduce
Steps to reproduce the behavior:

1. Create a Wheels application
2. Run:

wheels deploy secrets fetch

3. Observe the output

Actual behavior
The command resolves to LuCLI's global secrets command:

Usage: secrets [-hV] [COMMAND]
Manage secrets for LuCLI projects

instead of executing a Wheels deploy workflow.

Full output:
testapp % wheels deploy secrets fetch

Usage: secrets [-hV] [COMMAND]
Manage secrets for LuCLI projects
  -h, --help      Show this help message and exit.
  -V, --version   Print version information and exit.
Commands:
  init      Initialize the local encrypted secret store
  set       Set or update a secret value
  list      List stored secrets (names and metadata only)
  rm        Remove a stored secret
  get       Retrieve a secret value
  provider  Manage secret providers

Expected behavior
wheels deploy secrets fetch should execute the intended Wheels deploy secrets workflow.
Example:

wheels deploy secrets fetch
Fetching deploy secrets...

Screenshots

Desktop (please complete the following information):

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

[wheels-bot]

Wheels Bot — Triage

Classified as bug.

The report cleanly describes a "what happened / what I expected" mismatch:

The command resolves to LuCLI's global secrets command... instead of executing a Wheels deploy workflow.

Suspected layer

cli — see .ai/wheels/cli/ for canonical patterns.

Fix sketch

This is the same picocli command-shadowing pattern already documented in CLAUDE.md for wheels deploy server (tracked as #2677): LuCLI registers secrets as a top-level subcommand (init / set / list / rm / get / provider), so picocli grabs the secrets token before it can reach the deploy dispatcher in cli/lucli/Module.cfc::deploy(). The case "secrets": branch at cli/lucli/Module.cfc:1966 is therefore unreachable from the CLI even though it works for MCP / programmatic callers. The likely fix mirrors the server/bootstrap/exec workaround: expose flat aliases (e.g. wheels deploy fetch-secrets, wheels deploy extract-secrets, wheels deploy print-secrets) in cli/lucli/Module.cfc, delegating to cli/lucli/services/deploy/cli/DeploySecretsCli.cfc. The nested secrets <verb> branch should stay for MCP/programmatic callers.

Confidence: medium

The bug surface and fix shape are clear and there is direct prior art, but the deploy subsystem auto-downgrade rule caps this at medium.

<!-- wheels-bot:triage:2697 -->
<!-- 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 wheels deploy dispatcher in cli/lucli/Module.cfc) and the bot's safety net requires a human in the loop before any code is written.

The triage's fix sketch mirrors the prior wheels deploy bootstrap/exec flat-alias workaround (#2677, merged in b720ad5) and the --release alias workaround (#2674, merged in 41a846f) for picocli command-shadowing. A human can pattern-match on those PRs to author the equivalent wheels deploy fetch-secrets / extract-secrets / print-secrets aliases, or pick different verb names if the secrets surface warrants a different shape.