wheels deploy init should generate a default `Dockerfile`

[zainforbjs]

Describe the bug
wheels deploy init scaffolds config/deploy.yml and .kamal/secrets, but does not generate a Dockerfile. Without one, wheels deploy immediately fail at the build stage because there's no ./Dockerfile to build from. New users following the init → setup workflow hit a confusing dead end.

To Reproduce
Steps to reproduce the behavior:

1. Run Command

wheels deploy init

2. Observe the output.

Expected behavior
Add a Dockerfile.mustache template to cli/lucli/templates/deploy/init/ that scaffolds a production-appropriate Dockerfile for Wheels apps.

Desktop:

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

Additional context
The old 3.x wheels docker init command (cli/src/commands/wheels/docker/init.cfc) does generate a Dockerfile. The new LuCLI 4.0.0 deploy init doesn't.

[wheels-bot]

Wheels Bot — Triage

Classified as bug.

The report quotes concrete, observable wrong behavior ("wheels deploy init scaffolds config/deploy.yml and .kamal/secrets, but does not generate a Dockerfile") with a clear repro (run wheels deploy init) and an explicit expectation ("Add a Dockerfile.mustache template to cli/lucli/templates/deploy/init/"). Verified locally: cli/lucli/templates/deploy/init/ contains only deploy.yml.mustache and secrets.mustache.

Suspected layer

cli — see .ai/wheels/cli/ for canonical patterns. The deploy subsystem entry point is cli/lucli/services/deploy/cli/DeployMainCli.cfc::init_stub() (around lines 313–350), with templates under cli/lucli/templates/deploy/init/.

Fix sketch

Add a Dockerfile.mustache (and likely a .dockerignore.mustache) under cli/lucli/templates/deploy/init/, modeled on the production-appropriate Dockerfile emitted by the 3.x cli/src/commands/wheels/docker/init.cfc. Then extend DeployMainCli.cfc::init_stub() to render and write ./Dockerfile (and .dockerignore) alongside config/deploy.yml and .kamal/secrets, honoring the existing --force semantics and updating the success message + next-steps output. Docs under docs/src/working-with-wheels/deployment/first-deploy.* and docs/src/command-line-tools/commands/deploy/ should be checked for any references that need a matching update.

Confidence: medium

Fix shape is mechanical and one-layer, but the auto-downgrade rule for the deploy subsystem caps confidence at medium — the scaffolded Dockerfile shapes user production builds, so the template needs review for sensible defaults (base image, Java/CFML runtime, port, build args, multi-stage layout) rather than being treated as a pure CLI plumbing change.

<!-- wheels-bot:triage:2673 -->
<!-- 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/** — the wheels deploy subsystem) and the bot's safety net requires a human in the loop before any code is written.

Specifically, the triage proposes adding a Dockerfile.mustache template under cli/lucli/templates/deploy/init/ and wiring it through DeployMainCli.cfc::init_stub(). The scaffolded Dockerfile will shape every new user's production build (base image, Java/CFML runtime, port, build args, multi-stage layout), so the defaults deserve a human design pass rather than a mechanical port from the 3.x cli/src/commands/wheels/docker/init.cfc.