deploy: ${VAR} interpolation resolves .kamal/secrets relative to deploy.yml's directory (config/.kamal/secrets), not the project root

[bpamiri]

Summary

ConfigLoader builds its SecretResolver with projectRoot: getDirectoryFromPath(arguments.path) (cli/lucli/services/deploy/config/ConfigLoader.cfc:55). For the standard layout (config/deploy.yml), ${VAR} tokens are resolved against config/.kamal/secrets — a file nothing creates — instead of the project-root .kamal/secrets that wheels deploy init scaffolds and that every other deploy code path (DeploySecretsCli, registry login via new SecretResolver() defaulting to expandPath("./")) uses.

Repro (wheels 4.0.3 and develop)

printf 'APP_NAME=fromsecrets\n' > .kamal/secrets
printf 'service: ${APP_NAME}\nimage: x/y\nservers:\n  - 192.0.2.10\n' > config/deploy.yml
wheels deploy config        # SERVICE: ''   ← secrets leg never fired
mkdir -p config/.kamal && cp .kamal/secrets config/.kamal/secrets
wheels deploy config        # SERVICE resolves  ← from the wrong location

Process-env fallback works (APP_NAME=fromenv wheels deploy config → fromenv), which masks the bug until someone relies on the documented lookup order — config-reference.mdx, architecture.mdx, and migrating-from-kamal.mdx all document .kamal/secrets as step 2 of the interpolation chain.

Root cause

ConfigLoader.cfc:55 derives the secrets root from the YAML file's own directory instead of the project root.

Proposed direction

Resolve the secrets root as the parent of the config directory when the config path ends in config/deploy.yml — or better, accept an explicit projectRoot from the verb layer (Module.cfc knows the CWD) instead of deriving it from the YAML path.

Acceptance

• Root-level .kamal/secrets feeds ${VAR} interpolation for the standard config/deploy.yml layout (spec asserting $resolveVar sees it).
• The DeploySecretsCli / registry-login resolution and the interpolation resolution agree on one root.

Reported by the guide-behavioral-audit P1 batch 2 (work item p1-16-deploy, claim arch-04; wheels CLI 4.0.3 + develop source).

[wheels-bot]

Wheels Bot — Triage

Classified as bug.

The report describes observable wrong behavior with a clear what-happened/what-expected: ${VAR} interpolation for the standard config/deploy.yml layout resolves against config/.kamal/secrets (a file nothing creates) instead of the project-root .kamal/secrets that wheels deploy init scaffolds and every other deploy code path uses. It includes a concrete repro and pins the root cause to a specific line.

Suspected layer

cli — see .ai/wheels/deploy.md for the deploy subsystem (Kamal port under cli/lucli/services/deploy/).

Fix sketch

cli/lucli/services/deploy/config/ConfigLoader.cfc:55 derives the SecretResolver projectRoot from getDirectoryFromPath(arguments.path) — i.e. the YAML file's own directory — so for config/deploy.yml it looks one level too deep. The fix changes how the secrets root is computed: either special-case the config/deploy.yml layout to use the parent of the config directory, or (cleaner) accept an explicit projectRoot passed down from the verb layer in Module.cfc, which knows the CWD. The change must keep the interpolation root in agreement with the DeploySecretsCli / registry-login resolution (new SecretResolver() defaulting to expandPath("./")). Likely a one-to-two-file change in ConfigLoader.cfc (and possibly its caller).

Confidence: medium

Auto-downgrade fired: the fix touches the deploy subsystem (cli/lucli/services/deploy/**), and there is a real design choice between path-heuristic vs. explicit-projectRoot threading — so capped at medium even though the report itself is high-quality.

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