Deploy commands report successful execution even when no deployment action actually occurs

[zainforbjs]

Describe the bug
Several wheels deploy commands currently report successful execution even when no actual deployment action occurs on the target server(s).
This creates a misleading UX where commands appear successful despite:

• no container being started
• no deployment verification is occurring
• no remote execution confirmation
• no validation that the requested action actually completed
  Example:

wheels deploy setup

returns

Deployed testapp version unknown to 1 host(s)

Even though no image exists on Docker Hub, no GitHub repo.
Example 2:

wheels deploy remove --confirm

returns:

Removed testapp and its containers from 1 host(s)

even though no application container actually exists on the remote server.

To Reproduce
Steps to reproduce the behavior:

1. Run:

wheels deploy setup

2. Observe success output:
   Deployed testapp version unknown to 1 host(s)
3. Verify remote server/container state.
4. Observe that:

• No container is running
• No deployment actually completed
• command still reported success

Expected behavior
Deploy commands should provide accurate execution status and validation.
Only report success when:

• remote command executed successfully
• container/process exists and is running
• deployment state is verified

If deployment fails, or no container is started:

✗ Failed to start the application on host(s)
Reason: container failed to start

or:

No deployment action completed.

Actual behavior
Commands currently report optimistic success messages without validating the actual deployment state.
This appears to affect multiple deploy commands, not only:

wheels deploy setup

But likely the broader deploy command suite.

Impact

• Misleading deployment feedback
• Difficult debugging during deployment setup
• False-positive success states in CI/CD pipelines
• Users may assume applications are running when they are not
• Poor operational UX during infrastructure management

Desktop:

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

[wheels-bot]

Wheels Bot — Triage

Classified as bug.

Suspected layer

cli — deploy subsystem under cli/lucli/services/deploy/. See CLAUDE.md § "Deploy Quick Reference" for the architecture; .ai/wheels/cli/ for general CLI conventions.

Fix sketch

The success strings are unconditional. Every CLI verb in cli/lucli/services/deploy/cli/Deploy*Cli.cfc builds a command string, hands it to a private $dispatch(hosts, cmd, dryRun) helper, then returns $renderResult(opts, "Deployed ... to N host(s)") regardless of what actually ran on the remote. $dispatch itself calls variables.sshPool.onEach(hosts, function(ssh, host) { ssh.run(c); }) (e.g. DeployAppCli.cfc:143, DeployMainCli.cfc $dispatch), and SshClient.run() returns {stdout, stderr, exitCode, durationMs} — but the callback throws the struct away. SshPool.onEach only rethrows on Java-level failures (auth/connect), not on nonzero exit codes, so "container failed to start" is invisible to the caller.

Likely change shape: thread a per-host result aggregator through $dispatch (or have the callback collect {host, exitCode, stderr} into a shared struct), check exitCode \!= 0, and have $renderResult distinguish full success / partial failure / total failure with the affected hosts named. setup / deploy / remove orchestrators in DeployMainCli.cfc (deploy() around line 115, remove() around line 285) need to short-circuit or aggregate when any underlying step fails. Tests in cli/lucli/tests/specs/deploy/ exercising FakeSshPool will need a way to inject non-zero exit codes; the fake currently records calls but doesn't simulate exit codes.

Confidence: medium

Auto-downgrade rule fired — deploy subsystem is on the sensitive-area list, so triage caps confidence at medium. The fix shape is clear but spans several Cli/Pool files and has design trade-offs (when is a nonzero exit code expected and ignorable, e.g. docker rm of a missing container vs. a real failure?); propose-fix should think through those before committing.

<!-- wheels-bot:triage:2696 -->
<!-- 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.