SSH config (ssh.user, ssh.port) from `deploy.yml` not propagated to `SshPool`

[zainforbjs]

Describe the bug
Every deploy CLI class creates new SshPool() with no arguments, causing the pool to use hardcoded defaults (user: root, port: 22, no private key). The ssh: block values from deploy.yml (e.g., ssh.user: admin) are loaded by ConfigLoader but never passed to the SshPool. The pool always connects as root@host regardless of the config.

To Reproduce
Steps to reproduce the behavior:

1. Create config/deploy.yml with:

ssh:
  user: admin
servers:
  web:
    - 192.168.1.1

2. Run wheels deploy --dry-run — note no model@ prefix on commands
3. The deploy attempts SSH as root@192.168.1.1 and fails if root key auth isn't set up

Expected behavior
The ssh.user and ssh.port values from deploy.yml should be propagated to the SshPool so connections use the configured user. The admin@host workaround in the servers list should not be necessary.

Desktop:

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

[wheels-bot]

Wheels Bot — Triage

Classified as bug.

Suspected layer

cli — see .ai/wheels/cli/ for CLI conventions. The defect is in the wheels deploy subsystem under cli/lucli/services/deploy/.

Fix sketch

The report is accurate against current develop. Every new SshPool() instantiation in cli/lucli/Module.cfc passes no arguments (9 call sites: lines 1753, 1791, 1814, 1835, 1852, 1873, 1897, 1917, 1934), so the pool falls back to its hardcoded init() defaults (user: "root", port: 22, no privateKey). Meanwhile cli/lucli/services/deploy/config/Ssh.cfc already exposes user(), port(), keysOnly(), etc., parsed from the ssh: block in deploy.yml by ConfigLoader — those values just never reach the pool.

The fix shape is mechanical: in Module.cfc::deploy(), load the deploy config once (the call sites already need to do this for other reasons), then build an sshDefaults struct from cfg.ssh() (mapping user, port, and the privateKey path that Ssh.cfc should resolve from keys / keys_only) and pass it to every new SshPool(sshDefaults) call. A small helper like $buildSshPool(cfg) would dedupe the nine sites. Add a unit spec under cli/lucli/tests/specs/deploy/lib/ that constructs SshPool from a Config fixture and asserts the resolved $defaults reflect the YAML.

Confidence: medium

The fix shape is mechanical and the call sites are easy to find, but the deploy subsystem is in the auto-downgrade list and the privateKey mapping needs to honor Kamal-compatible YAML keys (ssh.keys is an array in Kamal; pick a deterministic resolution).

<!-- wheels-bot:triage:2672 -->
<!-- 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, including SshPool instantiation in cli/lucli/Module.cfc and the Ssh.cfc config surface) and the bot's safety net requires a human in the loop before any code is written.

The triage comment already flags this: the privateKey resolution needs to honour Kamal-compatible ssh.keys semantics (which is an array in Kamal), and the nine new SshPool() call sites in Module.cfc interact with SshPool / FakeSshPool test parity. Both are easy to get subtly wrong in ways that only surface against a real sshd.